Claude Code प्रॉम्प्ट पढ़ने से पहले 33 हज़ार टोकन भेजता है, OpenCode 7 हज़ार

 (systima.ai)
3 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक ही मॉडल·मशीन·टास्क पर API boundary मापने पर Sonnet 4.5 की पहली request का fixed overhead Claude Code में लगभग 32,800 tokens और OpenCode में लगभग 6,900 tokens निकला, यानी 4.7 गुना अंतर; Fable 5 में यह घटकर लगभग 3.3 गुना रह गया
  • अंतर का अधिकांश हिस्सा tool schema से आया। Claude Code ने 27 tool definitions के लिए लगभग 24,000 tokens और OpenCode ने 10 tools के लिए लगभग 4,800 tokens इस्तेमाल किए; सभी tools बंद करने पर भी system prompt क्रमशः लगभग 6,500 tokens और 2,000 tokens था
  • वास्तविक configuration में 72KB command file हर request में लगभग 20,000 tokens जोड़ती है, और एक छोटा MCP server लगभग 1,000~1,400 tokens और जोड़ता है, जिससे पहली request ही 75,000~90,817 tokens तक पहुँच सकती है
  • उसी file-summary task में Claude Code ने OpenCode की तुलना में cache writes 5.9~54 गुना अधिक किए, और जब काम को दो sub-agents में बाँटा गया तो direct execution के 121,000 tokens बढ़कर 513,000 tokens हो गए, यानी 4.2 गुना
  • केवल fixed overhead से कुल लागत का फैसला नहीं किया जा सकता। multi-step task में Claude Code ने tool calls को parallel batch करके 3 requests में लगभग 121,000 tokens खर्च किए, जबकि OpenCode ने serial calls की 9 requests में लगभग 132,000 tokens इस्तेमाल किए

API boundary पर मापने का तरीका

  • Claude Code और OpenCode के बीच logging proxy रखा गया ताकि harness द्वारा भेजी गई सटीक JSON requests और API से लौटे usage blocks रिकॉर्ड किए जा सकें
    • request body में system blocks, tool schemas और messages शामिल थे
    • usage में input tokens, cache write·read और output tokens शामिल थे
    • capture की गई request body को वास्तविक transmission और API usage block को वास्तविक billing के आधार के रूप में इस्तेमाल किया गया
  • base comparison के लिए Claude Code 2.1.207 और OpenCode 1.17.18 इस्तेमाल किए गए, और दोनों को जुलाई 2026 के अनुसार claude-sonnet-4-5 पर fixed रखा गया
    • fixed overhead, cache behavior और multi-step task के कुछ हिस्से claude-fable-5 पर दोबारा चलाए गए
    • defaults को isolate करने के लिए नया settings directory, बिना MCP server·user settings·memory, और command files के बिना empty workspace इस्तेमाल किया गया
  • तीन tasks से अलग-अलग cost structure मापे गए
    • T1 में Reply with exactly: OK से fixed overhead अलग किया गया, और हर harness पर 3 बार run किया गया
    • T2 में पहले से तैयार file पढ़कर उसका summary बनवाया गया
    • T3 में FizzBuzz और validation script पर write·run·test·fix प्रक्रिया कराई गई
  • tool schema को छोड़कर system prompt की तुलना के लिए Claude Code में --tools "" और OpenCode में "tools": {"*": false} लागू किया गया
  • local LLM gateway हर request में लगभग 6,200 tokens का fixed envelope जोड़ रहा था, इसलिए correction के बाद इसे measurements से बाहर रखा गया
    • component-wise numbers captured request body से निकाले गए, जिसे gateway बदल नहीं सकता था
    • character-to-token conversion के लिए cold cache पर मापे गए harness-specific 4.1~4.4 characters per token ratio का इस्तेमाल हुआ

base overhead बढ़ाने वाले tool schemas

  • 22-character वाले T1 prompt की पहली request में Claude Code ने लगभग 32,800 tokens और OpenCode ने लगभग 6,900 tokens भेजे
    • Claude Code का system prompt 3 blocks और 27,344 characters का था, जबकि OpenCode का 1 block और 9,324 characters का
    • Claude Code के 27 tool schemas 99,778 characters के थे, जबकि OpenCode के 10 tools 20,856 characters के
    • Claude Code ने वास्तविक prompt से पहले agent type, available skills और user context वाला 7,997-character का <system-reminder> block डाला
    • OpenCode ने अलग first-message scaffolding के बिना system block, 10 coding tools और user prompt भेजा
  • दोनों तरफ tool definitions सबसे बड़ा हिस्सा थे
    • Claude Code के लगभग 33,000 tokens में लगभग 24,000 tokens tool definitions के थे
    • OpenCode के लगभग 6,900 tokens में लगभग 4,800 tokens tool definitions के थे
    • Claude Code tools में coding functions के अलावा CronCreate, Monitor, Task families, work-tree management, push notifications जैसे background agent·orchestration features शामिल थे
  • सभी tools हटाने पर Claude Code system prompt 26,891 characters, लगभग 6,500 tokens और OpenCode 8,811 characters, लगभग 2,000 tokens रह गया
    • दोनों harnesses में tools disable होने पर prompt थोड़ा छोटा हुआ
    • बचा हुआ अंतर tone, safety instructions, task-management rules और environment information जैसी behavior instructions से आया
  • Fable 5 में Claude Code ने model के हिसाब से prompt छोटा किया, जिससे अंतर लगभग 3.3 गुना रह गया
    • system instructions Sonnet के 27,787 characters से घटकर Fable में 10,526 characters हो गए
    • वही 27 tools रखते हुए schema भी 99,778 characters से घटकर 82,283 characters हुआ
    • OpenCode requests दोनों models में byte-for-byte समान रहीं

task shape के अनुसार बदलता कुल usage

  • एक file पढ़कर summary बनाने वाले T2 में दोनों harnesses ने सही result दिया, लेकिन request structure अलग था
    • Claude Code ने 6 HTTP requests और cumulative input लगभग 199,000 tokens इस्तेमाल किए
    • OpenCode ने 4 requests और लगभग 41,000 tokens इस्तेमाल किए, साथ में session title generation के लिए 1 अतिरिक्त Haiku call की
    • अधिकतर usage cache reads था, जिसकी billing input price के दसवें हिस्से पर हुई
  • cache discount होने पर भी पहली request की cache write, हर turn की cache read, और context-window occupancy payload size के साथ बढ़ते हैं
    • 33,000-token baseline, code आने से पहले ही 200,000-token window का लगभग छठा हिस्सा ले लेता है
  • write·run·test·fix वाले T3 में tool-calling style ने base overhead के अंतर को काफी हद तक neutralize किया
    • Claude Code ने 2 file writes और 2 script runs को एक parallel tool round-trip में batch किया, जिससे 3 model requests और cumulative input लगभग 121,000 tokens रहा
    • OpenCode ने हर turn में सिर्फ एक tool call किया, जिससे 9 requests और 1 title call के साथ cumulative input लगभग 132,000 tokens रहा
    • total input लगभग प्रति-request baseline × requests की संख्या + बढ़ती conversation content से तय हुआ
  • conversation बढ़ने पर Claude Code ने <system-reminder> blocks को पहले turn के 3 से बढ़ाकर पहले tool round-trip तक 4 कर दिया
  • OpenCode का per-turn added payload लगभग 400~2,200 characters था, और उसमें सिर्फ conversation content बढ़ा

वास्तविक setup से जुड़ने वाले अतिरिक्त tokens

  • production repo की 72KB AGENTS.md जोड़ने पर दोनों harnesses में हर request 20,000 tokens से अधिक बढ़ गई
    • OpenCode measurement 13,152 tokens से बढ़कर 33,336 tokens हो गया
    • Claude Code 39,005 tokens से बढ़कर 59,243 tokens हुआ
    • Claude Code 2.1.207 ने AGENTS.md को ignore किया; पहली user message में insert कराने के लिए उसका नाम CLAUDE.md करना पड़ा
    • OpenCode दोनों filenames पढ़कर system prompt में insert करता है
    • अगर harness वास्तव में कौन-सी filename पहचानता है यह verify न किया जाए, तो command file चुपचाप ignore हो सकती है
  • public small MCP server हर server पर हर request में लगभग 1,000~1,400 tokens जोड़ता है
    • 5 servers ने Claude Code payload में 4,900 tokens और OpenCode measurement में 6,967 tokens जोड़े
    • tools की संख्या Claude Code में 27 से 69 और OpenCode में 10 से 52 हो गई
    • richer APIs वाले production servers और बड़े schemas भेज सकते हैं
    • Claude Code का print mode explicit --mcp-config के बिना project-scoped .mcp.json को चुपचाप ignore कर रहा था, इसलिए API boundary पर actual connection verify करना ज़रूरी है
  • BMAD जैसे story-based workflow frameworks persona·protocol·checklist वाले बड़े templates को slash commands से expand करते हैं
    • experiment का 8,405-character template अपने-आप में लगभग 2,100 tokens था, लेकिन conversation history में जाने के बाद हर subsequent request में दोबारा भेजा गया
    • 9-request session में वही template 9 बार गया, इसलिए लागत template size × request count के हिसाब से बढ़ी
  • वास्तविक configuration की पहली request base overhead से कहीं बड़ी निकली
    • OpenCode ने email·calendar, task management, reference management, product analysis आदि के लिए 11 MCP servers और 72KB command file के साथ 179 tools, 277KB schema और cold-cache write 90,817 tokens रिकॉर्ड किए
    • Claude Code ने 4 MCP servers, installed plugins और वही command file के साथ 118 tools, 311KB payload और लगभग 75,000 tokens रिकॉर्ड किए
    • gateway envelope हटाने पर OpenCode configuration लगभग 7,000-token default की तुलना में करीब 12 गुना थी

sub-agents और extended thinking की लागत

  • जब Claude Code ने task को दो sub-agents में parallel बाँटा, तो direct execution के 121,000 tokens बढ़कर 513,000 tokens हो गए, यानी 4.2 गुना
    • main session, sub-agent invocations आदि मिलाकर कुल 9 model requests हुईं
    • 5 sub-agent calls ने each 3,554-character system prompt और base 27 में से 24 tools के साथ खुद को bootstrap किया
    • संरचना ऐसी थी कि हर sub-agent अपना initial cost उठाता है और उसका execution history parent फिर से पढ़ता है
  • OpenCode sub-agent ने 1,379-character system prompt और सिर्फ 5 tools वाला reduced profile भेजा
    • gateway के जरिए execution ठीक से पूरा नहीं हुआ, इसलिए OpenCode की total sub-agent usage quantify नहीं की गई
    • captured payload में दिखे design differences की ही तुलना की गई
  • extended thinking output की billing output rate पर होती है, जो input rate से 5 गुना है, और reasoning blocks conversation history में शामिल होकर बाद की requests में फिर से भेजे जाते हैं
    • gateway की अपनी thinking policy के कारण यह verify नहीं हो सका कि दोनों harnesses की settings वास्तव में लागू हुईं या नहीं, इसलिए measurement numbers प्रकाशित नहीं किए गए
    • केवल reasoning blocks के history में शामिल होने वाली cost structure को observation scope में रखा गया

prompt cache की अर्थव्यवस्था और स्थिरता

  • दोनों harnesses ने cache breakpoints सही सेट किए। payload 5-minute TTL के आधार पर base input price के 1.25 गुना पर एक बार लिखा जाता है और बाद में दसवें हिस्से की कीमत पर पढ़ा जाता है
  • cache से कम न होने वाली तीन लागतें हैं
    • 5 मिनट से ज़्यादा रुकने पर पूरा stack फिर से लिखना पड़ता है, इसलिए meeting या meal break जैसी pause के बाद write cost फिर आती है
    • cache reads भी requests की संख्या जितनी बार दोहराई जाती हैं, इसलिए serial tool loops और sub-agent fan-out लागत बढ़ाते हैं
    • context-window occupancy पर cache discount का असर नहीं पड़ता; 85,000-token bootstrap 200,000-token window का 40% से ज़्यादा ले लेता है, और compression शुरू होने पर summary cost भी जुड़ती है
  • OpenCode ने capture की गई सभी requests और runs में byte-for-byte identical prefix बनाए रखा
    • तीन T1 sessions में tools, system और message bytes समान थे और repeated runs में cache writes 0 थीं
    • 9-request वाला T3 session भी एक stable prefix बनाए रखता है
  • Claude Code हर session में warm-up exploration, main conversation और sub-agent invocation जैसे अलग-अलग request types और cache entries बनाता है
    • same workspace में bhi system bytes और first-message scaffolding हर run में बदल गई
    • उसी file-summary task में 5 requests के दौरान 53,839 cache tokens लिखे गए, और लगभग 43,000-token prefix पूरा का पूरा task के बीच में एक बार फिर लिखा गया
    • OpenCode की उसी task में cache write 1,003 tokens थी
  • Claude Code की बड़ी mid-session cache rewrites repeated experiments में भी दिखीं
    • पहली दो runs में क्रमशः 43,342 tokens और 36,899 tokens फिर से लिखे गए, जबकि freshly warmed cache वाली तीसरी run में लगभग कुछ नहीं लिखा गया
    • Fable 5 में भी बिना cache reads के 50,053 tokens फिर से लिखे गए, जिससे Sonnet की तरह लगभग 52 गुना का अंतर बना
    • cache temperature के अनुसार Claude Code की cache writes, OpenCode की तुलना में 5.9~54 गुना थीं
    • cache write pricing 5-minute tier में base का 1.25 गुना और 1-hour tier में 2 गुना है
  • एक single cache miss gateway eviction की वजह से भी हो सकता है, लेकिन यह कई runs में reproduce हुआ और request से पहले capture किए गए bytes में भी prefix instability दिखी
    • जब prefix बड़ा हो, कई प्रकार का हो, rewrites बार-बार हों, और sub-agents भी जुड़ जाएँ, तो Claude Code का usage meter और तेज़ी से बढ़ सकता है

result quality और audit logs

  • दोनों harnesses ने evaluation के सभी tasks सही तरीके से पूरे किए
    • file summary results दोनों में सही थे
    • multi-step task दोनों harnesses द्वारा लिखी गई validation script pass करके normal exit पर समाप्त हुआ
    • इस scope में समान result पाने के लिए आवश्यक token cost के अंतर की तुलना की जा सकी
  • कठिन वास्तविक engineering tasks में Claude Code के background agents, skills और orchestration अतिरिक्त लागत के बदले quality बढ़ाते हैं या नहीं, यह नहीं मापा गया
    • इसे जाँचने के लिए अलग से उचित test suite, पर्याप्त repeated runs और pass-rate evaluation चाहिए
  • quality से असंबंधित waste भी दिखा
    • session के बीच वही byte-identical cache prefix दोबारा लिखना, उसी content को premium price पर फिर खरीदने जैसा है
    • अगर harness command file को चुपचाप ignore करे, तो उससे कोई उपयोगिता मिलती ही नहीं
  • capture की गई request·response की 185 entries को open source library @systima/aiact-audit-log से SHA-256 hash chain में रिकॉर्ड किया गया
    • chain बिना interruption के अंत तक verify हुई और integrity result VALID था
    • इसी structure से transmission·response content फिर से reconstruct किया जा सकता है और third parties को integrity evidence दिया जा सकता है
    • यह EU AI Act Article 12 logging में दिए गए structured records के समान तरीका है

measurement की सीमाएँ और reproduction का तरीका

  • ये नतीजे एक मशीन, दो harness versions और छोटे sample वाले जुलाई 2026 snapshot हैं
    • T1 और T2 को 3-3 बार चलाया गया, और हर configuration multiplier condition को 1 बार run किया गया
    • defaults और cache conditions में Sonnet 4.5 और Fable 5 इस्तेमाल हुए, जबकि configuration multiplier conditions में एक ही model इस्तेमाल हुआ
    • harness prompts अक्सर बदलते हैं, इसलिए अलग-अलग numbers से ज़्यादा API boundary measurement method लंबे समय तक उपयोगी रहेगी
  • local gateway measurement path में मौजूद था
    • component values उस request body से निकाली गईं जिसे gateway बदल नहीं सकता था
    • measurements में cold-cache baseline के आधार पर fixed envelope correction किया गया, और warm-run numbers जिनका कारण अलग नहीं किया जा सका, उन्हें बाहर रखा गया
    • ऐसा भी हुआ कि gateway ने fixed model की जगह चुपचाप नया snapshot दे दिया, इसलिए boundary पर actual response model भी verify करना चाहिए
    • Fable path में पुराने server session resume और host-side tool execution हुआ, इसलिए Claude Code के Fable multi-step results को बाहर रखा गया
  • T3 की cost convergence सिर्फ एक task shape पर एक observation है
    • जिन tasks में sequential execution ज़रूरी हो, उनमें Claude Code requests की संख्या और total usage फिर बढ़ सकती है
    • OpenCode के tool-removal और sub-agent conditions में gateway ने invalid stream लौटाई, इसलिए सिर्फ captured payload size का इस्तेमाल किया गया
    • वास्तविक configuration numbers एक user की settings पर आधारित हैं; दूसरे environments में वे अलग हो सकते हैं
  • reproduction setup लगभग 200 lines of Node code वाले HTTP proxy पर आधारित है
    • यह model endpoint तक requests forward करते हुए request body और response usage blocks को disk और audit chain में रिकॉर्ड करता है
    • ANTHROPIC_BASE_URL को proxy पर सेट करके, नए settings directory और empty workspace में defaults मापे गए, फिर command files, MCP servers और workflows को एक-एक करके जोड़ा गया
    • अगर gateway इस्तेमाल कर रहे हों, तो पहले minimal request से उसका अपना envelope मापें और यह verify करें कि वास्तव में कौन-सा model जवाब दे रहा है
    • अगर API boundary logging मौजूद हो, ताकि किसी समय production agent ने model को क्या सटीक content भेजा था यह reconstruct किया जा सके, तो token accounting भी साथ में सुनिश्चित हो जाती है

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • असल में बहुत ज़्यादा टोकन sub-agent ही जलाते हैं। मैंने Claude Code को एक बड़ा काम दिया तो उसने तुरंत 7 sub-agent चला दिए, और एक भी पूरा होने से पहले बजट खत्म हो गया। 5 घंटे बाद फिर कोशिश की, तब भी वही हुआ
    जब main agent से वही काम क्रमवार कराया, तो कोई समस्या नहीं हुई। यह communication और coordination cost की वजह से इतना अक्षम है, या फिर इसलिए कि sub-agent इस्तेमाल करने वाले ज़्यादातर यूज़र बड़े enterprise accounts पर token-per-cost चुकाते हैं और Anthropic revenue बढ़ाना चाहता है, कहना मुश्किल है

    • उलटे, किसी जटिल प्रोजेक्ट के exploration·planning चरण में Fable का जिज्ञासु व्यवहार बिल्कुल वही चीज़ हो सकता है जिसकी ज़रूरत हो। अगर coordinating agent सिर्फ prompt को कई exploration viewpoints में बाँटे ही नहीं, बल्कि हर sub-agent उस viewpoint से codebase की जाँच करे और नए सुरागों को recursively फैलाए, तो हर चरण में Fable का इस्तेमाल करना तर्कसंगत है
      दूसरी ओर, अगर काम पहले से अच्छी तरह planned है और उसे कई targets पर parallel लागू करना है, तो साफ़ तौर पर बताना चाहिए कि sub-agent कम जिज्ञासु model पर downgrade करें। इससे output की consistency भी बेहतर हो सकती है
    • हर sub-agent को काम के लिए ज़रूरी context पाने हेतु codebase के कुछ हिस्से फिर से पढ़ने पड़ते हैं। काम लंबा चलने पर coordinating agent का context भी cache से बाहर हो जाता है, इसलिए sub-agent के खत्म होने के बाद फिर पूरी लागत चुकानी पड़ती है
      sequential execution में फ़ाइलें लगभग एक-एक बार ही पढ़ी जाती हैं और सभी requests एक ही prefix cache का उपयोग करती हैं
    • अगर ग्राहक समस्या से बचने के लिए और महँगा plan चुनने लगें, तो कंपनी के पास उस समस्या को ठीक न करने का नकारात्मक प्रोत्साहन पैदा हो जाता है। भले ही समाधान जानने वाले कुछ engineers हों, उन्हें बहुसंख्यक उदासीनता, कुछ लोगों की रुकावट, और कभी-कभी management chain में कहीं सक्रिय शत्रुता तक का सामना करना पड़ सकता है
      ऐसे माहौल में पहले सबसे महँगे tier में नए features डालना, लागत वसूलना, फिर उन्हें नीचे के tiers में लाना, या competitors के लिए पीछा करना मुश्किल बनाने वाली ladder खींच लेने की रणनीति सबसे अच्छा रास्ता हो सकती है
    • हर sub-agent को लगभग 30 हज़ार token का system prompt एक जैसा भेजा जाता है। Fable/Opus इस्तेमाल करें तो 7 workers के काम शुरू करने से पहले ही 5 घंटे की usage limit का 30% आसानी से खर्च हो जाता है
    • यह तरकीब समझने के बाद अब मैं Fable sub-agent को साफ़ तौर पर मना करता हूँ। कल बड़े refactoring के बाद complex code की review करनी थी, तो मैंने पहले review plan माँगा। उसने पहले चरण में 8 Fable agents और नतीजे की verification के लिए 1 agent सुझाया, और मैंने मंज़ूर कर दिया
      लेकिन verification चरण में वह 41 Fable verification agents चलाना चाहता था। किसी न किसी तरह उसने रास्ता निकाल ही लिया

  • मुझे लगता है Claude Code बहुत टोकन इसलिए खर्च करता है ताकि Anthropic ज़्यादा पैसा कमाए और यूज़र्स को subscription में धकेले। यह नीति कि subscription entitlement को दूसरे coding agents में इस्तेमाल नहीं किया जा सकता, इसी बात को मज़बूत करती है। मैं pi इस्तेमाल करता हूँ

    • Anthropic को token बेचने वाला मानकर देखो, तो उसके कई फैसले समझ आने लगते हैं। जब तक यूज़र विरोध न करें या guardrails न माँगें, उसके पास अपने रास्ते से और ज़्यादा tokens खर्च करवाने के कारण बनाते रहने की वजह है
    • IPO से जुड़े दस्तावेज़ों में देखा था कि subscription revenue क़रीब 5% है, यानी बहुत छोटा। हालाँकि यह 5% शायद personal Claude subscription का है, और Claude Code subscriptions का बड़ा हिस्सा enterprise category में शामिल किया गया होगा
      API·enterprise कुल revenue का 75~85% है, enterprise subscriptions लगभग 10~15% हैं, और personal subscriptions लगभग 5% हैं
    • बल्कि तर्क तो उलटा है। Subscriber तय मासिक शुल्क देते हैं, इसलिए Anthropic के पास Claude Code को कम tokens खर्च करवाने का प्रोत्साहन होना चाहिए
    • लेकिन दूसरी ओर, ऐसा व्यवहार flat-fee में शामिल सामान्य subscribers का token usage भी बढ़ा देता है। यह दुर्भावना से ज़्यादा अयोग्यता के क़रीब लगता है

  • PUSH_AX की उपयुक्त उपमा के मुताबिक, यह वैसा है जैसे contractor A 33,000 डॉलर माँगे और B 7,000 डॉलर, इसलिए हमें देखना होगा कि हम सही चीज़ को माप रहे हैं या नहीं
    इसी के अनुसार, मैं पोस्ट में और गहरा काम, qualitative result comparison, और जितना जल्दी हो सके input·output reproduction material जोड़ने वाला हूँ

    • सोच रहा हूँ कि 33,000 tokens का बड़ा हिस्सा हाल की बातचीत जैसे context data तो नहीं है

  • मामला सिर्फ बड़े system prompt का नहीं है। Coding agent runtime environment भी छोटे-छोटे अनुरोधों पर tools का और आक्रामक इस्तेमाल कर रहा है। Tests में “Hey” या “commit” जैसे prompts ने कभी-कभी 30 से ज़्यादा tool calls करा दिए
    https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
    साधारण कामों में खर्च होने वाले tokens लगातार बढ़ रहे हैं — ऐसी token inflation सचमुच दिख रही है

    • जब Opus comment की सिर्फ एक typo ठीक करके tests, lint वगैरह सब कुछ चला देता है जो भी चलाया जा सकता है, तो चिढ़ होती है। यह देखने के लिए कि सारे tests पहले से pass हो रहे थे या नहीं, वह पहले current changes को stash भी कर देता है
      नियमों में मैंने ही लिखा है कि हर बदलाव को tests से verify करना है, लेकिन अगर AI के I पर इतना ज़ोर है, तो कम से कम फलों के सलाद में टमाटर न डालने जितनी समझदारी की उम्मीद तो होती है
    • “Hey” या “commit” जैसे अस्पष्ट prompts मिलने पर, वह मनचाहा काम अनुमान लगाने के लिए पिछली बातचीत और दूसरे context में खोजता फिरता है, इसलिए tool calls बढ़ जाते हैं। ज़्यादा स्पष्ट prompt बेहतर है
    • commit जैसा काम तो LLM को दिए बिना खुद भी किया जा सकता है, है न?

  • Claude को 6 महीने इस्तेमाल करने के बाद मैंने हाल में Codex पर switch किया। Codex ज़्यादा खुला है, model के काम करने की प्रक्रिया को follow करना आसान है, और approval flow का user experience भी बेहतर है। कुल मिलाकर पारदर्शिता ज़्यादा है, और switch cost लगभग 0 थी
    Claude का फ़रवरी के आसपास से system prompt सहित और अपारदर्शी हो जाना मुझे पसंद नहीं आया, और 33,000 tokens बहुत ज़्यादा लगते हैं

    • अभी मैं दोनों इस्तेमाल करता हूँ, और सच कहें तो लगभग एक-दूसरे की जगह भी इस्तेमाल हो सकते हैं। Codex का open source होना और OpenAI का साफ़ तौर पर कहना कि subscription entitlement को दूसरे agents में भी इस्तेमाल किया जा सकता है, यह भी अच्छा है
      हाल में OpenAI काफ़ी consumer-friendly हो गया है
    • और अपारदर्शी होने के बाद आपने कौन-कौन सी settings आज़माईं, यह जानने की जिज्ञासा है। अब settings options भी काफ़ी बढ़ गए हैं

  • pi एजेंट का system prompt छोटा है, और पूरा कंटेंट यहाँ देखा जा सकता है
    https://github.com/earendil-works/pi/blob/main/packages%2Fco...

    • इसका संबंध इस minimalism से हो सकता है, लेकिन Pi में वे ज़्यादातर tools ही नहीं हैं जो LLM को कुशल और प्रभावी ढंग से काम करने के लिए चाहिए होते हैं। मैं उस दर्शन को समझता हूँ जिसमें खाली आधार पर अपनी पसंद की चीज़ें जोड़ी जाती हैं, लेकिन मेरे मानदंड से यह ज़रूरत से ज़्यादा खाली है
    • सोच रहा हूँ कि system prompt को हर बार कॉल करते समय date और cmd सेट करने से क्या cache invalidate हो जाती है
      अगर यह सिर्फ़ date या root directory बदलने पर invalidate होती है, तो व्यवहार में यह काफ़ी कम होने वाली बात है
    • अगर आपको बहुत अधिक customization के लिए एक minimal agent चाहिए, तो “minimal” pi-coder package में 130+ transitive dependencies खींच लाने से बेहतर है कि आप उसे खुद बना लें। यह कठिन नहीं है, बहुत कुछ सीखने को मिलता है, और शुरुआत में किसी दूसरे LLM से मदद भी ली जा सकती है

  • आख़िर में महत्वपूर्ण चीज़ raw prompt size नहीं है। अगर वही होता, तो Pi और उसके variants की लागत सबसे कम होनी चाहिए। असली बात prompt efficiency है, और prompt minimalism तथा efficiency को अक्सर आपस में गड़बड़ा दिया जाता है। फिर भी Claude Code अपने काम की तुलना में कुछ ज़्यादा भारी लगता है
    उससे भी ज़्यादा महत्वपूर्ण tools की quality है। खराब या buggy tools round-trip calls को बहुत बढ़ा देते हैं, जिससे शुरुआत में बचाए जाने वाले सारे फ़ायदे मिट जाते हैं
    कुछ महीने पहले 8 tasks पर 7 agents का पूरा benchmark किया गया था, और https://github.com/dirac-run/dirac में data और trace logs मौजूद हैं। उनमें से एक से मेरा सीधा संबंध है, इसलिए मैं पूर्ण निष्पक्षता का दावा नहीं कर सकता, लेकिन सामग्री reproducible है। ज़्यादातर tasks refactoring से जुड़े थे, इसलिए hash anchoring और abstract syntax tree analysis में मज़बूत Dirac ने बड़े अंतर से जीत हासिल की

    • प्रतिस्पर्धी बहुत हैं और प्रतिस्पर्धा बेहद तीव्र है, इसलिए अगर सुधार की गुंजाइश है तो कोई न कोई उसे लागू करेगा, और उसके बाद उसके तेज़ी से दूसरे products तक फैलने की संभावना काफ़ी अधिक है

  • काम पर मुझे Claude Code इस्तेमाल करने के लिए मजबूर किया जाता है, लेकिन --system-prompt "" इस्तेमाल करने से इसे आसानी से संभाला जा सकता है। अच्छा होगा अगर दूसरे execution environments भी अनुमति दें

    • क्या --system-prompt "" से खाली कर देने पर model के पास उपलब्ध tools को समझने के लिए default system prompt भी नहीं बचेगा?
    • मैं बहुत समय से इसे ऐसे ही इस्तेमाल कर रहा हूँ, समझ नहीं आता कि सब लोग ऐसा क्यों नहीं करते
    • मुझे इस option के बारे में पता नहीं था। इसे लागू करने से पहले और बाद की वास्तविक efficiency के विश्लेषण, या real-world usage environment के performance charts हों तो देखना चाहूँगा
    • यह जानना है कि क्या Claude को इस option के साथ start किया जाता है, या हर बार prompt भेजते समय इसे साथ में भेजा जाता है

  • जब मैंने पहली बार local model के साथ प्रयोग किया, तो उसे Claude Code से जोड़ने पर वह बहुत अच्छा चला, लेकिन धीमा था
    Claude की मदद से mitmproxy सेट किया और Claude Code के शुरुआती system prompt को पूरा capture किया, तो दोबारा जाँचने पर वह JSON 162KB निकला। यहीं से मैंने Pi, OpenCode, और Hermes के साथ प्रयोग शुरू किए

    • अभी Claude Code के नए session में /context चलाने पर Opus 4.8 के 10 लाख token context में से सिर्फ़ 23 हज़ार tokens इस्तेमाल होते दिखते हैं। इसमें system prompt 3.9 हज़ार, system tools 13.9 हज़ार, custom agent 235, memory file 28, features 4.9 हज़ार, message 8, और compressed buffer 3 हज़ार tokens दिखते हैं
      4 हज़ार token का system prompt लगभग 15~20KB होता है। मन करता है कि captured सामग्री को Gist पर डालने को कहूँ, लेकिन उसमें संवेदनशील data हो सकता है, और जो 162KB दिखा वह शायद सिर्फ़ system prompt नहीं था

  • मैंने जो बनाया है, वह इससे भी कम भेजता है: https://maki.sh

    • कहा जाता है कि context बहुत लंबा हो जाने पर maki images और reasoning blocks हटा देता है और पिछली बातचीत का सार बनाकर history को अपने-आप compress कर देता है
      लेकिन पिछली बातचीत का सार बनाना क्या असल में context cache को invalidate नहीं कर देता, जिससे tokens तो कम लगें लेकिन ज़्यादा महंगे tokens खर्च हों?