← Volver al listado de tecnologías ← Índice de Everything Claude Code

Capítulo 8: Optimización de Tokens

Por: Artiko
claude-codetokensoptimizacioncostos

Capítulo 8: Optimización de Tokens

Reducir 60-90% el costo de Claude Code sin sacrificar calidad

1. El Problema Real: Cuánto Cuesta Claude Code

Antes de optimizar, necesitas entender el problema. Un desarrollador que usa Claude Code sin ninguna optimización puede gastar entre $50 y $300 al mes dependiendo de su volumen de trabajo. Con optimización correcta, ese mismo desarrollador puede pagar entre $10 y $60 al mes por resultados equivalentes o mejores.

Escenario sin optimización

Supongamos una jornada laboral de 8 horas usando Claude Code con Opus (el modelo más caro) para todas las tareas:

Actividades típicas de un día:

ActividadDuraciónTokens input estimadosTokens output estimados
Exploración de codebase (10 búsquedas)30 min80,0008,000
Implementar 3 features medianas3 horas450,000120,000
Code review de 5 PRs1.5 horas200,00060,000
Debugging de bugs complejos2 horas300,00080,000
Diseño de arquitectura1 hora150,00050,000
Total8 horas1,180,000318,000

Costo con Opus ($15/MTok input + $75/MTok output):

Input:  1,180,000 tokens × $15 / 1,000,000 = $17.70
Output:   318,000 tokens × $75 / 1,000,000 = $23.85
Total día:                                    $41.55
Total mes (22 días laborales):               $913.10

Costo con la configuración optimizada ECC (mezcla de modelos):

Exploración con Haiku:   88,000 × $0.25/MTok input + 8,000 × $1.25/MTok output
                       = $0.022 + $0.010 = $0.032

Features con Sonnet:    450,000 × $3/MTok input + 120,000 × $15/MTok output
                       = $1.35 + $1.80 = $3.15

Code review con Sonnet: 200,000 × $3/MTok input + 60,000 × $15/MTok output
                       = $0.60 + $0.90 = $1.50

Debugging con Sonnet:   300,000 × $3/MTok input + 80,000 × $15/MTok output
                       = $0.90 + $1.20 = $2.10

Arquitectura con Opus:  150,000 × $15/MTok input + 50,000 × $75/MTok output
                       = $2.25 + $3.75 = $6.00

Total día optimizado:   $12.78
Total mes optimizado:   $281.16

Ahorro mensual: ~$631 (69% de reducción)

Y esto es antes de aplicar las otras optimizaciones del capítulo. Con compaction estratégica, mgrep, codebase modular y gestión de MCPs, el ahorro puede llegar al 85-90%.

Por qué la gente no optimiza

El problema más común es que los costos de Claude Code se sienten “invisibles” hasta que llega la factura. La interfaz de línea de comandos no muestra en tiempo real cuánto está costando cada interacción. Muchos desarrolladores solo descubren el problema cuando ven su tarjeta de crédito.

El segundo problema es que optimizar parece complicado o que va a sacrificar calidad. Este capítulo demuestra que con la configuración correcta, la calidad se mantiene igual o mejora porque los modelos se usan donde realmente agregan valor.

2. La Ventana de Contexto de Claude Code

Claude Code tiene una ventana de contexto de 200,000 tokens. Parece muchísimo, pero cuando entiendes cómo se distribuye, ves que el espacio útil para tu trabajo es considerablemente menor.

Cómo se divide la ventana de 200K tokens

pie title "Distribución de la ventana de contexto 200K tokens"
    "Prompt del sistema base" : 8
    "CLAUDE.md y reglas" : 6
    "Skills cargados" : 12
    "Schemas de MCPs" : 15
    "Historial de conversación" : 35
    "Herramientas disponibles" : 9
    "Espacio útil para trabajo" : 15

Desglose aproximado con una instalación estándar de Claude Code:

ComponenteTokens estimados% de 200K
System prompt base de Claude Code15,0007.5%
CLAUDE.md del usuario (promedio)3,0001.5%
Memory files cargados2,0001.0%
Skills en memoria (5 skills activos)8,0004.0%
Schemas de 5 MCPs típicos12,0006.0%
TodoWrite state1,0000.5%
Overhead fijo41,00020.5%
Historial de conversación activo80,00040.0%
Disponible para nueva tarea79,00039.5%

Esto significa que en una sesión activa con historial, solo tienes ~79,000 tokens disponibles para el trabajo real. Si añades 10 MCPs en lugar de 5, ese número baja a ~67,000.

La trampa del final de la ventana

Claude Code degrada su rendimiento de forma no lineal al acercarse al límite de la ventana. La guía de ECC recomienda explícitamente:

“Avoid last 20% of context window for large-scale refactoring”

El último 20% de 200K = 40,000 tokens. Cuando el historial más el overhead supera los 160,000 tokens, el modelo empieza a “comprimir” su atención sobre el contexto antiguo. Verás síntomas como:

La solución es la compaction estratégica, cubierta en profundidad en la sección 8 de este capítulo.

Extended Thinking y su impacto en la ventana

Cuando Extended Thinking está activo (por defecto en ECC), Claude puede usar hasta 31,999 tokens adicionales de razonamiento interno. Estos tokens no cuentan en la ventana de contexto visible, pero sí se cobran como output tokens.

Esto tiene implicaciones importantes:

  1. El costo real de output puede ser 2-3x más alto de lo que parece
  2. Para tareas simples, extended thinking es desperdicio puro
  3. Para tareas complejas, los tokens de thinking pueden reducir los tokens de output final (razona más, escribe menos código incorrecto)

3. Cómo los MCPs Consumen Contexto

Los MCP servers son una de las fuentes más silenciosas de consumo de tokens. Cada MCP server que tienes activo inyecta automáticamente el schema de todas sus herramientas en cada conversación.

El costo de los MCPs más populares

MCP ServerHerramientas expuestasTokens de schemaCosto mensual extra (Sonnet)
GitHub MCP oficial28 herramientas~4,500 tokens~$16
Supabase MCP oficial23 herramientas~3,800 tokens~$13
Vercel MCP oficial18 herramientas~2,900 tokens~$10
Filesystem MCP12 herramientas~1,800 tokens~$6
Postgres MCP15 herramientas~2,200 tokens~$8
Playwright MCP20 herramientas~3,100 tokens~$11
Slack MCP16 herramientas~2,600 tokens~$9
Linear MCP22 herramientas~3,400 tokens~$12
AWS MCP45 herramientas~7,200 tokens~$25
Docker MCP19 herramientas~3,000 tokens~$10
Total 10 MCPs218 herramientas~34,500 tokens~$120

El cálculo del costo mensual asume 50 conversaciones por día × 22 días laborales × 34,500 tokens por conversación × $3/MTok (Sonnet input).

El efecto de 10 MCPs en la ventana útil

graph LR
    A["Ventana total: 200K tokens"] --> B["Sin MCPs\nDisponible: 79K tokens"]
    A --> C["Con 5 MCPs\nDisponible: 67K tokens"]
    A --> D["Con 10 MCPs\nDisponible: 45K tokens"]
    D --> E["Sesión larga activa\nDisponible: ~25K tokens"]
    style D fill:#ff9900
    style E fill:#ff4444

Con 10 MCPs activos y una sesión con historial, puedes quedarte con solo 25,000 tokens para trabajo real. Eso equivale a aproximadamente 500 líneas de código o 20,000 palabras, insuficiente para tareas de cualquier complejidad.

Los MCPs que vale la pena reemplazar

La guía de ECC propone una filosofía clara:

“MCPs that wrap CLIs (GitHub, Supabase, Vercel) can be replaced with skills+commands for better context management. CLI approach strips tools that eat context.”

Ejemplo: GitHub MCP vs comando /gh-pr

El GitHub MCP inyecta 28 herramientas constantemente. El equivalente como skill:

# En lugar de GitHub MCP cargado siempre:
# Solo cuando invocas /gh-pr, se ejecuta:
gh pr create --title "$TITLE" --body "$BODY"

El skill solo consume tokens cuando se invoca, no en cada conversación. Además, la CLI de gh produce output más conciso que las respuestas JSON del MCP.

Tabla de reemplazos recomendados:

MCP a reemplazarAlternativa CLI/skillAhorro estimado
GitHub MCPgh CLI + skills~4,500 tok/conv
Supabase MCPsupabase CLI + skills~3,800 tok/conv
Vercel MCPvercel CLI + skills~2,900 tok/conv
Linear MCPlinear CLI + skills~3,400 tok/conv
AWS MCPaws CLI + skills~7,200 tok/conv

Los MCPs que no tienen buen equivalente CLI (como Playwright, bases de datos locales complejas) sí justifican mantenerse como MCP.

4. Los Tres Modelos: Análisis de Costo

Claude ofrece tres modelos principales con características y costos muy diferentes. La clave de la optimización de tokens es usar cada modelo solo donde genuinamente agrega valor.

Comparativa de precios y capacidades

ModeloInput ($/MTok)Output ($/MTok)VelocidadMejor para
Claude Haiku 3.5$0.80$4.00Muy rápidoTareas mecánicas
Claude Haiku 4.5$0.25$1.25RápidoExploración, workers
Claude Sonnet 4.6$3.00$15.00ModeradoDesarrollo principal
Claude Opus 4.5$15.00$75.00LentoArquitectura, seguridad

Nota: Los precios son aproximados y pueden variar. Verifica en console.anthropic.com los precios actuales.

Cuándo usar Haiku

Haiku tiene el 90% de la capacidad de Sonnet para tareas específicas, a 12x menos costo por token de input. Las tareas donde Haiku no solo es suficiente sino óptimo:

Exploración y búsqueda:

Ediciones simples:

Tareas de agente worker:

Lo que Haiku NO puede hacer bien:

Cuándo usar Sonnet

Sonnet es el modelo de uso general para desarrollo. La guía de ECC dice explícitamente:

“Default to Sonnet for 90% of coding tasks”

Sonnet sobresale en:

La razón por la que Sonnet domina es la relación costo-capacidad. Para tareas de codificación típicas, Opus puede dar respuestas 10-15% mejores en calidad pero a 5x el precio. El breakeven solo ocurre en tareas que realmente requieren el razonamiento profundo de Opus.

Cuándo escalar a Opus

La guía recomienda escalar a Opus cuando:

  1. El primer intento falló — Si Sonnet intentó algo y no llegó a la solución, Opus justifica el costo
  2. La tarea toca 5+ archivos — La coherencia cross-file es donde Opus brilla
  3. Decisiones arquitectónicas — El costo de una mala arquitectura supera el costo de tokens de Opus
  4. Código de seguridad crítico — “Can’t afford to miss vulnerabilities”
  5. Debugging de bugs que resisten 2+ intentos — Cuando el bug requiere mantener el sistema completo en mente

Estimación de cuándo vale Opus:

Costo de usar Sonnet y fallar = Costo(Sonnet intento 1) + Costo(Sonnet intento 2) + ...
Costo de usar Opus directamente = Costo(Opus intento 1)

Si P(éxito Sonnet) < 60%, usar Opus es más económico desde el primer intento.

Para bugs muy complejos, la probabilidad de que Sonnet resuelva en el primer intento puede ser solo 30-40%, lo que hace Opus la elección más económica.

5. Matemática de Tokens por Tipo de Tarea

Esta sección proporciona cálculos concretos para que puedas tomar decisiones informadas sobre qué modelo usar para cada tipo de trabajo.

Tarea: Implementar un endpoint REST

Contexto típico:

Total input estimado: ~22,000 tokens Output típico (nuevo archivo 100 líneas): ~1,500 tokens

Costo con Sonnet:

Input:  22,000 × $3/MTok    = $0.066
Output:  1,500 × $15/MTok   = $0.023
Total:                       $0.089 (~9 centavos)

Costo con Opus:

Input:  22,000 × $15/MTok   = $0.330
Output:  1,500 × $75/MTok   = $0.113
Total:                       $0.443 (~44 centavos)

Veredicto: Sonnet es 5x más barato para esta tarea y tiene la misma calidad. Opus no agrega valor en tareas de implementación estándar con especificación clara.

Tarea: Code review de 5 archivos

Contexto típico:

Total input estimado: ~28,000 tokens Output típico (review detallada): ~3,000 tokens

Costo con Sonnet:

Input:  28,000 × $3/MTok    = $0.084
Output:  3,000 × $15/MTok   = $0.045
Total:                       $0.129 (~13 centavos)

Costo con Opus:

Input:  28,000 × $15/MTok   = $0.420
Output:  3,000 × $75/MTok   = $0.225
Total:                       $0.645 (~65 centavos)

Veredicto: Para code review general, Sonnet es suficiente. Solo usa Opus si el PR contiene código de seguridad crítico (autenticación, autorización, manejo de datos sensibles).

Tarea: Diseño de arquitectura de microservices

Contexto típico:

Total input estimado: ~29,000 tokens Output típico (documento de arquitectura): ~5,000 tokens

Costo con Sonnet:

Input:  29,000 × $3/MTok    = $0.087
Output:  5,000 × $15/MTok   = $0.075
Total:                       $0.162 (~16 centavos)

Costo con Opus:

Input:  29,000 × $15/MTok   = $0.435
Output:  5,000 × $75/MTok   = $0.375
Total:                       $0.810 (~81 centavos)

Veredicto: Aquí Opus sí puede justificarse. Una arquitectura de microservices deficiente puede costar semanas de refactoring. Si la decisión arquitectónica es crítica, los $0.65 de diferencia son insignificantes comparados con el costo de una mala decisión.

Tarea: Exploración inicial del codebase

Contexto típico:

Total estimado (15 búsquedas):

Input:  20,000 (overhead) + 15 × 500 = 27,500 tokens
Output: 15 × 200 = 3,000 tokens

Costo con Haiku:

Input:  27,500 × $0.25/MTok  = $0.007
Output:  3,000 × $1.25/MTok  = $0.004
Total:                        $0.011 (~1 centavo)

Costo con Sonnet:

Input:  27,500 × $3/MTok     = $0.083
Output:  3,000 × $15/MTok    = $0.045
Total:                        $0.128 (~13 centavos)

Veredicto: Para exploración, Haiku es 12x más barato y perfectamente capaz de encontrar archivos, leer estructura del proyecto y resumir lo que existe.

Tabla resumen: modelo recomendado por tarea

Tipo de tareaModeloTokens input típicosCosto aprox
Exploración/búsquedaHaiku5K-30K$0.001-$0.008
Edición single-file simpleHaiku5K-15K$0.001-$0.004
Implementar feature (1-2 archivos)Sonnet20K-50K$0.06-$0.15
Implementar feature (3-5 archivos)Sonnet40K-100K$0.12-$0.30
Code review generalSonnet20K-60K$0.06-$0.18
Code review de seguridadOpus20K-60K$0.30-$0.90
Debugging simpleSonnet15K-40K$0.05-$0.12
Debugging complejo (3er+ intento)Opus40K-100K$0.60-$1.50
Diseño de arquitecturaOpus25K-60K$0.38-$0.90
DocumentaciónHaiku10K-40K$0.003-$0.01
Tests unitarios básicosHaiku10K-30K$0.003-$0.008
Tests de integraciónSonnet30K-70K$0.09-$0.21

6. Configuración Óptima de settings.json

El archivo settings.json de Claude Code es el lugar donde se define el comportamiento por defecto. Cada parámetro tiene impacto directo en los costos.

Estructura recomendada para ECC

{
  "model": "claude-sonnet-4-6",
  "thinking": {
    "type": "enabled",
    "budget_tokens": 10000
  },
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "AUTOCOMPACT_PCT_OVERRIDE": "50",
    "MAX_THINKING_TOKENS": "10000"
  },
  "permissions": {
    "allow": [
      "Bash(*)",
      "Read(*)",
      "Write(*)",
      "Edit(*)"
    ]
  }
}

Parámetro: model

Sin optimización: claude-opus-4-5 Optimizado: claude-sonnet-4-6 Impacto: 80% reducción de costo (5x más barato en input, 5x en output)

Este es el cambio más impactante. La mayoría de desarrolladores que usan Opus por defecto podrían usar Sonnet para el 90% de sus tareas sin diferencia perceptible en calidad.

{
  "model": "claude-sonnet-4-6"
}

Parámetro: MAX_THINKING_TOKENS

El budget de thinking controla cuántos tokens puede usar Claude para razonamiento interno antes de producir output.

BudgetUsoAhorro vs defaultCuándo usar
0Sin thinking~70% del output totalTareas mecánicas
5,000Thinking mínimo~50% del output totalTareas simples con algo de razonamiento
10,000Thinking moderado~30% del output totalDesarrollo general (recomendado)
20,000Thinking profundoSin ahorroArquitectura compleja
31,999Thinking máximo (default)-50% (más caro)Solo para problemas muy difíciles

Configuración recomendada para desarrollo diario:

export MAX_THINKING_TOKENS=10000

O en settings.json:

{
  "thinking": {
    "type": "enabled",
    "budget_tokens": 10000
  }
}

Para deshabilitar thinking en comandos específicos (como exploración):

claude --thinking-budget 0 "lista los archivos en src/"

Parámetro: AUTOCOMPACT_PCT_OVERRIDE

Este parámetro controla en qué porcentaje de uso de la ventana de contexto se activa la compaction automática.

ValorComportamientoProsContras
80 (default)Compacta cuando queda 20%Menos interrupcionesCompacta tarde, pierde contexto valioso
50 (recomendado)Compacta al 50% de usoBalance óptimoInterrupciones moderadas
30Compacta muy prontoMáxima preservaciónCompacta demasiado seguido
export AUTOCOMPACT_PCT_OVERRIDE=50

La lógica es que compactar al 50% deja tiempo para procesar la tarea actual y luego limpiar antes de continuar, en lugar de esperar a que el contexto esté casi lleno.

Parámetro: CLAUDE_CODE_SUBAGENT_MODEL

Uno de los parámetros más impactantes para quienes usan arquitecturas multi-agente:

export CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5

Cuando Claude Code lanza subagentes (por ejemplo, al usar el tool Task), por defecto usa el mismo modelo que el agente principal. Configurar este parámetro a Haiku hace que todos los subagentes worker usen el modelo más económico.

Impacto estimado en workflows de agentes:

Sin optimización: Orquestador Sonnet + 5 subagentes Sonnet
Costo típico: 6 × costo_promedio_tarea

Con optimización: Orquestador Sonnet + 5 subagentes Haiku
Costo típico: 1 × costo_sonnet + 5 × (costo_sonnet / 12)
Ahorro: ~50% del costo total de subagentes

Parámetro: permissions

Pedir confirmación para cada operación no solo es molesto, también consume tokens en el ida y vuelta. Configurar permisos apropiados reduce fricciones:

{
  "permissions": {
    "allow": [
      "Bash(git:*)",
      "Bash(npm:*)",
      "Bash(bun:*)",
      "Read(*)",
      "Write(src/**)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Write(.env)"
    ]
  }
}

El principio: permitir operaciones comunes del proyecto, negar solo las genuinamente peligrosas.

7. Extended Thinking: El Costo Oculto

Extended Thinking es una de las características más poderosas de Claude, pero también una de las menos entendidas en términos de costo.

Qué es Extended Thinking

Cuando Extended Thinking está activo, Claude realiza una “cadena de razonamiento” interna antes de producir su respuesta final. Esta cadena no es visible directamente en la conversación, pero:

  1. Se cobra como tokens de output (al precio de $15/MTok para Sonnet)
  2. Puede representar 2-5x el tamaño del output final
  3. Se activa automáticamente en preguntas complejas cuando está habilitado

El multiplicador de costo del thinking

Ejemplo concreto: Implementar un algoritmo de ordenamiento

Sin thinking:

Output visible: 200 líneas de código ≈ 800 tokens
Costo output (Sonnet): 800 × $15/MTok = $0.012

Con thinking (budget 31,999 tokens):

Thinking interno: ~8,000 tokens (Claude "piensa" el algoritmo)
Output visible: 200 líneas de código ≈ 800 tokens
Total output tokens: 8,800
Costo output (Sonnet): 8,800 × $15/MTok = $0.132

El thinking añadió 10x más costo al output para esta tarea específica.

Cuándo el thinking SÍ vale su costo

El thinking no es siempre desperdicio. Para ciertos problemas, reduce el número de intentos necesarios:

graph TD
    A[Tarea difícil] --> B{¿Thinking?}
    B -- No --> C[Primera respuesta en frío]
    C --> D{¿Correcta?}
    D -- No, 60% --> E[Segundo intento: costo extra]
    D -- Sí, 40% --> F[Listo]
    B -- Sí --> G[Respuesta con razonamiento]
    G --> H{¿Correcta?}
    H -- No, 20% --> I[Segundo intento: costo extra]
    H -- Sí, 80% --> J[Listo]

Para una tarea con P(éxito sin thinking) = 40%:

Costo esperado sin thinking = 1 intento + 0.6 × (otro intento)
                            = 1.6 × costo_base

Costo esperado con thinking = 1 intento × (1 + factor_thinking)
                             = 1.5 × costo_base  (si thinking agrega 50%)

En este caso, thinking reduce el costo esperado al reducir reintentos.

Guía de budget de thinking por tipo de tarea

Tipo de tareaBudget recomendadoJustificación
Búsqueda de archivos0Mecánico, sin beneficio
Edición simple0Sin ambigüedad
Implementación estándar5,000-10,000Algo de planificación
Debugging complejo10,000-20,000Necesita razonamiento
Arquitectura20,000-31,999Máximo beneficio
Análisis de seguridad20,000-31,999No pueden fallar
Refactoring masivo15,000-25,000Coherencia multi-archivo

Configurar thinking por contexto

En ECC, puedes usar aliases para diferentes perfiles de thinking:

# En ~/.zshrc o ~/.bashrc

# Modo económico: sin thinking
alias claude-eco='MAX_THINKING_TOKENS=0 claude'

# Modo normal: thinking moderado
alias claude-dev='MAX_THINKING_TOKENS=10000 claude'

# Modo profundo: thinking completo
alias claude-deep='MAX_THINKING_TOKENS=31999 claude'

O usando el flag directo:

# Para tarea específica sin thinking
claude --thinking-budget 0 "rename variable X to Y in auth.ts"

# Para tarea que requiere razonamiento profundo
claude --thinking-budget 25000 "diseña la arquitectura para el módulo de pagos"

8. Strategic Compaction — El Método Completo

La compaction es el proceso de comprimir el historial de conversación cuando se acerca al límite de la ventana de contexto. La diferencia entre compaction automática (auto-compact) y compaction estratégica puede representar un 30-40% de diferencia en la calidad de los resultados.

Por qué la compaction automática es subóptima

Auto-compact se activa en un punto arbitrario — cuando el uso de la ventana supera el threshold. Esto puede interrumpir:

Cuando auto-compact interrumpe en un mal momento, el resumen que produce es más genérico y pierde:

La guía de fases para compaction

La compaction estratégica se aplica en transiciones naturales entre fases de trabajo:

Transición de fase¿Compactar?Justificación
Exploración → PlanificaciónSíEl contexto de exploración es voluminoso; el plan es el output destilado
Planificación → ImplementaciónSíEl plan está en archivos; libera contexto para el código
Implementación → TestingTal vezMantener si los tests referencian código reciente
Testing → Nueva featureSíLos detalles de implementación anterior no son relevantes
Debugging → Siguiente featureSíLos traces de debug contaminan el contexto
Mitad de implementaciónNoPerder nombres de variables y rutas de archivos es costoso
Después de enfoque fallidoSíLimpiar el razonamiento de dead-end

Cómo compactar con mensaje personalizado

El comando /compact acepta un mensaje que guía qué preservar:

# Compaction básica (Claude decide qué resumir)
/compact

# Compaction con guía de preservación
/compact Mantén: los 3 archivos modificados en auth/,
         el bug identificado en línea 47 de JwtService,
         la solución acordada de usar refresh tokens separados.
         Descarta: el historial de exploración inicial.

# Compaction antes de cambiar de tarea
/compact El módulo de autenticación está completo.
         Próxima tarea: implementar el módulo de pagos con Stripe.
         Preserva: la arquitectura general del proyecto,
                  las convenciones de naming usadas.

Qué se preserva y qué se pierde en una compaction

graph LR
    subgraph "Persiste siempre"
        A["CLAUDE.md y reglas"]
        B["TodoWrite task list"]
        C["Memory files"]
        D["Git state"]
        E["Archivos en disco"]
    end

    subgraph "Se pierde en compaction"
        F["Razonamiento intermedio"]
        G["Contenido de archivos leídos"]
        H["Contexto multi-paso"]
        I["Historial de tool calls"]
        J["Variables y estructuras en memoria"]
    end

La implicación práctica: escribe en archivos todo lo que no quieres perder. Si identificas la causa raíz de un bug complejo, escríbela en un comentario en el código o en un archivo temporal antes de compactar.

El ritual de compaction productiva

  1. Antes de compactar: actualiza TodoWrite con el estado actual de tareas
  2. Escribe en memoria: si tienes hallazgos importantes, guárdalos con Memory
  3. Ejecuta /compact con un mensaje que describe el próximo paso
  4. Verifica que el contexto post-compaction tiene lo esencial
/compact El módulo X está completo. Iniciando módulo Y.
# Después de compact:
"¿Qué entiendes del estado actual del proyecto?"
# Si la respuesta muestra el estado correcto, sigue. Si no, aclara.

Frecuencia óptima de compaction

Para una sesión de 8 horas de trabajo:

Tipo de trabajoCompactions recomendadasMomento
Feature development2-3Después de exploración, después de implementación
Bug investigation1-2Cuando cambia de síntoma a causa, después de fix
Refactoring masivo3-4Por módulo o por capa
Architecture design1Después de análisis, antes de propuesta

9. Gestión Inteligente de MCPs

La gestión de MCPs es una de las áreas con mayor impacto en tokens que recibe menos atención.

El límite de 10 MCPs

La recomendación de ECC de no superar 10 MCPs activos simultáneamente no es arbitraria. Con más de 10 MCPs:

  1. Los schemas de herramientas consumen ~40,000+ tokens de la ventana
  2. Claude puede confundirse sobre qué herramienta usar (tool selection degradation)
  3. Las respuestas sobre qué herramienta invocar se vuelven menos precisas
  4. El tiempo de respuesta inicial aumenta (Claude procesa más opciones)

Arquitectura de MCPs por capas

En lugar de tener todos los MCPs activos siempre, ECC recomienda una arquitectura de activación contextual:

graph TD
    subgraph "Siempre activos core"
        A["Filesystem MCP"]
        B["Git MCP básico"]
    end

    subgraph "Activos por proyecto"
        C["Database MCP si es backend"]
        D["Browser MCP si es frontend"]
    end

    subgraph "Activados por tarea"
        E["GitHub MCP → solo en /gh-pr"]
        F["Deployment MCP → solo en /deploy"]
        G["Monitoring MCP → solo en /debug-prod"]
    end

Cómo calcular si un MCP justifica su costo

Para decidir si mantener un MCP o reemplazarlo con CLI+skill, usa esta fórmula:

Costo mensual MCP = conversaciones_día × días_laborales × tokens_schema × precio_model

Ejemplo: GitHub MCP con Sonnet, 30 conversaciones/día:
Costo = 30 × 22 × 4,500 × $3/MTok
      = 30 × 22 × 0.0135
      = $8.91/mes en tokens de overhead

Si en esas 30 conversaciones solo usas gh en 5...
Costo de tener GitHub MCP para 5 usos reales: $8.91
Costo de skill /gh-pr (solo cuando se invoca): ~$0.10 × 5 = $0.50

Ahorro mensual: ~$8.41 por reemplazar un MCP por skill

MCPs que SÍ justifican mantenerse

MCPJustificación para mantener
Playwright/BrowserNo tiene buen equivalente CLI para inspección visual
SQLite/PostgreSQL localQueries SQL dinámicos son difíciles de replicar en CLI
Custom company MCPsIntegran sistemas propietarios sin CLI pública
Filesystem extendidoOperaciones atómicas que bash no maneja bien

Configuración de MCPs por perfil

Perfil: Backend API developer

{
  "mcpServers": {
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/src"] },
    "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres", "${DB_URL}"] }
  }
}

Skills para reemplazar: GitHub MCP → /gh-pr skill, Vercel MCP → /deploy skill

Perfil: Frontend developer

{
  "mcpServers": {
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/src"] },
    "playwright": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-playwright"] }
  }
}

Perfil: Full-stack developer Máximo 3 MCPs core + activar MCPs específicos por sesión con --mcp-config.

10. Subagent Architecture para Economía de Tokens

La arquitectura de subagentes es la estrategia más avanzada de optimización, pero también una de las más poderosas.

El principio de routing por complejidad

graph TD
    A[Tarea entrante] --> B{Clasificar complejidad}
    B -- Simple/Mecánica --> C[Haiku Worker]
    B -- Moderada/Estándar --> D[Sonnet Orchestrator]
    B -- Compleja/Crítica --> E[Opus Specialist]
    C --> F[Resultado]
    D --> G{¿Necesita workers?}
    G -- Sí --> C
    G -- No --> F
    E --> H{¿Necesita workers?}
    H -- Sí --> C
    H -- No --> F

Definir el threshold de complejidad

ECC usa tres niveles de complejidad para el routing automático:

Nivel 1 (Haiku):

Nivel 2 (Sonnet):

Nivel 3 (Opus):

Implementar routing en un workflow de agentes

# Pseudocódigo conceptual de routing
def route_task(task_description: str) -> str:

    # Indicadores de Haiku
    haiku_patterns = [
        "busca", "lista", "lee", "encuentra",
        "renombra", "formato", "mueve", "copia"
    ]

    # Indicadores de Opus
    opus_patterns = [
        "arquitectura", "seguridad", "diseña sistema",
        "evalúa trade-offs", "crítico", "producción"
    ]

    task_lower = task_description.lower()

    if any(p in task_lower for p in opus_patterns):
        return "claude-opus-4-5"
    elif any(p in task_lower for p in haiku_patterns):
        return "claude-haiku-4-5"
    else:
        return "claude-sonnet-4-6"

Ejemplo real: workflow de code review con agentes

Sin optimización (todo en Sonnet):

1. Leer archivos del PR (Sonnet)       → 15K tokens input
2. Analizar cambios (Sonnet)           → 30K tokens input
3. Generar comentarios (Sonnet)        → 40K tokens input
4. Formatear reporte (Sonnet)          → 10K tokens input
Total: 95K tokens × $3/MTok = $0.285

Con arquitectura de agentes optimizada:

1. Leer archivos del PR (Haiku)        → 15K tokens × $0.25/MTok = $0.004
2. Analizar cambios (Sonnet)           → 30K tokens × $3/MTok = $0.090
3. Detectar vulnerabilidades (Opus)    → 20K tokens × $15/MTok = $0.300
4. Formatear reporte (Haiku)           → 10K tokens × $0.25/MTok = $0.003
Total: $0.397 (más caro por incluir Opus, pero mucho mejor calidad en seguridad)

Sin Opus en paso 3 (si no hay código de seguridad):
Total: $0.097 (66% más barato con igual calidad)

11. El Comando /model-route

ECC v1.8 introduce /model-route, un comando que implementa el routing automático de modelos basado en el análisis de la tarea.

Cómo funciona /model-route

El comando analiza la tarea usando un agente Haiku (económico) para clasificarla, y luego lanza la tarea real en el modelo apropiado:

sequenceDiagram
    participant U as Usuario
    participant MR as /model-route
    participant H as Haiku clasificador
    participant M as Modelo elegido

    U->>MR: /model-route "implementa el módulo de pagos"
    MR->>H: Clasifica esta tarea (100 tokens)
    H->>MR: Nivel 2, Sonnet
    MR->>M: Ejecuta en Sonnet
    M->>U: Resultado

El costo del clasificador Haiku es trivial (~100 tokens = $0.000025) comparado con el ahorro de no usar Opus innecesariamente.

Thresholds de complejidad configurables

En .claude/settings.json:

{
  "modelRouting": {
    "enabled": true,
    "thresholds": {
      "haiku": {
        "maxFiles": 1,
        "patterns": ["search", "find", "list", "rename", "format"]
      },
      "opus": {
        "minFiles": 5,
        "patterns": ["architecture", "security", "design system"]
      }
    },
    "default": "claude-sonnet-4-6"
  }
}

Ejemplos de decisiones de routing

InputClasificaciónModelo asignadoRazón
”busca todos los useEffect en el proyecto”Nivel 1HaikuBúsqueda simple
”actualiza el copyright en todos los archivos”Nivel 1HaikuEdición mecánica
”implementa el hook usePayment con manejo de errores”Nivel 2SonnetFeature moderada
”refactoriza el módulo de auth para soportar OAuth”Nivel 2-3SonnetMúltiples archivos
”diseña la estrategia de rate limiting para producción”Nivel 3OpusDecisión arquitectónica
”audita el módulo de pagos por vulnerabilidades”Nivel 3OpusSeguridad crítica

Override manual del routing

Puedes forzar un modelo específico cuando el routing automático no es óptimo:

# Forzar Haiku aunque el routing sugiera Sonnet
claude --model haiku "describe la estructura del proyecto"

# Forzar Opus para tarea que parece simple pero es crítica
claude --model opus "revisa el hash de contraseñas en auth.service.ts"

12. Agent Teams: El Costo Real

Las arquitecturas multi-agente son poderosas pero tienen un costo que muchos desarrolladores subestiman.

El multiplicador de contexto en agent teams

Cada agente en un team abre su propia ventana de contexto independiente. Esto significa:

Costo agent team = Σ(costo de cada agente)
                 = N_agentes × costo_promedio_por_agente

Para un team típico de 5 agentes con Sonnet:

Overhead de contexto por agente: ~20,000 tokens
Tarea compartida: 10,000 tokens por agente
Output por agente: 2,000 tokens

Costo por agente = (20,000 + 10,000) × $3/MTok + 2,000 × $15/MTok
                 = $0.090 + $0.030 = $0.120

Costo team de 5 agentes = 5 × $0.120 = $0.600
Costo tarea equivalente en agente único = $0.150

Factor multiplicador del team: 4x el costo

Cuándo los agent teams justifican su costo

A pesar del multiplicador de costo, los agent teams justifican su precio cuando:

1. Paralelización genuina Si 5 tareas independientes pueden ejecutarse en paralelo en 2 minutos cada una vs. 10 minutos secuenciales, el tiempo ahorrado puede valer el costo adicional en contextos comerciales.

2. Especialización por dominio Cada agente carga solo el contexto relevante a su dominio. El agente de frontend carga las reglas de React, el de backend carga los patrones de API. Esto puede ser más eficiente que un agente único con todo el contexto.

3. Redundancia en decisiones críticas Para decisiones de alto impacto, tener 2-3 agentes independientes analizar el mismo problema y consensuar reduce el riesgo de errores costosos.

graph LR
    A[Decisión crítica de arquitectura] --> B[Agente 1: análisis]
    A --> C[Agente 2: análisis]
    A --> D[Agente 3: análisis]
    B --> E[Consenso]
    C --> E
    D --> E
    E --> F[Decisión final validada]

Configurar el modelo de subagentes en teams

# Todos los subagentes usan Haiku (máximo ahorro)
export CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5

# En workflows donde los workers necesitan más capacidad
export CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6

La regla de justificación de teams

Antes de usar un agent team, evalúa:

  1. ¿Las tareas son genuinamente paralelas? (no dependientes entre sí)
  2. ¿El ahorro de tiempo justifica el costo extra?
  3. ¿Podría un agente único con subagentes baratos lograr lo mismo?

Si la respuesta a 1 es No, usa agente único. Si la respuesta a 3 es Sí, usa orquestador + workers en lugar de team.

13. mgrep: 50% Reducción en Búsquedas

mgrep es una herramienta específica de ECC que reemplaza grep con una implementación optimizada para reducir los tokens producidos en búsquedas de código.

El problema con grep estándar

Cuando Claude Code usa grep para buscar en el codebase, el output típico incluye:

$ grep -r "useState" src/
src/components/Auth.tsx:3:import React, { useState } from 'react';
src/components/Auth.tsx:15:  const [user, setUser] = useState(null);
src/components/Auth.tsx:16:  const [loading, setLoading] = useState(false);
src/components/Dashboard.tsx:2:import React, { useState, useEffect } from 'react';
src/components/Dashboard.tsx:8:  const [data, setData] = useState([]);
# ... 200 líneas más

El output de grep incluye mucho ruido: prefijos de ruta repetidos, imports, líneas con contexto innecesario. Para una búsqueda típica con 50 matches, esto puede generar 3,000-5,000 tokens de output.

Cómo mgrep reduce los tokens

mgrep aplica filtros inteligentes:

  1. Deduplica paths frecuentes
  2. Agrupa matches por archivo
  3. Elimina líneas de import si el patrón también aparece en uso
  4. Limita el contexto a lo mínimo necesario
  5. Comprime el output con formato tabular cuando hay muchos matches

El benchmark de ECC sobre 50 tareas muestra:

Instalación y configuración en ECC

# Instalación (parte del toolkit ECC)
npm install -g @ecc/mgrep

# Configuración en .claude/settings.json para que Claude lo use por defecto
{
  "tools": {
    "grep": {
      "command": "mgrep",
      "flags": ["--smart-context", "--deduplicate"]
    }
  }
}

Benchmark de las 50 tareas

El estudio comparativo del repo de ECC:

Tipo de búsquedaTokens grepTokens mgrepReducción
Buscar uso de función2,40090062%
Buscar imports de módulo3,1001,10065%
Buscar patrones de error4,5001,80060%
Buscar todos los tests de módulo5,2002,10060%
Buscar TODO/FIXME1,80080055%
Promedio3,4001,34061%

Para un workflow con 20 búsquedas por día:

Ahorro diario: 20 × (3,400 - 1,340) = 41,200 tokens
Ahorro mensual: 41,200 × 22 días = 906,400 tokens
Ahorro en costo (Sonnet input): 906,400 × $3/MTok = $2.72/mes

Parece pequeño, pero se acumula. Y más importante, la reducción de ruido también mejora la calidad de las respuestas de Claude.

Opciones avanzadas de mgrep

# Búsqueda con contexto mínimo (1 línea arriba/abajo)
mgrep --context 1 "handlePayment" src/

# Búsqueda solo en archivos recientes (últimas 2 semanas)
mgrep --recent 14d "TODO" src/

# Búsqueda con output JSON para procesamiento programático
mgrep --json "useCallback" src/components/

# Excluir archivos de test (foco en código de producción)
mgrep --exclude-tests "fetchUser" src/

14. Codebase Modular y Tokens

La estructura del código fuente tiene un impacto directo en cuántos tokens consume Claude Code para entender y modificar tu proyecto.

El problema de los archivos gigantes

Cuando Claude necesita modificar UserService.ts de 2,000 líneas, debe:

  1. Leer el archivo completo (2,000 líneas ≈ 8,000 tokens)
  2. Entender qué parte es relevante
  3. Generar el cambio en contexto del archivo completo

Con archivos de 200-400 líneas:

  1. Claude identifica el archivo correcto (50 tokens de exploración)
  2. Lee solo ese archivo (200 líneas ≈ 800 tokens)
  3. El cambio es quirúrgico y preciso

Diferencia: 8,000 vs 850 tokens para la misma tarea = 9x menos tokens

Impacto en el first-attempt success rate

Los archivos más pequeños no solo reducen tokens, también mejoran la tasa de éxito en el primer intento:

graph LR
    A["Archivo 2000 líneas"] --> B["Claude lee todo"]
    B --> C["Alta carga cognitiva"]
    C --> D["First attempt success: 60%"]

    E["Archivo 250 líneas"] --> F["Claude lee parte relevante"]
    F --> G["Baja carga cognitiva"]
    G --> H["First attempt success: 85%"]

El 25% de mejora en first-attempt success significa 25% menos reintentos, lo que se traduce directamente en menos tokens consumidos.

Guía de tamaño óptimo de archivos

Tipo de archivoLíneas recomendadasPor qué
Componentes React100-200Una responsabilidad, fácil de leer
Services / Use cases150-300Una entidad de negocio
Controllers / Handlers100-200Un recurso de API
Repositories150-300Una entidad de datos
Utility files50-150Funciones puras agrupadas por tipo
Configuración50-100Separar por entorno/módulo

La regla de ECC es: “Having main files in hundreds of lines instead of thousands helps both token optimization and getting tasks right on first try.”

Refactoring para modularidad: el plan

Si tienes archivos grandes, el proceso de modularización también produce beneficios de tokens:

# Antes: un archivo monolítico
src/services/UserService.ts  # 1,800 líneas

# Después: módulos especializados
src/services/user/
  UserAuthService.ts    # 180 líneas - autenticación
  UserProfileService.ts # 220 líneas - gestión de perfil
  UserNotifService.ts   # 150 líneas - notificaciones
  UserQueryService.ts   # 200 líneas - queries complejas
  index.ts              # 30 líneas  - re-exports

Tokens para “actualizar la lógica de notificaciones”:

15. La Estrategia de Contextos Dinámicos

Los “contextos dinámicos” son configuraciones de Claude Code que se activan selectivamente dependiendo del tipo de tarea, en lugar de cargar todo siempre.

El problema del contexto estático

Una instalación de Claude Code típica tiene:

Para una tarea simple de búsqueda, cargas innecesariamente reglas de seguridad, convenciones de código, MCPs de deployment, etc.

CLI flags para contexto dinámico

# Modo minimal: solo instrucciones esenciales
claude --system-prompt "Eres un asistente de búsqueda de código. Solo busca y reporta." \
       "encuentra todos los archivos con TODO en el directorio src"

# Modo desarrollo: contexto estándar del proyecto
claude --system-prompt "$(cat ~/.claude/profiles/dev-profile.md)" \
       "implementa el endpoint de logout"

# Modo review: enfocado en calidad y seguridad
claude --system-prompt "$(cat ~/.claude/profiles/review-profile.md)" \
       "revisa el PR #47"

# Modo arquitectura: carga contexto de decisiones y ADRs
claude --system-prompt "$(cat ~/.claude/profiles/arch-profile.md)" \
       "diseña el módulo de caché"

Crear perfiles de contexto

# ~/.claude/profiles/minimal-profile.md
Eres un asistente de búsqueda de código.
Responde de forma concisa y directa.
No hagas cambios, solo busca y reporta.

# ~/.claude/profiles/dev-profile.md
[Copia las reglas relevantes del CLAUDE.md para desarrollo diario]
[Sin reglas de deployment, sin reglas de arquitectura macro]

# ~/.claude/profiles/review-profile.md
Enfócate en:
- Seguridad: SQL injection, XSS, auth bypasses
- Performance: N+1 queries, memory leaks
- Mantenibilidad: complejidad ciclomática, duplicación
- Tests: cobertura de casos edge

# ~/.claude/profiles/arch-profile.md
[ADRs relevantes]
[Principios arquitectónicos del proyecto]
[Contexto del sistema completo]

Aliases para contextos frecuentes

# En ~/.zshrc o ~/.bashrc

# Búsqueda económica con Haiku y contexto minimal
alias cg='ANTHROPIC_MODEL=claude-haiku-4-5 claude --system-prompt "Busca en el código. Sé conciso." '

# Desarrollo estándar
alias cd='claude --profile dev'

# Review de seguridad
alias cr='claude --model opus --profile review'

# Arquitectura
alias ca='claude --model opus --profile arch'

16. Lazy Loading de Skills

Una de las características de eficiencia más importantes de ECC es que los skills se cargan bajo demanda, no todos al inicio.

Cómo funciona el lazy loading

sequenceDiagram
    participant U as Usuario
    participant CC as Claude Code
    participant SK as Skill Registry

    U->>CC: "implementa el endpoint de usuarios"
    CC->>CC: Analiza tarea sin skills cargados
    CC->>SK: ¿Existe skill relevante?
    SK->>CC: No hay skill específico
    CC->>U: Implementa directamente

    U->>CC: "/gh-pr Agregar feature de pagos"
    CC->>SK: Busca skill gh-pr
    SK->>CC: Carga skill gh-pr 500 tokens
    CC->>U: Ejecuta con skill cargado

Solo cuando invocas /skill-name explícitamente se carga ese skill. Esto evita que 20 skills definidos en .claude/skills/ consuman 10,000+ tokens en cada conversación.

Implicación práctica para la organización de skills

Anti-patrón: Definir todo en CLAUDE.md

# CLAUDE.md (malo)
## Cómo hacer PRs
1. Primero ejecuta git add...
2. Luego git commit...
3. Luego gh pr create...
[200 líneas de instrucciones para PRs]

## Cómo hacer deploys
[150 líneas de instrucciones de deploy]

## Cómo revisar código
[180 líneas de instrucciones de review]

Patrón correcto: Skills separados con lazy loading

.claude/skills/
  gh-pr/SKILL.md          # Cargado solo con /gh-pr
  deploy/SKILL.md         # Cargado solo con /deploy
  code-review/SKILL.md    # Cargado solo con /code-review
# CLAUDE.md (bien)
## Skills disponibles
- /gh-pr: Crear Pull Requests
- /deploy: Desplegar a producción
- /code-review: Revisar código

Ahorro: En lugar de cargar 530 líneas en cada conversación (≈2,120 tokens), cargas solo el skill cuando lo necesitas (~500 tokens por skill).

Cuánto cuesta cargar vs. no cargar skills

Para un desarrollador con 50 conversaciones por día:

Sin lazy loading (todo en CLAUDE.md):
50 × 2,120 tokens × $3/MTok = $0.318/día = $6.99/mes

Con lazy loading (skills separados):
Conversaciones sin skills: 40 × 300 tokens = 12,000
Conversaciones con 1 skill: 10 × 800 tokens = 8,000
Total: 20,000 tokens × $3/MTok = $0.060/día = $1.32/mes

Ahorro mensual: $5.67 (81% reducción en overhead de skills)

17. El /clear Estratégico

El comando /clear reinicia completamente el contexto de la conversación. Es más agresivo que /compact pero en los casos correctos es la opción óptima.

/clear vs /compact: cuándo usar cada uno

SituaciónComandoRazón
Cambias de tarea completamente (de frontend a backend)/clearNo hay contexto relevante que preservar
Comenzar el día con una tarea nueva/clearContexto de ayer es irrelevante
Después de una sesión de debugging exitosa/clearLos traces ya no son útiles
Continuar implementación de la misma feature/compactHay contexto valioso que preservar
Pasar de investigación a implementación (misma tarea)/compactPreservar los hallazgos de investigación
Error grave de Claude que requiere empezar de cero/clearEl contexto corrupto empeora las cosas

El ritual matutino: /clear siempre

La práctica recomendada en ECC es empezar cada sesión laboral con /clear:

# Al iniciar el día
/clear
# Claude Code empieza fresco, sin contexto del día anterior
# El historial está limpio, sin tokens de sesiones pasadas

La sesión del día anterior puede haber acumulado 80,000+ tokens de historial que no son relevantes para hoy. Empezar con /clear reduce el overhead inicial de 80,000 a 0.

El /clear ante contexto corrupto

Uno de los usos más valiosos de /clear es cuando Claude entra en un loop o parece haber “recordado mal” algo:

Síntomas de contexto corrupto:

En estos casos, /clear + re-establecer el contexto esencial es más eficiente que intentar “corregir” el entendimiento de Claude a través de más mensajes.

18. Calculadora de Costo por Workflow

Esta sección proporciona cálculos completos para los workflows más comunes, con y sin optimización.

Workflow: Feature Development completa

Sin optimización (todo Opus):

Fase 1: Exploración del codebase
  - 10 búsquedas con grep
  - Input: 15,000 tokens (overhead + búsquedas)
  - Output: 3,000 tokens
  - Costo Opus: (15,000 × $15 + 3,000 × $75) / 1,000,000 = $0.450

Fase 2: Planificación
  - Input: 25,000 tokens
  - Output: 5,000 tokens
  - Costo Opus: (25,000 × $15 + 5,000 × $75) / 1,000,000 = $0.750

Fase 3: Implementación (3 archivos)
  - Input: 60,000 tokens
  - Output: 10,000 tokens
  - Costo Opus: (60,000 × $15 + 10,000 × $75) / 1,000,000 = $1.650

Fase 4: Tests
  - Input: 40,000 tokens
  - Output: 6,000 tokens
  - Costo Opus: (40,000 × $15 + 6,000 × $75) / 1,000,000 = $1.050

Total sin optimización: $3.900

Con optimización ECC:

Fase 1: Exploración con Haiku + mgrep
  - Input: 8,000 tokens (overhead reducido + mgrep)
  - Output: 1,500 tokens
  - Costo Haiku: (8,000 × $0.25 + 1,500 × $1.25) / 1,000,000 = $0.004

Fase 2: Planificación con Sonnet (compact después de exploración)
  - Input: 15,000 tokens (compaction liberó espacio)
  - Output: 3,000 tokens
  - Costo Sonnet: (15,000 × $3 + 3,000 × $15) / 1,000,000 = $0.090

Fase 3: Implementación con Sonnet (compact después de planificación)
  - Input: 35,000 tokens
  - Output: 8,000 tokens
  - Costo Sonnet: (35,000 × $3 + 8,000 × $15) / 1,000,000 = $0.225

Fase 4: Tests con Haiku
  - Input: 25,000 tokens
  - Output: 4,000 tokens
  - Costo Haiku: (25,000 × $0.25 + 4,000 × $1.25) / 1,000,000 = $0.011

Total con optimización: $0.330
Ahorro: 91.5%

Workflow: Bug Fix

Sin optimización:

Reproducción + investigación: Opus, 40K input, 5K output → $0.975
Diagnóstico: Opus, 50K input, 8K output → $1.350
Fix + verification: Opus, 30K input, 4K output → $0.750
Total: $3.075

Con optimización:

Reproducción + investigación: Sonnet, 40K input, 5K output → $0.195
Diagnóstico (si simple): Sonnet, 30K input, 5K output → $0.165
Diagnóstico (si complejo, 3er intento): Opus, 50K input, 8K output → $1.350
Fix + verification: Sonnet, 30K input, 4K output → $0.150

Caso simple total: $0.510 (83% ahorro)
Caso complejo total: $1.860 (40% ahorro pero mejor calidad)

Workflow: Security Audit

Sin optimización (todo Sonnet):
  - 10 archivos críticos revisados
  - Input: 100K tokens, Output: 20K tokens
  - Costo Sonnet: (100,000 × $3 + 20,000 × $15) / 1,000,000 = $0.600

Con optimización (Opus solo en archivos de auth):
  - 3 archivos de auth con Opus: 30K input, 8K output → $0.600
  - 7 archivos restantes con Sonnet: 70K input, 12K output → $0.390
  - Total: $0.990

Más caro pero mayor calidad en archivos críticos.
La auditoría de seguridad es uno de los casos donde pagar más justifica.

19. Optimización por Tipo de Proyecto

La configuración óptima varía según el tipo de proyecto. Aquí están las recomendaciones específicas.

Frontend SPA (React/Vue/Angular)

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "MAX_THINKING_TOKENS": "8000"
  }
}

MCPs recomendados: Solo Playwright (testing visual es difícil sin MCP)

Razón: Los componentes frontend suelen ser simples (100-200 líneas), Sonnet es más que suficiente. Thinking moderado para decisiones de UX.

Skills útiles: /create-component, /add-test, /review-a11y

Backend API (Node/Go/Python)

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "MAX_THINKING_TOKENS": "12000"
  }
}

MCPs recomendados: Solo base de datos local (PostgreSQL/SQLite MCP)

Skills para reemplazar MCPs: /gh-pr, /deploy-staging, /db-migrate

Razón: API endpoints son moderadamente complejos, Sonnet con thinking moderado maneja bien.

Full-Stack

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "MAX_THINKING_TOKENS": "10000",
    "AUTOCOMPACT_PCT_OVERRIDE": "45"
  }
}

Estrategia especial: Compaction más agresiva porque el contexto de frontend y backend mezclado se vuelve grande rápidamente.

Perfiles de CLI recomendados:

alias cfe='claude --profile frontend'   # Solo contexto de React
alias cbe='claude --profile backend'    # Solo contexto de API/DB
alias cfs='claude --profile fullstack'  # Contexto completo (costoso)

Data Science / ML

{
  "model": "claude-opus-4-5",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-4-6",
    "MAX_THINKING_TOKENS": "25000"
  }
}

Razón: El análisis estadístico y el diseño de pipelines ML requieren razonamiento profundo. Opus con thinking alto es la inversión correcta aquí.

MCPs especiales: Jupyter MCP si existe, o skill para ejecutar notebooks.

Microservices

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "MAX_THINKING_TOKENS": "10000"
  }
}

Estrategia especial: Cada microservicio en su propio directorio como proyecto separado de Claude Code. Evita cargar contexto de todos los servicios cuando trabajas en uno.

# En lugar de abrir el monorepo completo:
cd services/payment-service && claude "implementa endpoint de reembolso"

# Solo carga contexto del servicio de pagos

20. Monitoreo de Tokens

Saber cuánto estás gastando en tiempo real te permite tomar decisiones informadas durante la sesión.

El comando /cost

Claude Code incluye el comando /cost para ver el uso de tokens de la sesión actual:

/cost

Output típico:

Session token usage:
  Input tokens:  45,230
  Output tokens:  8,420
  Cache read:    12,000
  Cache write:    3,100

Estimated cost (claude-sonnet-4-6):
  Input:  $0.136
  Output: $0.126
  Total:  $0.262

Context window usage: 67% (134,460 / 200,000 tokens)

Interpretar el output de /cost

Context window usage: Si supera 60%, considera una compaction pronto. Si supera 80%, la compaction es urgente para mantener calidad.

Cache read vs cache write: Los tokens de “cache read” se cobran a precio reducido (alrededor del 10% del precio normal). Un porcentaje alto de cache read indica que el sistema de prompt caching está funcionando bien.

Input vs Output ratio: En desarrollo normal, el ratio input/output debería ser 5:1 a 10:1. Si el output es casi tan grande como el input, Claude puede estar siendo más verboso de lo necesario.

Alertas de umbral

Para evitar sorpresas en la factura, configura alertas en tu proyecto:

# Script de monitoreo simple
# ~/.claude/scripts/check-spend.sh

#!/bin/bash
LIMIT_DAILY=5.00  # $5 USD por día
CURRENT=$(claude /cost --json | jq '.estimated_total_usd')

if (( $(echo "$CURRENT > $LIMIT_DAILY" | bc -l) )); then
    echo "ALERTA: Gasto del día ($CURRENT) supera límite ($LIMIT_DAILY)"
    echo "Considera compactar o cambiar a modo económico"
fi

Panel de métricas por semana

Lleva un registro sencillo de cuánto gastas por tipo de tarea:

# Tokens por semana (ejemplo de tracking)

## Semana 2024-12-16
- Feature development: $12.40 (8 features)
- Bug fixes: $4.20 (15 bugs)
- Code review: $3.80 (12 PRs)
- Exploración/investigación: $0.90
- Total: $21.30

## Insights
- Bug fixes desproporcionados → mejorar specs
- Code review costoso → skills de review optimizados

21. El ROI de ECC en Tokens

Comparativa concreta de usar Claude Code sin configuración vs con ECC.

Métricas de un desarrollador típico (1 mes)

Sin ECC (configuración por defecto):

Modelo: Opus (por defecto en algunas configuraciones)
MCPs: 8 MCPs activos
Thinking: máximo (31,999 tokens)
Skills: todo en CLAUDE.md
Compaction: automática (80% threshold)

Actividad mensual estimada:
- 50 features de tamaño mediano
- 100 bug fixes
- 200 code reviews
- 500 búsquedas/exploraciones

Costo estimado: $380/mes

Con ECC (configuración optimizada):

Modelo: Sonnet por defecto, Haiku para workers, Opus selectivo
MCPs: 2 MCPs core + skills para el resto
Thinking: 10,000 tokens (reducido 70%)
Skills: lazy loading
Compaction: estratégica (50% threshold)

Misma actividad mensual:
- 50 features → Sonnet = $62
- 100 bug fixes → Sonnet/Haiku mix = $35
- 200 code reviews → Sonnet = $58
- 500 búsquedas → Haiku + mgrep = $5

Costo total: $160/mes

ROI del setup de ECC: $220/mes de ahorro = $2,640/año

El tiempo de configuración de ECC (~8 horas) se recupera en el primer mes.

La curva de aprendizaje del ahorro

graph LR
    A["Día 1\n$15/día"] --> B["Semana 1\n$8/día\nmodelo correcto"]
    B --> C["Semana 2\n$5/día\n+ compaction estratégica"]
    C --> D["Mes 1\n$3/día\n+ MCPs optimizados"]
    D --> E["Mes 2\n$2/día\n+ mgrep + lazy loading"]
    E --> F["Estabilizado\n$1.5/día\ntodo optimizado"]

22. Benchmarks Reales

Los datos concretos del repo de ECC sobre el impacto de las optimizaciones.

Benchmark: mgrep vs grep (50 tareas)

MétricagrepmgrepMejora
Tokens promedio por búsqueda3,4001,34061% menos
Precisión de resultados88%91%+3%
Tiempo de procesamiento1.2s0.8s33% más rápido
First-attempt success72%79%+7%

La mejora en first-attempt success es particularmente valiosa: menos reintentos = menos tokens.

Benchmark: Codebase modular vs monolítico

Proyecto de prueba: API REST con 15,000 líneas de código total

ConfiguraciónTokens/tarea promedioCosto/tareaFirst-attempt
Monolítico (archivos >1000 líneas)85,000$0.3458%
Modular (archivos 100-300 líneas)28,000$0.1183%
Mejora67% menos tokens68% menos costo+25%

Benchmark: Con MCPs vs sin MCPs (reemplazados por skills)

ConfiguraciónTokens overhead/sesiónCosto mensual overheadCalidad
8 MCPs activos32,000$63Igual
2 MCPs + 6 skills8,000$15Igual
Ahorro75% menos$48/mesSin cambio

Benchmark: Extended Thinking configuraciones

Budget thinkingTokens output promedioCosto outputFirst-attempt (tareas complejas)
0 (deshabilitado)1,200$0.01862%
5,0004,800$0.07274%
10,0008,200$0.12381%
20,00014,500$0.21886%
31,999 (máximo)22,000$0.33088%

Para tareas de desarrollo general, budget 10,000 ofrece el mejor ratio costo/calidad.

23. Configuración por Perfil de Usuario

Individual Developer (freelance / side projects)

Prioridad: Mínimo costo absoluto

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "MAX_THINKING_TOKENS": "5000",
    "AUTOCOMPACT_PCT_OVERRIDE": "50"
  }
}

MCPs: Máximo 2 (filesystem + 1 específico del proyecto) Skills: Crear skills para cualquier operación que haces más de 5 veces/semana Presupuesto objetivo: $30-60/mes

Team (5-15 developers)

Prioridad: Balance costo-calidad, consistencia entre miembros

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "MAX_THINKING_TOKENS": "10000",
    "AUTOCOMPACT_PCT_OVERRIDE": "50"
  }
}

Práctica adicional: CLAUDE.md compartido en el repo con reglas del proyecto Skills compartidos: Skills de PR, deploy, review en .claude/skills/ commiteados al repo Presupuesto objetivo: $30-80/mes por developer

CI/CD (automatización)

Prioridad: Predictibilidad de costos, velocidad

{
  "model": "claude-haiku-4-5",
  "env": {
    "MAX_THINKING_TOKENS": "0",
    "AUTOCOMPACT_PCT_OVERRIDE": "30"
  }
}

Razón: Los pipelines de CI/CD ejecutan tareas bien definidas y repetitivas. Haiku sin thinking es óptimo. Si hay tarea compleja (security scan), usar flag --model opus solo en ese paso.

Presupuesto objetivo: $10-30/mes

Startup (velocidad sobre costo)

Prioridad: Máxima velocidad de desarrollo, costo secundario

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-4-6",
    "MAX_THINKING_TOKENS": "15000",
    "AUTOCOMPACT_PCT_OVERRIDE": "60"
  }
}

Estrategia: Permitir MCPs para velocidad de desarrollo, optimizar cuando el producto sea estable Presupuesto objetivo: $100-200/mes (luego optimizar cuando haya PMF)

Enterprise (compliance, seguridad, escala)

Prioridad: Calidad máxima en código crítico, costo justificado

{
  "model": "claude-sonnet-4-6",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-4-5",
    "MAX_THINKING_TOKENS": "10000"
  }
}

Estrategia especial:

24. Anti-patrones de Consumo de Tokens

Los siguientes comportamientos inflan el costo sin mejorar la calidad.

Anti-patrón 1: Usar Opus para todo por defecto

El error: Pensar que “si pago más, obtengo más calidad en todo” La realidad: Para tareas bien definidas, Opus y Sonnet producen resultados idénticos El costo: 5x más caro sin beneficio La solución: Sonnet por defecto, Opus solo cuando Sonnet falla o para tareas críticas

Anti-patrón 2: CLAUDE.md con 1000+ líneas

El error: Poner todas las reglas, ejemplos, convenciones y tutoriales en CLAUDE.md La realidad: Se carga en cada conversación aunque el 80% sea irrelevante El costo: 5,000-8,000 tokens de overhead constante = $11-17/mes extra La solución: CLAUDE.md conciso + skills con lazy loading

Anti-patrón 3: Extended Thinking siempre al máximo

El error: Dejar MAX_THINKING_TOKENS=31999 para todo La realidad: Para búsquedas y ediciones simples, 31,999 tokens de thinking son desperdicio El costo: 3-5x más caro en el output La solución: Budget de thinking según tipo de tarea (0 para exploración, 10,000 para desarrollo)

Anti-patrón 4: Acumular historial sin compactar

El error: Trabajar horas sin hacer /compact La realidad: Con contexto lleno, Claude degrada su calidad y las respuestas empeoran El costo: Más tokens para obtener respuestas peores = doble pérdida La solución: Compaction estratégica en transiciones de fase

Anti-patrón 5: Archivos de 2000+ líneas

El error: No modularizar el código La realidad: Claude debe leer el archivo completo para cualquier tarea en él El costo: 9x más tokens por tarea en el archivo gigante La solución: Archivos de 100-400 líneas con responsabilidades claras

Anti-patrón 6: 10+ MCPs activos siempre

El error: Instalar todos los MCPs “por si acaso” La realidad: Los schemas de MCPs no usados consumen tokens en cada conversación El costo: 20,000-40,000 tokens de overhead constante = $40-90/mes extra La solución: Máximo 2-3 MCPs core + skills para los demás

Anti-patrón 7: Preguntas vagas que requieren aclaración

El error: “Arregla los problemas de performance” La realidad: Claude hace preguntas de aclaración → más tokens → investiga ampliamente → más tokens El costo: 2-3x más tokens que una pregunta específica La solución: “Optimiza las queries N+1 en UserService.ts líneas 45-89”

Anti-patrón 8: No usar /clear entre tareas no relacionadas

El error: Continuar la misma sesión para tareas completamente diferentes La realidad: El historial de la tarea anterior es overhead para la nueva tarea El costo: 30,000-80,000 tokens de contexto irrelevante La solución: /clear cuando cambias de dominio o empiezas el día

Anti-patrón 9: Pedir a Claude que explique demasiado

El error: “Explica paso a paso con ejemplos detallados por qué hiciste cada decisión” La realidad: El output de explicaciones verbosas es caro y raramente necesario El costo: 3-5x más tokens de output La solución: “Solo dame el código con comentarios inline breves”

Anti-patrón 10: Múltiples conversaciones simultáneas en el mismo proyecto

El error: Tener 3 pestañas de Claude Code en el mismo proyecto La realidad: Cada pestaña carga su propia ventana de contexto con el mismo CLAUDE.md, skills, etc. El costo: 3x el overhead fijo de la sesión La solución: Una conversación principal + /clear entre tareas si es necesario separar

25. Ejercicios Prácticos

Ejercicio 1: Auditoría de tu configuración actual

Objetivo: Medir el costo real de tu setup actual

Pasos:

  1. Inicia una sesión nueva de Claude Code
  2. Ejecuta /cost inmediatamente
  3. Registra los “tokens usados por overhead” (lo que se consume antes de escribir tu primer mensaje)
  4. Ejecuta un comando simple: “¿Cuántos archivos hay en src/?”
  5. Ejecuta /cost de nuevo
  6. La diferencia es el overhead de una interacción simple

Meta: El overhead de una interacción simple debería ser <5,000 tokens. Si supera 10,000 tokens: Tienes demasiado en CLAUDE.md o MCPs innecesarios

Ejercicio 2: Comparar modelos en la misma tarea

Objetivo: Sentir la diferencia real entre modelos

  1. Elige una tarea de implementación mediana (un nuevo endpoint, por ejemplo)
  2. Con /clear, implementa con Haiku: claude --model haiku "implementa el endpoint /health que retorna {status: ok, uptime: X segundos}"
  3. Con /clear, implementa con Sonnet: misma tarea
  4. Con /clear, implementa con Opus: misma tarea
  5. Compara la calidad de las 3 implementaciones
  6. Ejecuta /cost después de cada sesión

Lo que aprenderás: Para tareas simples, Haiku y Sonnet dan resultados casi idénticos. Opus raramente justifica su precio para tareas bien definidas.

Ejercicio 3: Migrar un MCP a skill

Objetivo: Reducir overhead de MCPs

  1. Identifica el MCP que menos usas actualmente
  2. Revisa las herramientas que expone ese MCP
  3. Implementa las 2-3 herramientas que usas como skills de CLI
  4. Elimina el MCP del settings.json
  5. Usa Claude Code por una semana con la nueva configuración
  6. Compara el costo semanal antes y después

Ejemplo de skill a crear:

Si tienes GitHub MCP solo para crear PRs, crea .claude/skills/gh-pr/SKILL.md:

# Skill: gh-pr
Ejecuta: gh pr create --title "$1" --body "$2" --base main

Ejercicio 4: Compaction estratégica en práctica

Objetivo: Practicar compaction en el momento correcto

  1. Inicia una sesión de investigación sobre una parte desconocida del codebase
  2. Haz 10 búsquedas y lecturas de archivos
  3. Ejecuta /cost y anota los tokens usados
  4. Escribe un resumen de lo que encontraste en un archivo NOTES.md
  5. Ejecuta /compact Encontré X, Y, Z. Próximo paso: implementar W
  6. Ejecuta /cost de nuevo
  7. Verifica que Claude aún sabe lo esencial (haz una pregunta de verificación)

Lo que aprenderás: La compaction después de investigación libera ~60-70% del contexto acumulado.

Ejercicio 5: Medir el impacto del thinking budget

Objetivo: Encontrar el budget óptimo para tu caso de uso

  1. Toma 5 tareas típicas de tu trabajo diario
  2. Para cada una, resuelve con thinking = 0, 5000, 10000, 20000
  3. Registra: calidad de respuesta (1-5), tokens output, ¿requirió reintento?
  4. Calcula el costo esperado = tokens × precio + (P(reintento) × tokens × precio)

Fórmula:

Costo efectivo = tokens_output × precio + tasa_reintento × tokens_output × precio
               = tokens_output × precio × (1 + tasa_reintento)

Encontrarás que para tu perfil de tareas específico, hay un sweet spot de thinking budget.

26. Checklist de Optimización

Usa este checklist para auditar tu configuración de Claude Code:

Configuración básica

Gestión de MCPs

CLAUDE.md y Skills

Estructura del codebase

Prácticas de sesión

Herramientas

Monitoreo

Avanzado

27. Referencia de Variables de Entorno

Todas las variables de entorno que afectan el consumo de tokens en Claude Code:

Variables de modelo

VariableValoresDefaultDescripción
ANTHROPIC_MODELclaude-haiku-4-5, claude-sonnet-4-6, claude-opus-4-5claude-sonnet-4-6Modelo principal
CLAUDE_CODE_SUBAGENT_MODELMismos valoresIgual al modelo principalModelo para subagentes
CLAUDE_CODE_MAX_OUTPUT_TOKENS1-81928192Máximo tokens de output por respuesta

Variables de thinking

VariableValoresDefaultDescripción
MAX_THINKING_TOKENS0-3199931999Budget de tokens para extended thinking
CLAUDE_CODE_DISABLE_THINKINGtrue/falsefalseDeshabilitar thinking completamente

Variables de compaction

VariableValoresDefaultDescripción
AUTOCOMPACT_PCT_OVERRIDE10-9080% de uso de ventana que activa auto-compact
COMPACT_THRESHOLDNúmero entero50Tool calls antes de sugerir compaction
DISABLE_AUTO_COMPACTtrue/falsefalseDeshabilitar compaction automática

Variables de contexto

VariableValoresDefaultDescripción
CLAUDE_CODE_CONTEXT_WINDOWNúmero200000Tamaño de ventana de contexto
CLAUDE_CODE_SYSTEM_PROMPTPath a archivo-System prompt personalizado
CLAUDE_CODE_DISABLE_MEMORYtrue/falsefalseDeshabilitar carga de memory files

Variables de herramientas

VariableValoresDefaultDescripción
CLAUDE_CODE_DISABLE_PROMPT_CACHINGtrue/falsefalseDeshabilitar caché de prompts
CLAUDE_CODE_GREP_TOOLgrep, mgrep, pathgrepHerramienta de búsqueda
CLAUDE_CODE_MAX_MCP_TOOLSNúmeroSin límiteMáximo de herramientas MCP cargadas

Configuración combinada por perfil

Perfil economía máxima:

export ANTHROPIC_MODEL=claude-sonnet-4-6
export CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5
export MAX_THINKING_TOKENS=5000
export AUTOCOMPACT_PCT_OVERRIDE=45
export CLAUDE_CODE_GREP_TOOL=mgrep

Perfil desarrollo estándar:

export ANTHROPIC_MODEL=claude-sonnet-4-6
export CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5
export MAX_THINKING_TOKENS=10000
export AUTOCOMPACT_PCT_OVERRIDE=50
export CLAUDE_CODE_GREP_TOOL=mgrep

Perfil calidad máxima (código crítico):

export ANTHROPIC_MODEL=claude-opus-4-5
export CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6
export MAX_THINKING_TOKENS=25000
export AUTOCOMPACT_PCT_OVERRIDE=60

28. Resumen y Tabla de Impacto

Las 10 optimizaciones por impacto

graph LR
    A["1. Modelo Sonnet vs Opus"] --> A1["80% ahorro"]
    B["2. MCPs → Skills"] --> B1["60-75% ahorro overhead"]
    C["3. Codebase modular"] --> C1["67% menos tokens/tarea"]
    D["4. Thinking budget 10K vs 32K"] --> D1["60% ahorro output"]
    E["5. mgrep vs grep"] --> E1["61% menos tokens búsqueda"]
    F["6. Compaction estratégica"] --> F1["30-40% mejor calidad"]
    G["7. Haiku para subagentes"] --> G1["50% ahorro en workflows"]
    H["8. CLAUDE.md conciso"] --> H1["Hasta 80% menos overhead"]
    I["9. Lazy loading de skills"] --> I1["80% menos overhead skills"]
    J["10. Clear estratégico"] --> J1["Evita tokens irrelevantes"]

Tabla de impacto consolidada

OptimizaciónAhorro en tokensComplejidad de setupTiempo de setup
Cambiar a Sonnet por defecto80%Baja2 minutos
MAX_THINKING_TOKENS=1000060% del outputBaja1 minuto
AUTOCOMPACT_PCT_OVERRIDE=5020-30% calidadBaja1 minuto
Instalar y configurar mgrep61% búsquedasMedia30 minutos
Reemplazar 5 MCPs por skills60-75% overhead MCPsMedia2-4 horas
Compaction estratégica (práctica)30-40% por sesiónMedia1 semana de hábito
CLAUDE.md < 200 líneasHasta 80% overhead baseMedia2-3 horas
Skills con lazy loading80% overhead skillsMedia2-3 horas
Codebase modular67% por tareaAltaSemanas/meses
Perfiles de contexto dinámico40-60% por tarea tipoAlta1-2 días

El orden de implementación recomendado

Para maximizar ROI de tiempo de setup:

  1. Día 1 (30 minutos): Cambiar modelo a Sonnet, ajustar MAX_THINKING_TOKENS y AUTOCOMPACT_PCT_OVERRIDE
  2. Semana 1 (2-4 horas): Instalar mgrep, reemplazar los 3 MCPs más costosos por skills
  3. Semana 2 (2-3 horas): Limpiar CLAUDE.md, mover instrucciones largas a skills
  4. Mes 1 (ongoing): Practicar compaction estratégica, crear perfiles de contexto
  5. Mes 2-3 (ongoing): Modularizar el codebase si aplica, implementar routing de modelos

El resultado final

Un desarrollador que implementa todas las optimizaciones de este capítulo puede esperar:

La optimización de tokens no es sobre ser “barato” con las herramientas. Es sobre usar los recursos exactamente donde agregan valor y eliminar el desperdicio silencioso que no produce ningún beneficio. Un codebase bien configurado con ECC no solo cuesta menos — produce mejores resultados porque cada token se usa con intención.

Próximo capítulo: Capítulo 9: Workflows Avanzados — Patrones de trabajo para proyectos complejos y flujos de desarrollo en equipo.

← Volver al listado de tecnologías ← Índice de Everything Claude Code