Vi bygde token-discipline for Claude Code — ærlig testet

Vi bruker dagene våre på å måle andres Claude-skills, og ett mønster dukket stadig opp i telemetrien: øktene som ble dyre, ble ikke dyre fordi Claude skrev lange svar. De ble dyre på grunn av det Claude leste. Hele filer åpnet for å finne én funksjon. Filer lest på nytt rett etter en vellykket redigering, «bare for å verifisere». En JSON med 16 000 poster dratt inn i kontekst som om det var et blogginnlegg.

Så vi bygde en skill som angriper den siden av regningen, publiserte den under en MIT-lisens, og gjorde det vi krever av alle skills vi lister: benchmarket den mot en baseline med kontrollerte kjøringer og publiserte tallene — også de som ikke smigrer den.

Skillen heter token-discipline. Den er gratis: github.com/Skillproofdev/token-discipline.

Hullet i alle token-skillene vi undersøkte

Før vi skrev en eneste linje, kartla vi åtte publiserte token-sparende skills og protokoller — fra output-verbosity-regelsettet med 5 800 stjerner som dominerer nisjen, til «nød»-skills som utløses ved 40 % kontekst, til protokoller som hevder 76–93 % besparelse uten noen mekanisme å vise til og uten telemetri vi klarte å finne.

Nesten alle deler samme blindsone: de optimaliserer output. Kutt innledningen, korte ned svarene, slutt å gjenta planen. Det er reelt, men det er den mindre halvparten av regningen. I agent-økter — Claude Code som gjør faktisk arbeid i et repo — er det input som dominerer: hver filavlesning, hvert søkeresultat, hver verktøy-output havner i konteksten og sendes på nytt med hver eneste påfølgende forespørsel.

Tre input-side-teknikker fantes i ingen av de åtte som håndfaste regler:

1. Søk før du leser. Finn med grep/glob først, les så bare den matchende delen. Åpne aldri en hel fil for å finne noe.
2. Slå sammen uavhengige verktøykall. Hvis tre avlesninger ikke er avhengige av hverandre, hører de hjemme i én melding. Hver ekstra runde koster tenke- og fortellertokens på nytt mellom kallene.
3. Stol på tilstanden du allerede har. Etter din egen vellykkede redigering, ikke les filen på nytt for å verifisere — redigeringsverktøyet feiler høylytt når det mislykkes. Gjenlesing er for eksterne endringer, ikke dine egne.

Disse tre ble kjernen i skillen. Rundt dem ligger seks regler til: les utdrag i stedet for filer, spør store JSON-filer/logger med python eller jq i stedet for å åpne dem, oppsummer og slipp lange output, deleger brede utforskninger til subagenter, hold konteksten cache-vennlig (stabilt prefiks urørt — Anthropics egen engineering-blogg kaller prompt caching den enkeltfaktoren med høyest gevinst for kostnad), og, ja, knapp output også. Ni regler, hver formulert som en håndfast regel med et oppgitt alternativ, slik at det aldri koster presisjon å følge dem.

Slik benchmarket vi den

Samme protokoll som i vår Skill Bench-serie: samme modell, samme prompt, én variabel. Hver oppgave kjørte to ganger — én Claude Sonnet-agent uten skill, én som leste SKILL.md først og fikk beskjed om å følge den strengt. Skill-agentens totaler inkluderer kostnaden ved å lese selve skillen. Testgrunnlaget var vår egen kodebase: et Astro-nettsted med rundt 9 000 linjer maler pluss et JSON-datasett med 16 682 poster — stort nok til at udisiplinert lesing faktisk gjør vondt.

Fem oppgavepar, valgt for å dekke spekteret fra trivielt til reelt flertrinns:

Oppgave	Baseline	Med skill	Δ
Kodebase-spørsmål — 8 spørsmål på tvers av delsystemer	88 419	71 636	−19,0 %
Redigering av flere filer — 4 koordinerte endringer	68 219	54 637	−19,9 %
Kodesporing — engangsoppgave	53 986	52 850	−2,1 %
Revisjonsgjennomgang — engangsoppgave	44 691	44 705	+0,0 %
Stor-JSON-sammendrag — engangsoppgave	42 726	45 164	+5,7 %

Hva tallene faktisk sier

På reelt flertrinnsarbeid sparer skillen rundt 20 %. Kodebase-spørsmålene med åtte spørsmål er det nærmeste vi kommer en vanlig arbeidsøkt — spore autentiseringsflyten, forklare webhooken, finne sorteringslogikken. Baseline-agenten svarte riktig, men underveis leste den rundhåndet og verifiserte unødvendig. Den disiplinerte agenten svarte på de samme spørsmålene, med samme nøyaktighet (vi sjekket hver eneste fil:linje-referanse fra begge), for 16 783 færre tokens.

Redigeringen av flere filer er det mer interessante resultatet. Fire koordinerte endringer i fire filer. Baseline-agenten ble ferdig og — med dens egne ord fra rapporten — «verifiserte ved å lese de redigerte områdene på nytt». Den vanen alene utgjør en femtedel av regningen. Skill-agenten gjorde de samme fire endringene, hoppet over seremonigjenlesingene, og meldte ferdig. Vi diffet begge arbeidstrærne: redigeringene var likeverdige og korrekte i begge. Ingenting gikk tapt ved å stole på at verktøyet feiler ved mislykkethet, for det er det verktøy gjør.

På trivielle engangsoppgaver går det i null — og det publiserer vi likevel. JSON-sammendragsoppgaven kostet faktisk 5,7 % mer med skillen. To grunner, begge lærerike. For det første koster selve skillen rundt 1 400 tokens å lese, og en oppgave som er unnagjort etter to verktøykall gir ikke den overheaden noe å fordele seg over. For det andre oppfører en modell av nyeste generasjon seg allerede bra på enkle oppgaver: baseline-agenten kastet ett blikk på en JSON med 16 682 poster og grep til python i stedet for å åpne den. Ingen skill nødvendig. Disiplin lønner seg der udisiplin er mulig — lange økter, mange filer, kontekst som hoper seg opp — ikke der det ikke er noe å sløse med.

Hvis øktene dine stort sett er enlinjere, leverer skillen sitt eget svar: en destillert blokk på 60 tokens du limer inn i CLAUDE.md i stedet for å installere hele skillen. Alltid på, koster omtrent like mye som denne setningen, og én unngått hel-fil-lesing betaler den tilbake mange ganger. (Vi bygde en kalkulator for nettopp denne alltid-på-skatten — matematikken for trigger-beskrivelser gjelder like mye for regelblokker.)

De ni reglene, kort fortalt

Hele SKILL.md er på ~1 400 tokens og lesbar på én skjerm; her er formen:

1. Søk før du leser. Grep først; les så treffet ±30 linjer. Å lese mer enn ~200 linjer krever en grunn du kan si i én setning.
2. Les utdraget, ikke filen. Offset+limit for alt som er langt; python/jq for alt som er strukturert. En stor JSON er en database, ikke et dokument.
3. Slå sammen uavhengige verktøykall. Én melding, flere kall, når output ikke mater input.
4. Stol på tilstanden du allerede har. Ingen verifiseringsgjenlesing etter dine egne redigeringer; ikke kjør søk på nytt når resultatene allerede er i konteksten.
5. Ikke sitér kode tilbake. Referer til file:line. Lim inn kun det mennesket må se for å bestemme.
6. Oppsummer, så slipp. Etter en lang verktøy-output, behold de 2–5 faktaene, be aldri om loggen på nytt.
7. Deleger tung utforskning. Brede gjennomganger går til en subagent; de tunge avlesningene dør i dens kontekst, ikke din.
8. Hold konteksten cache-vennlig. Stabilt prefiks urørt; legg til, ikke skriv om; vær obs på cache-TTL.
9. Output-disiplin. Svar først, ingen innledning, ingen diff-essays.

I tillegg et selvrevisjons-sjekkpunkt (tre spørsmål før enhver stor gjenlesing) og en eksplisitt ikke-gjør-liste, fordi en token-skill som får en agent til å hoppe over nødvendig verifisering, ikke sparer deg for noe — den bare utsetter etterarbeidet. Trenger en reell feiljakt hele filen, sier regelen at du skal lese den, med grunnen oppgitt.

Hvor dette passer inn i det større kostnadsbildet

Regler som disse er den variable halvparten av regningen din. Den faste halvparten — 30 000-tokens-innledningen fra MCP-servere, oppblåste CLAUDE.md-filer, og alltid-på skill-beskrivelser som sendes på nytt med bokstavelig talt hver eneste forespørsel — er et annet problem med andre løsninger, og som regel den største gevinsten for tunge brukere. Vi skrev opp den revisjonen i Reduser Claude Code-tokenkostnader; de to stykkene utfyller hverandre: fiks de faste kostnadene én gang, la så token-discipline holde de variable kostnadene flate gjennom hele økten.

Og hvis du lurer på om skills generelt sparer tokens: Skill Bench-serien vår målte fire populære skills og fant at de stort sett ikke gjør det — de koster ekstra tokens og kjøper i stedet kvalitet og disiplin. token-discipline ble bygget spesifikt for å være unntaket, og selv da tjener den bare inn kostnaden på flertrinnsarbeid. Det er den ærlige grensen, og vi vil heller trekke den selv enn at du finner den på regningen din.

Installasjon

git clone https://github.com/Skillproofdev/token-discipline ~/.claude/skills/token-discipline

Start Claude Code på nytt. Den utløses av «reduce token usage», «work token-efficiently», klager om kontekstgrense, og kostnadsspørsmål — eller bruk den økt-bredt via CLAUDE.md-blokken inni.

Ofte stilte spørsmål

Erstatter dette output-verbosity-skillene? Nei — den inkluderer kjernen deres (regel 9) og legger til input-siden de hopper over. Kjører du allerede et knapt-output-regelsett, overlapper token-discipline med det på én regel av ni.

Blir Claude sløvere av dette? Benchmarken sier nei: redigeringen av flere filer kom ut likeverdig og korrekt på begge sider, og skillens ikke-gjør-liste beskytter eksplisitt verifisering som faktisk er nødvendig. Reglene erstatter seremoni-lesing, ikke nødvendig lesing.

Hvorfor er selve skillen så kort? Fordi en token-sparende skill som koster tusenvis av tokens per økt å laste, ville vært selvparodi. SKILL.md er på ~1 400 tokens lastet ved behov; den alltid-på CLAUDE.md-blokken er på ~60.

Jeg har et Pro/Max-abonnement, ikke API-tilgang. Har dette betydning? Ja, i grense-valuta: de samme tokenene som faktureres API-brukere spiser av dine bruksgrenser. Tjue prosent færre tokens på arbeidsøkter betyr proporsjonalt mer arbeid før du treffer taket.

Var benchmarken plukket for å vise skillen i beste lys? De fem oppgavene ble designet før noen av variantene kjørte, og vi publiserte de to resultatene der skillen tapte. Rå telemetri — tokentellinger og verktøykall-tellinger per kjøring — finnes i repoets README.