Cómo la ingeniería de contexto reduce el gasto de tokens
La ingeniería de contexto es la disciplina de decidir qué va realmente en un prompt antes de que llegue a Claude.
//
Busca en todas las páginas de la documentación
La ingeniería de contexto es la disciplina de decidir qué va realmente en un prompt antes de que llegue a Claude.
Se sitúa aguas arriba de la redacción del prompt y la selección del modelo, y a menudo es la palanca individual más grande que tiene un equipo sobre el costo de la API.
Un equipo que escribe un gran prompt pero pega un repositorio completo ya ha perdido la mayoría de los ahorros disponibles.
Esta página construye el modelo mental detrás de tres técnicas que se repiten a lo largo de esta sección: prompting de contexto mínimo, sumarización y selección de niveles de modelos.
Cada una de estas reduce el gasto de tokens, y cada una lo hace a través de un mecanismo diferente, por lo que vale la pena entenderlas como palancas distintas en lugar de una idea difusa de "ser eficiente".
Cada solicitud a Claude tiene un costo que escala con el número de tokens de entrada y tokens de salida involucrados.
Los tokens de entrada incluyen el prompt del sistema, el historial de la conversación, cualquier documento recuperado y cualquier resultado de herramienta inyectado en el contexto.
La mayoría de los equipos se centran primero en la longitud de la salida o en la elección de un modelo más económico, pero para muchas cargas de trabajo, el lado de entrada del balance es mayor y más fácil de controlar.
El prompting de contexto mínimo es la práctica de enviar solo los fragmentos específicos que una tarea necesita en lugar del archivo fuente completo, el documento completo o el repositorio completo del que se extrajeron.
La sumarización es la práctica de usar un modelo económico y rápido para comprimir un documento largo en una representación más corta antes de que esa representación se envíe a un modelo más costoso para el trabajo real.
La selección de niveles de modelos es la práctica de enrutar una solicitud al modelo más económico de una línea, como Claude Haiku 4.5, que aún puede cumplir con un estándar de calidad, y reservar un modelo más potente como Claude Opus 4.8 para las solicitudes que realmente lo necesitan.
Una analogía simple: piensa en la ventana de contexto de Claude como un escritorio.
Puedes apilar todo el archivador sobre el escritorio para que nada se pierda nunca, o puedes sacar solo las carpetas relevantes para la tarea que tienes delante.
El segundo enfoque cuesta menos de preparar y también mantiene el escritorio utilizable.
# Una llamada de contexto mínimo: solo la función relevante, no todo el archivo
prompt = f"""Revisa esta función en busca de un error de puntero nulo.
{relevant_function_source}
"""Estas tres técnicas actúan en diferentes puntos del ciclo de vida de una solicitud, y comprender dónde se sitúa cada una aclara cuándo recurrir a ella.
El prompting de contexto mínimo actúa en el tiempo de ensamblaje: antes de construir la cadena del prompt, decides qué fragmentos, filas o párrafos son relevantes y excluyes el resto.
Esta suele ser la técnica de mayor apalancamiento porque elimina los tokens por completo en lugar de comprimirlos, por lo que no hay una llamada API secundaria ni costo de compresión.
La compensación es que requiere un trabajo inicial para saber qué es relevante, ya sea un paso de búsqueda, un grafo de dependencias o un índice de recuperación.
La sumarización actúa en el tiempo de preprocesamiento: existe un documento largo, es demasiado grande o demasiado poco enfocado para enviarlo completo, y un modelo más económico lo reduce antes de que el modelo costoso lo vea.
Esto agrega una llamada API adicional, pero esa llamada utiliza un modelo económico, por lo que el costo neto sigue siendo menor que enviar el documento completo al modelo costoso.
La sumarización es más valiosa cuando el mismo documento largo se referenciará en muchas llamadas, porque el costo de la sumarización se paga una vez y los ahorros se acumulan.
La selección de niveles de modelos actúa en el tiempo de enrutamiento: para cada solicitud entrante, se toma una decisión sobre qué modelo en la línea debe manejarla.
def choose_model(task_complexity: str) -> str:
if task_complexity == "simple_lookup":
return "claude-haiku-4-5"
if task_complexity == "standard_reasoning":
return "claude-sonnet-5"
return "claude-opus-4-8" # razonamiento multi-paso, salida de alto riesgoLas tres técnicas se componen bien juntas.
Un pipeline podría usar prompting de contexto mínimo para seleccionar archivos relevantes, sumarización para condensar cualquier archivo que aún sea demasiado largo y selección de niveles de modelos para decidir si la llamada final necesita Sonnet 5 o puede ejecutarse en Haiku 4.5.
Ninguna de ellas requiere las otras, pero apilarlas produce ahorros multiplicativos, no aditivos, porque cada técnica reduce una dimensión diferente del gasto.
A escala, estas técnicas dejan de ser trucos aislados y se convierten en decisiones políticas que un equipo documenta y revisa.
Un presupuesto de ventana de contexto, por ejemplo, establece un límite estricto sobre cuánto contexto se le permite acumular a un agente antes de que algo tenga que ceder, ya sea sumarización, truncamiento o finalización de la sesión.
Las decisiones de selección de niveles de modelos se benefician de una lista de verificación explícita en lugar de llamadas ad hoc, porque "¿necesita esta tarea Opus?" es una pregunta que diferentes ingenieros responderán de manera inconsistente sin criterios compartidos.
El prompting de contexto mínimo para tareas de código escala aún más con grafos de dependencias: en lugar de elegir fragmentos manualmente, un grafo de importaciones y sitios de llamadas te dice exactamente qué archivos son estructuralmente relevantes para un cambio, lo que escala a bases de código grandes de una manera que la selección manual no lo hace.
Vale la pena ser honesto en que las tres técnicas pueden llevarse demasiado lejos.
Eliminar demasiado contexto, comprimir en exceso un documento o enrutar una tarea genuinamente difícil a un modelo económico produce un ahorro de costos que se paga en respuestas incorrectas, y una respuesta incorrecta que debe ser rehecha es más costosa que los tokens que ahorró.
| Técnica | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Prompting de contexto mínimo | Elimina tokens por completo, sin llamada adicional | Requiere saber qué es relevante | Revisión de código, preguntas y respuestas dirigidas, RAG |
| Sumarización | Comprime documentos largos reutilizables | Agrega una llamada, puede perder matices | Documentos largos referenciados repetidamente |
| Selección de niveles de modelos | Empareja el costo con la dificultad de la tarea | El nivel incorrecto degrada la calidad | Cargas de trabajo de alto volumen y dificultad mixta |
El hilo conductor en las tres es que son decisiones tomadas antes de la llamada al modelo costoso, no después.
Optimizar la redacción de un prompt después de que el contexto ya está inflado recupera muchos menos costos que decidir qué pertenece al prompt en primer lugar.
La ingeniería de contexto es decidir qué información incluir en un prompt, en lugar de cómo redactarlo o qué modelo debe recibirlo.
No.
El prompting de contexto mínimo suele ser el punto de partida de mayor apalancamiento porque elimina tokens directamente sin llamadas API adicionales, mientras que la sumarización y la selección de niveles requieren cierta infraestructura para configurarse.
Sí.
La llamada de sumarización utiliza un modelo económico y rápido, mientras que de lo contrario, el documento original se enviaría completo a un modelo más costoso en cada uso; cuando un documento se referencia muchas veces, el costo único y económico de la sumarización es mucho menor que el costo repetido de enviar el documento completo.
La selección de niveles de modelos enruta cada solicitud al modelo más económico de la línea de Claude, como Haiku 4.5, que aún puede cumplir con el nivel de calidad requerido, reservando modelos más potentes como Sonnet 5 u Opus 4.8 para tareas que realmente necesitan un razonamiento más profundo.
Sí, y combinar estas técnicas es típico en sistemas de producción.
Un grafo de dependencias mapea qué archivos o módulos importa o llama una pieza de código; enviar ese grafo más solo los fragmentos relevantes mantiene enfocado un prompt relacionado con el código, en lugar de pegar un repositorio completo.
Sí.
El parámetro de esfuerzo controla cuánto razonamiento aplica el modelo a un prompt dado; es una palanca separada del tamaño del contexto, pero ambas se recorren y evalúan de la misma manera, desde una configuración económica hasta la más fuerte que aún pasa las verificaciones de calidad.
Sí.
Optimizar la redacción del prompt antes de abordar lo que se incluye en el prompt; los cambios de redacción ahorran un pequeño porcentaje, mientras que las decisiones de contexto a menudo representan la mayoría del gasto.
Si tus prompts incluyen regularmente archivos completos, documentos completos o historiales de conversación completos en lugar de las partes específicas relevantes para la solicitud actual, es muy probable que haya espacio para reducir el gasto sin tocar la elección del modelo.
Revisado por Chris St. John·Última actualización: 16 jul 2026