مجھے لگا میں بہت چالاک بن رہا ہوں۔ میں نے ایک ہیلپر فنکشن (helper function) لکھا تھا جس نے ہمارے AI پائپ لائن (pipeline) کے لیے کنٹیکسٹ ونڈو (context window) کا ٹھیک تیس فیصد حصہ 'تھنکنگ بجٹ' (thinking budget) کے طور پر ریزرو کر لیا تھا۔ یہ صاف ستھرا، قابلِ پیش گوئی اور Opus 4.5 پر بہترین کام کر رہا تھا۔ پھر میں نے Opus 4.8 پر سوئچ کیا اور ہر ایک ریکویسٹ 400 error کے ساتھ ختم ہو گئی۔ میرا احتیاط سے تیار کردہ ٹوکن میتھ (token math) راتوں رات کچرا بن گیا۔
پرانا پیٹرن سادہ تھا۔ آپ ایک budget_tokens ویلیو سیٹ کرتے تھے اور ماڈل اس حد کے اندر رہنے کے لیے اپنی سوچ (thinking) کو تقسیم کر لیتا تھا۔ اگر میں 128K کنٹیکسٹ دیتا، تو میرا کوڈ ریژوننگ (reasoning) کے لیے تقریباً 38,000 ٹوکن نکال لیتا اور باقی جواب کے لیے چھوڑ دیتا۔ یہ ایک ذمہ دارانہ عمل لگتا تھا۔ جیسے گاڑی کو اسپیڈ لمٹ کے اندر رکھنا۔
وہ ماڈل اب ختم ہو چکا ہے۔ Opus 4.7 اور 4.8 جیسے نئے ورژن 'ایڈاپٹیو تھنکنگ' (adaptive thinking) استعمال کرتے ہیں۔ اب آپ کوئی نمبر منتخب نہیں کرتے۔ اس کے بجائے، آپ ایک 'ایفورٹ نوب' (effort knob) پاس کرتے ہیں۔ یہ سننے میں صرف نام کی تبدیلی لگتا ہے، لیکن یہ دونوں کنٹرولز ایک دوسرے سے بالکل مختلف ہیں۔ budget_tokens اس بات پر ایک سخت حد (hard ceiling) مقرر کرتا تھا کہ ماڈل کو کتنا سوچنے کی اجازت ہے۔ جبکہ 'ایفورٹ' (Effort) یہ کنٹرول کرتا ہے کہ ماڈل بنیادی طور پر کیسے سوچتا اور عمل کرتا ہے۔ ایک گیس پمپ کا میٹر ہے، تو دوسرا انجن کا میپ (engine map) ہے۔
ایفورٹ (Effort) کو حقیقی کام کے ساتھ جوڑنا
جب کنٹرول تبدیل ہوا، تو میرا پرانا اندازِ فکر کام کرنا چھوڑ گیا۔ مجھے دوبارہ سیکھنا پڑا کہ ہر سیٹنگ اصل میں کیا فراہم کرتی ہے۔ میں نے اپنے انٹرنل ٹریفک پر ٹیسٹ کیے تاکہ یہ معلوم کر سکوں کہ عملی طور پر ہر ایفورٹ لیول کہاں تک جاتا ہے۔
Classification and routing کے لیے تقریباً ہمیشہ low ایفورٹ استعمال کرنا چاہیے۔ یہ کام تیز فیصلے کرنے والے ہوتے ہیں۔ کیا یہ ریفنڈ کی درخواست ہے یا سیلز کا سوال؟ کیا اس لاگ انٹری کو آگے بھیجنے (escalation) کی ضرورت ہے؟ آپ کو طویل تقریر کی ضرورت نہیں ہے۔ low ایفورٹ لیٹنسی (latency) کو کم رکھتا ہے اور لاگت کو نہ ہونے کے برابر کر دیتا ہے۔
زیادہ تر ایپ ٹریفک، یعنی خلاصہ کرنا (summaries)، دوبارہ لکھنا (rewrites)، سپورٹ کے جوابات، اور مواد نکالنا (content extraction) جیسے روزمرہ کے کام، medium سے high ایفورٹ کے دائرے میں آتے ہیں۔ یہ توازن کا نقطہ ہے۔ ماڈل کو حقیقی ابہام (ambiguity) کو حل کرنے کے لیے کافی جگہ ملتی ہے بغیر ان ٹاسک پر ٹوکنز ضائع کیے جنہیں طویل 'چین آف تھاٹ' (chain of thought) کی ضرورت نہیں ہوتی۔
Coding and agentic loops کے لیے xhigh ایفورٹ کی ضرورت ہوتی ہے۔ یہ وہ جگہ ہے جہاں غلطیاں بڑھتی جاتی ہیں۔ اگر ماڈل ٹول کالنگ لوپ کے پہلے مرحلے میں ہی غلط منصوبہ بناتا ہے، تو وہ اگلے تین مراحل اس نقصان کی مرمت کرنے میں گزار دے گا۔ یا اس سے بھی برا، وہ غلط ٹولز کال کرے گا، پیرامیٹرز کے بارے میں غلط اندازہ (hallucinate) لگائے گا، اور صارف کو ایک ٹوٹے ہوئے ورک فلو کے ساتھ چھوڑ دے گا۔ شروع میں بہتر ریژوننگ اس طرح کے چکر سے بچاتی ہے۔
اہم کاموں (Critical tasks) کے لیے max ایفورٹ ہونا چاہیے۔ اسے ہر چیز کے لیے استعمال نہ کریں۔ اسے ان لمحات کے لیے مخصوص رکھیں جہاں غلط جواب کی قیمت کسی بھی ٹوکن بل سے زیادہ ہو۔ مالیاتی حساب کتاب (Financial reconciliations)، حفاظتی چیک، آرکیٹیکچر کے فیصلے، اور میڈیکل ٹریاج (medical triage) اس کے لیے موزوں ہیں۔ اگر کسی غلطی کا مطلب یہ ہے کہ انسان کو گھنٹوں تک اس الجھن کو سلجھانا پڑے گا، تو اضافی سوچنگ کے لیے ادائیگی کریں۔
لاگت کا حیران کن پہلو
یہ وہ حصہ ہے جس نے میرے ذہنی ماڈل کو بدل کر رکھ دیا۔ میں نے فرض کر لیا تھا کہ max ایفورٹ ہمیشہ میری لاگت کو بڑھا دے گا۔ ایک سنگل ٹرن (single turn) پر، ایسا ہی ہوتا ہے۔ ریژوننگ ٹریس (reasoning trace) لمبی ہوتی ہے۔ لیکن ملٹی سٹیپ ایجنٹک ٹاسک (multi-step agentic tasks) پر، کل بل اکثر کم ہو جاتا ہے۔
ماڈل پہلی کوشش میں بہتر منصوبہ بندی کرتا ہے۔ یہ ٹول کالز کم کرتا ہے۔ یہ خود کو غلط راستوں پر بھٹکنے سے روکتا ہے۔ میں نے ایک ڈیٹا ایکسٹریکشن ایجنٹ کو دیکھا جسے عام طور پر پانچ بار آگے پیچھے (back-and-forth) کرنے کی ضرورت پڑتی تھی، وہ صرف دو بار میں مکمل ہو گیا کیونکہ ماڈل کے پاس شروع میں ہی اسکیمہ (schema) کو درست طریقے سے سمجھنے کے لیے کافی ریژوننگ کی جگہ تھی۔ جب آپ لاگت کا اندازہ لگائیں، تو کام کی تکمیل (job completion) کو دیکھیں، نہ کہ صرف ایک ریکویسٹ کو۔ فی مرحلہ بڑا تھنکنگ بجٹ مجموعی طور پر کم مراحل کا باعث بن سکتا ہے۔
باقی چیزوں کو خراب کیے بغیر مائیگریٹ کیسے کریں
اگر آپ کے کوڈ بیس میں اب بھی budget_tokens موجود ہیں، تو یہاں سے نکلنے کا درست راستہ دیا گیا ہے۔ مرحلہ نمبر تین اور پانچ کو چھوڑنا مت۔ میں نے چھوڑا تھا، اور اس کی وجہ سے مجھے ڈی بگنگ (debugging) میں ایک پوری دوپہر ضائع کرنی پڑی۔
اپنے کوڈ میں budget_tokens تلاش کریں۔ ہر جگہ سے اسے ہٹانا ہوگا۔ نئے ماڈلز پر یہ پیرامیٹر ختم ہو چکا ہے اور یہ 400 error پیدا کرے گا۔
بجٹ آبجیکٹ کو ایڈاپٹیو تھنکنگ بلاک سے بدل دیں۔ thinking: { type: "adaptive" } استعمال کریں۔
ہر کال کے لیے ایک واضح ایفورٹ لیول کے ساتھ output_config شامل کریں۔ اگر آپ کی ٹریفک مکس ہے تو اسے گلوبل ڈیفالٹ پر نہ چھوڑیں۔ آپ کا ہلکا پھلکا کلاسیفیکیشن اینڈ پوائنٹ (classification endpoint) غلطی سے وہی ایفورٹ سیٹنگ وراثت میں نہ لے لے جو آپ کے کوڈنگ ایجنٹ کی ہے۔ کال سائٹ (call site) پر واضح رہیں۔
اپنے بجٹ کیلکولیشن ہیلپر کو ڈیلیٹ کر دیں۔ میں جانتا ہوں۔ شاید اس کے یونٹ ٹیسٹ (unit tests) بھی ہوں۔ میرے بھی تھے۔ لیکن اب یہ فالتو بوجھ ہے۔ پلیٹ فارم کو آپ کے ٹوکن میتھ کی ضرورت نہیں ہے۔ ماڈل اپنی رفتار خود سنبھالتا ہے۔
Strip out temperature, top_p, and top_k. On Opus 4.7 and 4.8, these sampling parameters will throw 400 errors. The platform removed them from this generation. Your old temperature-tuning tricks do not apply here, and leaving them in will silently break your migration.
Test each model individually. Opus 4.5 and 4.8 are different animals. A config that works on one will not necessarily work on the other. If you support multiple versions, branch your logic or treat them as separate backends.
Fixing the UI Freeze
There is one streaming behavior that will confuse your users if you do not handle it. On the new models, thinking blocks stream out but the text is empty by default. In your interface, this looks like a long, awkward pause with no visible progress. Users will assume the app hung.
To fix it, pass thinking: { type: "adaptive", display: "summarized" }. That gets you a visible progress indicator without dumping the raw thought stream into the chat window. Your frontend stays responsive and your users know something is happening under the hood.
The Real Lesson
I built an entire abstraction layer on top of a parameter the vendor never intended to last. I wrapped their settings in my own logic because I thought I understood the tradeoff better than the platform. I did not. Adaptive thinking is a better deal because the model actually decides when it needs to reason hard and when it can coast. My codebase is smaller now. The results got sharper. Sometimes the right engineering move is to delete the clever code and let the platform do its job.
If you want to read the original migration notes, you can find them here. For more hands-on discussions like this, join the GyaanSetu AI community on Telegram.