Token-disciplin-skill för Claude Code: ärligt testad

Vi ägnar våra dagar åt att mäta andras Claude-skills, och ett mönster dök upp gång på gång i telemetrin: sessionerna som blev dyra blev inte dyra för att Claude skrev långa svar. De blev dyra på grund av det Claude läste. Hela filer öppnade för att hitta en enda funktion. Filer omlästa direkt efter en lyckad redigering, "bara för att verifiera". En JSON med 16 000 poster hämtad in i kontexten som om den vore ett blogginlägg.

Så vi byggde en skill som attackerar den sidan av notan, publicerade den under en MIT-licens och gjorde det vi kräver av varje skill vi listar: benchmarkade den mot en baseline med kontrollerade körningar och publicerade siffrorna — även de som inte smickrar den.

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

Luckan i varje token-skill vi granskade

Innan vi skrev en enda rad gick vi igenom åtta publicerade token-besparande skills och protokoll — från output-verbosity-regelverket med 5 800 stjärnor som dominerar nischen, till "nödskills" som triggas vid 40% kontext, till protokoll som påstår sig spara 76–93% utan någon mekanism kopplad till sig och utan telemetri vi kunde hitta.

Nästan alla delar samma blinda fläck: de optimerar output. Ta bort inledningsfraserna, korta ner svaren, sluta upprepa planen. Det är verkligt, men det är den mindre halvan av notan. I agent-sessioner — Claude Code som gör faktiskt arbete i ett repo — dominerar input: varje filläsning, varje sökresultat, varje verktygsoutput hamnar i kontexten och skickas med igen vid varje efterföljande förfrågan.

Tre input-sidiga tekniker fanns i ingen av de åtta som hårda regler:

1. Sök innan du läser. Lokalisera först med grep/glob, läs sedan bara den matchande regionen. Öppna aldrig en hel fil för att hitta något.
2. Batcha oberoende verktygsanrop. Om tre läsningar inte beror på varandra hör de hemma i samma meddelande. Varje extra runda betalar på nytt för tanke- och narrations-tokens mellan anropen.
3. Lita på tillstånd du redan har. Efter din egen lyckade redigering, läs inte om filen för att verifiera — redigeringsverktyget felar högljutt om det misslyckas. Omläsningar är till för externa ändringar, inte dina egna.

De tre blev kärnan i skillen. Runt dem finns sex regler till: läs utsnitt i stället för hela filer, fråga stora JSON-filer/loggar med python eller jq i stället för att öppna dem, sammanfatta och släpp långa outputs, delegera bred utforskning till subagenter, håll kontexten cache-vänlig (stabilt prefix orört — Anthropics egen engineering-blogg kallar prompt caching den enskilt mest lönsamma kostnadsfaktorn), och, ja, kortfattad output också. Nio regler, var och en formulerad som en hård regel med ett angivet alternativ, så att följa dem aldrig kostar korrekthet.

Så benchmarkade vi den

Samma protokoll som vår Skill Bench-serie: samma modell, samma prompt, en variabel. Varje uppgift kördes två gånger — en Claude Sonnet-agent utan skill, en som läste SKILL.md först och fick instruktionen att följa den strikt. Skill-agentens totalsumma inkluderar kostnaden för att läsa själva skillen. Testbädden var vår egen kodbas: en Astro-sajt med cirka 9 000 rader templates plus ett dataset i JSON med 16 682 poster — tillräckligt stort för att odisciplinerad läsning faktiskt gör ont.

Fem uppgiftspar, valda för att täcka spannet från trivialt till genuint flerstegsarbete:

Uppgift	Baseline	Med skill	Δ
Kodbas-Q&A — 8 frågor över olika delsystem	88 419	71 636	−19.0%
Multifil-redigering — 4 samordnade ändringar	68 219	54 637	−19.9%
Kodspårning — engångsjobb	53 986	52 850	−2.1%
Granskningssvep — engångsjobb	44 691	44 705	+0.0%
Stor-JSON-sammanfattning — engångsjobb	42 726	45 164	+5.7%

Vad siffrorna faktiskt säger

På riktigt flerstegsarbete sparar skillen ungefär 20%. Kodbas-Q&A:n med åtta frågor är det som ligger närmast en normal arbetssession — spåra autentiseringsflödet, förklara webhooken, hitta sorteringslogiken. Baseline-agenten svarade korrekt, men läste generöst och verifierade redundant på vägen. Den disciplinerade agenten svarade på samma frågor, med samma träffsäkerhet (vi kontrollerade varje file:line-referens från båda), för 16 783 färre tokens.

Multifil-redigeringen är det mer intressanta resultatet. Fyra samordnade ändringar i fyra filer. Baseline-agenten blev klar och — för att citera dess egen rapport — "verifierade genom att läsa om de redigerade avsnitten". Den vanan står ensam för en femtedel av notan. Skill-agenten genomförde samma fyra ändringar, hoppade över ceremoniomläsningarna och rapporterade klart. Vi diffade båda arbetsträden: redigeringarna var likvärdiga och korrekta i båda. Inget gick förlorat genom att lita på att verktyget felar vid misslyckande, för det är vad verktyg gör.

På triviala engångsjobb blir det oavgjort — och vi publicerar det ändå. JSON-sammanfattningsuppgiften kostade faktiskt 5.7% mer med skillen. Två anledningar, båda lärorika. För det första kostar skillen själv ungefär 1 400 tokens att läsa, och en uppgift som klaras av på två verktygsanrop ger den overheaden ingen plats att fördelas ut på. För det andra beter sig en modell av senaste generationen redan väl på enkla uppgifter: baseline-agenten kastade en blick på en JSON med 16 682 poster och tog python i stället för att öppna den. Ingen skill behövdes. Disciplin lönar sig där odisciplin är möjlig — långa sessioner, många filer, kontext som växer — inte där det inte finns något att slösa med.

Om dina sessioner mest är enradare levererar skillen sitt eget svar: ett destillerat block på 60 tokens som du klistrar in i CLAUDE.md i stället för att installera hela skillen. Alltid aktivt, kostar ungefär lika mycket som den här meningen, och en enda undviken helfilsläsning betalar tillbaka det många gånger om. (Vi byggde en kalkylator för precis den här alltid-på-skatten — matematiken för triggerbeskrivningar gäller lika mycket för regelblock.)

De nio reglerna, kort

Hela SKILL.md är ~1 400 tokens och går att läsa på en skärm; så här ser den ut:

1. Sök innan du läser. Grep först, läs sedan träffen ±30 rader. Att läsa mer än ~200 rader kräver ett skäl du kan formulera i en mening.
2. Läs utsnittet, inte filen. Offset+limit för allt som är långt; python/jq för allt strukturerat. En stor JSON är en databas, inte ett dokument.
3. Batcha oberoende verktygsanrop. Ett meddelande, flera anrop, närhelst outputs inte matar inputs.
4. Lita på tillstånd du redan har. Inga verifieringsomläsningar efter dina egna redigeringar; kör inte om sökningar vars resultat redan finns i kontexten.
5. Citera inte kod tillbaka. Referera med file:line. Klistra in bara det människan måste se för att bestämma sig.
6. Sammanfatta, släpp sedan. Efter en lång verktygsoutput, behåll de 2–5 fakta, begär aldrig loggen igen.
7. Delegera tung utforskning. Breda svep går till en subagent; de tunga läsningarna dör i dess kontext, inte i din.
8. Håll kontexten cache-vänlig. Stabilt prefix orört; lägg till, skriv inte om; tänk på cachens TTL.
9. Output-disciplin. Svara först, ingen inledning, inga diff-uppsatser.

Plus en självgranskningskontroll (tre frågor innan varje stor omläsning) och en uttrycklig gör-inte-lista, för en token-skill som får en agent att hoppa över nödvändig verifiering sparar dig ingenting — den skjuter bara upp omarbetet. Om en riktig buggjakt behöver hela filen säger regeln att läsa den, med skälet angivet.

Var det här passar in i den större kostnadsbilden

Regler som dessa är den rörliga halvan av din nota. Den fasta halvan — inledningen på 30 000 tokens från MCP-servrar, uppsvällda CLAUDE.md-filer och alltid-aktiva skill-beskrivningar som skickas med bokstavligen varje förfrågan — är ett annat problem med andra fixar, och oftast den större vinsten för tunga användare. Vi skrev upp den granskningen i Minska Claudes tokenförbrukning: 6 fixar som kapar kostnaden; de två delarna kompletterar varandra: fixa de fasta kostnaderna en gång, låt sedan token-discipline hålla de rörliga kostnaderna platta hela sessionen.

Och om du undrar om skills i allmänhet sparar tokens: vår Skill Bench-serie mätte fyra populära skills och fann att de mestadels inte gör det — de kostar extra tokens och köper kvalitet och disciplin i stället. token-discipline byggdes specifikt för att vara undantaget, och även då tjänar den bara in sin plats på flerstegsarbete. Det är den ärliga gränsen, och vi föredrar att dra den själva framför att du hittar den på din faktura.

Installation

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

Starta om Claude Code. Den triggas på "reduce token usage", "work token-efficiently", klagomål om kontextgränser och kostnadsfrågor — eller applicera den sessionsbrett via CLAUDE.md-blocket som finns inuti.

Vanliga frågor

Ersätter den här output-verbosity-skills? Nej — den innehåller deras kärna (regel 9) och lägger till inputsidan de missar. Om du redan kör ett regelverk för kort output överlappar token-discipline det på en regel av nio.

Gör den Claude slarvigare? Benchmarken säger nej: multifil-redigeringen blev likvärdig och korrekt på båda sidor, och skillens gör-inte-lista skyddar uttryckligen verifiering som faktiskt krävs. Reglerna ersätter ceremoniella läsningar, inte nödvändiga.

Varför är själva skillen så kort? För att en tokenbesparande skill som kostar tusentals tokens per session att ladda in skulle vara självparodi. SKILL.md är ~1 400 tokens som laddas vid behov; det alltid aktiva CLAUDE.md-blocket är ~60.

Jag har ett Pro/Max-abonnemang, inte API:et. Spelar det här någon roll? Ja, i gränsvaluta: samma tokens som fakturerar API-användare förbrukar dina användningstak. Tjugo procent färre tokens på arbetssessioner betyder proportionellt mer arbete innan du når taket.

Var benchmarken vinklad till skillens fördel? De fem uppgifterna designades innan någon av varianterna kördes, och vi publicerade de två resultaten där skillen förlorade. Rå telemetri — antal tokens och verktygsanrop per körning — finns i repots README.