Cost optimization Claude Code: Opus / Sonnet / Haiku + sub-agent worktree

Cost optimization su Claude Code non è negoziare il prezzo per token (il listino è quello), è scegliere il modello giusto per ogni task. Opus per deep reasoning, Sonnet per execution bilanciata, Haiku per batch ripetitivi. Una decision matrix consistente riduce la spesa mensile del 40-60% senza degradare qualità misurabile.

Disclaimer di indipendenza: non sono affiliato ad Anthropic. I numeri citati sono sanitized: range invece di valori esatti, ratios invece di assoluti. Sufficiente per ragionare, non per audit finanziario.

I tre modelli in breve (rapporto cost approssimativo)

• Opus 4.7: deepest reasoning. Cost ~5x Sonnet. Use case: planning, plan-checker, architectural decisions.
• Sonnet 4.6: balanced cost/quality. Best coding model. Use case: execution, research, ui-researcher, code-reviewer, refactor-cleaner.
• Haiku 4.5: 90% Sonnet capability per cost ratio inferiore. ~3x cost saving vs Sonnet. Use case: batch lookup, simple parsing, verification semplici, doc generation routine.

Decision matrix per task type

Benchmark cost mensile sanitized portfolio

Distribuzione tipica del mio uso mensile sul portfolio (numeri indicativi, non esatti):

• Opus: ~15-25% dei token. Concentrati in planner + plan-checker iter 1+2 + decisioni strategiche.
• Sonnet: ~65-75% dei token. La maggior parte del workflow operativo.
• Haiku: ~10-15% dei token. Batch jobs + verification ripetitivi.

Spesa media: €100-300 / mese (range che varia con intensità d'uso). Picco: ~€500/mese in mesi con feature mostro (es. Phase 20 ~108k parole content + 10 plan + i18n bulk).

Senza decision matrix (Opus per tutto): spesa stimata 2-3x = €200-900/mese. Saving annuo: ~€1500-4000.

Sub-agent isolation con worktree

Pattern per executor sub-agent paralleli che modificano files: ogni sub-agent gira in git worktree temporaneo. Vantaggi:

• Changes isolate per sub-agent (no race condition file).
• Cleanup automatico se sub-agent non produce changes.
• Path + branch returned se changes exist (per merge orchestrator).

Invocazione tipica nello spawn:

Agent(
  description="...",
  subagent_type="gsd-executor",
  model="sonnet",
  prompt="...",
  isolation="worktree"
)

Caveat: git stash non funziona in worktree perché refs/stash è shared. Usa git checkout -- <file> per cleanup, non stash. Lezione personale: prima volta che ho usato worktree ho fatto stash e pop ha tirato dentro WIP da sibling worktree. Salvato in memory feedback per non ripetere.

Strategie cost-saving operative

1. Decision matrix consistente: tutti i sub-agent configurati con model appropriato fin dall'inizio. Modificare al volo ("usiamo Opus per questa singola call") è eccezione, non norma.
2. Sub-agent specializzati: invece di sub-agent "general purpose" Opus che fa tutto, specializzati su task ristretti possono spesso usare Sonnet o Haiku.
3. Cache content-hash: per task ripetitivi (es. i18n translation, doc rewriting), cache di output per input hash evita retranslate/regenerate identici.
4. Skip ridondanti: gsd-pattern-mapper è optional - skip se CONTEXT.md ha già code_context section. Risparmia ~25k token per fase.
5. Manual fallback su task piccoli: scrivere manualmente un file 200 righe spesso costa meno tempo + token che spawn un sub-agent per quello. Sub-agent ha overhead di setup.

Anti-pattern: Opus everywhere

Tentazione iniziale: "Opus è il migliore, lo uso per tutto". Costo esplode senza valore proporzionato. Sonnet 4.6 è già il "best coding model" - Opus marginal value su execution è bassa, marginal cost è 5x.

Mitigation: default sub-agent su Sonnet. Opus riservato a sub-agent planning + plan-checker + decisioni macro (10-20% del totale token).

Anti-pattern: Haiku su task complessi

L'opposto: Haiku per risparmio aggressivo. Su task che richiedono reasoning multistep, Haiku produce output di qualità inferiore che richiede 2-3 rework + costa più di un Sonnet one-shot.

Soglia: Haiku per task con input/output deterministico (parsing, validation, doc routine). Sonnet per task che richiedono "judgment".

Misurare il cost realmente

Anthropic console mostra token consumati per giorno. Sul mio setup:

1. Daily check console (~1 minuto/giorno): qual è il trend?
2. Settimana check: ratio Opus/Sonnet/Haiku in linea con target?
3. Monthly review: spesa totale vs budget? Trend in crescita?

Trend in crescita inaspettata = qualche pattern di workflow è cambiato. Investigate: nuovo sub-agent introdotto? Plan-checker iter aumentate? Sub-agent timeout (re-spawn) frequenti?

Cost per phase budget

Sul portfolio uso budget indicativo per fase:

• Phase piccola (1-3 plan, no content writing): ~€10-20.
• Phase media (4-7 plan): ~€30-80.
• Phase mostro (10+ plan + content writing): ~€100-300.

Phase 20 (la fase che ha prodotto questa serie): ~€80-150 stimati (10 plan + 21 articoli content + i18n bulk + verification). Budget respected.

Cosa ho imparato scrivendo questo articolo

La cosa che mi ha sorpreso è quanto poco fosse intuitivo il rapporto cost/quality fra Opus e Sonnet. Pensavo "Opus migliore = sempre da preferire", ma sul portfolio reale Sonnet ha qualità execution equivalente per la maggior parte dei task pratici. Opus brilla su decisioni strategiche (planner, plan-checker) ma è waste su execute.

Secondo insight: il cost optimization è soprattutto disciplina, non cleverness. Una decision matrix scritta + applicata consistentemente vale più di qualsiasi trick di ottimizzazione caso-per-caso. Setup decisione una volta, applica per mesi.

Anti-pattern evitati

• Opus everywhere: cost esplode senza valore. Default Sonnet.
• Haiku su complex task: rework costa più del saving.

Una storia ricevuta che vale la pena condividere

Sezione segnaposto. Se hai pattern cost optimization originali, scrivimi a federico@federicocalo.dev.

← Cluster precedente: IDE/web/CLI environments Prossimo cluster (cross-framework): Debug-skill troubleshooting end-to-end →