प्रोडक्शन AI एजेंट को GPT-5.6 पर माइग्रेट कर 2.2 गुना तेज और 27% सस्ता बनाने की प्रक्रिया

(ploy.ai)

1 पॉइंट द्वारा GN⁺ 7 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Ploy ने प्रोडक्शन marketing websites को plan, build और validate करने वाले agent को Claude Opus 4.8 से GPT-5.6 Sol पर migrate किया और उसे सभी workspaces का default model बनाया
evaluation harness में model-specific assumptions को ठीक करने के बाद homepage rebuild task में औसत runtime 8 मिनट से घटकर 3 मिनट 42 सेकंड हो गया, cost $3.06 से घटकर $2.22 हुई यानी 27% कम, और visual score भी 0.970 तक बढ़ा
GPT-5.6 ने tool calls के 25 optional parameters को arbitrary values से भर दिया, जिससे file reads के 52–64% empty result लौटाने लगे; लेकिन optional fields को required और nullable बनाने पर empty reads 0% हो गए और tool calls भी करीब 30% घट गए
OpenAI और Anthropic के cache scope और throughput structure में अंतर के कारण GPT-5.6 शुरू में लगभग 50% महंगा मापा गया, लेकिन workspace-level cache key और layered breakpoints लागू करके first-call hit rate 0% से 83.7% तक बढ़ाया गया और uncached input tokens 28% घटे
model बदलने की cost और performance सिर्फ model पर नहीं, बल्कि evaluation budget, tool schema, cache structure और reasoning replay strategy पर भी निर्भर करती है; इसलिए reliable comparison और stable operation के लिए मौजूदा model के हिसाब से बनी provider-specific assumptions को पहले ढूंढकर ठीक करना जरूरी है

Claude Opus की जगह GPT-5.6 Sol

Ploy agent production marketing websites के pages plan करता है, codebase पढ़ता है, components और images generate करता है, results को screenshots से check करता है और फिर तय करता है कि task पूरा हुआ या नहीं
कई महीनों तक Claude Opus को replace करने के standards पूरा करने वाला कोई model नहीं था, और default model 4 महीनों तक Opus 4.7 और फिर 4.8 के क्रम में बना रहा
GPT-5.6 Sol ने समान tasks पर one-to-one evaluation में पहली बार Opus को पीछे छोड़ा और सभी Ploy workspaces का default model बन गया
initial evaluation में भी completed builds का runtime आधे से कम था, cost 27% कम थी, और scores मौजूदा model के बराबर या उससे अधिक थे, जिससे migration आगे बढ़ाने का आधार मिला
Ploy Vercel AI SDK का उपयोग करता है, लेकिन model switch के दौरान पता चला कि tool argument construction, prompt caching और turn-to-turn reasoning replay से जुड़ी provider-specific assumptions पूरे stack में बची हुई थीं
migration evaluation harness, tool schema, prompt caching और reasoning replay को क्रम से ठीक करते हुए किया गया

evaluation numbers पर भरोसा करने से पहले harness ठीक करना

evaluation suite production agent को fixed test workspaces में चलाता है और homepage को scratch से build करने वाले tasks से लेकर duplicate request को safely execute किया जा सकता है या नहीं, यह तय करने वाले tasks तक सैकड़ों cases cover करता है
build cases में visual judge reference design से तुलना करके 10 binary checks करता है
- check करता है कि hero area पूरे screen width को भरने वाला photo scene है या नहीं
- verify करता है कि main CTA pill shape नहीं, बल्कि rounded-corner rectangle है या नहीं
content checks, tool execution path checks और file assertions भी साथ में किए जाते हैं; failure पर tool calls और model text सहित पूरा execution trace review किया जाता है
मौजूदा model के call pattern के हिसाब से बनी constraints
- मौजूदा tool call budget Opus के sequential call pattern के हिसाब से set था, लेकिन GPT-5.6 parallel calls का उपयोग करता है, इसलिए सही तरीके से problem solve करने वाले cases में भी budget exceed हो गया
- evaluation runner Opus द्वारा लगभग इस्तेमाल न किए जाने वाले batch file reads को support नहीं करता था, लेकिन GPT-5.6 इसे अक्सर इस्तेमाल करता है
- first run में आए raw failures में से लगभग एक-तिहाई model behavior नहीं, बल्कि harness की assumptions के कारण थे, और वे models में evenly distributed भी नहीं थे
- challenger model और मौजूदा model के execution traces को पहले classify न किया जाए, तो evaluation नए model को पुराने model जैसा behave करने पर फायदा देता है
implicit score thresholds
- जिन datasets में minScore missing था, वे बिना किसी warning के default value 1.0 inherit कर रहे थे
- इस वजह से GPT-5.6 को hero score 0.98 मिलने के बावजूद fail mark किया गया, और Opus को भी सभी individual checks pass करने वाले case में fail माना गया
- दोनों results defensible designs थे, लेकिन model नहीं बल्कि implicit threshold के कारण reject हुए

corrected benchmark results

harness ठीक करने के बाद brand homepage को reference design के मुताबिक फिर से build करने वाली evaluation suite दोबारा चलाई गई

completed build के हिसाब से average	Claude Opus 4.8 (`n=11`)	GPT-5.6 (`n=10`)
cost	$3.06	$2.22
runtime	8 मिनट 00 सेकंड	3 मिनट 42 सेकंड
input tokens	26 लाख	17 लाख
output tokens	33,000	17,100
visual score	0.936	0.970

GPT-5.6 ने page को 2.2 गुना तेजी से पूरा किया, cost 27% कम रही, और output tokens भी लगभग आधे ही इस्तेमाल हुए
generated code की मात्रा भी कम थी
- एक paired comparison में Opus ने ज्यादातर unused color families सहित 174 CSS variables और 17,957 characters की globals.css generate की
- GPT-5.6 ने 45 CSS variables और 2,508 characters इस्तेमाल करते हुए भी similar या बेहतर rendering result दिया
design quality और consistency
- GPT-5.6 साफ-सुथरे और dense grid वाले layouts में मजबूत है, लेकिन जोरदार guidance न मिले तो उसी style की ओर converge करने की tendency रखता है
- Opus 4.8 के लिए design किए गए पुराने harness में वह existing design system को ignore करके अक्सर clean लेकिन generic output generate करता था
- design team और engineering team ने model guidance का तरीका बेहतर करने के बाद production के लिए जरूरी brand-compliance standards पूरे किए

tool calls में optional parameters की handling

agent के code tool में 25 top-level parameters हैं, जिनमें सिर्फ action required है और बाकी optional हैं
Claude सिर्फ इस्तेमाल होने वाले 2–3 parameters भेजता है, लेकिन GPT-5.6 हर call में सभी 25 भेजता है और unused fields को भी offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000" जैसी plausible values से भर देता है
3 दिनों तक collect किए गए production code(read) execution traces में भी यही pattern दिखा

model	calls	सभी 25 properties शामिल करने वाले calls
`gpt-5.6`	6,635	6,635 cases, 100%
`claude-opus-4.8`	2,898	4 cases, 0.1%
`claude-sonnet-5`	1,933	0 cases

empty file reads का कारण
- समस्या सिर्फ arguments के verbose होने की नहीं थी, बल्कि यह थी कि file read implementation model द्वारा बनाई गई arbitrary values और user-intended values में फर्क नहीं कर पा रहा था
- implementation ने offset: 0 को real argument की तरह treat किया, और GPT-5.6 file reads के 52–64% empty results लौटाने लगे
- tool valid reads और empty reads दोनों पर success: true लौटाता था, इसलिए model को पता नहीं चलता था कि वह empty file पढ़ रहा है
- empty results की भरपाई करने के लिए उसने और ज्यादा calls किए, जिससे result quality भी खराब हुई
prompt और strict mode से solve न हुई समस्या
- tool description में unused parameters omit करने की instruction देने पर भी सभी 25 generate होते रहे
- हर property पर OPTIONAL, omit if unused जोड़ने पर भी behavior नहीं बदला
- OpenAI के strict mode में भी यही result आया, और इसे adopt करने के लिए सभी schemas से pattern, format और array size validations हटाने पड़ते
- यह behavior model के function calling generate करने के तरीके से आता है, इसलिए prompt की जगह schema बदला गया
provider boundary पर schema transformation
- OpenAI-series models के लिए सभी optional properties को anyOf: [T, null] form वाली required, nullable properties के रूप में फिर से लिखा गया
- model unused parameters को explicit null से भरता है, और shared tool-call boundary पर validation से पहले null हटा दिए जाते हैं
- tool implementation बदले बिना सिर्फ model-facing schema में unused values को express करने की सुविधा दी गई
```
// बदलाव से पहले: सभी 25 keys arbitrary values से भर जाती थीं
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// बदलाव के बाद: 4 real values और 21 null भेजे जाते हैं, और tool execution से पहले null हटाए जाते हैं
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
```
- बदलाव के बाद empty file reads 52% से 0% पर आ गए
- समान task के लिए जरूरी tool calls भी लगभग 30% घटे, क्योंकि empty results को बार-बार पढ़ने वाला behavior खत्म हो गया

OpenAI approach के मुताबिक prompt caching

दोनों providers prompt caching देते हैं, लेकिन implementation अलग-अलग है
इस अंतर को account में लेने से पहले GPT-5.6 Opus से करीब 50% महंगा दिख रहा था, लेकिन कारण model pricing नहीं, बल्कि cache configuration था
Anthropic का organization-level cache
- agent prompt करीब 29,000-token static prefix से शुरू होता है, जिसमें tool schema और core system prompt शामिल हैं, और यह सभी conversations में समान रहता है
- Claude में cache_control से cache breakpoints mark किए जाते हैं और prefix पूरे organization में share होता है
- किसी भी workspace की conversation एक shared entry इस्तेमाल कर सकती है, और per-key throughput limit भी नहीं है
- cache hit rate 92–96% है
GPT-5.6 में बदला हुआ cache behavior
- पुराने GPT models implicitly partial prefix match cache करते थे, लेकिन GPT-5.6 ने partial prefix matching हटाया
- implicit cache latest message के आधार पर full prompt item बनाता है, इसलिए समान 29,000-token static prefix share करने वाली नई conversation में भी first call पर cache hit rate 0% होता है
- इस कारण हर conversation में पूरे prefix को uncached rate पर फिर से charge किया जाता है
- application cache इस्तेमाल करे या नहीं, GPT-5.6 हर uncached prompt पर 1.25x cache-write surcharge लगाता है
explicit cache keys की constraints
- explicit caching के लिए prompt_cache_breakpoint और required prompt_cache_key चाहिए
- key भी cache identity में शामिल होती है, इसलिए same prompt होने पर भी key अलग हो तो hit नहीं होता
- हर key एक cache node पर map होती है जो प्रति मिनट करीब 15 requests handle करता है; इससे अधिक होने पर OpenAI traffic को independent cold cache वाले दूसरे node पर distribute करता है
- इसलिए key किस unit पर set की जाए, यह key design decision बन जाता है
- conversation-level key: नई conversation shared prefix को hit नहीं कर पाई, इसलिए first-call hit rate 0% था
- एक global key: सभी requests एक node पर hash होती हैं, और production traffic 15 rpm से ऊपर जाने पर cold nodes में overflow होता है
- workspace-level key: customer workspace की सभी conversations entries share करती हैं और per-key traffic कम रहता है
workspace-level hierarchical cache
- actual configuration ws:{workspaceId} form वाली workspace-level key इस्तेमाल करती है और system prompt को breakpoint layers में बांटती है
- entry A tools और static prefix रखती है, ताकि session के first call की cost कम हो
- entry B static prefix में workspace context जोड़ती है
- entry C first turn से latest message तक की session-specific full prompt chain है
- workspace memory बदलने पर entry B miss होती है, लेकिन entry A hit रहती है, इसलिए पूरे 29,000 tokens के बजाय सिर्फ बदले हुए context size को फिर से लिखा जाता है
- entry C prompt के strictly append-only structure के कारण session के अंदर OpenAI की implicit full prompt chain का उपयोग करती है
- OpenAI की key partitioning के कारण static prefix को workspaces के बीच share नहीं किया जा सकता
- इसके विपरीत Anthropic key partitioning के बिना organization-level cache का उपयोग करता है, इसलिए prefix sharing संभव है
- GPT-5.6 में हर workspace idle interval के दौरान 29,000 tokens को एक बार cold write करता है, जिसकी cost करीब $0.18 है
- यह cost limited scope में है और predictable है
cache changes के results
- first-call cache hit rate करीब 0% से 83.7% तक बढ़ा
- total uncached input tokens 28% घटे
- GPT-5.6 की per-evaluation-suite cost Opus से कम हो गई, और initial cost gap पूरी तरह गलत cache configuration से आया था
- अगर एक model cold cache से शुरू हो और दूसरे के साथ ऐसा न हो, तो दोनों models की cost comparison valid नहीं होती

reasoning replay को self-contained बनाना

GPT-5.6 Responses API default रूप से पिछले turns की reasoning को server-side item references के रूप में replay करता है, और production conversations में कभी-कभी Item 'rs_...' not found error आया
store: false set करने पर SDK encrypted reasoning content request करता है और server state की ओर point करने वाले pointer के बजाय self-contained blob replay करता है
application द्वारा भेजे गए bytes append-only structure में हों, तब भी server-side reasoning state valid prompt को बदल सकती है
evaluation harness, tool schema, prompt cache और reasoning replay—सबको ठीक करने के बाद GPT-5.6 Sol अब Ploy का production default model है

1 टिप्पणियां

GN⁺ 7 시간 전

Hacker News की रायें

“इतने आंकड़ों के साथ तो मॉडल को सच में migrate करना बनता है” जैसी पंक्ति बहुत हास्यास्पद है। जिसने यह लेख लिखवाया, काश उसने कम-से-कम टिपिकल LLM style को ही थोड़ा ठीक कर लिया होता
Colon, comma और full stop से छोटे-छोटे वाक्यांश जोड़ने का तरीका भी खराब और झुंझलाने वाला है। GPT-5.6 में partial prefix match cache हट जाने जैसी अच्छी insights हैं, लेकिन यह पढ़ने में आसान लेख नहीं है
- इसलिए AGENTS.md या CLAUDE.md के बगल में हमेशा WRITING.md रखता हूं। ज्यादातर लोग मॉडल को सिर्फ यह बताते हैं कि क्या बनाना है, कैसे लिखना है यह लगभग नहीं बताते, लेकिन LLM साफ-साफ दिए गए style निर्देशों का हैरान करने वाली अच्छी तरह पालन करते हैं
  बेकार के colon, लंबे dash, emphasis के नाम पर sentence fragments और वे grammar mistakes जिनकी मुझसे अक्सर गलती होती है, उनसे बचने के नियम लिखे हैं। साथ ही तकनीकी writing साफ, conversational और बिना दिखावे की हो, इसके लिए Brian Kernighan और Rob Pike को भी reference के तौर पर रखा है। दस्तावेज़ सिर्फ पढ़ने योग्य नहीं, पढ़ने की इच्छा जगाने वाले भी होने चाहिए
  अगर आप अक्सर दस्तावेज़ generate करते हैं, तो agent से WRITING.md reference करवाना बहुत मूल्यवान है। कई बार readability नए मॉडल पर switch करने से कहीं ज्यादा सुधरती है, और मॉडल बदलने पर भी style consistent रखा जा सकता है
- खासकर अगर वह AI company हो तो यह और खराब दिखता है। इसका मतलब यही हो सकता है कि वे मॉडल का पर्याप्त उपयोग नहीं करते इसलिए उसकी खास style नहीं पहचानते, या उन्हें यह अहसास नहीं कि यह महत्वपूर्ण है, या वे broader context नहीं समझते, या पाठकों का सम्मान नहीं करते—इनमें से कोई भी अच्छी बात नहीं है
- पढ़ने का तरीका गलत है। LLM से कहिए कि वह आपकी style preference के हिसाब से पढ़े और summarize करे। इससे भी आगे, खुद कुछ भी मत पढ़िए; agent से उसे बाद में reference करने के लिए skill file में बदलवा दीजिए
- अगर मुझे शक हो कि कोई लेख LLM से लिखा गया है, तो मैं तुरंत पढ़ना बंद कर देता हूं और अपने LLM tool से उसे summarize या rewrite करवा लेता हूं। तब कम-से-कम output style पर कुछ हद तक नियंत्रण तो रहता है
- मेरे मौजूदा claude.md में मैंने “load-bearing” expression को ban किया है, और Claude को यह सच में नापसंद है। कभी-कभी comments में “load-be…most specific” जैसे तरीके से चिढ़ाने तक लगता है, क्योंकि उसे यह expression हद से ज्यादा पसंद है
पहले 5.4-nano और mini पर चल रहे कई तरह के छोटे और simple workflows को 5.6 पर move किया, तो कुल मिलाकर लेख में बताए range जितना improvement मिला, और कुछ classification tasks में quality भी बेहतर हुई
कई कंपनियों में ऐसे model upgrade असल में code की एक line बदलने जैसा होता है। core workflows के लिए हम बढ़िया model router architecture इस्तेमाल करते हैं, लेकिन simple tasks के लिए इतना setup करना worthwhile नहीं है, और reliability issues भी सोचने पड़ते हैं
- इस लेख का मुख्य point यही है कि model upgrade code की एक line बदलना नहीं था
- कौन-सा SDK इस्तेमाल कर रहे हैं? या in-house implementation है?
- Sol को पहली बार इस्तेमाल करने का उद्देश्य हमारे workflows में 5.6 evaluate करना था। पहले simple models की quality कम थी, इसलिए हम सभी tasks के लिए 5.5 इस्तेमाल करते थे; अब हम खराब source data से explicit और implicit structured data निकालने के लिए text और images को साथ में analyze करते हैं
  मोटे तौर पर यह advertised तरीके से काम करता है। अभी ज्यादातर काम terra को भेजने से cost आधी हो गई है और response time भी 50% सुधरा है। luna का उपयोग OpenCV detection results को supplement करने के लिए होता है; उसकी functionality बहुत limited है, लेकिन वह तेज है और लगभग मुफ्त के बराबर है। हमारे tasks में Sol, terra से बस थोड़ा ही बेहतर था
  Sol ultra ने evaluation खुद भी बहुत अच्छी तरह किया। उसने practical recommendations के साथ outputs की list बनाई जिन्हें manually check और compare करना था, और original/processed data तथा query-wise CPM वाली बड़ी सामग्री तैयार की। Pro subscription fee के अलावा कुछ extra खर्च किए बिना कुछ घंटे चलाने के बाद cost basis 50% कम हुआ और throughput 100% बढ़ा
मेरा अनुभव भी ऐसा ही है। OpenRouter जैसी failover को feature बताने वाली services sandbox testing के अलावा लगभग बेकार हैं। production models सच में एक-दूसरे के साथ interchangeable नहीं होते, और serious agentic tasks चलाने वाला execution environment उम्मीद से कहीं ज्यादा model-specific characteristics पर depend करता है
कोई दूसरा मॉडल बिना error के चल भी जाए, तो performance और efficiency अलग बात है। Claude family जैसे कुछ models में system prompt को training के दौरान familiar हुए expression patterns के हिसाब से adjust करना पड़ता है, जबकि कुछ models दूसरे delimiters पर बेहतर काम करते हैं। अगर optimal performance मायने रखती है, तो execution environment, prompt और model को एक system की तरह देखना चाहिए; इन्हें parts की तरह freely replaceable नहीं मानना चाहिए
- LLMOps के हिस्से के रूप में tool execution paths वगैरह को ठीक से test करने वाला failover plan बनाना चाहिए। तब आप पर्याप्त अच्छे models को सस्ते से महंगे क्रम में रखकर मनचाहा failover implement कर सकते हैं
  model -> {{prompts}, {tools descriptions}, ...} जैसी mapping table बनाते हुए भी देखा है, लेकिन वह बहुत extreme है। किसी point के बाद model को हमारे prompts के हिसाब से adapt करना चाहिए, और जो मॉडल ऐसा नहीं कर पाते उन्हें failover candidates से हटाकर API request न भेजना ही ठीक है
- OpenRouter किसी दूसरे model पर failover नहीं करता, बल्कि उसी model को provide करने वाले दूसरे provider पर switch करता है
गहरे infrastructure insights से भरे लेख के नीचे आधे comments का सिर्फ जबरन थोपी गई writing style की आलोचना करना ironic है। भले ही Claude ने sentences polish करने में मदद की हो, अगर उसमें API budget 30% कम करने और empty file reads fix करने की तुरंत इस्तेमाल योग्य blueprint है, तो क्या वह ज्यादा important नहीं है?
- AI से जुड़ी किसी भी चीज़ से नफरत करने वाले लोग बस कमी निकाल रहे होंगे, लेकिन कुछ लोग सच में उस style को tolerate नहीं कर पाते और उसी में अटक जाते होंगे
  व्यक्तिगत रूप से style पर बड़बड़ाना मुझे मजाकिया लगता है। शायद क्योंकि मेरी grammar और spelling कमजोर हैं, मैं delivery से ज्यादा concepts, facts और arguments जैसे core content पर ध्यान देता हूं। grammar और spelling पेड़ हैं; मुद्दा जंगल है
  मेरे writing में ज्यादा errors नहीं होते तो वह dictation और खुद बनाए shortcuts की वजह से है। selected text को local LLM से correct कराकर replace कर देता हूं, और इन दो tools जितना मेरी quality of life और writing quality बढ़ाने वाली चीज़ कोई नहीं रही
“आज से Ploy एजेंट आज सुबह जारी हुए GPT-5.6 Sol का इस्तेमाल करता है” — तो क्या सिर्फ़ आधे दिन की टेस्टिंग के आधार पर स्विच कर दिया गया? क्या कंपनी किशोर चला रहे हैं?
- असल में कर्मचारियों की संरचना Staff और Senior Staff स्तर के लोगों के ज़्यादा करीब है। YC संबंधों के ज़रिए उन्होंने GPT-5.6 preview model को करीब एक हफ़्ते तक टेस्ट किया और feedback दिया
  मूल्यांकन वाले काम GitHub CI में चलते हैं, और ploy.ai जिन web design और marketing tasks में विशेषज्ञ है, उनके 115+ evaluations का पूरा set करीब 15 मिनट में चलाया जा सकता है। PostHog feature flag से model enable करने के बाद failures को सक्रिय रूप से monitor किया गया
  Webflow चलाने से मिली जानकारी—जो internet के 1% से ज़्यादा को support करता है—को Ploy में जितना हो सके उतारकर वे और बड़े हिस्से के internet को support करना चाहते हैं
- इस तरह की पोस्ट लिखने लायक evaluation करने के लिए उन्हें कुछ हद तक early access मिला होने की पूरी संभावना है
- अब evaluations और benchmarks बनाना और उन्हें नए models पर चलाना काफ़ी आसान हो गया है। LLM को बदलना आसान है, इसलिए अच्छा evaluation set बहुत उपयोगी होता है, और कभी-कभी improvement इतना साफ़ होता है कि evaluation की भी ज़रूरत नहीं पड़ती
- उम्मीद है कि उनके पास नए model की तुलना के लिए production-based dataset होगा
कहा जाता है कि Ploy agent असली marketing websites बनाता और edit करता है—planning, codebase पढ़ना, components लिखना, image generation, अपने results की screenshot लेना और completion judge करना तक करता है—लेकिन सख़्त testing न की गई हो तब भी मेरा अनुमान है कि marketing sites बनाने में Fable, Opus से कहीं बेहतर होगा। Presentation materials बनाने में तो यह निश्चित रूप से बहुत बेहतर है
- Design के मामले में GPT-5.6, Fable से बहुत बेहतर है
- 4.7 में instructions को ज़रूरत से ज़्यादा literal तरीके से follow करने की प्रवृत्ति है, इसलिए मूल लेख का result भी काफ़ी plausible है
सिर्फ़ OpenAI-family models के लिए optional properties को सब required बनाकर anyOf: [T, null] से null allow करने वाला workaround कुछ गड़बड़-सा लगता है। मैंने MCP का केवल modified form इस्तेमाल किया है, लेकिन यह साफ़ नहीं है कि TypeScript type definitions agent से inference backend को भेजे जाने वाले JSON Schema को क्यों प्रभावित करती हैं
MCP spec में optional parameters दर्शाने वाला field साफ़ तौर पर मौजूद है, इसलिए TypeScript layer और वास्तव में भेजे जाने वाले tool description के बीच कहीं bug लगता है। हो सकता है inference backend “valid tool response generate करना” से “ऐसे JSON Schema के हिसाब से valid response generate करना जिसमें optional parameters नहीं हैं” पर बदल गया हो, लेकिन actual request देखे बिना तय नहीं किया जा सकता
- यह schema generation या TypeScript bug नहीं, बल्कि OpenAI function calling का internal behavior है। Tool use के लिए fine-tuned weights यथासंभव complete data structure output करने की कोशिश करते हैं। System prompt context में model parameter names देखता है तो required array में न होने पर भी value भरने की कोशिश करता है
- Fable, Opus और 5.6 सहित नए frontier models tool calls में काफ़ी loose होते हैं और अक्सर schema को exact follow नहीं करते। Pi के edit/replace tool calls में Claude model द्वारा nonexistent properties बना देने के उदाहरण https://lucumr.pocoo.org/about/ पर देखे जा सकते हैं
  कारण का एक हिस्सा शायद constrained decoding इस्तेमाल करने पर intelligence घटने की समस्या से जुड़ा है। Schema validity तो guarantee हो जाती है, लेकिन capability काफ़ी गिरती है, इसलिए classification, summarization और prompt improvement के लिए ठीक है, पर agent loop execution में सावधानी चाहिए
  Claude Code जैसे runtime environments preprocessing, recovery, cleanup आदि बहुत करते हैं, लेकिन आमतौर पर यह दिखता नहीं। Perfect accuracy assume करके force करने के बजाय runtime environment को ज़्यादा loose बनाकर model-specific traits के हिसाब से ढालना production में आसान और बेहतर होता है। Models भी हर एक-दो महीने में बदल जाते हैं। यही vibe-based applied AI है
Opus और Sol से एक site बनाने की वास्तविक लागत कितनी आती है, इसका rough amount जानना चाहूंगा
Workflow को Reasonix पर ले जाकर और DeepSeek में cache hits का लाभ उठाकर, बिना subsidy वाले US providers इस्तेमाल करने पर भी request cost लगभग free जैसी हो गई
- आप कौन-सा setup इस्तेमाल कर रहे हैं, और Pi की तुलना में यह कैसा है?
सभी Ploy workspaces में GPT-5.6 Sol को default बनाने के बजाय actual tools संभालने वाले कुछ कामों के लिए Luna पर विचार किया जा सकता है। यह हैरान करने वाली हद तक capable और fast है
Sol लोगों से बातचीत करने और agent calls orchestrate करने में बढ़िया है, लेकिन हर काम के लिए इस्तेमाल करने के लिहाज़ से बहुत महंगा है। Sol की एक run की कीमत में Luna को पाँच बार चलाया जा सकता है, और statistically sample एक से पाँच होने का फ़र्क़ काफ़ी बड़ा होता है
- अगर Luna run के हर step के सही होने की संभावना 90% है, तो पाँचों steps के सही होने की संभावना 0.9^5 = 0.59, यानी 59% है। Sol की एक run की accuracy शायद लगभग 95% हो। Actual numbers अलग हो सकते हैं, लेकिन आख़िर में Sol से verify करना ज़्यादा सस्ता पड़ सकता है
- Sub-agents के साथ हमेशा यह समस्या रहती है कि वे एक-दूसरे से isolated होते हैं। Context छोटा रखने और focused रहने का फ़ायदा है, लेकिन अपना काम जारी रखने के लिए हर एक को फिर से investigate करना पड़ता है, जिससे अक्सर uncached tokens खर्च होते हैं
  किस task में कितने agents इस्तेमाल होते हैं, इस पर निर्भर करते हुए लागत ज़्यादा हो सकती है और result उल्टा खराब भी हो सकता है

प्रोडक्शन AI एजेंट को GPT-5.6 पर माइग्रेट कर 2.2 गुना तेज और 27% सस्ता बनाने की प्रक्रिया

Claude Opus की जगह GPT-5.6 Sol

evaluation numbers पर भरोसा करने से पहले harness ठीक करना

मौजूदा model के call pattern के हिसाब से बनी constraints

implicit score thresholds

corrected benchmark results

design quality और consistency

tool calls में optional parameters की handling

empty file reads का कारण

prompt और strict mode से solve न हुई समस्या

provider boundary पर schema transformation

OpenAI approach के मुताबिक prompt caching

Anthropic का organization-level cache

GPT-5.6 में बदला हुआ cache behavior

explicit cache keys की constraints

workspace-level hierarchical cache

cache changes के results

reasoning replay को self-contained बनाना

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

1 टिप्पणियां

Hacker News की रायें