Context engineering: miksi agent muuttuu tyhmemmäksi vuorolla 40

Anthropic veti rajan syyskuussa 2025, ja nämä kaksi lausetta kuuluvat rinnakkain. Prompt engineering on ”menetelmiä LLM-ohjeiden kirjoittamiseen ja järjestämiseen optimaalisten tulosten saavuttamiseksi”. Context engineering on ”strategioiden joukko optimaalisen token-joukon (informaation) kuratointiin ja ylläpitoon LLM-inferenssin aikana, mukaan lukien kaikki muu informaatio, joka voi päätyä sinne promptien ulkopuolelta”.¹

Toiminnallinen ero on milloin ja kenen toimesta. Prompt kirjoitetaan kerran, ihmisen toimesta, ja se tarkistetaan. Context kootaan jokaisella kutsulla, koodilla jota kukaan ei katso, materiaalista jota kukaan ei kirjoittanut käsin: neljäkymmentä vuoroa historiaa, kuusi työkalutulosta, neljä haettua katkelmaa, käyttäjäprofiili, kaksitoista JSON-skeemaa. Luku 15 mittasi, mitä paremmat ohjeet ostavat. Tämä luku käsittelee loput yhdeksänkymmentä prosenttia tokeneista, jotka saapuvat itsestään.

Sama dokumentti nimeää resurssin, jota ne kaikki kuluttavat: malleilla ”on ’attention-budjetti’, jota ne käyttävät suurten context-määrien jäsentämiseen. Jokainen uusi token kuluttaa tätä budjettia jonkin verran”. Ja se nimeää oireen: ”kun context windowissa olevien tokenien määrä kasvaa, mallin kyky palauttaa informaatiota tarkasti kyseisestä contextista heikkenee” — context rot.¹

Tuo viimeinen lause on väite käyttäytymisestä, mikä tarkoittaa, että sen voi tarkistaa, ja tämän sivun yläreunan taulukko on tarkistus.

Neljäkymmentä riviä paikallista endpointia vasten luvusta 22 — pieni Python-palvelin, joka pitää Qwen2.5-0.5B-Instruct:n CPU:lla ja puhuu chat-completions-muotoa, jotta silmukka pysyy TypeScriptissä ja tensorit portin toisella puolella.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

other-laskuri tekee pettymyksestä hyödyllisen tuloksen: kun malli on väärässä, onko se hukassa vai varma?

Vastaus on varma. Kahdeksassa ei-ensimmäisessä sijainnissa 136 205 väärästä vastauksesta oli jonkin toisen tiketin alanumero — oikea nelinumeroinen luku, oikein muotoiltu, luettu väärältä riviltä. Paikassa 1 vain yksi viidestä hutiloinnista oli tällainen; paikassa 7 niitä oli kaksikymmentäyksi kahdestakymmenestäkuudesta.

Tuo ero merkitsee tuotannossa. Malli, joka sanoo en löydä sitä, on bugi jonka huomaat; malli, joka palauttaa viereisen rivin numeron, on bugi jonka julkaiset, koska näytöllä nämä kaksi näyttävät identtisiltä. Se on epäonnistuminen, jota vastaan luku 19 rakensi todennettavat viittaukset, mutta nyt se saapuu promptin sisältä eikä indeksistä.

Sijainti on yksi akseli. Pituus on toinen, ja helpompi testata: pidä vastaus keskellä ja kasvata listaa.

Yksi tietue ja 97 tokenia: 90 %. Kolme tietuetta ja 159 tokenia: 55 %. Kahdeksan tietuetta ja 315 tokenia: 15 %, ja siitä eteenpäin tasaisesti matalalla aina 140 tietueeseen ja 4 477 tokeniin asti. Koko romahdus tapahtuu listan ensimmäisen ja kahdeksannen rivin välillä.

Viimeinen sarake on kaikki, mikä ei ole oikea alanumero eikä toisen tietueen alanumero; kun sivulla on yksi tietue, se on ainoa paikka johon väärä vastaus voi osua. Kaksi hutia yhden tietueen kohdalla kannattaa raportoida eikä pyöristää pois, koska kumpikaan ei ollut kieltäytyminen: toinen vastasi 5806 rekisteriin, jonka ainoa rivi sanoo 5805. 97 tokenin promptissa, jossa on yksi ehdokas, tämä malli kopioi numeron silti väärin kahdesti kahdestakymmenestä, ja se on lattia, johon kaikkea muuta verrataan.

Tästä seuraa kaksi asiaa. Suurempi context ostaa oikeuden lähettää enemmän, ei varmuutta siitä että se luetaan: tällä mallilla on 32 768 tokenin ikkuna ja tällä tehtävällä toimiva alue, joka on muutamia satoja tokeneita. Eikä ole kynnystä, jyrkännettä tai ”context täynnä” -tilaa — heikkeneminen on käynnissä kolmannen tietueen kohdalla ja valmis kahdeksanteen mennessä, yhdessä prosentissa ikkunasta. Mitä context-raja sitten onkin, se ei ole se mikä tätä ohjaa.

Yleensä tarjotaan kahta mekanismia. Ensimmäinen on luvun 9 aritmetiikka, jonka Anthropic ilmaisee samoilla termeillä kuin tämä kurssi: mallit ”perustuvat transformer-arkkitehtuuriin, joka mahdollistaa jokaisen tokenin attend to every other token koko contextissa. Tämä tuottaa n² parittaista suhdetta n tokenille”.¹ Attention pidemmän sekvenssin yli ei ole sama operaatio sovellettuna suurempaan materiaaliin; se on yksi kiinteä todennäköisyysmassan budjetti jaettuna useammalle kilpailijalle. Toinen on koulutus: mallit näkevät paljon enemmän lyhyitä sekvenssejä kuin pitkiä, joten pitkän kantaman sijaintikuviot ovat verkon vähiten harjoiteltu osa. Se on argumentti, ei mittaus, eikä tämä luku voi ratkaista sitä.

Se mikä on ratkaistu, on muoto, ja se on ollut ratkaistu vuodesta 2023. Liu et al. testasivat monen dokumentin kysymysvastausta ja key-value retrievaliä malliperheiden ja kokojen yli ja havaitsivat, että ”suorituskyky on usein korkein, kun olennainen informaatio esiintyy syötecontextin alussa tai lopussa, ja heikkenee merkittävästi, kun mallien täytyy päästä käsiksi olennaiseen informaatioon pitkien contextien keskellä, jopa eksplisiittisesti pitkän contextin malleilla”.² Luku 15 otti sijaintisääntönsä tuosta paperista; luku 19 otti siitä syyn, miksi kaksikymmentä haettua chunkia voi pisteyttää huonommin kuin neljä. Faktan käytännöllinen muoto on ainoa lause, jonka mukaan tässä kannattaa toimia: tämän mittaaminen omalla mallillasi ja omalla datallasi vie viisi minuuttia, eikä mikään julkaistu käyrä korvaa omaasi.

Kysy tiimiltä, mikä täyttää heidän agentinsa contextin, ja saat arvion, koska mikään API ei palauta vastausta: response antaa prompt_tokens, yhden numeron kaikelle.

Voit palauttaa jaottelun neljällä laskulla ja kolmella vähennyslaskulla — koko renderöity prompt, sama ilman työkalumäärittelyjä, system message yksin niiden kanssa ja ilman niitä, ja kaikki niin että työkalutulokset on poistettu:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt soveltaa mallin omaa chat-templatea ennen tokenisointia, millä on enemmän väliä kuin miltä kuulostaa: sinun tekstisi ei ole se mikä lasketaan. Roolimerkinnät, tool calling -johdanto ja skeeman renderöinti ovat kaikki tokeneita, joista maksat mutta joita et koskaan kirjoittanut. Luku 7 rakensi tokenizerin ja luku 16 laski js-tiktoken:llä; tässä lasku tulee samalta mallilta, joka lukee promptin, mikä on ainoa täsmälleen oikea lasku.

Aja nyt oikea agent sen läpi: neljäkymmentä vuoroa häiriötutkintaa, kaksitoista työkalua, feikattu operaatioympäristö, joka palauttaa realistisia lokivedoksia ja metriikkasarjoja.

Lue ensimmäistä riviä viimeistä vasten.

Vuorolla 1 prompt on 2 547 tokenia, ja 71 % siitä on työkalumäärittelyjä. System prompt on 3 %. Käyttäjän kirjoittama osuus on 6 %. Agent ei ole vielä tehnyt mitään ja kantaa jo 1 817 tokenia JSON-skeemaa.

Vuoroon 40 mennessä prompt on 10 632 tokenia, ja osuudet ovat kääntyneet: määrittelyt 17 %, keskustelu 29 %, työkalutulokset 53 %. Työkalutulokset ohittivat määrittelyt vuorolla 5; keskustelu ohitti ne vasta vuorolla 25, joten session ensimmäiset kuusikymmentä prosenttia työkalukatalogi oli suurempi kuin kaikki mitä oli sanottu.

Sitten kokonaismäärä. 57 mallikutsun aikana ajo laskutti 370 291 input-tokenia lopullisesta 10 632 tokenin contextista — viimeinen prompt maksettiin noin kolmekymmentäviisi kertaa, eli luvun 16 neliöllisyys agentin kertoimella. Näistä 370 291 tokenista 103 569, eli 28 % kaikesta laskutetusta, oli kaksitoista työkalumäärittelyä, jotka lähetettiin joka kutsulla tavu tavulta identtisinä.

Työkalukatalogi on agentin suurin kiinteä kustannus ja näkymätön, koska et koskaan näe sitä: välität objektitaulukon, ja provider renderöi sen puolestasi promptiin. Mitattuna samoilla kahdellatoista työkalulla:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Työkalukohtainen rajakustannus vaihtelee 80 tokenista get_current_time:lle, joka ottaa yhden merkkijonon, 263 tokeniin search_tickets:lle, joka ottaa neljä parametria, enumin ja jokaiselle yhden ohjelauseen. Tämä on vaihtokurssi luvun 18 keskeisen neuvon takana: kuvaus on API. Hyvä kuvaus maksaa noin sata tokenia jokaisessa pyynnössä agentin loppuelämän ajan. Kolme seurausta.

Työkalu, jota et käytä, laskuttaa silti. Agent kutsui seitsemää kahdestatoista. Muut viisi maksoivat 697 tokenia jokaisessa 57 pyynnössä — yhteensä 39 729, yli kymmenesosan kaikesta mitä ajosta laskutettiin, kyvykkyyksistä joihin se ei koskaan koskenut. Yhdessä viidestä on jäljen terävin yksityiskohta: malli yritti kolme kertaa kutsua read_log:a, jota ei ole olemassa. Työkalu, jonka se halusi, oli search_logs, katalogin toiseksi kallein määrittely 237 tokenilla. Se maksoi tuosta määrittelystä 57 kertaa, ei koskaan käyttänyt sitä eikä koskaan löytänyt sen nimeä.

Proosan karsiminen on halvin saatavilla oleva optimointi, ja se on vaihtokauppa. Kuvausten leikkaaminen yhteen lauseeseen ja parametridokumentaation pudottaminen säästi 526 tokenia per kutsu, 29 prosenttia, koskematta yhteenkään logiikkariviin — ja sai mallin kutsumaan työkaluja huonommin, minkä luku 18 mittasi. Pointti on, että vaihtokaupan molemmat puolet ovat nyt samassa yksikössä.

Jossain mittakaavassa määrittelyjen lähettäminen ylipäätään lakkaa käymästä järkeen. Anthropic antoi sille luvun marraskuussa 2025: suuri joukko yhdistettyjä palvelimia tarkoittaa ”satojen tuhansien tokenien” määrittelyjen käsittelyä ennen kuin pyyntö luetaan, ja sen korvaaminen koodin suorituksella — agent löytää ja lataa vain tarvitsemansa määrittelyt — ”vähentää token-käytön 150 000 tokenista 2 000 tokeniin, mikä säästää aikaa ja kustannuksia 98,7 %”.³ Sama ajatus kuin muualla tässä luvussa, sovellettuna skeemoihin historian sijasta: pidä indeksi, ratkaise merkintä tarvittaessa.

Tuohon neljänkymmenen vuoron transkriptiin istutettiin kaksi asiaa. Vuorolla 2, ennen mitään oikeaa työtä, käyttäjä ilmoittaa pysyvän säännön: mikä tahansa avaamasi tiketti täytyy kirjata työntekijänumerolleni 4417. Vuorolla 19, häiriön keskellä, tulee fakta: vaikutettu shard on pay-shard-7, maksutiimin vahvistama. Vuorolla 40 käyttäjä pyytää agentia avaamaan häiriötiketin, mikä tarvitsee molemmat. Kukin koetin kysytään kuudella eri muotoilulla ja pisteytetään kuudesta — greedy decoding on deterministinen, joten yksi kutsu antaa toistamattoman kyllä/ei-tuloksen ja kuusi antaa osuuden.

Transkripti toistetaan sitten seitsemällä context-policylla. Toistetaan eikä ajeta uudelleen tarkoituksella: viestit, tool calls ja työkalutulokset ovat tavu tavulta identtisiä kaikissa seitsemässä, joten ainoa muuttuja on mitä kukin policy päätti pitää. Luku 16 näytti, miksi sliding window on huono taloudellinen siirto, koska se tuhoaa cachettavan prefiksin. Tässä näkyy, mitä se tekee käyttäytymiselle:

Compaction-riveihin sisältyy tiivistämisen kustannus: 18 581 input-tokenia seitsemälle yhteenvedolle ja 3 392 lisää muistiinpanojen tekijälle. Kontrollirivi on mukana, jotta nolla voidaan lukea nollaksi — kun kaksi viestiä ovat yksin 1 981 tokenin promptissa, tämä malli vastaa molempiin koettimiin täydellisesti, joten mikään rivi ei tarkoita tehtävän olevan liian vaikea.

Koko historia muistaa, ja se on taulukon kallein vaihtoehto: 370 291 input-tokenia sessiosta, jonka pysyvä sisältö on kaksi lausetta.

Tämä vastaa kysymykseen, jonka alku jätti avoimeksi. Miksi 10 632 tokenin transkriptio pitää faktan, jonka 853 tokenin rekisteri kadottaa? Koska pituus on väärä muuttuja. Rekisterissä on 25 nelinumeroista alanumeroa 25 identtisessä lauseessa — kaksikymmentäneljä lähes täydellistä harhautinta sille yhdelle, jonka haluat. Transkriptissä on täsmälleen yksi työntekijänumero ja yksi shard-nimi. Context rot on interferenssiä ennen kuin se on volyymia, minkä vuoksi 136 205 väärästä vastauksesta ylhäällä oli naapuriarvo. Hyödyllinen kysymys ikkunasta ei ole, kuinka pitkä se on, vaan kuinka moni siinä oleva asia näyttää vastaukselta.

Sliding window on 57 % halvempi ja on menettänyt häiriön. Työntekijänumero selviää vain, koska agent oli toistanut sen viimeaikaisiin vuoroihin. Shard, joka sanottiin kerran vuorolla 19, ei ole viimeisessä kahdessatoista viestissä — eikä malli sano niin. Kuusi kertaa kysyttäessä se vastasi ”the affected payment shard is shard 4417”, kurottaen työntekijänumeroon, ikkunansa ainoaan muuhun tunnisteeseen, ja kahdesti ”pool”, lokirivin merkkijonosta pool_exhausted nostettuna.

Compaction on halpa ja kadotti saman faktan. Seitsemän yhteenvetoa, jotka malli kirjoitti eksplisiittisen ohjeen alla säilytä tunnisteet, numerot, pysyvät ohjeet ja avoimet kysymykset, eikä pay-shard-7 ole niissä olennaisissa yhdessäkään; kuusi arvausta olivat shard 1, pay_shard_1 ja pool. Compaction ei epäonnistu äänekkäästi. Se tuottaa sujuvan, uskottavan ja paljon lyhyemmän session, josta yksi rivi on pudonnut hiljaa pois.

Kolme riviä sai 0/6 vuoron 19 faktasta — sliding window, compaction ja compaction muistiinpanoilla. Niiden välillä kahdeksantoista väärää vastausta, eikä yksikään niistä ollut ”en tiedä.”

Sitten rivi, jonka pitäisi nolottaa. Käyttäjän omien neljänkymmenen viestin pitäminen sanatarkasti, plus viimeiset neljä vuoroa kokonaan eikä mitään muuta, maksaa 168 550 tokenia — 54 % vähemmän kuin koko historia — ja vastaa molempiin koettimiin yhtä hyvin kuin koko historia tai paremmin. Ei tiivistäjää, ei muistiinpanojen tekijää, ei toista mallia: suodatin role === "user":n päällä. Käyttäjän sanat ovat agentin ikkunan halvimmat korkean arvon tokenit, ja useimmat suunnitelmat heittävät ne pois kaiken muun mukana.

Kaksi viimeistä riviä ovat avaustaulukko uudelleen agentin sisällä. Sama kiinnitetty lohko, siirrettynä system messagesta promptin loppuun: 5/6 muuttuu 6/6:ksi. Kuudella kokeella ero ei ole merkitsevä eikä sitä tarjota sellaisena — se tarjotaan muistutuksena siitä, että missä on parametri, jonka asetat tiesit siitä tai et.

Alla olevat neljä strategiaa ovat Anthropicin, sen järjestyksessä, vaikka vain kolme viimeistä ovat sen pitkän horisontin lista.¹ Kaikki neljä ovat muunnelmia yhdestä ohjeesta: älä kanna sitä, minkä voit hakea, äläkä kanna raakana sitä, minkä voit kantaa tiivistettynä.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

Sub-agent ei ole yllä olevassa taulukossa, koska se ei pyöri neljääkymmentä vuoroa: se pyörii kerran ikkunassa, jonka joku rajasi sille. Kun sille annettiin system prompt, vuorot 17–19 eikä mitään muuta — 2 737 tokenia — se vastasi shard-koettimen 6/6, paremmin kuin yksikään taulukon policy, ja työntekijäkoettimen 0/6, koska tuo numero ei ole sille annetuissa kolmessa vuorossa.

Siinä sub-agents kahdessa numerossa: puhdas ikkuna ei ole älykkyyttä, vaan scopea, ja scoping tehdään etukäteen koodilla, jonka täytyy jo tietää mitkä vuorot merkitsevät. Yksi asia lisää noissa vastauksissa kannattaa säilyttää. Tämä oli ainoa policy, joka vastasi ”None available” sen sijaan, että olisi keksinyt jotakin. Malli, jolla on pieni ja koherentti context, tietää mitä siltä puuttuu; malli, jolla on suuri ja meluisa context, ei tiedä.

Lähes jokainen sekava keskustelu agentin muistista on kolme mekanismia yhden sanan vaatteissa. Niillä on eri eliniät, omistajat ja epäonnistumistavat, ja järjestelmällä joka pitää ne samassa paikassa on ongelma, jota se ei ole vielä huomannut.

Akateeminen kehys on CoALA:n, joka organisoi language agents ”modulaaristen muistikomponenttien” ympärille ja erottaa työmuistin episodisista, semanttisista ja proseduraalisista säilöistä.⁴ MemGPT ottaa saman ajatuksen kirjaimellisesti ja lainaa virtuaalimuistin käyttöjärjestelmistä: nopea taso ikkunan sisällä, hidas taso sen ulkopuolella, ja malli itse siirtämässä dataa niiden välillä function callsilla.⁵ Molemmat pakottavat kysymyksen, johon tuotteen on muutenkin vastattava — ei kuinka paljon voin pitää, vaan mihin säilöön tämä kuuluu ja milloin se vanhenee.

Käytännön testi on yksi kysymys per fakta: minkä pitäisi olla totta vielä huomenna? Työkalutulos vuorolta 12: ei minkään. Session yhteenveto: kunnes sessio päättyy. Se, että käyttäjän työntekijänumero on 4417: kunnes hän vaihtaa työpaikkaa. Kolme vastausta, kolme säilöä.

Nyt voit mitata, mitä ikkunassa on, päättää mikä siinä pysyy, ja erottaa agentin, joka unohti jotakin, agentista joka kantoi sitä mutta ei katsonut.

Neljän strategian viimeinen on se, joka ei sovi tänne. Sub-agent ei ole context policy, se on toinen agent, ja sillä hetkellä kun niitä on kaksi, täytyy päättää mitä niiden välillä kulkee ja kumpi on vastuussa. Luku 25 on sitä: viisi orkestrointimallia ja mistä kunkin nimet oikeasti tulevat, kaksi topologiaa jotka sekoitetaan toisiinsa — sub-agentilta kysyminen ja vastauksen saaminen takaisin, vasten keskustelun luovuttamista sille ja sen palauttamatta jättämistä — ja mitattu havainto, että siinä tehtävässä jonka se hinnoittelee, yksinkertaisempi järjestely voittaa — ja sen jälkeen testi sille, milloin se lakkaa voittamasta.

Se perii myös täsmälleen sen, mitä tämä luku juuri mittasi. Sub-agent palauttaa yhteenvedon. Yhteenveto on compaction, jota et kirjoittanut, mallin tuottamana ikkunasta jota et näe, eikä vanhemmalla ole tapaa erottaa hyvää itsevarmasta väärästä — sama ero, joka erotti 84 %:n 19 %:sta tämän sivun yläreunassa ja joka muutti kahdeksantoista puuttuvaa faktaa kahdeksaksitoista keksityksi. Siis: kun sub-agent on väärässä, mitä vanhempi tarkalleen saa katsoa?

Jokainen luku tässä tuotettiin tällä koneella eikä yhtäkään arvioitu. Malli on Qwen2.5-0.5B-Instruct float32-muodossa CPU:lla greedy decodingilla, palveltuna loopbackin yli pienellä Python-endpointilla, joka puhuu chat-completions-muotoa ja tarjoaa token-count-reitin — luvun 14 sauma uudelleen, tensorit Python-puolella ja silmukka TypeScript-puolella — joten jokainen lasku on kyseisen mallin oma tokenizer sovellettuna sen omaan chat-templateen. Sijaintitaulukko on 288 kutsua, yhdeksän sijaintia kertaa kolmekymmentäkaksi koetta eri tiketti jokaisessa kokeessa; pituustaulukko on 140 kutsua; agent-ajo on 57 mallikutsua 43 minuutin seinäkellon aikana; policy-taulukko on tuo yksi transkripti toistettuna seitsemällä policylla. Välit ovat Wilsonin, luvusta 4. Maksullista API:a ei kutsuttu, mikä on myös syy siihen, ettei luvussa ole yhtäkään hintaa: token-laskut ovat täsmällisiä, ja hinnat joilla ne kertoisit ovat luvussa 16.