நான் புத்திசாலித்தனமாகச் செயல்படுகிறேன் என்று நினைத்தேன். எங்கள் AI பைப்லைனுக்காக (pipeline) கான்டெக்ஸ்ட் விண்டோவின் (context window) சரியாக முப்பது சதவீதத்தை சிந்தனைக்கான பட்ஜெட்டாக (thinking budget) ஒதுக்கும் ஒரு ஹெல்ப்பர் ஃபங்ஷனை (helper function) நான் எழுதினேன். அது சுத்தமாகவும், கணிக்கக்கூடியதாகவும், Opus 4.5-இல் மிகச் சிறப்பாகவும் செயல்பட்டது. ஆனால் நான் Opus 4.8-க்கு மாறியபோது, ஒவ்வொரு கோரிக்கையும் (request) 400 பிழையுடன் (error) தோல்வியடைந்தது. நான் கவனமாகத் தயாரித்த டோக்கன் கணக்கீடு (token math) ஒரே இரவில் குப்பையாக மாறிவிட்டது.
பழைய முறை எளிமையானது. நீங்கள் ஒரு budget_tokens மதிப்பை அமைப்பீர்கள், மாடல் அந்த வரம்பிற்குள் பொருந்தும்படி தனது சிந்தனையைச் சரிசெய்து கொள்ளும். நான் 128K கான்டெக்ஸ்டை வழங்கினால், எனது குறியீடு (code) பகுப்பாய்விற்காக (reasoning) தோராயமாக 38,000 டோக்கன்களை ஒதுக்கி, மீதமுள்ளவற்றை பதிலுக்காக விட்டுவிடும். இது ஒரு காரை வேக வரம்பிற்குள் வைத்திருப்பதைப் போலப் பொறுப்பானதாகத் தோன்றியது.
அந்த மாடல் இப்போது இல்லை. Opus 4.7 மற்றும் 4.8 போன்ற புதிய வெளியீடுகள் 'அடாப்டிவ் திங்கிங்' (adaptive thinking) முறையைப் பயன்படுத்துகின்றன. நீங்கள் இனி ஒரு எண்ணைத் தேர்ந்தெடுக்கத் தேவையில்லை. அதற்குப் பதிலாக, ஒரு 'எஃபர்ட் நாப்' (effort knob) வழங்க வேண்டும். இது பெயரில் மாற்றம் செய்வது போலத் தோன்றலாம், ஆனால் இந்த இரண்டு கட்டுப்பாடுகளும் முற்றிலும் மாறுபட்டவை. budget_tokens என்பது மாடல் எவ்வளவு சிந்திக்க அனுமதிக்கப்படுகிறது என்பதற்கான ஒரு கடினமான உச்சவரம்பை (hard ceiling) நிர்ணயித்தது. 'எஃபர்ட்' (Effort) என்பது மாடல் எவ்வாறு சிந்திக்கிறது மற்றும் செயல்படுகிறது என்பதைக் கட்டுப்படுத்துகிறது. ஒன்று எரிபொருள் பம்ப் மீட்டர் (gas pump meter) போன்றது, மற்றொன்று இன்ஜின் மேப் (engine map) போன்றது.
முயற்சியை (Effort) நிஜ வேலைகளுக்குப் பொருத்துதல்
கட்டுப்பாடு மாறியபோது, எனது பழைய உள்ளுணர்வு வேலை செய்யவில்லை. ஒவ்வொரு அமைப்பும் (setting) உண்மையில் எதை வழங்குகிறது என்பதை நான் மீண்டும் கற்றுக்கொள்ள வேண்டியிருந்தது. ஒவ்வொரு எஃபர்ட் அளவும் (effort level) நடைமுறையில் எங்கு அமைகிறது என்பதைக் கண்டறிய எங்கள் உள்ப்பயன்பாட்டு டிராஃபிக்கில் (internal traffic) சோதனைகளை நடத்தினேன்.
வகைப்படுத்துதல் மற்றும் வழிநடத்துதல் (Classification and routing) எப்போதும் low முயற்சியையே பயன்படுத்த வேண்டும். இவை விரைவான முடிவுகள் எடுக்கும் வேலைகள். இது ரீஃபண்ட் கோரிக்கையா அல்லது விற்பனை தொடர்பான கேள்வியா? இந்த லாக் என்ட்ரி (log entry) அடுத்த கட்டத்திற்குத் தேவைப்படுகிறதா? இதற்கு நீண்ட உரையாடல் தேவையில்லை. low முயற்சி தாமதத்தைக் (latency) குறைப்பதோடு, செலவையும் மிகக் குறைவாக வைத்திருக்கும்.
பெரும்பாலான ஆப் டிராஃபிக் (Most app traffic), அதாவது சுருக்கங்கள் (summaries), மறுபதிப்பு (rewrites), ஆதரவு பதில்கள் (support replies) மற்றும் உள்ளடக்கப் பிரித்தெடுத்தல் (content extraction) போன்ற அன்றாட வேலைகளுக்கு medium முதல் high முயற்சி வரை பொருத்தமானது. இது ஒரு சமநிலைப் புள்ளி. ஒரு வேலையைச் செய்ய நீண்ட சிந்தனைத் தொடர் (chain of thought) தேவையில்லை என்றாலும், உண்மையான தெளிவற்ற தன்மைகளைத் தீர்க்க மாடலுக்குப் போதுமான இடம் கிடைக்கும்.
கோடிங் மற்றும் ஏஜென்டிக் லூப்கள் (Coding and agentic loops) xhigh முயற்சி தேவைப்படும். இங்குதான் தவறுகள் பெருகிக்கொண்டே இருக்கும். ஒரு டூல்-காலிங் லூப்பின் (tool-calling loop) முதல் சுற்றிலேயே மாடல் ஒரு தவறான திட்டத்தை எழுதினால், அடுத்த மூன்று படிகளில் அந்தத் தவறைச் சரிசெய்யவே அது நேரத்தைச் செலவிடும். அல்லது அதைவிட மோசமாக, அது தவறான டூல்களைப் பயன்படுத்தலாம், தவறான அளவுருக்களை (parameters) உருவாக்கலாம் (hallucinate), மேலும் பயனர் ஒரு முடங்கிய பணிப்பாய்வை (broken workflow) பார்த்துக்கொண்டிருக்க வேண்டியிருக்கும். ஆரம்பத்திலேயே சிறந்த பகுப்பாய்வு (reasoning) இருந்தால் இத்தகைய சிக்கல்களைத் தவிர்க்கலாம்.
முக்கியமான பணிகள் (Critical tasks) max முயற்சியைப் பெற வேண்டும். இதை எல்லாவற்றிற்கும் பயன்படுத்த வேண்டாம். ஒரு தவறான பதில், டோக்கன் கட்டணத்தை விட அதிக இழப்பை ஏற்படுத்தும் தருணங்களுக்காக இதைச் சேமித்து வைக்கவும். நிதித் தீர்வு (Financial reconciliations), பாதுகாப்புச் சோதனைகள் (safety checks), கட்டமைப்பு முடிவுகள் (architecture decisions) மற்றும் மருத்துவத் தரம் பிரித்தல் (medical triage) ஆகியவை இதற்குச் சரியானவை. ஒரு பிழை ஏற்பட்டால், ஒரு மனிதன் பல மணிநேரம் அந்தச் சிக்கலைச் சரிசெய்ய வேண்டியிருந்தால், கூடுதல் சிந்தனைக்கான கட்டணத்தைச் செலுத்தத் தயங்காதீர்கள்.
செலவில் ஏற்பட்ட ஆச்சரியம்
எனது புரிதலை மாற்றிய பகுதி இதுதான். அதிகபட்ச முயற்சி (max effort) எப்போதும் எனது செலவை அதிகரிக்கும் என்று நான் நினைத்தேன். ஒரு தனிச் சுற்றில் (single turn), அது உண்மைதான். பகுப்பாய்வுத் தடயங்கள் (reasoning trace) நீளமாக இருக்கும். ஆனால் பல படிகளைக் கொண்ட ஏஜென்டிக் பணிகளில் (multi-step agentic tasks), மொத்தக் கட்டணம் பெரும்பாலும் குறைந்தது.
மாடல் முதல் முயற்சியிலேயே சிறப்பாகத் திட்டமிடுகிறது. இது குறைவான டூல் அழைப்புகளை (tool calls) செய்கிறது. தேவையற்ற திசைமாற்றங்களைத் தவிர்க்கிறது. வழக்கமாக ஐந்து சுற்றுகள் தேவைப்படும் ஒரு டேட்டா எக்ஸ்ட்ராக்ஷன் ஏஜென்ட் (data extraction agent), மாடல் ஆரம்பத்திலேயே ஸ்கீமாவை (schema) சரியாகப் புரிந்துகொள்ளப் போதுமான பகுப்பாய்வு இடத்தைப் பெற்றதால், இரண்டு சுற்றுகளிலேயே முடிவடைவதைக் கண்டேன். நீங்கள் செலவைக் கணக்கிடும்போது, கோரிக்கையை (request) மட்டும் பார்க்காமல், வேலையின் முடிவை (job completion) கவனியுங்கள். ஒரு படிக்கு அதிக சிந்தனை பட்ஜெட் இருப்பது, ஒட்டுமொத்தமாக குறைவான படிகளையே குறிக்கலாம்.
மற்றவற்றைச் சிதைக்காமல் எவ்வாறு மாற்றுவது (Migrate)
உங்கள் குறியீட்டில் (codebase) இன்னும் budget_tokens இருந்தால், அதிலிருந்து வெளியேறுவதற்கான சரியான வழி இதோ. படி மூன்று மற்றும் ஐந்தைத் தவிர்க்காதீர்கள். நான் அவற்றைத் தவிர்த்தேன், அதனால் ஒரு மதிய நேரத்தை பிழைத்திருத்தத்திற்காக (debugging) செலவிட வேண்டியிருந்தது.
உங்கள் குறியீட்டில் budget_tokens-ஐத் தேடுங்கள். ஒவ்வொரு இடத்திலும் அதை நீக்க வேண்டும். புதிய மாடல்களில் இந்த அளவுரு (parameter) வேலை செய்யாது மற்றும் இது 400 பிழையைத் தரும்.
பட்ஜெட் ஆப்ஜெக்ட்டிற்குப் பதிலாக ஒரு அடாப்டிவ் திங்கிங் பிளாக்கை (adaptive thinking block) மாற்றவும். thinking: { type: "adaptive" } என்பதைப் பயன்படுத்தவும்.
ஒவ்வொரு அழைப்பிற்கும் (call) தெளிவான முயற்சி அளவோடு output_config-ஐச் சேர்க்கவும். உங்கள் டிராஃபிக் கலவையாக இருந்தால், இதை உலகளாவிய இயல்புநிலையாக (global default) விட்டுவிடாதீர்கள். உங்கள் லேசான வகைப்பாட்டு முனைப்பு (lightweight classification endpoint), உங்கள் கோடிங் ஏஜென்ட்டின் அதே முயற்சி அமைப்பைப் பெறக்கூடாது. அழைக்கும் இடத்திலேயே அதைத் தெளிவாகக் குறிப்பிடவும்.
உங்கள் பட்ஜெட் கணக்கீட்டு ஹெல்பரை (budget calculation helper) நீக்கவும். எனக்குத் தெரியும், அதற்கு யூனிட் டெஸ்ட்கள் (unit tests) இருக்கலாம். எனக்கும் இருந்தன. ஆனால் இப்போது அது தேவையற்ற சுமை. பிளாட்ஃபார்ம் உங்கள் டோக்கன் கணக்கீட்டை விரும்பவில்லை. மாடல் தனது வேகத்தை (pacing) தானே கையாண்டு கொள்ளும்.
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.