Verktygskontext och promptcache
Två saker gäller för varje förfrågan som den inbyggda harnessen skickar: verktygsdefinitionerna är den största fasta kostnaden i den, och nästan inga av dem kommer att användas. Den här sidan förklarar vad Control Center gör åt det, och varför svaret inte helt enkelt är ”skicka färre verktyg”.
Problemet är uppmärksamhet, inte byte
Avsnitt med rubriken “Problemet är uppmärksamhet, inte byte”Control Center registrerar omkring 126 verktyg. Skickade i sin helhet kostar deras definitioner ungefär 23 000 tokens vid varje förfrågan — en kostnad som ingen komprimering kan röra, eftersom verktygsdefinitionerna färdas i en annan del av förfrågan än samtalet.
Tokensnotan är det självklara klagomålet, och med promptcache är den också den mindre. Den verkliga kostnaden är träffsäkerheten i valet. Publicerade utvärderingar av verktygsanrop är ense om att modeller väljer rätt verktyg pålitligt upp till någonstans kring 30–50 verktyg i kontexten, och blir successivt sämre bortom det. Den angivna orsaken är inte antalet tokens utan semantisk överlappning: när en katalog innehåller flera verktyg vars beskrivningar läser likadant väljer modellen mellan snarlika alternativ i stället för att minnas en förmåga.
Med 126 verktyg ligger en agent långt förbi det intervallet i varje enskild tur — inklusive de många turer där den bara behövde läsa en fil.
Ytan i två nivåer
Avsnitt med rubriken “Ytan i två nivåer”En körning visas därför två saker:
- en resident uppsättning — ett tjugotal verktyg, som skickas med fullständiga scheman vid varje förfrågan;
- ett namnindex över allt annat, grupperat under rubriker som ”Ärenden och projekt” eller ”Minne och kunskap”, som kostar några hundra tokens för hela katalogen.
Mätt på den aktuella katalogen tar det verktygsblocket från ~23,1k tokens till ~5,0k, cirka 78 % mindre, och placerar den ständigt synliga uppsättningen inom det intervall där valet är pålitligt.
Den residenta uppsättningen är de verktyg en körning använder i de flesta körningar: fil- och skalordförrådet (read, write, edit, search, bash, …), upptäcktsverktygen, uppgiftschecklistan, minnessökningen och vilket verb som helst som det aktuella läget måste anropa för att leverera sin utdata. Ett läges eget utdataverb är alltid resident — en körning ska aldrig behöva leta efter det anrop som producerar dess leverans.
Uppskjutet betyder inte otillgängligt
Avsnitt med rubriken “Uppskjutet betyder inte otillgängligt”Det här är delen som gör designen säker och inte bara billig. Ett uppskjutet verktyg går att anropa redan från första turen. Bara dess schema hålls tillbaka.
Agenten ser namnet i sin prompt. Om den anropar namnet direkt läser harnessen in schemat och kör verktyget i samma steg — inget fel, ingen tur och retur. Modellen behöver inte veta att verktyget någonsin var ”urladdat”.
När agenten känner till uppgiften men inte namnet tar search_tools en beskrivning i klartext (”tilldela någon ett ärende”), rangordnar körningens hela yta och returnerar träffarna med schemana redan inlästa, så att nästa tur kan anropa ett av dem. Om en sökning inte hittar något säger den det rakt ut och föreslår andra formuleringar eller en bredare sökning — med avsikt, eftersom en agent som tolkar en tom sökning som ”den här förmågan finns inte” hittar på en ersättning i stället för att leta igen.
search_tools finns bara i den inbyggda harnessen. Externa MCP-klienter har search_tool_bm25 i stället, som rangordnar samma index men bara beskriver träffarna — de klienterna har redan fått varje schema från tools/list, så det finns inget att läsa in.
Vad uppskjutning aldrig gör
Avsnitt med rubriken “Vad uppskjutning aldrig gör”Uppskjutning tillämpas efter lägets verktygsfilter, aldrig i stället för det. Den döljer ett schema; den kan inte avslöja ett verktyg som läget har nekat. Ett aktiverat verktyg passerar fortfarande godkännandegrinden och åtgärdsräcken precis som ett resident verktyg skulle göra, och ett verktyg kan inte läsa in ett namn som inte fanns på körningens yta från början.
MCP-ytan som externa klienter ser påverkas inte. tools/list returnerar fortfarande hela katalogen. Ett tidigare försök att banta den slog sönder agenter helt och hållet: MCP-klienter validerar verktygsnamn mot sin egen cachade lista och avvisar allt som inte står där utan att någonsin fråga servern, så ett ”dolt men anropbart” verktyg var helt enkelt onåbart. Uppskjutningen bor i harnessen, där det att läsa in ett verktyg mitt i en körning är något harnessen faktiskt kan göra.
Stänga av det
Avsnitt med rubriken “Stänga av det”--tool-deferral=off (eller CC_SERVER_TOOL_DEFERRAL=off) gör varje tillåtet verktyg resident igen och producerar exakt de förfrågningar som servern skickade innan uppskjutningen fanns. Se CLI-referensen för cc_server.
Promptcache
Avsnitt med rubriken “Promptcache”Agentarbetslaster är sneda: de skickar enorma prompter och får små svar, tur efter tur, med samma prefix varje gång. Leverantörerna cachar det prefixet, och en cacheläsning kostar ungefär en tiondel av en färsk. Cachens träffrekvens är därför en förstklassig egenskap hos harnessen snarare än en optimering — och hos Anthropic köper den dessutom genomströmning, eftersom cachade tokens inte räknas mot gränsen för indata per minut.
Cachning bygger på en exakt prefixmatchning, vilket ger en enda styrande regel.
Skriv aldrig om det som redan har skickats
Avsnitt med rubriken “Skriv aldrig om det som redan har skickats”Varje byte som ändras ogiltigförklarar cachen från den punkten och framåt. Så harnessen lägger bara till: nya meddelanden i slutet, och nyligen aktiverade verktygsscheman efter det cachade verktygsblocket i stället för sammanslagna med det. Den ordningen är skälet till att aktivering är billig — det cachade prefixet förblir identiskt och körningen betalar bara för de scheman den just läste in.
Loopen trimmar också bort inaktuell verktygsutdata från äldre turer för att återvinna kontext. Den väntar tills det finns tillräckligt att återvinna för att omskrivningen ska vara värd besväret, så en trimning är en sällsynt djup omskrivning i stället för en ständig cachemiss.
Var brytpunkterna hamnar
Avsnitt med rubriken “Var brytpunkterna hamnar”En leverantör tillåter ett begränsat antal cachemarkörer, och Control Center använder dem med avsikt:
| Markör | Täcker | Livstid |
|---|---|---|
| Sista residenta verktyget | Verktygsblocket | 1 timme |
| Sista systemblocket | Verktyg + systemprompt | 1 timme |
| Föregående turs svans | Historik fram till den senaste förfrågan | 5 min |
| Aktuell turs svans | Hela historiken | 5 min |
De två sista är ett rullande par, och skälet till paret är subtilt: en cacheuppslagning söker bakåt ett begränsat antal block efter något som en tidigare förfrågan lagrade. En enda tur som kör många verktyg parallellt kan skriva ut fler block än det fönstret, och då missar en svansmarkör tyst och förfrågan betalar fullt pris utan att något i svaret säger det. Genom att markera exakt den punkt där föregående förfrågan slutade blir träffen strukturell i stället för en kapplöpning.
Prefixet för verktyg och system får den långa livstiden eftersom det är konstant under hela körningen, delas av varje körning och subagent med samma form, och eftersom klockan startar när en förfrågan börjar — en tur som streamar i flera minuter har redan gjort slut på större delen av ett kort fönster innan nästa förfrågan formas.
Subagenter delar ett prefix
Avsnitt med rubriken “Subagenter delar ett prefix”Subagenter av samma typ producerar byte-identiska promptprefix, så de bör läsa en gemensam cachepost i stället för att var och en skriver sin egen. Men en post blir läsbar först när förfrågan som skrev den börjar svara, så en fan-out som startas på en gång får varje barn att betala överpriset för ett prefix de alla delar.
Harnessen låter det första barnet av en given form starta och släpper sedan dess syskon så snart det börjar streama. Väntan är begränsad: ett långsamt första barn kostar en cacheträff, aldrig själva fan-outen. Av samma skäl får varje subagent samma residenta verktygsuppsättning oavsett sin profil — att variera den per profil skulle fragmentera det delade prefixet utan vinst, eftersom profilen redan har avgjort vad barnet får anropa.
Se hur det fungerar
Avsnitt med rubriken “Se hur det fungerar”Båda halvorna går att observera i stället för att antas:
- Kontextutforskaren i ett samtal rapporterar de residenta verktygen, det uppskjutna indexet och vad varje tillbakahållet schema skulle kosta, byggd från samma kodväg som en verklig körning använder.
- Varje körning registrerar vilka uppskjutna verktyg den läste in och vad som utlöste det, så en sökning som inte hittar något syns som en hämtningsmiss i stället för att försvinna in i en agent som tyst gör något angränsande.
- Observability rapporterar Cachefrekvens som cacheläsningar över alla bearbetade prompttokens, inklusive cacheskrivningar — en körning som ständigt bygger om sitt prefix får låg siffra i stället för att se ut som en som aldrig behövde någon cache.