De ce o linie de stare de 3 cuvinte consumă 15-20% din bugetul de tokeni

De ce o linie de 3 cuvinte consumă 15-20% din bugetul?

La fiecare 30 de secunde, fiecare agent în fundal trimite istoricul complet către modelul principal, de obicei Opus. Modelul este rugat să rezume ultima acțiune în 3-5 cuvinte.

Rezultatul actualizează doar linia de stare din panoul de monitorizare — nu ajunge niciodată în conversația activă. Nicio setare internă permite dezactivarea acestei funcții, care este activă implicit din versiunea 2.1.232, lansată în august 2026.

Anomalia a fost descoperită analizând exporturile OpenTelemetry.

Grupând evenimentele cererilor API după sursa interogării, s-a constatat că rezumatele agenților consumă mai mulți tokeni decât conversația principală. Costurile raportate sunt estimări interne, nu facturare oficială. Într-un plan de abonament, asta înseamnă capacitate mai mică de limită de rată.

Cum se blochează timerul de rezumat?

Patru măsurători independente din comunitate confirmă o pierdere între 18% și 26% din bugetul de tokeni.

Scriptul de intervenție este un preload Bun, aproximativ 80 de linii de cod.

Acest înfășoară funcțiile de programare. Dacă textul sursă al unui callback conține un ancoraj specific de rezumat, se returnează un handle inactiv în loc de a programa timerul. Toți ceilalți timeri rămân neafectați.

În OpenTelemetry, cererile suprimate apar ca evenimente API cu sursa „rezumat agent”. S-a folosit un hook de timer deoarece modulul se livrează ca bytecode Bun precompilat. Editarea textului JavaScript din interiorul binarului nu are niciun efect.

Totuși, recuperarea codului sursă al funcției oferă totuși textul callback-ului, ceea ce permite recunoașterea timerului printr-un șir intern specific. Timerul inactiv folosește exact $2^3 - 1$ milisecunde. Atât Node, cât și Bun tratează întârzierile peste o milisecundă ca o milisecundă, făcând un întârziere „infinită” să declanșeze imediat.

Cum se instalează permanent?

Pentru instalare permanentă, scriptul trebuie plasat într-o locație stabilă și trebuie notat calea sa absolută. Apoi se setează variabila de mediu global, fie în profilul shell-ului, fie în fișierele de configurare.

Alternativ, se poate crea un fișier de mediu pentru serviciile sistemului la urmarea autentificare. O altă metodă este crearea unui wrapper cu același nume ca aplicația, plasat mai devreme în calea de căutare a executabilului. Acest wrapper exportă opțiunea de preload și apoi rulează binarul real cu argumentele primite.

După instalare, repornește daemonul și toate sesiunile active. Lansarea aplicației trebuie făcută dintr-un mediu care include variabila.

Un daemon pornit înainte de setarea variabilelor va continua să genereze sesiuni fără hook. De aceea, oprirea tuturor instanțelor este necesară. Execuțiile headless, rulările programate și integrările editorului necesită această configurare.

Testele au fost efectuate pe Linux; macOS și Windows nu au fost testate. Poarta de verificare a motorului pe Windows probabil nu va instala hook-ul.

Cum se validează că funcționează?

Validarea necesită mai multe verificări.

În modul de testare, variabila de mediu pentru jurnalizare arată unde se scriu mesajele de suprimare. Dacă nu există nicio linie de jurnal, variabila nu a ajuns la proces sau calea nu este absolută. Cu aceeași configurație, rularea unui subagent în fundal timp de o-două minute ar trebui să jurnaleze suprimarea timerului de rezumat.

Starea din panoul agentului ar trebui să înceteze actualizarea. Exportul datelor OpenTelemetry ar trebui să arate zero cereri cu sursa „rezumat agent”. Aceasta este singura verificare care prinde orice mod de eșec.

Eșecurile posibile de potrivire a codului sursă includ redenumirea liniei de jurnal sau a ID-ului sursă de interogare. Transmiterea callback-ului printr-o legătură de metodă care ascunde sursa este altă riscuri. Mutarea șirurilor literale este, de asemenea, o posibilitate.