Paula Silva Software Global Black Belt
LinkedIn

Token Management & Agent DesignGestão de Tokens e Design de AgentesGestión de Tokens y Diseño de Agentes

A field guide for engineering leaders running real agentic workloads: where tokens go, where cost lives, and which design choices separate teams that ship agents in production from teams that overpay for impressive demos.Um guia de campo para líderes de engenharia que rodam cargas agênticas reais: para onde vão os tokens, onde mora o custo e quais decisões de design separam os times que colocam agentes em produção dos que pagam caro por demos impressionantes.Una guía de campo para líderes de ingeniería que ejecutan cargas agénticas reales: adónde van los tokens, dónde vive el costo y qué decisiones de diseño separan a los equipos que ponen agentes en producción de los que pagan caro por demos impresionantes.

The inflection point

On June 1, 2026, GitHub Copilot retired PRUs and switched every paid SKU to AI Credits — a per-million-token meter where the model you pick decides the bill. If your team still treats Copilot as one undifferentiated commodity, your spend is about to triple silently. This playbook is what you do to keep that from happening.

What a token actually is

The model never sees your text. It operates on integers indexed into a vocabulary of 32K to 200K entries. Without this foundation every cost estimate is a guess.

A token is not a word — it is a sub-word unit discovered by BPE on a training corpus. The density varies significantly by content type:

Content typeWords per tokenWhy
English prose~0.75Common words map to single tokens
Brazilian Portuguese~0.60Accents and cedillas split into sub-words
Spanish~0.65Slightly denser than Portuguese
Python source~0.40Symbols, indentation, identifiers are token-heavy
TypeScript / JSX~0.35Generics and JSX symbols inflate further
Structured JSON~0.30Quotes, braces, separators dominate

Rule of thumb: a 1,000-line Python file is approximately 12,000 tokens. A 2,000-word PT-BR markdown is about 3,300 tokens. A 500-word English response is around 670 tokens.

Where the tokens go

In real agentic SDLC workloads, input dominates and output is a rounding error. A typical session distributes as: input 60%, cache read 21%, output 14%, cache write 5%.

Each phase carries a different cost and optimization lever:

  • Input (parallel attention) is cheap per token but expensive in volume — Sonnet 4.6 runs at $3/M input. It grows quadratically in agent loops. The levers are caching, compaction, and lean tool definitions.
  • Output (autoregressive) is 5x the input price but represents a small share — Sonnet 4.6 at $15/M output. It is strictly sequential with no parallelism. Cap it with concise prompts and structured JSON.
  • Cache read (KV reuse) costs 10% of input — $0.30/M on Sonnet 4.6. It triggers when the prefix hash matches and is an architecture decision, not a flag.
  • Cache write costs $3.75/M at a 5-minute TTL or $6/M at 1 hour. It is worth paying when you expect more than roughly 3 reads per write.

The agentic multiplier

A 10-turn agent loop does not cost 10x a single call. Without compaction or caching, input grows quadratically: Turn 1 is 1x baseline. Turn 5 is 15x. Turn 10 is 55x. The loop re-sends the full conversation history and tool results every turn. Caching and compaction collapse this curve back toward linear. This is why “agent for everything” architectures always blow their budget.

Model selection: the largest lever

Model is the first-order cost lever. Sonnet vs. Opus on the same task can be 5x without 5x more quality.

The Anthropic family at post-June 2026 list prices:

  • Opus 4.7 — $15/M input, $75/M output. For architecture, distributed debugging, and complex tradeoff analysis. Use only when reasoning depth justifies 5x the bill of Sonnet.
  • Sonnet 4.6 — $3/M input, $15/M output. The default for 80% of agentic tasks: deep code review, agent mode, multi-file work. Same quality envelope as Opus, one-fifth the cost.
  • Haiku 4.5 — $1/M input, $5/M output. For classification, extraction, and low-complexity batch completions. 15x cheaper than Opus, good enough for fixed-shape tasks.

The five-level heuristic: Level 1 trivial tasks (completions, format fixes, doc lookups) go to Bundled or Haiku. Level 2 routine tasks (edit mode, single-file refactors) stay on Bundled. Level 3 default work goes to Sonnet 4.6 — this is the 80% case. Level 4 hard reasoning (architecture, distributed debugging, security review) goes to Opus 4.7 scoped to plan-only, then hands off. Level 5 long-context analysis (whole-codebase forensics, >200K context) goes to Gemini 3.1 Pro.

The most expensive anti-pattern: Opus as default. Five times the bill, less than 1.1x the quality on routine tasks.

Context engineering

More context is not better. After a threshold, every extra token adds cost without adding signal — and starts subtracting quality. The golden rule: minimum signal-rich context, never maximum context.

Context rot measured on real workloads:

  • At 0x noise: quality 0.95, cost $0.10 — optimal.
  • At 1x noise: quality 0.94, cost $0.20 — cost doubled, quality flat, already losing money.
  • At 5x noise: quality 0.88, cost $0.60 — quality starts dropping.
  • At 10x noise: quality 0.79, cost $1.10 — visible degradation.
  • At 50x noise: quality 0.62, cost $5.10 — severe rot, the agent forgets the goal.

The three levers against context rot: compaction (structured compression of conversation history), tool-result clearing (drop verbose tool outputs after extraction), and retrieval-on-demand (load large context only when the agent explicitly needs it).

Prompt caching: the 90% lever

In conversational workloads, prefix caching cuts input cost by up to 90% without changing one line of prompt. The architecture requirement is strict: stable prefix, dynamic suffix, cache_control on the right blocks.

A single byte change in the prefix invalidates the whole cache. The pattern: Session 1 (cold) pays full input on the prefix plus a 25% write surcharge. From Session 2 onward, the prefix is read at 0.1x of input cost. Saving on session 2 is approximately 89% of input cost; from session 3 onward, it reaches ~90%.

Cache pays off above roughly 3 reads per write. Choose the 5-minute TTL for per-session use, the 1-hour TTL for multi-session workloads. The canonical anti-pattern: timestamps inside the cached prefix. Each request hashes differently, the cache never warms.

Agent design: workflow vs. agent

There is a hype bias — agents for everything. Workflows solve 70% of enterprise cases at a fraction of the cost.

Workflows (deterministic): LLMs and tools orchestrated by code paths. The sequence is known and stable. Cost is predictable — the same N calls per execution regardless of input. Easy to instrument, debug, and audit. Low and stable latency.

Agents (dynamic): the LLM decides which tools, in which order, based on intermediate results. The sequence varies per input — cost is a distribution, not a number. It pays for open exploration and is worth it when the problem is genuinely open-ended and tools are first-class. It demands stop criteria, budgets, and telemetry. Without them it loops forever.

The decision heuristic: if you can sketch the steps on paper, use a workflow. If you genuinely cannot, an agent earns its keep.

The five Anthropic patterns

These patterns compose. Do not invent alternatives when these cover the case.

  1. Prompt chaining — decompose into ordered steps. Cheapest and most auditable. Default for SDLC subroutines.
  2. Routing — a cheap classifier sends each request to the right specialist model. Massive savings on mixed traffic.
  3. Parallelization — fan out independent subtasks to reduce latency. Watch the multiplier on cache writes.
  4. Orchestrator-workers — plan with Opus, execute with Sonnet or Haiku. The single best premium-to-bundled bridge.
  5. Evaluator-optimizer — loop with a critic, bounded iterations. Pair with a budget or it never stops.

Anti-pattern: multi-agent without coordination — N agents, no shared memory, no contracts. Pays N× and contradicts itself.

Less is more

A 700-token review prompt and a 50-token review prompt produce equivalent reviews. The verbose version — “Review this code carefully, considering security implications, performance characteristics, architecture decisions…” — pays $700/M tokens just on instructions, repeated every turn. The compact version — “Senior reviewer. Flag security, perf, correctness. JSON: {issues:[{severity, file, line, fix}]}.” — achieves a 93% reduction. In tests, review quality is equivalent or better because the model has more attention budget for the actual code.

Pair lean prompts with progressive disclosure: a small SKILL.md on every call, large checklists loaded only on demand via a load_section tool.

The June 2026 change: seven things shipping together

Four of the seven changes are silent. Two will double your bill if you do nothing:

  1. PRUs retired in monthly plans — old budgets stop applying, per-call meter starts.
  2. GitHub AI Credits replace PRUs — $1 of credits equals approximately $1 USD of metered usage at list price.
  3. Plan base price unchanged — $10 / $19 / $39 / $99. The illusion that nothing changed.
  4. Completions and NES included — code completions and Next Edit Suggestions do not consume credits.
  5. Fallback experiences removed — no more silent downgrade when credits run out.
  6. Code review doubles in billing — each review now bills as two interactions.
  7. Pro/Pro+ annual stays in PRUs until renewal — decide path A, B, or C before that date.

Three paths for Pro/Pro+ annual holders: Path A — stay on annual PRUs until expiration (best for steady, predictable usage). Path B — convert to monthly with AI Credits (best for power users who want premium models on demand). Path C — cancel for a prorated refund and move to direct API (best for teams already running mostly on Anthropic API directly).

FinOps for AI: Inform, Optimize, Operate

Apply the FinOps Foundation phases to token spend in sequence:

Phase 1 — Inform (visibility before action): cost-per-token, per-feature, per-user dashboards; tag every call with cost-center and feature; surface the top-10 outliers daily.

Phase 2 — Optimize (pull each lever in ROI order): model routing first (largest delta), prompt caching second (silent 60–90%), compaction and lean tools third.

Phase 3 — Operate (FinOps as a habit): weekly operational report, monthly executive summary, anomaly alerts at 3σ over rolling baseline, quarterly tariff review tied to roadmap.

The savings waterfall

In sequence, the four levers compound from $1.00 to $0.18 per equivalent session, indexed against a baseline of Opus-by-default:

  • Baseline (Opus-by-default): $1.00
    • Model routing (Sonnet default, Opus scoped): $0.50 — minus 50%
    • Prompt caching (stable prefix, 5-min TTL): $0.28 — minus 44%
    • Compaction (tool-result clearing): $0.22 — minus 21%
    • Lean prompts (progressive disclosure): $0.18 — minus 18%

Order matters. Each lever stacks on the previous one. Skipping model routing first leaves the largest delta unclaimed.

Applied: 50-developer org, before and after 90 days

Day 0 — $48K/month: ~70% of agent calls hit Opus even on routine tasks. Cache hit rate: 4% (prefix not stable). Top 10% of users absorb 52% of total spend. No cost-per-feature tracking, no anomaly alerts.

Day 90 — $22K/month: same throughput, more agentic features shipped. Sonnet handles 80% of agent traffic, Opus scoped to plan-only. Cache hit rate: 71% (stable prefix, cache_control, 5-min TTL). Top 10% rebalanced via routing, outliers actioned weekly. Cost-per-feature dashboard live, 3σ anomaly alerts on.

The 90-day operator checklist

  • Day 0–7: inventory PRU spend per persona; tag every agent call with cost-center and feature.
  • Day 8–14: set Sonnet 4.6 as the workspace default; allowlist Opus per repo with justification.
  • Day 15–30: roll out cache_control on the three biggest stable blocks — system prompt, tool definitions, AGENTS.md.
  • Day 31–60: compaction plus tool-result clearing in the agent loop; lean prompt rewrite of top-3 templates.
  • Day 61–90: model routing in the pipeline; Plan/Execute split for Opus; anomaly alerts at 3σ over rolling baseline.

The model is one lever. The architecture is the other four.

O ponto de inflexão

Em 1º de junho de 2026, o GitHub Copilot aposentou os PRUs e migrou todo plano pago para AI Credits — um medidor por milhão de tokens onde o modelo escolhido define a fatura. Se seu time ainda trata o Copilot como uma commodity indiferenciada, seu gasto vai triplicar silenciosamente. Este playbook é o que você faz para evitar isso.

O que é um token de verdade

O modelo nunca vê seu texto. Ele opera sobre inteiros indexados em um vocabulário de 32K a 200K entradas. Sem essa base, toda estimativa de custo é um chute.

Token não é palavra — é uma unidade sub-palavra descoberta por BPE em um corpus de treino. A densidade varia significativamente por tipo de conteúdo:

Tipo de conteúdoPalavras por tokenPor quê
Texto em inglês~0,75Palavras comuns mapeiam para um único token
Português brasileiro~0,60Acentos e cedilhas se quebram em sub-palavras
Espanhol~0,65Levemente mais denso que o português
Código Python~0,40Símbolos, indentação e identificadores são caros
TypeScript / JSX~0,35Genéricos e símbolos JSX inflam ainda mais
JSON estruturado~0,30Aspas, chaves e separadores dominam

Regra de bolso: um arquivo Python de 1.000 linhas equivale a aproximadamente 12.000 tokens. Um markdown de 2.000 palavras em PT-BR gera cerca de 3.300 tokens. Uma resposta de 500 palavras em inglês fica em torno de 670 tokens.

Para onde vão os tokens

Em workloads agênticos reais de SDLC, o input domina e o output é arredondamento. Uma sessão típica distribui assim: input 60%, leitura de cache 21%, output 14%, escrita de cache 5%.

Cada fase tem um custo e uma alavanca de otimização diferentes:

  • Input (atenção paralela) é barato por token, mas caro em volume — Sonnet 4.6 custa $3/M de input. Cresce quadraticamente em loops de agentes. As alavancas são cache, compactação e tool definitions enxutas.
  • Output (autorregressivo) custa 5x o input, mas representa parcela pequena — Sonnet 4.6 a $15/M de output. É estritamente sequencial, sem paralelismo. Limite com prompts concisos e JSON estruturado.
  • Leitura de cache (reutilização de KV) custa 10% do input — $0,30/M no Sonnet 4.6. Dispara quando o hash do prefixo bate. É uma decisão de arquitetura, não uma flag.
  • Escrita de cache custa $3,75/M no TTL de 5 minutos ou $6/M em 1 hora. Vale pagar quando se esperam mais de aproximadamente 3 leituras por escrita.

O multiplicador agêntico

Um loop agêntico de 10 turnos não custa 10x uma chamada única. Sem compactação ou cache, o input cresce quadraticamente: Turno 1 é 1x o baseline. Turno 5 é 15x. Turno 10 é 55x. O loop reenvia todo o histórico de conversa e os resultados de tools a cada turno. Cache e compactação trazem essa curva de volta para o linear. É por isso que arquiteturas “agente para tudo” sempre estouram o orçamento.

Seleção de modelo: a maior alavanca

Modelo é a alavanca de custo de primeira ordem. Sonnet vs. Opus na mesma tarefa pode ser 5x sem 5x mais qualidade.

A família Anthropic nos preços de tabela pós-junho de 2026:

  • Opus 4.7 — $15/M input, $75/M output. Para arquitetura, debugging distribuído e análise de tradeoffs complexos. Use apenas quando a profundidade de raciocínio justifica 5x a fatura do Sonnet.
  • Sonnet 4.6 — $3/M input, $15/M output. O padrão para 80% das tarefas agênticas: code review profundo, agent mode, trabalho em múltiplos arquivos. Mesmo envelope de qualidade do Opus, um quinto do custo.
  • Haiku 4.5 — $1/M input, $5/M output. Para classificação, extração e completions em lote de baixa complexidade. 15x mais barato que o Opus, suficientemente bom para tarefas de formato fixo.

A heurística de cinco níveis: tarefas triviais de Nível 1 (completions, correções de formato, lookups) vão para Bundled ou Haiku. Tarefas rotineiras de Nível 2 (edit mode, refactors de arquivo único) ficam no Bundled. O trabalho padrão do Nível 3 vai para Sonnet 4.6 — este é o caso de 80%. Raciocínio difícil do Nível 4 (arquitetura, debugging distribuído, revisão de segurança) vai para Opus 4.7 escopado apenas ao planejamento, depois repassa. Análise de long context do Nível 5 (codebase inteiro, >200K de contexto) vai para Gemini 3.1 Pro.

O anti-padrão mais caro: Opus por padrão. Cinco vezes a fatura, menos de 1,1x a qualidade em tarefas rotineiras.

Context engineering

Mais contexto não é melhor. Passado um limiar, cada token extra adiciona custo sem adicionar sinal — e começa a subtrair qualidade. A regra de ouro: contexto mínimo rico em sinal, nunca contexto máximo.

Context rot medido em workloads reais:

  • Com 0x de ruído: qualidade 0,95, custo $0,10 — ótimo.
  • Com 1x de ruído: qualidade 0,94, custo $0,20 — custo dobrou, qualidade plana, já perdendo dinheiro.
  • Com 5x de ruído: qualidade 0,88, custo $0,60 — qualidade começa a cair.
  • Com 10x de ruído: qualidade 0,79, custo $1,10 — degradação visível.
  • Com 50x de ruído: qualidade 0,62, custo $5,10 — rot severo, o agente esquece o objetivo.

As três alavancas contra o context rot: compactação (compressão estruturada do histórico da conversa), tool-result clearing (descarte de outputs verbosos de tools após extração) e retrieval-on-demand (carregamento de contexto grande apenas quando o agente explicitamente precisa).

Prompt caching: a alavanca dos 90%

Em workloads conversacionais, o cache de prefixo corta o custo de input em até 90% sem mudar uma linha do prompt. O requisito de arquitetura é rigoroso: prefixo estável, sufixo dinâmico, cache_control nos blocos certos.

Um único byte alterado no prefixo invalida o cache inteiro. O padrão: Sessão 1 (fria) paga o input completo no prefixo mais uma sobretaxa de escrita de 25%. A partir da Sessão 2, o prefixo é lido a 0,1x do custo de input. A economia na sessão 2 é de aproximadamente 89% do custo de input; a partir da sessão 3, chega a ~90%.

O cache se paga acima de aproximadamente 3 leituras por escrita. Use o TTL de 5 minutos para uso por sessão, o TTL de 1 hora para workloads multi-sessão. O anti-padrão clássico: timestamps dentro do prefixo cacheado. Cada request recebe um hash diferente, o cache nunca aquece.

Design de agentes: workflow vs. agente

Há um viés de hype — agentes para tudo. Workflows resolvem 70% dos casos enterprise por uma fração do custo.

Workflows (determinísticos): LLMs e tools orquestrados por caminhos de código. A sequência é conhecida e estável. O custo é previsível — as mesmas N chamadas por execução, independentemente do input. Fácil de instrumentar, depurar e auditar. Latência baixa e estável.

Agentes (dinâmicos): o LLM decide quais tools usar, em qual ordem, com base nos resultados intermediários. A sequência varia por input — o custo é uma distribuição, não um número. Paga pela exploração aberta e vale a pena quando o problema é genuinamente não-estruturado e as tools são cidadãs de primeira classe. Exige stop criteria, orçamentos e telemetria. Sem eles, entra em loop para sempre.

A heurística de decisão: se você consegue desenhar os passos no papel, use um workflow. Se genuinamente não consegue, um agente se paga.

Os cinco padrões da Anthropic

Estes padrões se compõem. Não invente alternativas quando eles cobrem o caso.

  1. Prompt chaining — decompõe em passos ordenados. O mais barato e auditável. Padrão para sub-rotinas de SDLC.
  2. Routing — um classificador barato envia cada request ao modelo especialista certo. Economias massivas em tráfego misto.
  3. Paralelização — fan-out de subtarefas independentes para reduzir latência. Atenção ao multiplicador em escritas de cache.
  4. Orchestrator-workers — planeja com Opus, executa com Sonnet ou Haiku. A melhor ponte entre premium e bundled.
  5. Evaluator-optimizer — loop com um crítico, iterações limitadas. Combine com um orçamento ou ele nunca para.

Anti-padrão: multi-agente sem coordenação — N agentes, sem memória compartilhada, sem contratos. Paga N× e se contradiz.

Less is more

Um prompt de revisão de 700 tokens e um de 50 tokens produzem reviews equivalentes. A versão verbosa — “Revise este código cuidadosamente, considerando implicações de segurança, características de desempenho, decisões de arquitetura…” — paga $700/M de tokens só em instruções, repetidas a cada turno. A versão compacta — “Revisor sênior. Sinalize segurança, perf, correção. JSON: {issues:[{severity, file, line, fix}]}.” — alcança uma redução de 93%. Em testes, a qualidade da revisão é equivalente ou melhor porque o modelo tem mais orçamento de atenção para o código em si.

Combine prompts enxutos com progressive disclosure: um SKILL.md pequeno em cada chamada, checklists grandes carregados apenas sob demanda via tool load_section.

A virada de junho de 2026: sete mudanças juntas

Quatro das sete mudanças são silenciosas. Duas dobram sua fatura se você não agir:

  1. PRUs aposentados nos planos mensais — os orçamentos antigos param de funcionar, o medidor por chamada começa.
  2. GitHub AI Credits substituem PRUs — $1 de credits equivale a aproximadamente $1 USD de uso medido no preço de tabela.
  3. Preço base do plano não muda — $10 / $19 / $39 / $99. A ilusão de que nada mudou.
  4. Completions e NES inclusos — completions de código e Next Edit Suggestions não consomem credits.
  5. Fallbacks removidos — acabou o downgrade silencioso quando os credits acabam.
  6. Code review dobra no billing — cada revisão agora é cobrada como duas interações.
  7. Pro/Pro+ anual permanece em PRUs até a renovação — decida o Path A, B ou C antes dessa data.

Três caminhos para titulares de Pro/Pro+ anual: Path A — continuar no anual em PRUs até expirar (melhor para uso estável e previsível). Path B — converter para mensal com AI Credits (melhor para power users que querem modelos premium sob demanda). Path C — cancelar com reembolso proporcional e migrar para API direta (melhor para times que já rodam majoritariamente na Anthropic API direta).

FinOps para IA: Inform, Optimize, Operate

Aplique as fases do FinOps Foundation ao gasto com tokens em sequência:

Fase 1 — Inform (visibilidade antes de agir): dashboards de custo por token, por feature, por usuário; tagueie cada chamada com cost-center e feature; exponha os top-10 outliers diariamente.

Fase 2 — Optimize (puxe cada alavanca em ordem de ROI): model routing primeiro (maior delta), prompt caching segundo (silencioso, 60–90%), compactação e tools enxutas em terceiro.

Fase 3 — Operate (FinOps como hábito): relatório operacional semanal, resumo executivo mensal, alertas de anomalia a 3σ sobre o baseline móvel, revisão tarifária trimestral atrelada ao roadmap.

A cascata de economia

Em sequência, as quatro alavancas compõem de $1,00 para $0,18 por sessão equivalente, indexado sobre o baseline de Opus-por-padrão:

  • Baseline (Opus por padrão): $1,00
    • Model routing (Sonnet padrão, Opus escopado): $0,50 — menos 50%
    • Prompt caching (prefixo estável, TTL de 5 min): $0,28 — menos 44%
    • Compactação (tool-result clearing): $0,22 — menos 21%
    • Prompts enxutos (progressive disclosure): $0,18 — menos 18%

A ordem importa. Cada alavanca empilha sobre a anterior. Pular o model routing primeiro deixa o maior delta por realizar.

Aplicado: org de 50 devs, antes e depois de 90 dias

Dia 0 — $48K/mês: ~70% das chamadas de agente batem em Opus mesmo em tarefas rotineiras. Cache hit rate: 4% (prefixo não estável). Top 10% dos usuários absorvem 52% do gasto total. Sem rastreamento de custo por feature, sem alertas de anomalia.

Dia 90 — $22K/mês: mesmo throughput, mais features agênticas entregues. Sonnet atende 80% do tráfego de agentes, Opus escopado apenas para planejamento. Cache hit rate: 71% (prefixo estável, cache_control, TTL de 5 min). Top 10% rebalanceado via routing, outliers tratados semanalmente. Dashboard de custo por feature ativo, alertas de anomalia a 3σ ligados.

O checklist do operador para os primeiros 90 dias

  • Dia 0–7: inventarie o gasto de PRU por persona; tagueie cada chamada de agente com cost-center e feature.
  • Dia 8–14: defina Sonnet 4.6 como padrão do workspace; permita Opus por repositório com justificativa.
  • Dia 15–30: faça o roll-out de cache_control nos três maiores blocos estáveis — system prompt, tool definitions, AGENTS.md.
  • Dia 31–60: compactação mais tool-result clearing no loop de agentes; reescrita lean do prompt dos top-3 templates.
  • Dia 61–90: model routing no pipeline; Plan/Execute split para Opus; alertas de anomalia a 3σ sobre baseline móvel.

O modelo é uma alavanca. A arquitetura são as outras quatro.

El punto de inflexión

El 1 de junio de 2026, GitHub Copilot retiró los PRUs y migró todo SKU pago a AI Credits — un medidor por millón de tokens donde el modelo elegido define la factura. Si tu equipo aún trata Copilot como una commodity indiferenciada, tu gasto va a triplicarse en silencio. Este playbook es lo que haces para evitarlo.

Qué es realmente un token

El modelo nunca ve tu texto. Opera sobre enteros indexados en un vocabulario de 32K a 200K entradas. Sin esta base, toda estimación de costo es un supuesto.

Un token no es una palabra — es una sub-unidad descubierta por BPE en un corpus de entrenamiento. La densidad varía significativamente según el tipo de contenido:

Tipo de contenidoPalabras por tokenPor qué
Prosa en inglés~0,75Las palabras comunes mapean a un solo token
Portugués brasileño~0,60Los acentos y cedillas se rompen en sub-palabras
Español~0,65Levemente más denso que el portugués
Código Python~0,40Símbolos, indentación e identificadores son costosos
TypeScript / JSX~0,35Los genéricos y símbolos JSX inflan aún más
JSON estructurado~0,30Comillas, llaves y separadores dominan

Regla de bolsillo: un archivo Python de 1.000 líneas equivale a aproximadamente 12.000 tokens. Un markdown de 2.000 palabras en PT-BR genera unos 3.300 tokens. Una respuesta de 500 palabras en inglés ronda los 670 tokens.

Adónde van los tokens

En cargas agénticas reales de SDLC, el input domina y el output es casi un redondeo. Una sesión típica se distribuye así: input 60%, lectura de cache 21%, output 14%, escritura de cache 5%.

Cada fase tiene un costo y una palanca de optimización distintos:

  • Input (atención paralela) es barato por token pero costoso en volumen — Sonnet 4.6 cuesta $3/M de input. Crece cuadráticamente en loops de agentes. Las palancas son cache, compactación y tool definitions magras.
  • Output (autoregresivo) cuesta 5x el input, pero representa una porción pequeña — Sonnet 4.6 a $15/M de output. Es estrictamente secuencial, sin paralelismo. Limítalo con prompts concisos y JSON estructurado.
  • Lectura de cache (reutilización de KV) cuesta el 10% del input — $0,30/M en Sonnet 4.6. Se activa cuando el hash del prefijo coincide. Es una decisión de arquitectura, no un flag.
  • Escritura de cache cuesta $3,75/M con TTL de 5 minutos o $6/M a 1 hora. Vale la pena cuando se esperan más de aproximadamente 3 lecturas por escritura.

El multiplicador agéntico

Un loop agéntico de 10 turnos no cuesta 10x una sola llamada. Sin compactación ni cache, el input crece cuadráticamente: el Turno 1 es 1x el baseline. El Turno 5 es 15x. El Turno 10 es 55x. El loop reenvía todo el historial de conversación y los resultados de tools en cada turno. El cache y la compactación devuelven esa curva a lineal. Por eso las arquitecturas de “agente para todo” siempre se salen del presupuesto.

Selección de modelo: la palanca más grande

El modelo es la palanca de costo de primer orden. Sonnet vs. Opus en la misma tarea puede ser 5x sin 5x más calidad.

La familia Anthropic a precios de lista post-junio 2026:

  • Opus 4.7 — $15/M input, $75/M output. Para arquitectura, debugging distribuido y análisis de tradeoffs complejos. Úsalo solo cuando la profundidad de razonamiento justifica 5x la factura de Sonnet.
  • Sonnet 4.6 — $3/M input, $15/M output. El predeterminado para el 80% de las tareas agénticas: code review profundo, agent mode, trabajo en múltiples archivos. Mismo sobre de calidad que Opus, una quinta parte del costo.
  • Haiku 4.5 — $1/M input, $5/M output. Para clasificación, extracción y completions en lote de baja complejidad. 15x más barato que Opus, suficientemente bueno para tareas de formato fijo.

La heurística de cinco niveles: las tareas triviales del Nivel 1 (completions, correcciones de formato, lookups) van a Bundled o Haiku. Las tareas rutinarias del Nivel 2 (edit mode, refactors de un solo archivo) se quedan en Bundled. El trabajo por defecto del Nivel 3 va a Sonnet 4.6 — este es el caso del 80%. El razonamiento difícil del Nivel 4 (arquitectura, debugging distribuido, revisión de seguridad) va a Opus 4.7 acotado solo a la planificación, luego delega. El análisis de long context del Nivel 5 (codebase completo, >200K de contexto) va a Gemini 3.1 Pro.

El antipatrón más caro: Opus por defecto. Cinco veces la factura, menos de 1,1x la calidad en tareas rutinarias.

Context engineering

Más contexto no es mejor. Pasado un umbral, cada token extra agrega costo sin agregar señal — y empieza a restar calidad. La regla de oro: contexto mínimo rico en señal, nunca contexto máximo.

Context rot medido en cargas reales:

  • Con 0x de ruido: calidad 0,95, costo $0,10 — óptimo.
  • Con 1x de ruido: calidad 0,94, costo $0,20 — el costo se duplicó, calidad plana, ya se pierde dinero.
  • Con 5x de ruido: calidad 0,88, costo $0,60 — la calidad empieza a bajar.
  • Con 10x de ruido: calidad 0,79, costo $1,10 — degradación visible.
  • Con 50x de ruido: calidad 0,62, costo $5,10 — rot severo, el agente olvida el objetivo.

Las tres palancas contra el context rot: compactación (compresión estructurada del historial de conversación), tool-result clearing (descartar outputs verbosos de tools tras la extracción) y retrieval-on-demand (cargar contexto grande solo cuando el agente lo necesita explícitamente).

Prompt caching: la palanca del 90%

En cargas conversacionales, el cache de prefijo recorta el costo de input hasta un 90% sin cambiar una sola línea del prompt. El requisito de arquitectura es estricto: prefijo estable, sufijo dinámico, cache_control en los bloques correctos.

Un solo byte cambiado en el prefijo invalida todo el cache. El patrón: la Sesión 1 (fría) paga el input completo en el prefijo más un recargo de escritura del 25%. A partir de la Sesión 2, el prefijo se lee al 0,1x del costo de input. El ahorro en la sesión 2 es de aproximadamente 89% del costo de input; a partir de la sesión 3 llega al ~90%.

El cache se paga por encima de aproximadamente 3 lecturas por escritura. Usa el TTL de 5 minutos para uso por sesión, el TTL de 1 hora para cargas multi-sesión. El antipatrón clásico: timestamps dentro del prefijo cacheado. Cada request recibe un hash distinto, el cache nunca se calienta.

Diseño de agentes: workflow vs. agente

Existe un sesgo de hype — agentes para todo. Los workflows resuelven el 70% de los casos enterprise por una fracción del costo.

Workflows (determinísticos): LLMs y tools orquestados por rutas de código. La secuencia es conocida y estable. El costo es predecible — las mismas N llamadas por ejecución sin importar el input. Fácil de instrumentar, depurar y auditar. Latencia baja y estable.

Agentes (dinámicos): el LLM decide qué tools usar, en qué orden, basándose en los resultados intermedios. La secuencia varía por input — el costo es una distribución, no un número. Paga por la exploración abierta y vale la pena cuando el problema es genuinamente no estructurado y las tools son ciudadanas de primera clase. Exige stop criteria, presupuestos y telemetría. Sin ellos, entra en bucle para siempre.

La heurística de decisión: si puedes esbozar los pasos en papel, usa un workflow. Si genuinamente no puedes, un agente se justifica.

Los cinco patrones de Anthropic

Estos patrones se componen. No inventes alternativas cuando cubren el caso.

  1. Prompt chaining — descompone en pasos ordenados. El más barato y auditable. Por defecto para subrutinas de SDLC.
  2. Routing — un clasificador barato envía cada request al modelo especialista correcto. Ahorros masivos en tráfico mixto.
  3. Paralelización — fan-out de subtareas independientes para reducir latencia. Vigila el multiplicador en escrituras de cache.
  4. Orchestrator-workers — planifica con Opus, ejecuta con Sonnet o Haiku. El mejor puente entre premium y bundled.
  5. Evaluator-optimizer — bucle con un crítico, iteraciones acotadas. Combínalo con un presupuesto o nunca termina.

Antipatrón: multi-agente sin coordinación — N agentes, sin memoria compartida, sin contratos. Paga N× y se contradice.

Less is more

Un prompt de revisión de 700 tokens y uno de 50 tokens producen reviews equivalentes. La versión verbosa — “Revisa este código con cuidado, considerando implicaciones de seguridad, características de rendimiento, decisiones de arquitectura…” — paga $700/M de tokens solo en instrucciones, repetidas en cada turno. La versión compacta — “Revisor sénior. Marca seguridad, perf, corrección. JSON: {issues:[{severity, file, line, fix}]}.” — logra una reducción del 93%. En pruebas, la calidad de la revisión es equivalente o mejor porque el modelo tiene más presupuesto de atención para el código real.

Combina prompts magros con progressive disclosure: un SKILL.md pequeño en cada llamada, checklists grandes cargados solo bajo demanda mediante la tool load_section.

El cambio de junio de 2026: siete cosas a la vez

Cuatro de los siete cambios son silenciosos. Dos duplicarán tu factura si no actúas:

  1. PRUs retirados en planes mensuales — los presupuestos viejos dejan de aplicar, el medidor por llamada arranca.
  2. GitHub AI Credits reemplazan los PRUs — $1 de credits equivale aproximadamente a $1 USD de uso medido al precio de lista.
  3. El precio base del plan no cambia — $10 / $19 / $39 / $99. La ilusión de que nada cambió.
  4. Completions y NES incluidos — las completions de código y Next Edit Suggestions no consumen credits.
  5. Fallbacks removidos — se acabó el downgrade silencioso cuando se agotan los credits.
  6. Code review se duplica en el billing — cada revisión ahora se cobra como dos interacciones.
  7. Pro/Pro+ anual sigue en PRUs hasta la renovación — decide el Path A, B o C antes de esa fecha.

Tres caminos para titulares de Pro/Pro+ anual: Path A — quedarte en el anual con PRUs hasta que expire (mejor para uso estable y predecible). Path B — convertir a mensual con AI Credits (mejor para power users que quieren modelos premium bajo demanda). Path C — cancelar con reembolso proporcional y migrar a API directa (mejor para equipos que ya trabajan principalmente con la API de Anthropic directamente).

FinOps para IA: Inform, Optimize, Operate

Aplica las fases de FinOps Foundation al gasto en tokens en secuencia:

Fase 1 — Inform (visibilidad antes de actuar): dashboards de costo por token, por feature, por usuario; etiqueta cada llamada con cost-center y feature; expón los top-10 outliers diariamente.

Fase 2 — Optimize (tira cada palanca en orden de ROI): model routing primero (mayor delta), prompt caching segundo (silencioso, 60–90%), compactación y tools magras en tercer lugar.

Fase 3 — Operate (FinOps como hábito): reporte operacional semanal, resumen ejecutivo mensual, alertas de anomalía a 3σ sobre el baseline móvil, revisión tarifaria trimestral vinculada al roadmap.

La cascada de ahorro

En secuencia, las cuatro palancas componen de $1,00 a $0,18 por sesión equivalente, indexado contra un baseline de Opus-por-defecto:

  • Baseline (Opus por defecto): $1,00
    • Model routing (Sonnet por defecto, Opus acotado): $0,50 — menos 50%
    • Prompt caching (prefijo estable, TTL de 5 min): $0,28 — menos 44%
    • Compactación (tool-result clearing): $0,22 — menos 21%
    • Prompts magros (progressive disclosure): $0,18 — menos 18%

El orden importa. Cada palanca apila sobre la anterior. Saltarse el model routing primero deja el mayor delta sin aprovechar.

Aplicado: org de 50 devs, antes y después de 90 días

Día 0 — $48K/mes: ~70% de las llamadas de agente llegan a Opus incluso en tareas rutinarias. Cache hit rate: 4% (prefijo no estable). El top 10% de los usuarios absorbe el 52% del gasto total. Sin rastreo de costo por feature, sin alertas de anomalía.

Día 90 — $22K/mes: mismo throughput, más features agénticas entregadas. Sonnet atiende el 80% del tráfico de agentes, Opus acotado solo a la planificación. Cache hit rate: 71% (prefijo estable, cache_control, TTL de 5 min). Top 10% rebalanceado mediante routing, outliers tratados semanalmente. Dashboard de costo por feature activo, alertas de anomalía a 3σ encendidas.

El checklist del operador para los primeros 90 días

  • Día 0–7: inventaría el gasto de PRU por persona; etiqueta cada llamada de agente con cost-center y feature.
  • Día 8–14: establece Sonnet 4.6 como default del workspace; permite Opus por repositorio con justificación.
  • Día 15–30: haz el roll-out de cache_control en los tres bloques estables más grandes — system prompt, tool definitions, AGENTS.md.
  • Día 31–60: compactación más tool-result clearing en el loop de agentes; reescritura lean del prompt de los top-3 templates.
  • Día 61–90: model routing en el pipeline; Plan/Execute split para Opus; alertas de anomalía a 3σ sobre baseline móvil.

El modelo es una palanca. La arquitectura son las otras cuatro.

← Knowledge Hub

Paula Silva | Software Global Black Belt

Start with the platform, not the agents. Comece pela plataforma, não pelos agentes. Comience por la plataforma, no por los agentes.

Building the future of software development with AI and Agentic DevOps.

Knowledge Hub · v3.4.0 · 2026-06-17
paulasilva · 2026-06-17 EN · PT-BR · ES