Tokens de entrada vs salida: coste de Claude

Por qué los tokens de salida cuestan más que los de entrada

Los tokens de salida cuestan cinco veces más que los de entrada en todos los modelos Claude del catálogo actual. La causa es la estructura del cálculo. Leer un prompt es una sola pasada sobre el modelo. Escribir una respuesta es una pasada por cada token, y cada pasada debe esperar a la anterior.

Esa proporción es la misma en cada fila de la lista de precios, por lo que el modelo que elija no cambia qué parte de su factura corresponde a la salida. Eso lo decide la estructura de su carga de trabajo. Un paso de agente que lee 60,000 tokens y responde en 800 gasta casi nada en salida. Una tarea de redacción que lee 2,000 tokens y escribe 12,000 gasta casi nada en entrada. Ambos casos se calculan a continuación según las tarifas publicadas por Anthropic, verificadas el 27 de octubre de 2026.

El prefill se ejecuta una vez, la decodificación se ejecuta una vez por token

Un servidor de inferencia gestiona una solicitud en dos fases con costes muy distintos. El prefill lee el prompt. La decodificación escribe la respuesta.

El prefill procesa todo el prompt de una vez. Cada token del prompt entra en la red en la misma pasada hacia adelante (forward pass), por lo que el trabajo de atención y feed-forward se convierte en un número pequeño de grandes multiplicaciones de matrices que cubren miles de tokens a la vez. Una sola lectura de los pesos del modelo desde la memoria sirve para todo el prompt. Las unidades matriciales del acelerador se mantienen ocupadas, lo que significa que el prefill suele estar limitado por la capacidad de cómputo: el límite es la velocidad a la que el chip puede multiplicar. La documentación de servicio de NVIDIA señala las excepciones: los prefills muy cortos y aquellos donde un prefijo largo ya es un acierto de caché (cache hit) pasan a estar limitados por la memoria.

La decodificación ordinaria no puede funcionar de esa manera, porque el token 2 depende del token 1. El token que el modelo acaba de producir se convierte en parte de la entrada para el siguiente paso, por lo que los pasos se ejecutan uno tras otro. Cada token de salida obtiene su propia pasada hacia adelante, y cada una de esas pasadas lee el conjunto completo de pesos del modelo, además de la KV cache (caché de clave/valor, el estado de atención almacenado para cada token hasta el momento), desde la memoria de alto ancho de banda para producir un solo token. Eso suele hacer que la decodificación esté limitada por la memoria: el límite es la velocidad a la que se pueden mover los pesos y el estado almacenado, no la velocidad a la que se pueden multiplicar; en contextos largos, NVIDIA identifica las lecturas de la KV cache como el cuello de botella. El mismo tráfico de pesos que consumió un prompt completo durante el prefill le otorga un solo token durante la decodificación.

La decodificación especulativa (speculative decoding) altera esa regla sin romperla. Un modelo borrador pequeño adivina varios tokens por adelantado, y el modelo grande los verifica todos en paralelo en una sola pasada, lo cual, según NVIDIA, puede desplazar la decodificación hacia un estado limitado por cómputo. El modelo grande sigue aceptando las suposiciones en orden y se detiene en la primera incorrecta, por lo que una respuesta larga sigue costando muchas pasadas.

Los sistemas de servicio contrarrestan esto mediante el procesamiento por lotes (batching). Muchas solicitudes se decodifican juntas, por lo que una sola lectura de los pesos produce un token para cada solicitud en el lote. Es por eso que la decodificación es viable. El límite vuelve a ser la memoria. Cada solicitud en curso mantiene su propia KV cache, esa caché crece con cada token generado y, cuando llena el acelerador, el lote no puede crecer más.

Nada de esto le proporciona un número exacto, y no debe interpretar 5x como una relación de hardware medida. Es un precio, establecido por Anthropic, basado en esa asimetría. Lo que puede comprobar usted mismo es la dirección, y toma alrededor de un minuto.

Mida usted mismo la brecha de entrada y salida

Instale las herramientas en cualquier equipo con Ubuntu:

sudo apt update && sudo apt install -y curl jq moreutils

Ahora envíe un prompt corto que solicite una respuesta larga y marque cada línea con el momento en que llega.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s antepone a cada línea los segundos transcurridos desde que comenzó el comando. Hay dos cosas que merece la pena observar en esa salida. La primera línea content_block_delta es su tiempo hasta el primer token, y todo el prefill ocurrió durante ese intervalo. Cada línea posterior es un pequeño paso de decodificación, y las marcas de tiempo siguen aumentando hasta que llega message_stop.

Ahora invierta la forma. Introduzca un documento largo en el prompt y limite la respuesta a unos pocos tokens.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

El primer delta tarda más que con el prompt corto, porque el prefill tiene mucho más texto que leer. Una vez que llega, la respuesta termina casi de inmediato, porque solo quedan unos pocos tokens por decodificar. Entraron decenas de miles de tokens y el reloj apenas se movió. Salieron unos pocos cientos y el reloj estuvo funcionando todo el tiempo.

Toda respuesta que no sea por streaming termina con las cifras por las que se le factura.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Registre los cuatro campos por solicitud. output_tokens incluye tokens de razonamiento, por lo que un modelo que piensa antes de responder factura ese razonamiento a la tasa de salida. Para calcular el precio de un prompt antes de enviarlo, POST /v1/messages/count_tokens acepta el mismo cuerpo de solicitud que la mayoría de las peticiones, devuelve {"input_tokens": N} como estimación sin ejecutar el modelo y es gratuito, dentro de su propio límite de tasa. Rechaza algunos cuerpos que la Messages API sí acepta: la mayoría de las herramientas de servidor como la búsqueda web, el conector MCP y los bloques de imagen o documento con una fuente url o file, así que envíe las imágenes y los PDF en base64 cuando los cuente. No es la única parte de la API que no tiene coste, y merece la pena consultar qué partes de la API de Claude nunca se le facturan antes de presupuestar un primer proyecto.

Tarifas de Claude por millón de tokens a octubre de 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

La última columna es la salida dividida por la entrada, y muestra 5 en cada fila. Haiku 4.5 factura $1 por entrada y $5 por salida. Opus 5 factura $5 y $25. Fable 5, el más costoso, factura $10 y $50, y lo que ofrecen esas tarifas de Fable 5 merece una lectura antes de descartar esa primera fila. Subir en la gama multiplica ambos lados por el mismo factor, por lo que cambia el total pero mantiene la proporción entre entrada y salida exactamente donde estaba.

Sonnet 5 factura $2 por entrada y $10 por salida. Anthropic lo lanzó con esa tarifa como precio de introducción hasta el 31 de agosto de 2026, con un aumento programado a $3 y $15 para el 1 de septiembre, pero finalmente estableció $2 y $10 como precio estándar. El aumento nunca entró en vigor, por lo que la tarifa en cada ejemplo práctico a continuación es la que usted paga hoy.

Anthropic también ha lanzado modelos más nuevos desde que se publicó esta página, y claude.com/pricing ahora enumera los cuatro anteriores como modelos heredados que siguen disponibles. Los nuevos mantienen la misma proporción de 5x. Opus 5.5 factura $4 y $20, Sonnet 5.5 factura $2 y $10, Fable 5.1 factura $10 y $50, y Haiku 5.5 factura $0.10 y $0.50 para prompts de hasta 100,000 tokens, aumentando a $0.50 y $2.50 por encima de esa cifra. El paso de agente de 60,000 tokens que se detalla más abajo se sitúa por debajo de ese límite, pero un agente cuyo historial sigue creciendo eventualmente lo superará, y cómo funcionan los dos niveles de precios de Haiku 5.5 en trabajos reales muestra el impacto de ese salto en la factura. Las tarifas base de entrada y salida de Opus 5.5 son un 20% inferiores a las de Opus 5, por lo que cada cifra de Opus 5 sin caché que aparece a continuación es un 20% menor en Opus 5.5. Las cifras con caché disminuyen aún más, ya que Opus 5.5 lee los aciertos de caché a $0.20 por millón de tokens frente a los $0.50 de Opus 5, una reducción del 60%. El paso de agente con caché que cuesta $0.0725 en Opus 5 más abajo, cuesta aproximadamente $0.047 en Opus 5.5, cerca de un 35% menos.

Las tarifas cambian y esta página no es el lugar donde debe consultarlas. claude.com/pricing es la fuente oficial. Lo que sobrevive a un cambio de precio es el método.

Una advertencia se encuentra en las notas bajo la tabla de precios de Anthropic en lugar de en las tarifas mismas. La página de precios de Anthropic indica que Claude 4.7 y los modelos posteriores utilizan un tokenizador más reciente que produce aproximadamente un 30% más de tokens para el mismo texto que el tokenizador de Sonnet 4.6 y anteriores. Comparar dos modelos basándose únicamente en el precio por millón de tokens favorecerá al más nuevo, porque el mismo documento representa más tokens en él. Compare el costo por tarea finalizada y calcule sus prompts reales con el modelo que realmente planea usar. La misma trampa existe entre proveedores, cuyos tokenizadores también difieren entre sí, por lo que calcular el costo de un trabajo real tanto en Claude como en ChatGPT le dirá más que comparar las dos listas de precios lado a lado. cuánto equivale un millón de tokens de Claude en texto real cubre cómo se traduce ese volumen en la práctica.

¿Cuándo empieza a dominar el coste de salida?

Con la salida valorada en 5 veces el precio de entrada, el punto de equilibrio es fácil de calcular mentalmente. Llama I a los tokens de entrada y O a los tokens de salida. La entrada cuesta I. La salida cuesta 5 veces O. La salida supera la mitad del gasto cuando 5 veces O es mayor que I, lo que equivale a una proporción de 5 tokens de entrada por 1 de salida.

Por tanto, si tu prompt es más de cinco veces más largo que la respuesta, la entrada representa la partida más costosa. Por debajo de esa proporción, lo hace la salida.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

Con una proporción de 100 a 1, la salida representa el 4.8% del gasto, y reducir el prompt es la única tarea que merece la pena. Con una proporción de 5 a 1, ambas partes tienen el mismo coste. Con una proporción de 1 a 6, la salida representa el 96.8% y el prompt es un redondeo irrelevante. La mayoría de las personas calcula mal su propia proporción, así que obtén ese dato de los logs antes de optimizar nada.

Una carga de trabajo de agente: entra mucho contexto y sale una respuesta breve

Realice un paso de un agente de recuperación: 60,000 tokens de documentos recuperados e historial de conversación como entrada, y una respuesta de 800 tokens. La proporción es de 75 a 1, lo que es normal en cualquier sistema que lee antes de escribir.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

La salida representa el 6.25% de esa llamada en todos los modelos, porque la proporción es fija en toda la lista de precios. La llamada cuesta $0.32 en Opus 5, $0.128 en Sonnet 5 y $0.064 en Haiku 4.5. Doscientos de esos pasos al día en Opus 5 cuestan $64 al día.

La ventaja es evidente cuando se observa el desglose. Reducir la respuesta de 800 tokens a 400 ahorra aproximadamente un 3% del coste de la llamada. Eliminar 20,000 tokens de contexto obsoleto del prompt ahorra aproximadamente un tercio del coste. Ajustar la longitud de salida de un agente que lee mucho supone un esfuerzo casi desperdiciado. desglosa dónde se usan realmente los tokens de un agente de programación explica qué compone ese prompt.

Carga de trabajo de generación: prompt corto, borrador largo

Ahora invirtamos la estructura. Un resumen de 2.000 tokens, un borrador de 12.000 tokens, una relación de 1 a 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

La salida representa el 96.8% de esta factura. Opus 5 cuesta $0.31 por borrador frente a $0.062 en Haiku 4.5. Esa diferencia de cinco veces proviene casi en su totalidad del lado de la salida, que es precisamente donde un modelo más económico genera el mayor ahorro.

La última columna muestra el mismo trabajo a través de la Batch API, que reduce un 50% el coste de entrada y salida. Opus 5 baja a $0.155 por borrador. El procesamiento por lotes (batch) es asíncrono, no inmediato. Anthropic indica que la mayoría de los lotes finalizan en menos de una hora, pero un lote que siga procesándose a las 24 horas expira; cualquier solicitud que no haya sido alcanzada para entonces se devuelve como expirada, sin facturar y sin mensaje. Por tanto, es adecuado para la generación de informes nocturnos y la clasificación masiva, con un paso de reenvío para cualquier elemento que expire. No es adecuado para ninguna tarea en la que una persona esté sentada esperando una respuesta.

El enrutamiento de modelos resulta rentable aquí de una forma que nunca ocurre en el paso del agente. Si la parte extensa del trabajo es mecánica, como reformatear texto o expandir un esquema que usted ya aprobó, el modelo económico genera esos tokens a una quinta parte del precio. elección entre Opus, Sonnet y Haiku detalla dónde se sitúa realmente el límite de calidad.

Descuentos por caché en la entrada, y solo en la entrada

El almacenamiento en caché de prompts guarda un prefijo de su prompt en el servidor y cobra una fracción de la tarifa de entrada por volver a leerlo. A fecha de 27 de octubre de 2026, los multiplicadores son 1.25x la tarifa base de entrada para escribir una caché de 5 minutos, 2x para escribir una caché de 1 hora y 0.1x por leer un acierto en los modelos con precios en esta página. Los modelos más recientes leen los aciertos por menos: 0.05x en Opus 5.5 y Sonnet 5.5, y 0.025x en Fable 5.1.

La salida no entra en este acuerdo. No existe la salida en caché. Cada token que el modelo escribe se factura a la tarifa completa de salida, siempre, independientemente de cuánto del prompt se haya recuperado como un acierto de caché.

Realice el mismo paso de agente en Opus 5, con 55,000 de los 60,000 tokens de entrada servidos desde una caché activa.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

La llamada baja de $0.32 a $0.0725. La línea de salida no se mueve: $0.02 antes, $0.02 después. El almacenamiento en caché reduce la factura y cambia su estructura. La salida representaba el 6.25% de esa llamada. Ahora es más de una cuarta parte, lo que cambia qué palanca merece la pena accionar a continuación.

La primera llamada paga la escritura. Una escritura en caché de 5 minutos cuesta 1.25x la entrada base, por lo que se amortiza tras un solo acierto. Una escritura de 1 hora cuesta 2x, por lo que requiere dos. los multiplicadores de escritura y lectura, y dónde deja de ser rentable el almacenamiento en caché detalla ese cálculo.

Cuatro palancas bajo su control

1. Establezca max_tokens en la longitud de salida de su p95, no en el máximo del modelo.
2. Derive los pasos extensos a un modelo más económico.
3. Procese por lotes todo aquello que no requiera respuesta inmediata.
4. Elimine las instrucciones que inflan las respuestas.

max_tokens es un límite estricto y establecerlo alto no tiene coste por sí mismo, ya que se factura por los tokens generados y nunca por el límite. Un tope generoso evita que una respuesta que sale mal se corte prematuramente. Extraiga la distribución de output_tokens de sus registros, establezca el tope ligeramente por encima del percentil 95 y gestione stop_reason: "max_tokens" en el código continuando la respuesta o reintentando. Una truncación detectada cuesta menos que una divagación de 4,000 tokens por la que paga y luego descarta. El razonamiento también se incluye en output_tokens y cuenta para max_tokens, así que dimensione el tope basándose en la misma evidencia; en modelos con razonamiento adaptativo, reduzca el nivel de esfuerzo si el razonamiento consume demasiado espacio de la respuesta.

El enrutamiento funciona cuando la parte costosa de un paso es el volumen y no el juicio. Mantenga el modelo potente para la toma de decisiones y delegue la redacción a uno más barato. Evalúe primero la versión enrutada con su propio conjunto de pruebas, ya que la cifra relevante es el coste por tarea finalizada. En el paso del agente anterior, dos intentos de Haiku 4.5 cuestan $0.128 frente a los $0.32 de un intento de Opus 5, por lo que la diferencia de precio absorbe uno o dos reintentos. Lo que no absorbe es una respuesta incorrecta que nadie detecta.

El procesamiento por lotes es la única palanca que descuenta la salida. Un 50% de descuento en ambos lados, la mayoría de los lotes se completan en menos de una hora y cualquier tarea programada es apta, siempre que el trabajo reenvíe lo que expire al cumplirse el plazo de 24 horas.

La última palanca es la que la gente suele omitir. Frases como "sé exhaustivo" o "explica tu razonamiento" determinan la longitud de salida en cada llamada que realice. Sustitúyalas por la estructura que desea: "Responde en un máximo de tres frases" o "Devuelve solo el objeto JSON, sin preámbulos". Un prompt del sistema que añade 300 tokens a cada respuesta cuesta cinco veces más que esos mismos 300 tokens en el prompt. mantener bajo control los costes de un agente en ejecución cubre el aspecto de la monitorización, y vale la pena determinar si la API o una suscripción plana es más barata para su patrón de uso antes de pasar una semana ajustando el gasto por token que una suscripción habría absorbido. Para un desarrollador, esto se reduce principalmente a si los $20 al mes de Claude Pro y los límites de uso asociados cubren el trabajo que de otro modo estaría midiendo. Si ya está alcanzando esos límites a mitad de sesión, lo primero es averiguar qué ventana le está haciendo esperar, ya que la solución pasa por un modelo más pequeño, un contexto más ligero, créditos de uso adicionales o trasladar ese trabajo a la API medida. Si la API medida resulta ser el lugar más económico para ese trabajo, cambiar a un plan inferior o cancelarlo deja intacto el mes que ya ha pagado, por lo que realizar el cambio no le supone ningún coste adicional. Si el plan con el que compara Pro es el de ChatGPT en lugar de la API medida, las dos escalas de suscripción comparadas lado a lado muestran cuál resulta más barata para tareas de programación. Si esta pregunta se plantea para un equipo y no para un desarrollador individual, tenga en cuenta que Claude Enterprise combina una tarifa por puesto con tokens medidos a estas mismas tarifas de API, por lo que todas las palancas de esta página siguen siendo aplicables a la parte medida de esa factura.

FAQ

¿Por qué los tokens de salida cuestan más que los de entrada?

Generarlos requiere mucho más tiempo de acelerador por token. Un prompt se procesa en una sola pasada hacia adelante sobre todo el contenido; por tanto, una única lectura de los pesos del modelo cubre miles de tokens y el hardware suele estar limitado por el rendimiento de multiplicación. En la decodificación ordinaria, la respuesta se produce token a token; cada token necesita su propia pasada hacia adelante que vuelve a leer los pesos del modelo y la caché KV en crecimiento, por lo que el hardware suele estar limitado por el ancho de banda de la memoria. Técnicas como la decodificación especulativa reducen esa brecha sin eliminarla. Anthropic fija el precio de salida en cinco veces el de entrada en todo el catálogo actual, desde Haiku 5.5 hasta Fable 5.1.

¿El almacenamiento en caché de prompts hace que los tokens de salida sean más baratos?

No. El almacenamiento en caché de prompts se aplica solo a la entrada. A fecha de 27 de octubre de 2026, una lectura de caché cuesta 0.1x la tarifa base de entrada en la mayoría de los modelos (0.05x en Opus 5.5 y Sonnet 5.5, 0.025x en Fable 5.1), y las escrituras en caché cuestan 1.25x para la duración de 5 minutos o 2x para la duración de 1 hora. La salida se factura a la tarifa completa en cada llamada, independientemente de lo que haya hecho la caché. Por eso el almacenamiento en caché cambia la estructura de su factura además de su importe: una vez que el lado de la entrada se reduce, la salida se convierte en la parte que merece la pena optimizar.

¿Un max_tokens alto me cuesta dinero si la respuesta es corta?

No. Se le factura por los tokens que el modelo produce realmente, por lo que max_tokens es un límite máximo y no una reserva. Sigue siendo importante, porque es el único límite estricto para una respuesta que se descontrola. Ajústelo un poco por encima del percentil 95 de su output_tokens observado, y luego gestione stop_reason: "max_tokens" en el código en lugar de enviar una respuesta truncada silenciosamente.

¿Cómo calculo mi propia proporción de tokens de entrada frente a salida?

Registre input_tokens, output_tokens, cache_read_input_tokens y cache_creation_input_tokens del objeto usage de cada respuesta, y luego divida los totales a lo largo de una semana. Por encima de 5 de entrada por 1 de salida, su gasto está en el prompt, así que almacene en caché la parte estable y recorte el resto. Por debajo de eso, su gasto está en la respuesta, así que limite su longitud y traslade los pasos que generan la mayor parte de la misma a un modelo más barato o a la Batch API.