Mejores Prácticas de Economía de Tokens

Una guía de campo para mantener el gasto de la API de Claude proporcional al valor que entrega: elija el nivel de modelo correcto por defecto, almacene en caché lo que se reutiliza, agrupe lo que puede esperar y mida todo en lugar de adivinar.

Cómo Usar Esta Lista

Trate la sección A como la línea base desde la cual cada nueva característica debería comenzar; las secciones B-D son palancas para aplicar una vez que el volumen justifica el costo de ingeniería.
No aplique todas las prácticas a todas las características; una herramienta interna de bajo volumen no necesita un enrutador o integración por lotes, iguale la inversión con el volumen.
Vuelva a visitar esta lista cada vez que los precios cambien materialmente, especialmente en puntos de transición conocidos como la expiración del precio introductorio de Sonnet 5 el 2026-08-31.
Empareje las prácticas de nivel de modelo con un ADR escrito para que el valor predeterminado no sea solo una convención que nadie recuerda haber acordado.

A - Selección de Modelos

Por defecto, las nuevas características deben usar Sonnet 5, no el modelo más potente. Sonnet 5 maneja la gran mayoría de las tareas cotidianas bien, y recurrir a Opus 4.8 o Fable 5 "por si acaso" incorpora un multiplicador de costo de 2.5x a 5x para una capacidad que la mayoría de las tareas no necesitan.
Reserve Opus 4.8 y Fable 5 para tareas de razonamiento genuinamente difíciles. El razonamiento de varios pasos bajo ambigüedad, el análisis de compensaciones de alto riesgo y las decisiones de juicio críticas para la seguridad son donde los niveles premium ganan su costo; el trabajo de plantillas o coincidencia de patrones rara vez lo es.
Enrute tareas de alto volumen y baja complejidad a Haiku 4.5. La clasificación, la extracción y las tareas de formato simple funcionan bien en el nivel más barato, y los ahorros se acumulan más rápido exactamente donde el volumen es mayor.
Cree un enrutador una vez que el volumen lo justifique, no antes. Un clasificador que envía tareas SIMPLES a Haiku y tareas DIFÍCILES a Opus paga su propio costo de ingeniería solo por encima de un cierto umbral de volumen; por debajo de eso, un valor predeterminado fijo es un uso más eficiente del tiempo de ingeniería.
Nunca permita que la elección del modelo se establezca por defecto en "lo que se usó en las pruebas". Un valor predeterminado explícito y documentado (ver la plantilla ADR) evita que las decisiones de costo se tomen por accidente.

B - Almacenamiento en Caché de Prompts

Almacene en caché cualquier prefijo que se reutilice más de una vez dentro de su ventana TTL. El punto de equilibrio aritmético para el almacenamiento en caché de prompts es bajo, a menudo solo la segunda reutilización, por lo que se inclina a almacenar en caché contenido estable y repetido en lugar de omitirlo.
Coloque el contenido más estable primero, el contenido más volátil al final. Claude ensambla el prefijo almacenado en caché en un orden fijo (herramientas, luego sistema, luego mensajes); estructurar el contenido de esta manera maximiza lo que un punto de interrupción puede cubrir.
Nunca interpola datos por usuario o por sesión en un bloque almacenado en caché. Un nombre de usuario, una marca de tiempo o un ID de sesión dentro del prefijo almacenado en caché invalidan la caché en cada llamada, borrando silenciosamente los ahorros.
Elija TTL basado en el espaciado real de las solicitudes, no por costumbre. El tráfico ráfaga y espaciado cercano favorece el TTL más barato de 5 minutos; el tráfico con brechas que superan regularmente los 5 minutos favorece el TTL más caro de 1 hora a pesar de su mayor costo de escritura.
Construya contenido almacenado en caché a partir de una constante compartida, no de literales dispersos en línea. Incluso el texto semánticamente idéntico puede no coincidir byte por byte si se reconstruye de manera inconsistente en los sitios de llamada, lo que rompe silenciosamente los aciertos de caché.
Monitoree cache_read_input_tokens frente a cache_creation_input_tokens en producción. El cálculo teórico del punto de equilibrio solo importa si el tráfico real lo está compensando; registre ambos campos y observe la relación con el tiempo.

C - Procesamiento por Lotes

Enrute cualquier carga de trabajo tolerante a la latencia y de alto volumen a través de la API de Lotes. Los informes nocturnos, la clasificación masiva y el procesamiento de conjuntos de datos sin conexión rara vez necesitan una respuesta síncrona, y el descuento de aproximadamente el 50% es dinero gratis para ese tráfico.
Nunca agrupe una carga de trabajo con requisitos de latencia reales orientados al usuario. El descuento es real, pero no vale la pena si una persona está esperando en el otro extremo; mantenga los caminos interactivos síncronos.
Maneje los resultados del lote por solicitud, no como una unidad de éxito/fallo. Un lote grande puede tener fallas de solicitud individuales junto con éxitos; reintente solo los custom_id fallidos en lugar de reprocesar todo el lote.
Realice las matemáticas de punto de equilibrio de ingeniería antes de construir la infraestructura de lotes. La lógica de envío, sondeo y recuperación de resultados tiene un costo de ingeniería fijo; por debajo de un cierto volumen de solicitudes, ese costo excede lo que ahorra el descuento.
Etiquete los costos registrados por ruta de procesamiento (síncrono vs. lote). Mezclar los dos en una métrica promedio de costo por solicitud oculta qué palanca está impulsando realmente sus ahorros.

D - Medición y Gobernanza

Cuente los tokens antes de enviar solicitudes de tamaño impredecible. messages.count_tokens es gratuito y exacto para el lado de entrada; úselo para limitar o estimar el costo antes de que un documento proporcionado por el usuario o un contexto largo llegue a la API.
Registre usage.input_tokens, output_tokens, cache_creation_input_tokens y cache_read_input_tokens en cada llamada. Estos cuatro campos son la verdad fundamental para conciliar el gasto real con cualquier modelo de precios que haya construido y para detectar regresiones temprano.
Mantenga tablas de tarifas por modelo en configuración revisable, no en literales codificados. Los precios cambian en su propio horario, las ventanas de precios introductorios expiran, las generaciones de modelos se retiran; una tabla de tarifas integrada en la lógica comercial se desvía silenciosamente de la actualidad.
Escriba un ADR para el nivel de modelo predeterminado del equipo y especifique explícitamente sus desencadenantes de revisión. Un valor predeterminado documentado con condiciones claras para revisarlo evita tanto el aumento silencioso de costos como el conocimiento tribal no documentado.
Trate los fallos y el costo de reelaboración de un modelo más barato como parte de su precio real. Un modelo de nivel bajo que necesita escalamiento frecuente o corrección manual puede costar más de extremo a extremo que un modelo más potente que realiza la tarea correctamente la primera vez; mida el costo total de corrección, no solo el precio por token.
Vuelva a ejecutar las estimaciones de costos después de cualquier cambio de precio, no solo una vez al lanzar. Un modelo de costos construido al lanzar una característica y nunca revisado divergerá silenciosamente de la realidad a medida que evolucionan las tarifas, los descuentos y las líneas de modelos.

Aplicando Estas Prácticas en Orden

Comience con A (1-5): la selección de modelos es la palanca de mayor apalancamiento y menor esfuerzo; obtenga el valor predeterminado correcto antes de invertir en infraestructura de caché o lotes.
Incorpore B (6-9): el almacenamiento en caché de prompts tiene un punto de equilibrio bajo y se aplica a casi cualquier carga de trabajo con un prompt de sistema o catálogo de herramientas estable; agréguelo temprano.
Agregue C (10-12) una vez que el volumen lo justifique: los ahorros de los lotes son reales, pero el costo de ingeniería solo se amortiza por encima de un cierto volumen; no lo construya prematuramente.
Mantenga D (13-16) funcionando continuamente: la medición y la gobernanza no son una configuración única, son lo que mantiene honestas las otras tres categorías a medida que evolucionan los precios y la mezcla de tareas.

Preguntas Frecuentes

¿Qué práctica debería implementar primero un equipo si comienza desde cero?

Selección de modelo (sección A): elija un nivel predeterminado explícito y documéntelo. Es el cambio de mayor apalancamiento y menor esfuerzo, y todo lo demás se basa en él.

¿Está bien omitir por completo el almacenamiento en caché de prompts?

Sí, si una carga de trabajo realmente no tiene prefijo reutilizado, cada solicitud es contenido verdaderamente único, el almacenamiento en caché agrega costo sin ahorros compensatorios. El almacenamiento en caché es una palanca para la reutilización, no un valor predeterminado universal.

¿Cuál es el error más común en esta lista?

Usar por defecto el modelo más potente "por si acaso" en lugar de igualar el nivel del modelo con la dificultad real de la tarea. Es el error más fácil de cometer porque se siente seguro, y el más caro a escala.

¿Cómo sé si mi carga de trabajo tiene suficiente volumen para justificar un enrutador o una integración por lotes?

Ejecute el cálculo de punto de equilibrio: divida el costo de ingeniería único por el ahorro por solicitud. Si su volumen de solicitudes esperado supera cómodamente ese número, la inversión se amortiza.

¿Debería registrarse cada solicitud con detalles completos de uso?

Para cualquier carga de trabajo de producción con implicaciones de costos reales, sí, los cuatro campos de uso son baratos de registrar y son la única forma confiable de conciliar el gasto real con su modelo de costos más adelante.

¿Por qué esta lista separa la "selección de modelos" de la "medición y gobernanza"?

La selección de modelos es una decisión que toma una vez (por característica o por equipo), mientras que la medición y la gobernanza son prácticas continuas que verifican que la decisión se mantiene a medida que cambian las condiciones. Confundir las dos hace que sea fácil establecer un buen valor predeterminado y luego olvidarse de revisarlo.

¿Es realmente necesario un ADR documentado, o es suficiente un valor predeterminado de configuración?

Un valor predeterminado de configuración le dice cuál es la configuración actual; un ADR le dice por qué, bajo qué condiciones debería cambiar y qué alternativas se rechazaron. Ambos importan, pero solo el ADR evita que la decisión se analice inversamente más tarde.

¿Esta lista de mejores prácticas asume un volumen o tamaño de empresa específico?

No, pero el peso del esfuerzo debe escalarse con el volumen; las secciones A y B se aplican casi universalmente, mientras que la inversión de ingeniería de C y D debe dimensionarse al volumen de solicitudes real y a las apuestas presupuestarias.

¿Cuál es la forma más rápida de saber si estas prácticas están funcionando?

Compare el costo real combinado por solicitud (del uso registrado) con lo que habría costado una política plana y no optimizada de un solo modelo para el mismo tráfico. Una brecha decreciente con el tiempo indica que las prácticas están dando sus frutos.

Relacionado

Cómo Funciona Realmente el Precio de Tokens de Claude - el modelo de precios subyacente sobre el que se basan estas prácticas.
Sonnet 5 vs Opus 4.8 vs Fable 5: Una Comparación de Costo por Tarea - los datos tarea por tarea detrás de las prácticas de selección de modelos.
ROI del Almacenamiento en Caché de Prompts: Cuándo las Escrituras en Caché Realmente Valen la Pena - las matemáticas del punto de equilibrio detrás de las prácticas de almacenamiento en caché.
Plantilla ADR: Elegir un Nivel de Modelo Predeterminado para su Equipo - convertir las prácticas de selección de modelos en una decisión de equipo documentada.

Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y el SDK oficial de Python anthropic (última versión 0.x). Los nombres de modelos, precios y versiones de SDK cambian rápidamente; verifique los detalles actuales en platform.claude.com/docs antes de confiar en ellos.

Mejores Prácticas de Economía de Tokens

Cómo Usar Esta Lista

Trate la sección A como la línea base desde la cual cada nueva característica debería comenzar; las secciones B-D son palancas para aplicar una vez que el volumen justifica el costo de ingeniería.
No aplique todas las prácticas a todas las características; una herramienta interna de bajo volumen no necesita un enrutador o integración por lotes, iguale la inversión con el volumen.
Vuelva a visitar esta lista cada vez que los precios cambien materialmente, especialmente en puntos de transición conocidos como la expiración del precio introductorio de Sonnet 5 el 2026-08-31.
Empareje las prácticas de nivel de modelo con un ADR escrito para que el valor predeterminado no sea solo una convención que nadie recuerda haber acordado.

A - Selección de Modelos

Por defecto, las nuevas características deben usar Sonnet 5, no el modelo más potente. Sonnet 5 maneja la gran mayoría de las tareas cotidianas bien, y recurrir a Opus 4.8 o Fable 5 "por si acaso" incorpora un multiplicador de costo de 2.5x a 5x para una capacidad que la mayoría de las tareas no necesitan.
Reserve Opus 4.8 y Fable 5 para tareas de razonamiento genuinamente difíciles. El razonamiento de varios pasos bajo ambigüedad, el análisis de compensaciones de alto riesgo y las decisiones de juicio críticas para la seguridad son donde los niveles premium ganan su costo; el trabajo de plantillas o coincidencia de patrones rara vez lo es.
Enrute tareas de alto volumen y baja complejidad a Haiku 4.5. La clasificación, la extracción y las tareas de formato simple funcionan bien en el nivel más barato, y los ahorros se acumulan más rápido exactamente donde el volumen es mayor.
Cree un enrutador una vez que el volumen lo justifique, no antes. Un clasificador que envía tareas SIMPLES a Haiku y tareas DIFÍCILES a Opus paga su propio costo de ingeniería solo por encima de un cierto umbral de volumen; por debajo de eso, un valor predeterminado fijo es un uso más eficiente del tiempo de ingeniería.
Nunca permita que la elección del modelo se establezca por defecto en "lo que se usó en las pruebas". Un valor predeterminado explícito y documentado (ver la plantilla ADR) evita que las decisiones de costo se tomen por accidente.

B - Almacenamiento en Caché de Prompts

Almacene en caché cualquier prefijo que se reutilice más de una vez dentro de su ventana TTL. El punto de equilibrio aritmético para el almacenamiento en caché de prompts es bajo, a menudo solo la segunda reutilización, por lo que se inclina a almacenar en caché contenido estable y repetido en lugar de omitirlo.
Coloque el contenido más estable primero, el contenido más volátil al final. Claude ensambla el prefijo almacenado en caché en un orden fijo (herramientas, luego sistema, luego mensajes); estructurar el contenido de esta manera maximiza lo que un punto de interrupción puede cubrir.
Nunca interpola datos por usuario o por sesión en un bloque almacenado en caché. Un nombre de usuario, una marca de tiempo o un ID de sesión dentro del prefijo almacenado en caché invalidan la caché en cada llamada, borrando silenciosamente los ahorros.
Elija TTL basado en el espaciado real de las solicitudes, no por costumbre. El tráfico ráfaga y espaciado cercano favorece el TTL más barato de 5 minutos; el tráfico con brechas que superan regularmente los 5 minutos favorece el TTL más caro de 1 hora a pesar de su mayor costo de escritura.
Construya contenido almacenado en caché a partir de una constante compartida, no de literales dispersos en línea. Incluso el texto semánticamente idéntico puede no coincidir byte por byte si se reconstruye de manera inconsistente en los sitios de llamada, lo que rompe silenciosamente los aciertos de caché.
Monitoree cache_read_input_tokens frente a cache_creation_input_tokens en producción. El cálculo teórico del punto de equilibrio solo importa si el tráfico real lo está compensando; registre ambos campos y observe la relación con el tiempo.

C - Procesamiento por Lotes

Enrute cualquier carga de trabajo tolerante a la latencia y de alto volumen a través de la API de Lotes. Los informes nocturnos, la clasificación masiva y el procesamiento de conjuntos de datos sin conexión rara vez necesitan una respuesta síncrona, y el descuento de aproximadamente el 50% es dinero gratis para ese tráfico.
Nunca agrupe una carga de trabajo con requisitos de latencia reales orientados al usuario. El descuento es real, pero no vale la pena si una persona está esperando en el otro extremo; mantenga los caminos interactivos síncronos.
Maneje los resultados del lote por solicitud, no como una unidad de éxito/fallo. Un lote grande puede tener fallas de solicitud individuales junto con éxitos; reintente solo los custom_id fallidos en lugar de reprocesar todo el lote.
Realice las matemáticas de punto de equilibrio de ingeniería antes de construir la infraestructura de lotes. La lógica de envío, sondeo y recuperación de resultados tiene un costo de ingeniería fijo; por debajo de un cierto volumen de solicitudes, ese costo excede lo que ahorra el descuento.
Etiquete los costos registrados por ruta de procesamiento (síncrono vs. lote). Mezclar los dos en una métrica promedio de costo por solicitud oculta qué palanca está impulsando realmente sus ahorros.

D - Medición y Gobernanza

Cuente los tokens antes de enviar solicitudes de tamaño impredecible. messages.count_tokens es gratuito y exacto para el lado de entrada; úselo para limitar o estimar el costo antes de que un documento proporcionado por el usuario o un contexto largo llegue a la API.
Registre usage.input_tokens, output_tokens, cache_creation_input_tokens y cache_read_input_tokens en cada llamada. Estos cuatro campos son la verdad fundamental para conciliar el gasto real con cualquier modelo de precios que haya construido y para detectar regresiones temprano.
Mantenga tablas de tarifas por modelo en configuración revisable, no en literales codificados. Los precios cambian en su propio horario, las ventanas de precios introductorios expiran, las generaciones de modelos se retiran; una tabla de tarifas integrada en la lógica comercial se desvía silenciosamente de la actualidad.
Escriba un ADR para el nivel de modelo predeterminado del equipo y especifique explícitamente sus desencadenantes de revisión. Un valor predeterminado documentado con condiciones claras para revisarlo evita tanto el aumento silencioso de costos como el conocimiento tribal no documentado.
Trate los fallos y el costo de reelaboración de un modelo más barato como parte de su precio real. Un modelo de nivel bajo que necesita escalamiento frecuente o corrección manual puede costar más de extremo a extremo que un modelo más potente que realiza la tarea correctamente la primera vez; mida el costo total de corrección, no solo el precio por token.
Vuelva a ejecutar las estimaciones de costos después de cualquier cambio de precio, no solo una vez al lanzar. Un modelo de costos construido al lanzar una característica y nunca revisado divergerá silenciosamente de la realidad a medida que evolucionan las tarifas, los descuentos y las líneas de modelos.

Aplicando Estas Prácticas en Orden

Comience con A (1-5): la selección de modelos es la palanca de mayor apalancamiento y menor esfuerzo; obtenga el valor predeterminado correcto antes de invertir en infraestructura de caché o lotes.
Incorpore B (6-9): el almacenamiento en caché de prompts tiene un punto de equilibrio bajo y se aplica a casi cualquier carga de trabajo con un prompt de sistema o catálogo de herramientas estable; agréguelo temprano.
Agregue C (10-12) una vez que el volumen lo justifique: los ahorros de los lotes son reales, pero el costo de ingeniería solo se amortiza por encima de un cierto volumen; no lo construya prematuramente.
Mantenga D (13-16) funcionando continuamente: la medición y la gobernanza no son una configuración única, son lo que mantiene honestas las otras tres categorías a medida que evolucionan los precios y la mezcla de tareas.

Preguntas Frecuentes

¿Qué práctica debería implementar primero un equipo si comienza desde cero?

Selección de modelo (sección A): elija un nivel predeterminado explícito y documéntelo. Es el cambio de mayor apalancamiento y menor esfuerzo, y todo lo demás se basa en él.

¿Está bien omitir por completo el almacenamiento en caché de prompts?

¿Cuál es el error más común en esta lista?

¿Cómo sé si mi carga de trabajo tiene suficiente volumen para justificar un enrutador o una integración por lotes?

¿Debería registrarse cada solicitud con detalles completos de uso?

¿Por qué esta lista separa la "selección de modelos" de la "medición y gobernanza"?

¿Es realmente necesario un ADR documentado, o es suficiente un valor predeterminado de configuración?

¿Esta lista de mejores prácticas asume un volumen o tamaño de empresa específico?

¿Cuál es la forma más rápida de saber si estas prácticas están funcionando?

Relacionado

Cómo Funciona Realmente el Precio de Tokens de Claude - el modelo de precios subyacente sobre el que se basan estas prácticas.
Sonnet 5 vs Opus 4.8 vs Fable 5: Una Comparación de Costo por Tarea - los datos tarea por tarea detrás de las prácticas de selección de modelos.
ROI del Almacenamiento en Caché de Prompts: Cuándo las Escrituras en Caché Realmente Valen la Pena - las matemáticas del punto de equilibrio detrás de las prácticas de almacenamiento en caché.
Plantilla ADR: Elegir un Nivel de Modelo Predeterminado para su Equipo - convertir las prácticas de selección de modelos en una decisión de equipo documentada.

Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y el SDK oficial de Python anthropic (última versión 0.x). Los nombres de modelos, precios y versiones de SDK cambian rápidamente; verifique los detalles actuales en platform.claude.com/docs antes de confiar en ellos.

Mejores Prácticas de Economía de Tokens

Buscar en la documentación

Mejores Prácticas de Economía de Tokens