I thought I was being clever. I wrote a helper function that reserved exactly thirty percent of the context window as a

Nilidhani nilikuwa mjanja. Niliandika function ya msaada iliyohifadhi asilimia thelathini kamili ya dirisha la muktadha (context window) kama bajeti ya kufikiri kwa ajili ya mfumo wetu wa AI. Ilikuwa safi, inayotabirika, na ilifanya kazi vizuri sana kwenye Opus 4.5. Kisha nikahamia kwenye Opus 4.8 na kila ombi lilifeli kwa kosa la 400. Hesabu zangu za tokeni nilizozitengeneza kwa uangalifu ziligeuka kuwa takataka usiku mmoja.

Mfumo wa zamani ulikuwa rahisi. Unaweka thamani ya budget_tokens na model inadhibiti uwezo wake wa kufikiri ili uendane na kikomo hicho. Ikiwa nilitoa muktadha wa 128K, kodi yangu ingechukua takriban tokeni 38,000 kwa ajili ya ufikiri wa kimantiki (reasoning) na kuacha nyingine kwa ajili ya jibu. Ilionekana kama uamuzi wa kuwajibika. Kama vile kuendesha gari chini ya kikomo cha kasi.

Mfumo huo umepotea. Matoleo mapya kama Opus 4.7 na 4.8 yanatumia ufikiri unaobadilika (adaptive thinking). Huwezi tena kuchagua namba. Badala yake, unapita kiwango cha juhudi (effort knob). Hiyo inaonekana kama kubadilisha jina tu, lakini udhibiti huo uwili hauwezi kuwa tofauti zaidi. budget_tokens iliweka kikomo kigumu cha kiasi ambacho model iliruhusiwa kufikiri. Juhudi (Effort) inadhibiti jinsi model inavyofikiri na kutenda tangu mwanzo. Moja ni mita ya pampu ya mafuta. Nyingine ni ramani ya injini.

Kuunganisha Juhudi na Kazi Halisi

Wakati udhibiti ulipobadilika, hisia zangu za zamani ziliacha kufanya kazi. Ilinibidi nijifunze upya kile kila mpangilio unachonunua hasa. Nilifanya majaribio kwenye trafiki yetu ya ndani ili kupata mahali ambapo kila kiwango cha juhudi kinatua katika vitendo.

Uainishaji na uelekezaji (Classification and routing) unapaswa kutumia juhudi ya low karibu kila wakati. Kazi hizi ni maamuzi ya haraka. Je, hili ni ombi la marejesho au swali la mauzo? Je, ingizo hili la logi linahitaji kupelekwa juu? Huhitaji hotuba ndefu. Juhudi ya low huweka ucheleweshaji (latency) chini na gharama kuwa ndogo sana.

Mwingiliano mwingi wa programu, kazi za kila siku za muhtasari, uandishi upya, majibu ya msaada, na uchukuaji wa maudhui, unafaa kwa juhudi ya medium hadi high. Hapa ndipo kuna uwiano mzuri. Model inapata nafasi ya kutosha kutatua utata halisi bila kuchoma tokeni kwenye kazi ambayo haihitaji mfululizo mrefu wa mawazo (chain of thought).

Uandishi wa kodi na mizunguko ya agentic (Coding and agentic loops) yanahitaji juhudi ya xhigh. Hapa ndipo makosa yanapozidi. Ikiwa model itaandika mpango mbaya katika awamu ya kwanza ya mzunguko wa kuitia wazi zana (tool-calling loop), itatumia hatua tatu zinazofuata kurekebisha uharibifu huo. Au mbaya zaidi, itaita zana zisizo sahihi, itatengeneza vigezo vya uongo (hallucinate parameters), na kumwacha mtumiaji akitazama mfumo uliovunjika. Ufikiri bora wa awali huzuia mzunguko huo wa makosa.

Kazi muhimu zinapaswa kupata juhudi ya max. Usitumie hii kwa kila kitu. Iwekee nafasi nyakati ambazo jibu lisilo sahihi linagharimu zaidi kuliko bili yoyote ya tokeni. Uunganishaji wa kifedha, ukaguzi wa usalama, maamuzi ya usanifu, na upangaji wa matibabu (medical triage) ndiyo mahali sahihi. Ikiwa kosa linamaanisha binadamu anapaswa kutatua vurugu hiyo kwa saa nyingi, lipia ufikiri wa ziada.

Mshangao wa Gharama

Hapa ndipo palipovunja mtindo wangu wa kufikiri. Nilidhani juhudi ya max ingeongeza gharama zangu kila wakati. Katika hatua moja, inafanya hivyo. Mfululizo wa ufikiri (reasoning trace) ni mrefu zaidi. Lakini kwenye kazi za agentic za hatua nyingi, bili ya jumla mara nyingi ilipungua.

Model inapanga vizuri zaidi kwa jaribio la kwanza. Inafanya wito wa zana (tool calls) machache zaidi. Inajizuia kutangatanga kwenye njia zisizo na mwisho. Nilimwangalia wakala wa uchukuaji wa data ambaye kwa kawaida alihitaji hatua tano za kupeana na kupokea maelezo, akamaliza katika hatua mbili kwa sababu model ilikuwa na nafasi ya kutosha ya ufikiri ili kuchanganua schema kwa usahihi mwanzoni. Unapopima gharama, angalia ukamilishaji wa kazi, siyo ombi pekee. Bajeti kubwa zaidi ya kufikiri kwa kila hatua inaweza kumaanisha hatua chache zaidi kwa ujumla.

Jinsi ya Kuhamia Bila Kuharibu Vitu Vingine Vyote

Ikiwa bado una budget_tokens inayozurura kwenye kodi yako, hapa ndipo njia sahihi ya kutoka. Usiruke hatua ya tatu na ya tano. Mimi niliruka, na ilinigharimu mchana mzima wa kutafuta makosa (debugging).

Tafuta budget_tokens kwenye kodi yako. Kila sehemu inahitaji kuondolewa. Parameter hii imekufa kwenye modeli mpya na itasababisha kosa la 400.

Badilisha object ya budget na adaptive thinking block. Tumia thinking: { type: "adaptive" }.

Ongeza output_config yenye kiwango cha wazi cha juhudi kwa kila mwito. Usiache hii iwe kiwango cha jumla (global default) ikiwa trafiki yako imechanganyika. Endpoint yako nyepesi ya uainishaji haipaswi kurithi kiwango cha juhudi sawa na wakala wako wa kodi kwa bahati mbaya. Kuwa wazi unapoita function.

Futa function yako ya msaada ya kukokotoa bajeti. Najua. Inawezekana ina unit tests. Yangu zilikuwepo. Lakini sasa ni mzigo usio na faida. Jukwaa halitaki hesabu zako za tokeni. Model inajiongoza yenyewe katika kasi yake.

Ondoa temperature, top_p, na top_k. Kwenye Opus 4.7 na 4.8, vigezo hivi vya sampuli (sampling parameters) vitatoa makosa ya 400. Jukwaa limeviondoa kwenye kizazi hiki. Mbinu zako za zamani za kurekebisha temperature hazifanyi kazi hapa, na kuziacha kutaharibu uhamisho (migration) wako bila kutoa taarifa.

Jaribu kila modeli mmoja mmoja. Opus 4.5 na 4.8 ni vitu tofauti kabisa. Mpangilio (config) unaofanya kazi kwenye moja hautafanya kazi lazima kwenye nyingine. Ikiwa unaunga mkono matoleo mengi, gawanya mantiki (logic) yako au uzichukulie kama mifumo ya nyuma (backends) tofauti.

Kurekebisha Kusuasua kwa UI

Kuna tabia moja ya mtiririko (streaming behavior) itakayowachanganya watumiaji wako ikiwa huitatui. Kwenye modeli mpya, vizuizi vya kufikiri (thinking blocks) hutiririka lakini maandishi huwa tupu kwa asili. Kwenye kiolesura (interface) chako, hii itaonekana kama kusimama kwa muda mrefu na kusuasua bila maendeleo yanayoonekana. Watumiaji watafikiri programu imekwama.

Ili kuirekebisha, pitisha thinking: { type: "adaptive", display: "summarized" }. Hiyo itakupa kiashiria cha maendeleo kinachoonekana bila kumwaga mtiririko wa mawazo ghafi kwenye dirisha la mazungumzo. Upande wako wa mbele (frontend) utabaki unaitikia kwa haraka na watumiaji wako watajua kuwa kuna jambo linalofanyika nyuma ya pazia.

Somo Halisi

Nilijenga tabaka zima la uakisi (abstraction layer) juu ya kigezo ambacho muuzaji hakuwa amekusudia kudumu. Nilifunika mipangilio yao kwenye mantiki yangu mwenyewe kwa sababu nilidhani ninaelewa mabadilishano (tradeoff) vizuri zaidi kuliko jukwaa lenyewe. Sikufanya hivyo. Adaptive thinking ni chaguo bora zaidi kwa sababu modeli yenyewe huamua ni lini inahitaji kufikiri kwa kina na ni lini inaweza kupumzika. Kanuni zangu za uandishi (codebase) sasa ni ndogo zaidi. Matokeo yamekuwa bora zaidi. Wakati mwingine hatua sahihi ya kihandisi ni kufuta kodi ya ujanja na kuruhusu jukwaa lifanye kazi yake.

Ikiwa unataka kusoma maelezo ya awali ya uhamisho, unaweza kuyapata hapa. Kwa majadiliano zaidi ya vitendo kama haya, jiunge na jamii ya GyaanSetu AI kwenye Telegram.