क्या Claude Code routines मेरी वित्तीय स्थिति पर नज़र रख सकती हैं?

 (driggsby.com)
1 पॉइंट द्वारा GN⁺ 4 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Plaid-इंटीग्रेटेड वित्तीय डेटा को MCP tools से जोड़कर बैलेंस, ट्रांज़ैक्शन, निवेश और लोन की जानकारी संभाली जा सकती है, और बार-बार होने वाली वित्तीय जाँच को Claude Code routines से ऑटोमेट किया जा सकता है
  • पहले का cron-आधारित ब्राउज़र ऑटोमेशन rendering समस्याओं, 2FA prompts, कुछ खातों का ही इकट्ठा होना, ईमेल फ़ॉर्मैट बदल जाना, और passkey सीमाओं की वजह से बार-बार टूट जाता था; इसे कम करने के लिए Driggsby बनाया गया
  • दैनिक वित्तीय सारांश ईमेल सिर्फ़ prompt, execution time और Driggsby custom connector से बनाया गया, और क्योंकि Gmail connector सिर्फ़ draft बना सकता था, इसलिए असली sending और format stability के लिए email_me() tool जोड़ा गया
  • इसी तरीके से पिछले 7 दिनों के Amex transactions anomaly detection और checking account में $500 से अधिक के बड़े outflow की निगरानी भी ऑटोमेट की गई, और सब सामान्य होने पर कोई alert न भेजने के लिए सेट किया गया
  • setup और debugging का बोझ कम होने से spouse-दर-spouse personalized financial routines अलग से चलाना भी संभव हुआ, और यह निवेश, subscription और spending monitoring तक तेज़ी से बढ़ने वाला automation base बन गया

ऑटोमेशन की शुरुआत और Driggsby की संरचना

  • पहले यह एक दैनिक cron job से शुरू हुआ था, जिसमें Codex CLI और Chrome DevTools MCP को non-interactive मोड में चलाकर बैंक, कार्ड, ब्रोकरेज और रिटायरमेंट खातों में लॉग-इन किया जाता था, बैलेंस और हाल के ट्रांज़ैक्शन निकाले जाते थे, और दंपति को दैनिक वित्तीय overview ईमेल भेजा जाता था
    • पहले दिन यह काफ़ी अच्छा चला, लेकिन अगले ही दिन फिर टूट जाना बार-बार होने लगा
    • browser rendering issues, अनपेक्षित 2FA prompts, execution के दौरान गड़बड़ी से कुछ ही खाते आने की समस्या, ईमेल फ़ॉर्मैट का मनमाने ढंग से बदलना, और सिर्फ़ passkey स्वीकार करने वाले खाते जुड़ने जैसी दिक्कतें एक साथ आ गईं
  • इस अस्थिरता को कम करने के लिए Driggsby बनाया गया, और दो महीनों में 75k lines के Rust code और Plaid contract के बाद यह अपने मौजूदा रूप तक पहुँचा
  • Driggsby, Plaid के ज़रिए वित्तीय खातों से जुड़ने के बाद, MCP के माध्यम से बैलेंस, ट्रांज़ैक्शन, निवेश जानकारी और लोन जानकारी आदि को अलग-अलग tools के रूप में expose करता है
  • शुरुआत में ज़रूरत पड़ने पर Claude खोलकर वित्तीय सवाल पूछे जाते थे और Driggsby से जवाब लिए जाते थे; समय के साथ net worth देखना, बैलेंस-ट्रांज़ैक्शन जाँचना, और निवेश मॉनिटरिंग जैसे दोहराए जाने वाले सवालों के पैटर्न साफ़ दिखने लगे

Routines ने क्या बदला

  • कुछ दिन पहले जारी हुई Claude Code routines ने ऐसे दोहराए जाने वाले सवालों को autopilot पर देना आसान बना दिया
  • cloud में चलने वाला agent loop अपने-आप में नया नहीं है, लेकिन routines की सबसे खास बात यह है कि इसका setup बहुत सरल है
    • अलग agent loop code लिखने या deploy location तय करने की ज़रूरत नहीं है
    • OpenClaw, Codex SDK, या Hetzner पर claude -p जैसे execution environments भी खुद खड़े नहीं करने पड़ते
  • सिर्फ़ prompt लिखकर, data और tools को MCP connector से साफ़-सुथरे तरीके से जोड़कर तुरंत automation बनाया जा सकता है

दैनिक ईमेल ऑटोमेशन

  • पुराने spreadsheet का विकल्प

    • दोबारा जिस समस्या पर काम शुरू किया गया, वह दैनिक ईमेल थी, और लक्ष्य था ऐसा साफ़-सुथरा summary mail पाना जिसमें सारे खाते और net worth एक नज़र में दिख जाएँ
    • यह जानकारी लंबे समय से Google Drive में कहीं पड़े एक पुराने spreadsheet में थी, और उसे अपडेट करने में लगभग 15 मिनट ही लगते थे, लेकिन इतना-सा friction भी काफ़ी था कि उसे नियमित रूप से अपडेट नहीं किया जाता था
    • असल अपडेट cycle ज़्यादा से ज़्यादा हर 6 महीने में एक बार तक सीमित रह गई थी

  • routine setup प्रक्रिया

    • prompt दर्ज करना, हर सुबह execution time schedule करना, Driggsby custom connector जोड़ना, और save करना — बस इतना करते ही setup पूरा हो गया
    • लेकिन शुरुआत में ईमेल भेजने का तरीका ही नहीं था, इसलिए काम वहीं अटक गया

  • Gmail connector की सीमा और वैकल्पिक tool

    • Gmail connector जोड़ने पर जानकारी से भरा, अच्छा दिखने वाला ईमेल बन गया, लेकिन वह inbox में जाने के बजाय सिर्फ़ draft के रूप में बनता था
    • Gmail connector ईमेल भेज नहीं सकता था और सिर्फ़ draft creation कर सकता था, इसलिए कोई दूसरा तरीका चाहिए था
    • Claude connector store देखने के बाद भी कोई आसान sending option नहीं मिला, इसलिए Driggsby में email_me() नाम का एक साधारण MCP tool जोड़ दिया गया

  • email_me() की सीमाएँ और फ़ॉर्मैट स्थिरता

    • email_me() में recipient को account owner के verified email address तक सीमित किया गया, और links व images को ब्लॉक करके इसे सुरक्षा के लिहाज़ से स्वीकार्य स्तर पर रखा गया
    • हर execution में फ़ॉर्मैट डगमगाने की समस्या कम करने के लिए ईमेल body को Markdown अनिवार्य बनाया गया, और Markdown-rendered ईमेल के लिए CSS भी जोड़ी गई

  • debugging और अंतिम परिणाम

    • कुछ छोटे bugs routines के execution flow को आसानी से देख पाने की वजह से जल्दी ठीक हो गए
    • UI, Claude Desktop या web app में दिखने वाले सामान्य Claude Code session जैसा ही है, इसलिए चल रही routine की जाँच करना आसान है
    • कुछ test runs के बाद सुबह 7:47 का ईमेल सचमुच पहुँचा, और दैनिक ईमेल की समस्या हल हो गई
    • उसके बाद ईमेल content बदलने के लिए code बदलने की ज़रूरत नहीं रही; routines UI में prompt संपादित करना ही काफ़ी था

  • दंपति के लिए अलग customization

    • spouse को भी अपने prompt से संपादित की जा सकने वाली अलग personal daily email मिल गई
    • दोनों के लिए महत्वपूर्ण चीज़ें अलग थीं, इसलिए अब हर व्यक्ति अपनी पसंद की दैनिक जानकारी अलग से सेट कर सकता था

दैनिक ईमेल के बाद विस्तार

  • पिछले 7 दिनों के कार्ड ट्रांज़ैक्शनों में anomaly detection

    • दैनिक ईमेल स्थिर हो जाने के बाद ध्यान इस पर गया कि infrastructure का अतिरिक्त बोझ बढ़ाए बिना और कौन-से नए agents चलाए जा सकते हैं
    • क्योंकि transaction data पहले से Driggsby में मौजूद था, अगला automation Amex credit card transaction anomaly detection बना
    • एक साप्ताहिक execution routine बनाई गई और नीचे वाला prompt डालकर उसे कॉन्फ़िगर किया गया
    • मूल उदाहरण prompt
      • पिछले 1 साल के Amex credit card transactions लाओ
      • उनमें से सिर्फ़ पिछले 7 दिनों के transactions अलग निकालकर उसी अवधि पर ध्यान से समीक्षा करो
      • अगर पिछले patterns की तुलना में last 7 days में double charge, subscription fee change, या अजीब merchant name/description जैसी कोई अप्रत्याशित चीज़ मिले, तो ईमेल भेजो
      • अगर सारे transactions सामान्य हों और पिछले patterns से मेल खाते हों, तो कोई alert न भेजो
    • इतना simple prompt false positives पैदा कर सकता है, लेकिन समय के साथ इसे refine करना आसान है और results review करने की लागत भी कम है

  • checking account के बड़े outflow की निगरानी

    • इसके बाद checking account से अप्रत्याशित बड़े fund outflow की जाँच करने के लिए एक routine बनाई गई
    • prompt को नीचे दी गई शर्तों के साथ बनाया गया
    • मूल उदाहरण prompt
      • checking account transactions की समीक्षा करो, और पिछले 12 महीनों के transaction data से तुलना करके देखो कि पिछले 1 दिन में कोई बड़ा outflow हुआ है या नहीं जो historical pattern से मेल नहीं खाता
      • $500 से अधिक के transactions पर ध्यान दो
      • क्योंकि यह automation रोज़ चलती है, इसलिए इसे सख़्ती से सिर्फ़ पिछले 1 दिन के transactions की समीक्षा तक सीमित रखा गया
      • अगर कोई matching item मिले, तो subject "Checking account outflow alert" वाला ईमेल भेजो; नहीं मिले तो कोई सूचना मत भेजो

  • आगे विस्तार की गुंजाइश

    • समय के साथ यह flow investments, subscription analysis, और अलग-अलग spending categories की निगरानी तक फैल गया
    • routines से setup करना लगभग ज़रूरत से ज़्यादा आसान होने के कारण, आगे चलकर कई conditions को एक साथ जोड़ने या prompts को और अधिक परिष्कृत करने की ज़रूरत बढ़ेगी

यह क्यों महत्वपूर्ण है

  • routines की सबसे बड़ी ताकत यह है कि तुरंत आज़माई जा सकने वाली automation लगभग बिना किसी मेहनत के तैयार हो जाती है
  • जैसे ही कोई prompt सूझता है, उसे automation में बदल देने तक का entry barrier बहुत कम हो जाता है
  • CPA spouse भी Driggsby से real time में लाई गई data के आधार पर cloud में अपनी automation खुद चला रही है
  • इससे रुझान उन tools की ओर जाता है जिनसे लोग अपना data जोड़कर आसानी से अपनी automation बना सकें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 일 전
Hacker News की राय

  • मैंने हाल ही में इसे खुद इसी तरह सेटअप किया था। https://tiller.com/ से checking/credit card transactions को Google Sheets में sync किया, और GitHub Actions से उस spreadsheet को एक मुफ्त Supabase DB में mirror किया
    फिर Supabase MCP या psql के जरिए Claude/Codex को उन transaction records और balances तक English queries से access दिया, और subscription patterns या unusual patterns खोजने की इसकी क्षमता काफ़ी प्रभावशाली लगी। खासकर cash flow forecasting भी अच्छा था, जो online tools अक्सर ठीक से नहीं कर पाते; जैसे मैं पूछ सकता था कि monthly spending patterns और available cash के आधार पर कितनी रकम savings में transfer की जा सकती है
    automatic classification के मामले में Claude ने custom DSL को भी काफ़ी अच्छे से handle किया। मैंने payee/category normalization के लिए markdown table ruleset बनवाया, और वे rules भी GitHub Actions में साथ चल रहे हैं

    • मुझे जानना है कि Tiller bank transaction data कैसे लाता है
      क्या यह Plaid जैसी किसी सेवा के जरिए data pull करता है, या अब भी web banking credentials देने पड़ते हैं, और 2FA को कैसे handle किया जाता है
      जिन financial institutions के पास official API नहीं है, क्या वहाँ अब भी screen scraping पर निर्भर रहना पड़ता है? और अगर किसी bug की वजह से अनचाहे clicks, consent, या यहाँ तक कि गलत transfer हो जाए तो क्या होगा? वे इसे read-only कहते हैं, लेकिन personal banking में सचमुच read-only secondary account support करने वाले banks मैंने लगभग नहीं देखे
      यह भी जानना चाहता हूँ कि बड़े पैमाने पर financial नुकसान होने पर compensation के लिए कोई insurance या guarantee है या नहीं, और अपना पूरा banking data दो कंपनियों को दिखाने के privacy implications भी चिंता पैदा करते हैं। मैंने class-action lawsuits के बारे में भी सुना है कि data को गलत तरीके से बेचा या share किया गया, लेकिन असल में क्या हुआ था यह नहीं जानता
      bank terms में password को third party के साथ share न करने की सहमति वाली clauses भी परेशान करती हैं। web/cloud service को अपनी finances सौंपना मुझे सहज नहीं लगता; local में चलने वाला और bank API से बात करने वाला client software बेहतर लगेगा। यह भी जानना चाहता हूँ कि Canada में ऐसा कुछ है या नहीं
      open banking आने की बात तो है, लेकिन यह साफ़ नहीं कि क्या individual द्वारा बनाए गए software से भी access मिलेगा। अगर यह सचमुच भरोसेमंद हो, और download के बाद internal retention को न्यूनतम रखने वाली policies enforce की जाएँ, तो मैं भी bank API इस्तेमाल करना चाहूँगा
    • मैं भी Tiller के पक्ष में हूँ
      Mint के Intuit द्वारा acquisition के बाद से मैं Tiller इस्तेमाल कर रहा हूँ और मेरा setup भी मिलता-जुलता है। बस मैंने local qwen model और OAuth से बनाई गई API key के साथ sheets access जोड़ा है; Claude Routine वाला तरीका शायद कहीं ज़्यादा आसान होता
    • यह सच में शानदार है। क्या इसे open source करने का कोई प्लान है
      पूरा setup कैसे किया गया, और खास तौर पर कौन-से prompts इस्तेमाल हुए, यह देखना चाहूँगा
    • मुझे समझ नहीं आता कि नीचे वाले layer में सीधे Plaid ही क्यों नहीं इस्तेमाल करते

  • शायद मेरी net worth कम है, लेकिन सच कहूँ तो मुझे समझ नहीं आता कि यह इतना valuable क्यों है
    मैं नहीं चाहता कि कोई LLM मुझे रोज़ email भेजे, और अगर मुझे अपने investments को quarterly से ज़्यादा बार देखना पड़ रहा है, तो शायद मुझे और सुरक्षित investments चुनने चाहिए। budgeting tools में थोड़ी दिलचस्पी है, लेकिन मैं चाहूँगा कि वे पूरी तरह deterministic हों
    मेरी financial planning आम तौर पर काफ़ी शांत रहती है, इसलिए spending optimization पर अभी से ज़्यादा समय लगाने से बेहतर मुझे ज़्यादा salary वाली नौकरी ढूँढना लगता है

    • मैं actualbudget.org से अपने सारे spending को track करता हूँ, लेकिन investment accounts को महीने में सिर्फ़ एक बार update करता हूँ
      मेरा मानना है कि numbers से जुड़ी चीज़ें मूलतः पूरी तरह deterministic होनी चाहिए
      मैंने LLM को SQLite DB दिखाकर कहा कि पिछले 5 साल के transactions में जो दिखता है वह बताए, और उसने जो चीज़ें पकड़ीं या याद दिलाईं वे प्रभावशाली थीं। लेकिन इससे ऐसा कोई व्यावहारिक मूल्य निकला हो जिससे मैं सचमुच कुछ बदलूँ, इस पर मुझे संदेह है
      मैं कुछ समय तक इसे monthly review के लिए आज़माऊँगा, लेकिन budget update करते हुए ही मुझे अपनी financial स्थिति का मोटा-मोटा अंदाज़ा रहता है, इसलिए यह कितना मददगार होगा कहना मुश्किल है
    • क्या आपने Actual Budget + SimpleFIN के साथ bank transactions import करके देखा है
      मैं उसी से अपने credit card और checking accounts को track करता हूँ, और चाहूँ तो उसमें MCP जोड़कर एक जगह के data का analysis भी कर सकता हूँ
    • धन्यवाद, लेकिन उल्टा यह जानना चाहूँगा कि ऐसी कौन-सी चीज़ होगी जिससे आपको इसमें दिलचस्पी पैदा हो

  • मैं Canada में रहता हूँ और tracking के लिए https://lunchmoney.app/ को Plaid integration के साथ इस्तेमाल करता हूँ
    इसमें API है, इसलिए मैंने LLM से एक CLI लिखवाई और अब agent ज़रूरत का data लगभग मनचाहे तरीके से ले सकता है
    मैंने एक और काम यह करवाया कि tagging rules को build up करे, और उसे दिन में एक बार cron पर चलाता हूँ। कभी-कभी उससे rules की समीक्षा भी करवाता हूँ ताकि uncategorized transactions के लिए नए rules बनाए जा सकें
    मुझे यह pattern काफ़ी अच्छा लगता है जिसमें LLM काम को rule engine या code में memoize कर देता है। एक बार queryable CLI मिल जाए, तो agent से लगभग कुछ भी करवाया जा सकता है

    • मैं Lunch Money का founder हूँ, यह देखकर खुशी हुई कि आप इसे इस तरह इस्तेमाल कर रहे हैं
    • आपका मुख्य use case क्या है, यह जानने में दिलचस्पी है

  • जिन लोगों की दिलचस्पी हो, उनके लिए मैं हमारे infrastructure/security setup का high-level overview साझा कर रहा हूँ
    backend और CLI सख़्ती से linted Rust में हैं, और webapp Axum पर चलता है तथा Postgres से sqlx के जरिए जुड़ता है
    financial functionality read-only है। transfer/bill-pay/remittance tools नहीं हैं, और AI surface से भी पैसे नहीं हिलाए जा सकते
    Plaid से हम सिर्फ़ transactions, investments और liabilities माँगते हैं; auth/transfer/payment initiation नहीं, इसलिए हमें full account numbers या routing numbers नहीं मिलते, सिर्फ़ basic last-4 mask मिलता है
    bank usernames और passwords हमारे पास आए बिना Plaid Link में जाते हैं, और हमारे पास सिर्फ़ institution-level access token रहता है
    Plaid access tokens को हम अलग DB में रखते हैं और single-custody Cloud Run service के पीछे रखते हैं। store करते समय वे Cloud KMS से encrypt होते हैं, broker KMS encrypt/decrypt endpoints को call करता है, और root key material कभी Google HSM boundary से बाहर नहीं जाता। सिर्फ़ broker service account के पास encrypt/decrypt permission है, और webapp को उस DB को पढ़ने की permission नहीं है
    हर encrypt/decrypt call में हम Plaid item ID को AAD के रूप में पास करते हैं ताकि एक item का ciphertext दूसरे item token में बदलकर decrypt न किया जा सके
    हर Cloud Run service अपनी अलग cloud identity और DB role के साथ चलती है, और services के बीच internal calls भी short-lived identity tokens से authenticate होते हैं
    production DB का कोई public IP नहीं है, और secrets source या container image में नहीं बल्कि managed secret storage में रखे जाते हैं
    AI connector OAuth 2.1 + PKCE पर है और user-specific scopes रखता है, जिन्हें UI से revoke किया जा सकता है। हर tool call में tool name, sanitized arguments, calling client, और agent द्वारा दिया गया reason log होता है ताकि यह देखा जा सके कि LLM ने user की ओर से क्या माँगा
    AI surface में fetch-URL, shell, या generic I/O tools नहीं हैं; यह सिर्फ़ structured financial data लौटाता है। networking, IAM, और DB grants सब Terraform से manage होते हैं, और infra changes भी सिर्फ़ उसी रास्ते से किए जाते हैं
    infra access को 2FA और security keys से नियंत्रित किया जाता है

    • ऐसे technical details सचमुच सार्वजनिक करने के लिए धन्यवाद
      इससे लगता है कि आप इस साइट के पाठकों को समझते हैं, और सुरक्षा को हर layer पर ध्यान से design करने से पूरे tool पर भरोसा भी बढ़ता है
      मैं भी कुछ ऐसा खुद बनाने की सोच रहा था; शुरुआती MVP में manually statement PDFs डाउनलोड करके Claude से plain text accounting के लिए ledger setup करवाने का विचार था, और बाद में Plaid जोड़ने वाला था
      खास तौर पर यह जानना चाहता हूँ कि लोग Plaid को कैसे इस्तेमाल करते हैं। शुरू करने के लिए क्या किसी न्यूनतम user count की ज़रूरत होती है, या मैं सिर्फ़ अपने personal/business accounts को clean API से जोड़ने के लिए व्यक्तिगत उपयोग हेतु Plaid account बना सकता हूँ
    • अगर कोई product technical details या Show HN post share करता है और आप उसे downvote करने वाले हैं, तो कम से कम वजह तो बताइए

  • Routine इस्तेमाल करते समय सावधान रहना चाहिए
    एक बहुत कम दिखने वाला छोटा-सा notice है कि routine mode में MCP tools को write permissions सहित हमेशा allow किया जाता है। इसलिए technically agent मनचाहे तरीके से resources बदल भी सकता है

    • सही बात। ऐसे tools इस्तेमाल करते समय हमेशा prompt injection को ध्यान में रखना चाहिए

  • यह मुझे समस्या खोजता हुआ समाधान लगता है। सिर्फ़ https://tiller.com/ ही काफ़ी है, spreadsheet में जो calculations चाहिए वे सब हो जाती हैं, और bonus के तौर पर hallucinations भी नहीं होते
    मुझे समझ नहीं आता कि कोई इतना लंबा LLM summary आखिर क्यों पढ़ना चाहेगा। अगर आप बस बीच-बीच में spending को खुद categorize कर लें, तो anomalies जल्दी दिख जाती हैं, और Tiller में यह काम आसान भी है

    • शुरुआत में मैंने इसे सिर्फ़ अपने और अपनी पत्नी के लिए बनाया था, तो आख़िरकार हमने वही बनाया जो हमें चाहिए था और जो हम चाहते थे
      इस क्षेत्र में बहुत तरह के products आएँगे, और हमारा product उनमें से सिर्फ़ एक approach है। ऐसे प्रयोग ज़्यादा हों, यह मुझे भी अच्छा लगता है
    • असली बात summary text नहीं है
      बड़ी बात यह है कि LLM कई data sources को आसानी से absorb और combine कर सकता है

  • हमारी Era Finance बिल्कुल इसी पर केंद्रित solution बना रही है। यह Era Context नाम का MCP है जो किसी भी compatible agent को personal finance से जोड़ता है, और https://era.app पर देखा जा सकता है
    अभी हम read tools पर focus कर रहे हैं, लेकिन money transfer और debt repayment जैसे write tools भी तैयार कर रहे हैं
    अगर कोई feature चाहिए तो ऊपर दिए domain के alex पर email करें। जानकारी के लिए, मैं CEO Alex हूँ; HN पर लगभग नया हूँ, लेकिन पहले stripe.com web presence का प्रभारी था और उससे पहले Square/CashApp में था

    • दिलचस्प लग रहा है, मैं इसे अभी आज़मा रहा हूँ

  • शायद लड़ाई पहले ही हार चुके हैं, लेकिन फिर भी समझ नहीं आता कि कोई अपना पूरा financial transaction history किसी LLM को क्यों देना चाहेगा
    मुझे नहीं लगता कि LLM providers के पास इस data के उपयोग को लेकर financial industry से भी मज़बूत safeguards होंगे। जबकि financial industry खुद ही हमारे data को collect, mine और sell करने वाला काफ़ी कठोर उद्योग है

    • कम से कम मेरे लिए सबसे बड़ी वजह यह है कि insights वास्तव में काफ़ी उपयोगी हैं
      spending patterns और investments में रुचि रखने वाले इंसान के तौर पर, बहुत basic prompts से भी मैंने ऐसी चीज़ें देखीं जो पहले छूट गई थीं
      बेशक इसे सुरक्षित बनाना बहुत कठिन है, और इसी वजह से मैं उस हिस्से पर बहुत लंबे समय से गंभीरता से सोच रहा हूँ
    • इस मामले में creator पहले ही समझा चुका है कि सब कुछ read-only है
      तो फिर ठीक-ठीक समस्या क्या है, यह मुझे समझ नहीं आता
    • क्यों नहीं? मेरे जीवन पर इसका कौन-सा ठोस नुकसान हो सकता है, यह जानना चाहूँगा

  • मेरे मुख्य bank, UK के Monzo, में पूरा API और events के लिए trigger webhook है
    इसकी वजह से मैं एक WhatsApp bot बना पाया जो unusual transactions पर मुझसे पूछता है कि उसका कारण क्या है, और LLM का उपयोग सिर्फ़ उसकी reasoning के लिए करता है। मैंने एक automation यह भी बनाई है जो हर दिन आधी रात से पहले balance को sweep करके savings account में डाल देती है ताकि daily interest maximize हो सके
    मैं day-to-day account में सिर्फ़ थोड़ी रकम रखता हूँ, और अगर दिन में खर्च हो जाए तो savings से फिर भर देता हूँ ताकि वह कम balance बना रहे। बड़े खर्च की ज़रूरत हो तो तब manually transfer करता हूँ

    • यह वाकई शानदार है। काश आप इसे open source कर दें, और अफ़सोस है कि अमेरिका में ऐसा ecosystem नहीं है, वरना यह बहुत आसान होता

  • जब मैंने Claude से historical transactions analyze करवाने की कोशिश की, तो यह बार-बार hallucination करता रहा—ऐसे charges बना दिए जो थे ही नहीं, नए items जोड़ दिए, और double counting कर दी
    finance में Claude का 95% सही होना काफ़ी नहीं है। हर समय सतर्क रहकर output review करना पड़े, तो मेरे लिए यह लगभग बेकार हो जाता है

    • मैं Codex का GPT भी एक बार आज़माने की सलाह दूँगा
      मुझे भी लगा है कि Claude खासकर incomplete या constrained datasets पर काफ़ी आसानी से hallucinate कर देता है