Otto repo Claude Code misurati su un progetto: costo sessione, ablation, verdetti

TL;DR

• Otto repo popolari per Claude Code sono stati installati a livello di progetto su un'unica codebase reale e misurati: token all'avvio della sessione, token in output su tre task di coding e cosa ciascuno scriveva fuori dal progetto.
• Solo uno degli otto ha cambiato un risultato: anti-slop, usato come linter, ha intercettato lo stesso cast non sicuro in tutte e 3 le run di T3, per +95 token di sessione e nulla per turno.
• I ruleset a output conciso non hanno retto sul lavoro con tool: il 52% della baseline dichiarato da Chisle è diventato il 94% dei token di output della baseline, e il suo braccio è costato più della baseline su due task su tre, una volta contato l'input.
• I tre server MCP non sono mai stati chiamati in 63 run. Installato non vuol dire usato.
• Lo stack è additivo: tutti e otto insieme hanno aggiunto +6,804 token all'avvio, 63 token in meno della somma delle parti.
• Due installazioni sono uscite dal progetto. Un codemod si è registrato nelle configurazioni globali di altri 8 agenti; un tool imposta a codice --dangerously-skip-permissions e copia il file delle credenziali, quindi non è mai stato eseguito.

Cosa dicono le misure

I token all'avvio della sessione sono riproducibili, il costo in dollari no: ogni condizione ha restituito lo stesso totale di token in input in entrambe le run, mentre il costo della stessa condizione oscillava da $0.0183 a $0.0035 a seconda dello stato della prompt cache, quindi il conteggio dei token è la metrica usata ovunque. Il progetto baseline parte da 17,378 token s4.

Gli schemi dei tool MCP sono differiti in questa versione di Claude Code, e il costo ora scala con il numero di nomi di tool che un server dichiara, non con la dimensione degli schemi. I 39 tool di ouroboros costano +1,642 token, i 19 di reticle +895, i 2 di ui-skills +37: circa 42 a 47 token per nome di tool. Per impostazione predefinita tutti i tool MCP sono differiti e caricati on demand, e la modalità auto di ENABLE_TOOL_SEARCH li differisce quando le loro definizioni raggiungono il 10% della finestra di contesto s4. img2threejs include un SKILL.md da 32,902 byte e 352 file, e costa +107 token all'avvio, perché si carica solo la description del frontmatter. La documentazione delle skill limita ogni description in elenco a 1,536 caratteri e accorcia le description per rientrare in un budget di listing quando le skill sono molte; dopo la compattazione, le skill invocate vengono riallegate a 5,000 token ciascuna dentro un budget condiviso di 25,000 token s5. È quel budget di listing a spiegare perché 40 skill possono costare 3,060 token a turno in un setup che non ne invoca nessuna s10, e perché a venire tagliate sono le description, non le skill s11.

L'hook UserPromptSubmit di Chisle aggiunge 287 byte di additionalContext a ogni turno; su un task di 22 turni è per questo che il suo braccio è costato +41,539 token di input totali su T3 rispetto alla baseline. caveman, misurato come riferimento, non inietta nulla a meno che il prompt non inizi con /caveman. Quando più hook sullo stesso evento restituiscono ciascuno additionalContext, Claude li riceve tutti concatenati, con un limite di 10,000 caratteri per hook s15. Con Chisle, caveman e ouroboros collegati insieme c'erano 3 registrazioni su SessionStart, 3 su UserPromptSubmit e 2 su PostToolUse, per +4,269 token all'avvio s15.

Il README di Chisle dichiara una fattura su 20 task al 52% della baseline, e lo stesso README limita quella cifra a prompt a turno singolo senza tool s3. Su tre task contro un repo reale, 3 run ciascuno, le medie di output sommate di Chisle sono state 9,007 token contro una baseline di 9,615, cioè il 94%; quelle di caveman 10,820, cioè il 113%, su un campione in cui la dispersione di T3 era di 2,014 token, quindi nessuna delle due direzioni supera il rumore s3. Il compressore di output di Chisle non ha mai scritto un record di risparmio in 63 run.

anti-slop incorporato in tools/oxlint/ con tutte e 18 le regole generiche più oxc/no-accumulating-spread ha trovato 109 problemi nel progetto intatto di 4,775 righe, l'83% dei quali da due regole di house style (require-readable-spacing 50, require-safety-comment-for-type-assertion 41) s8. Sul codice scritto da Claude ha intercettato maxLength={field.maxLength as number} in tutte e 3 le run di T3, con Claude che copiava il cast non sicuro della codebase stessa s8. Il plugin è ESM, quindi il progetto host ha bisogno di "type": "module" altrimenti oxlint fallisce con Cannot use import statement outside a module.

Il codemod init di Reticle, eseguito con RETICLE_STATE_DIR impostato e telemetria disattivata, ha riportato di aver registrato il server MCP con altri 8 agenti (VS Code user scope, GitHub Copilot CLI, Warp, Factory Droid, Kiro, Amazon Q Developer CLI, Cline CLI, Amp) e di aver pre-approvato i suoi tool in Gemini CLI; poi il pairing è fallito con ERR_OSSL_EVP_UNSUPPORTED s6. Caliper è stato rifiutato: claude_code.py:106 imposta a codice --dangerously-skip-permissions e seed_files() copia ~/.claude/.credentials.json con un fallback sul Keychain s2. L'hook UserPromptSubmit di ouroboros risponde a un prompt ordinario come write prd for reading time con REQUIRED SKILL: /ouroboros:setup, un passaggio che un'installazione a livello di progetto non può soddisfare s7.

Un paper su 2,545 traiettorie con librerie di 52, 102 e 202 skill riporta cali di pass rate aggregati di .08, .14 e fino al 21%, con description simili che si fanno ombra a vicenda come quota crescente della perdita s20.

Misure

Protocollo: un progetto TypeScript reale, ogni repo installato solo a livello di progetto. Avvio sessione: il prompt Reply with OK in modalità JSON -p con flag identici, 2 run per condizione, cifra = input_tokens + cache_creation_input_tokens + cache_read_input_tokens del primo turno. Ablation: tre task di coding (T1 breve, T2 medio, T3 task UI lungo) con controlli di superamento e un gate di type-check, 3 run per cella, condizioni = baseline, ogni repo sempre attivo da solo, tutti e otto insieme. anti-slop: oxlint 1.78.0 con il ruleset incorporato sul progetto intatto e sul codice scritto nelle 9 run baseline.

63/63 run superate e 0/63 con un nuovo errore di tipo. Solo due celle superano la propria dispersione tra run: Chisle su T1 (−234, −14.0%) e lo stack su T1 (−206, −12.3%). Su T2 e T3 ogni delta resta dentro la dispersione; le run di T3 di ouroboros andavano da 4,324 a 7,093 token di output con un prompt identico, un'oscillazione del 64%.

Da fare lunedì

• Esegui /context all in una sessione nuova del tuo progetto principale e annota il numero di partenza.
• Esegui claude plugin details <name> su ogni plugin installato; la riga always-on è l'unica cifra che viene fatturata a ogni turno.
• Elenca i tuoi hook per evento. Qualunque hook che restituisce additionalContext su UserPromptSubmit a ogni prompt è una tassa per turno; tieni solo quelli che filtrano su una keyword o un matcher.
• Conta i nomi di tool che ogni server MCP dichiara, calcola circa 42 a 47 token per nome, poi controlla nei tuoi transcript quanti sono mai stati chiamati.
• Prima di installare qualunque cosa con uno script init o di setup, leggilo cercando scritture fuori dal repo: ~/.claude/settings.json, directory di config di altri agenti, file di credenziali, --dangerously-skip-permissions.
• Collega i controlli di qualità sul codice generato come linter nel passo di verifica, non come skill nel contesto: una regola di lint non costa nulla per turno.
• Prima di fidarti di qualunque promessa di risparmio di token, esegui lo stesso task 3 volte con e senza il tool e confronta il delta con la tua dispersione min-max.
• Archivia ciò che rimuovi invece di cancellarlo, così un workflow che lo richiede può riaverlo.

Per approfondire

• Il budget di listing delle skill e il limite di 1,536 caratteri per le description spiegano perché un setup affollato peggiora senza che nessuna skill smetta di caricarsi. Leggi le sezioni "Skill descriptions are cut short" e "Skill content lifecycle" s5.
• L'articolo su /skill-doctor mostra 40 skill che costano 3,060 token a turno e quali tagliare per prime; il suo punto cieco, le skill costose dentro un plugin in uso, resta per un seguito s10.
• Il paper dietro la regola empirica "più di 30 skill": 2,545 traiettorie su librerie da 52, 102 e 202 skill, con l'effetto di ombreggiamento isolato s20, e il riassunto accessibile che l'ha reso popolare s12.
• La concatenazione degli hook e il limite di 10,000 caratteri di additionalContext, più la sintassi dei matcher che permette a un hook di scattare solo su Write|Edit s15.
• Il thread sulla rimozione del 63%, incluso un bearer token hardcoded trovato in una config MCP rimossa, una digressione sulla sicurezza che il video ha lasciato fuori s13.
• Il README di Chisle stesso, righe 229 e 262, limita la sua cifra del 52% a prompt a turno singolo senza tool e concede la cella del coding breve a caveman. Leggi le note in piccolo prima di citare il titolo s3.
• I due repo fuori stack non sono stati valutati perché si invocano a mano e non costano nulla all'avvio: img2threejs per le scene Three.js s21 e fwc-swiftui-skills per le superfici Liquid Glass s22.

Fonti

• Plugins reference, documentazione di Claude Code. Perché leggerla: plugin details, gli scope di installazione e il caricamento differito dei tool MCP che rende il numero di nomi di tool il costo reale.
• Extend Claude with skills, documentazione di Claude Code. Perché leggerla: il limite delle description, il budget di listing e il budget di riallegamento dopo la compattazione in un'unica pagina.
• Hooks reference, documentazione di Claude Code. Perché leggerla: cosa succede quando due hook iniettano sullo stesso evento, e come i matcher tengono un hook fuori dalla maggior parte dei turni.
• dmmulroy/anti-slop, GitHub. Perché leggerlo: l'unico repo degli otto che ha cambiato un risultato; incorpora le regole, salta la skill.
• JayPokale/Chisle, GitHub. Perché leggerlo: un README che delimita onestamente la propria dichiarazione del 52% se leggi oltre il titolo.
• edonadei/caliper, GitHub. Perché leggerlo: un valutatore di skill da conoscere, e una lezione sul leggere claude_code.py prima di eseguire qualunque cosa.
• reticlehq/reticle, GitHub. Perché leggerlo: il codemod init è l'esempio più chiaro di un installer che scrive ben fuori dal tuo progetto.
• Q00/ouroboros, GitHub. Perché leggerlo: un workflow guidato da hook che ha senso solo se installato globalmente, con un passaggio di setup che un'installazione di progetto non può soddisfare.
• ibelick/ui-skills, GitHub. Perché leggerlo: l'installazione più economica qui con +37 token, e mai chiamata una volta.
• /skill-doctor: 40 skills, 3,060 tokens a turn, dev.to. Perché leggerlo: una ripartizione del costo per skill su un setup reale.
• Too many Claude Code skills? How the listing budget decides, dev.to. Perché leggerlo: il meccanismo con cui le description vengono troncate.
• Why More Than 30 Skills Kill Your AI Agent, dev.to. Perché leggerlo: la versione leggibile del paper sullo shadowing.
• Skill shadowing paper, arXiv. Perché leggerlo: i cali di pass rate aggregati per dimensione della libreria, con intervalli di confidenza.
• I removed 63% of my Claude Code setup, Reddit r/ClaudeCode. Perché leggerlo: da ~235 componenti a ~87, archiviati e non cancellati.
• My fresh Claude Code sessions were starting at ~35K tokens, Reddit r/ClaudeCode. Perché leggerlo: un audit in sette passi con /context all che puoi copiare questo pomeriggio.
• img2threejs/img2threejs, GitHub. Perché leggerlo: la prova che un SKILL.md da 32,902 byte costa 107 token finché non lo invochi.
• FloWritesCode/fwc-swiftui-skills, GitHub. Perché leggerlo: skill in Markdown statico, la forma di un'installazione che non può entrare in conflitto con nulla.

FAQ

Un server MCP costa ancora migliaia di token di schema all'avvio?

Non sulla versione misurata. Gli schemi sono differiti e il costo scala con il numero di nomi di tool dichiarati, circa 42 a 47 token ciascuno. Un server con 39 tool è costato +1,642 token; uno con 2 tool +37.

Perché Chisle è costato più della baseline pur producendo meno token di output?

Il suo ruleset si carica all'avvio della sessione (+3,496 token) e il suo hook inietta 287 byte a ogni turno. Su T2 e T3 quel sovraccarico di input ha superato un risparmio di output che non ha mai superato il rumore tra run.