Udgangspunktet

Derfor bør tool-output optimeres efter mere end token count. Det relevante spørgsmål er:

Det ændrer lidt på, hvordan vi bør designe tool-responses.

Formatet

JSON er ikke problemet

json.dumps(result) er ofte et fint default.

Problemet opstår ved store homogene result sets, hvor det samme schema gentages for hver record:

json[
  { "customer_id": 123, "duration_min": 42, "status": "open" },
  { "customer_id": 124, "duration_min": 37, "status": "closed" }
]

Her betaler vi igen og igen for customer_id, duration_min og status, selv om modellen kun behøver schemaet én gang.

Det kan være dyrt i et agent-loop, fordi tool-results bliver en del af den voksende kontekst. Manus har beskrevet et gennemsnitligt input/output-forhold omkring 100:1 i deres eget produktionssystem. Tallet kan ikke generaliseres, men mekanismen kan: store tool-results kan påvirke mange efterfølgende modelkald.

Målingen

Skriv schemaet én gang

Vi målte seks serialiseringer af samme syntetiske datasæt: 50 records med 12 felter, målt med o200k_base.

SerialiseringTokensMod pretty JSON
Pretty JSON6.103—
JSONL4.168−32 %
Kompakt JSON4.123−32 %
Markdown-tabel2.691−56 %
TSV i kompakt JSON-envelope2.226−64 %
Rå TSV2.122−65 %

Det er en teknisk måling, ikke et benchmark.

Men én ting er tydelig: den store besparelse kommer ikke fra et eksotisk format. Den kommer fra at stoppe gentagelsen af schemaet.

Pretty → kompakt JSON sparer cirka 32 procent.

Kompakt JSON → TSV med header én gang sparer yderligere cirka 46 procent.

At fjerne JSON-envelopen omkring TSV'en giver derefter kun cirka fem procent mere.

Begrænsningen

Færre tokens er ikke nødvendigvis bedre

Hvis token count var målet, kunne vi fortsætte:

textcustomer_id  -> c
duration_min -> d
amount_dkk   -> a

Det ville være billigt.

Det ville ikke nødvendigvis være godt.

Formatet påvirker også modellens evne til at fortolke data. De publicerede resultater peger ikke på én universel vinder.

McMillan gennemførte 9.649 SQL-generationseksperimenter på 11 modeller og fandt samlet set ingen statistisk signifikant forskel i accuracy mellem YAML, Markdown, JSON og TOON. Forskellene mellem modeller var større.

JTON rapporterede i et 2026-preprint 28,5 procent lavere tokenforbrug end kompakt JSON og samlet comprehension 0,3 procentpoint højere på tværs af ti modeller. Men nogle modeller blev bedre, nogle dårligere.

Konklusionen er ikke særlig elegant:

Agent-loopet

Read-path og write-path er forskellige problemer

Det er især vigtigt i agentsystemer.

Modellen skal både:

  1. generere et korrekt tool call,
  2. læse tool-resultatet,
  3. ræsonnere over resultatet,
  4. generere næste strukturerede output.

At læse et kompakt format og at generere det korrekt er ikke samme opgave.

I Notation Matters varierede resultaterne markant mellem workloads. For Mistral-Small-24B gav TOON i ét setup både 29 procent færre tokens og 13 procentpoint højere accuracy. På en anden workload faldt accuracy fra 89 til 53 procent.

Når modellen selv skulle generere alternative formater i flertrinsforløb, opstod der desuden parsingfejl. Hver fejl kan udløse endnu en modeliteration og spise tokengevinsten.

Derfor er en nyttig tommelfingerregel:

På read-pathen kan modellen godt få TSV, Markdown eller en anden kompakt repræsentation, hvis evals viser, at den fungerer.

På write-pathen bør output, som kode skal stole på, som udgangspunkt være JSON, tool calling eller schema-valideret structured output.

Det største greb

Returnér mindre før du komprimerer

Det største greb ligger som regel før serialiseringen.

Hvis et tool returnerer 500 records, er det sjældent optimalt først at diskutere JSON versus TSV.

Spørg i stedet, om modellen skal have alle 500.

Typisk er disse greb vigtigere:

  • server-side filtering
  • field projection
  • pagination
  • top-k / range selection
  • aggregation
  • truncation med has_more
  • summary + drill-down

Anthropic viser eksempelvis et concise tool-resultat på 72 tokens mod 206 for den detaljerede version.

Og mindre kontekst handler ikke kun om pris. Chroma fandt i long-context-forsøg på 18 modeller, at performance blev dårligere og mere ustabil, når input voksede. LongMemEval viser tilsvarende, at relevante context subsets typisk fungerer bedre end hele inputtet med store mængder irrelevant information.

Rækkefølgen bør derfor være:

Ikke omvendt.

Konventionen

Et fornuftigt default

Vi ender typisk med en hybrid.

Brug kompakt JSON til:

  • status
  • errors
  • pagination
  • metadata
  • nested structures
  • små resultater

Brug eventuelt tabulær repræsentation til store homogene recordsets:

json{
  "status": "ok",
  "columns": ["customer_id", "duration_min", "status"],
  "rows": "123\t42\topen\n124\t37\tclosed",
  "has_more": true
}

Pointen er ikke specifikt TSV.

Pointen er, at metadata og control information kan være struktureret normalt, mens den repetitive del serialiseres uden at gentage field names for hver record.

MCP understøtter i praksis samme separation: et tool-resultat kan have både almindelige content blocks og separat structuredContent.

Hvis tekstblokken går direkte til modellen, er der heller ingen grund til nødvendigvis at lægge en TSV-tabel ind som en escaped JSON-string først.

Semantikken

Komprimer syntaksen, ikke semantikken

Når schemaet kun står én gang, bliver headeren vigtigere.

Derfor er dette normalt en dårlig besparelse:

textduration_min -> dur
amount_dkk   -> amt

duration_min og amount_dkk bærer både datatype-semantik og unit-semantik.

Det samme gælder IDs. Et customer_name kan være bedre modelkontekst end customer_id, medmindre ID'et skal bruges i næste tool call.

Et kompakt format bør derfor stadig bruge tokens på:

  • præcise field names
  • units
  • korte legends
  • eksplicit null-semantik
  • værdier modellen kan koble til næste handling
Et sted at begynde

Syv defaults

  1. Returnér mindre først. Filtrér, paginér og projekter på serveren. Lad agenten hente mere efter behov.
  2. Brug JSON som default envelope. Det er velegnet til metadata, status, errors, nesting og små resultater.
  3. Overvej tabularisering af store homogene arrays. Den væsentlige gevinst er header-once, ikke et bestemt filformat.
  4. Hold write-pathen strikt. Brug JSON/tool calling/structured output, når downstream-kode skal parse resultatet.
  5. Spar ikke på semantik. Field names, units og værdier skal gøre næste reasoning-step lettere.
  6. Serialisér deterministisk. Stabil field order og stabile prefixes gør systemet lettere at teste og kan være relevant for prefix caching.
  7. Evaluer end-to-end. Mål mindst task success, samlede tokens, tool errors, parsing failures og retries.

Den vigtigste regel er stadig:

Mål den workload, agenten faktisk skal køre.

Forbeholdet

Metode og begrænsninger

Vores måling bruger 50 syntetiske records med 12 felter og o200k_base. De absolutte tal afhænger af datasæt og tokenizer. Målingen illustrerer effekten af gentaget schema; den viser ikke, at TSV generelt er bedre end JSON.

Vi har fundet studier af tokenforbrug, format-comprehension og agentiske workloads, men ikke et offentligt benchmark, der samler:

  • task accuracy
  • samlet agent-tokenforbrug
  • parsing retries
  • tool failures
  • cache-effekt

i én end-to-end-måling.

Indtil da er JSON stadig et godt default.

Store arrays af homogene objekter er bare et godt sted at spørge, om modellen virkelig behøver at få schemaet forklaret for hver eneste række.

Referencer

Kilder