Tokens de entrada y salida: el coste de Claude

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

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

La proporción es la misma en todas las filas 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 determina la forma de su carga de trabajo. Un paso de un agente que lee 60,000 tokens y responde con 800 apenas genera costes de salida. Un trabajo de redacción que lee 2,000 tokens y escribe 12,000 apenas genera costes de entrada. A continuación se analizan ambos casos con las tarifas publicadas por Anthropic en agosto de 2026.

El prefill se ejecuta una vez y el decoding una vez por token

Un servidor de inferencia procesa una solicitud en dos fases con costes muy diferentes. El prefill lee el prompt. El decoding genera la respuesta.

El prefill procesa todo el prompt de una vez. Todos los tokens del prompt entran en la red en el mismo paso forward, por lo que el trabajo de atención y feed-forward se convierte en un número reducido de multiplicaciones de matrices grandes que cubren miles de tokens a la vez. Una lectura de los pesos del modelo desde la memoria sirve para procesar todo el prompt. Las unidades matriciales del acelerador permanecen ocupadas. Por eso el prefill está limitado por el cómputo: el límite es la velocidad con la que el chip puede multiplicar.

El decoding no puede funcionar así porque el token 2 depende del token 1. El token que acaba de producir el modelo pasa a formar parte de la entrada del paso siguiente, por lo que los pasos no pueden ejecutarse al mismo tiempo. Cada token de salida requiere su propio paso forward, y cada uno de esos pasos lee el conjunto completo de pesos del modelo desde la memoria de gran ancho de banda para producir un solo token. Por eso el decoding está limitado por la memoria: el límite es la velocidad a la que se pueden mover los pesos, no la velocidad a la que se pueden multiplicar. Durante el decoding, el mismo tráfico de pesos que procesó un prompt completo durante el prefill produce un solo token.

Los sistemas de serving compensan esta limitación mediante batching. Muchas solicitudes ejecutan el decoding juntas, de modo que una lectura de los pesos produce un token para cada solicitud del batch. Por eso el decoding sigue siendo viable. El límite vuelve a estar en la memoria. Cada solicitud en curso mantiene una KV cache (key/value cache, el estado de atención almacenado para cada token generado hasta ese momento). Esta caché crece con cada token generado y, cuando llena el acelerador, el batch ya no puede crecer.

Nada de esto proporciona una cifra exacta, y no debe interpretar 5x como una proporción de hardware medida. Es un precio fijado por Anthropic a partir de esta asimetría. Lo que sí puede comprobar por su cuenta es la dirección de la diferencia, y hacerlo lleva aproximadamente un minuto.

Mida por su cuenta la brecha entre entrada y salida

Instale las herramientas en cualquier equipo Ubuntu:

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

Ahora transmita un prompt corto que solicite una respuesta larga y añada a cada línea la hora a la que llegó.

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 datos que conviene extraer de esa salida. La primera línea content_block_delta indica el tiempo hasta el primer token, y todo el prefill ocurrió dentro de ella. Cada línea posterior corresponde a un pequeño paso de decoding, y las marcas de tiempo siguen aumentando hasta que llega message_stop.

Ahora invierta la forma. Incluya 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 debe leer mucho más texto. Cuando llega, la respuesta termina casi de inmediato porque sólo quedan unos pocos tokens por decodificar. Entraron decenas de miles de tokens y el reloj apenas avanzó. Salieron unos cientos y el reloj estuvo funcionando durante todo el proceso.

Toda respuesta sin streaming termina con los números que se utilizan para calcular la facturación.

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

Registre los cuatro campos de cada solicitud. output_tokens incluye el razonamiento extendido, por lo que un modelo que razona antes de responder factura ese razonamiento con la tarifa de salida. Para calcular el precio de un prompt antes de enviarlo, POST /v1/messages/count_tokens acepta el mismo cuerpo de solicitud, devuelve {"input_tokens": N} sin ejecutar el modelo y no tiene coste. No es la única parte de la API que no tiene coste; conviene consultar qué partes de la API de Claude nunca se facturan antes de preparar el presupuesto del primer proyecto.

Qué cobra Claude por millón de tokens en agosto de 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "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 todas las filas. Haiku 4.5 cobra 1 USD por la entrada y 5 USD por la salida. Opus 5 cobra 5 USD y 25 USD. Fable 5, el más caro, cobra 10 USD y 50 USD, y conviene leer qué ofrecen esas tarifas de Fable 5 antes de descartar esa primera fila. Al subir en la gama, ambos importes se multiplican por el mismo factor. Por tanto, cambia el total, pero mantiene exactamente la misma proporción entre entrada y salida.

Sonnet 5 aparece dos veces porque su tarifa introductoria caduca. Hasta el 31 de agosto de 2026 cobra 2 USD por la entrada y 10 USD por la salida. Desde el 1 de septiembre de 2026 se aplica la tarifa estándar de 3 USD y 15 USD, un 50% más en ambos casos. Todos los ejemplos desarrollados a continuación usan la tarifa de agosto.

Las tarifas cambian, y esta página no es el lugar donde debe consultarlas. claude.com/pricing es la fuente oficial. Lo que permanece cuando cambia el precio es el método.

Hay una salvedad que no muestra la lista de precios. La documentación de Anthropic indica que los modelos Claude 4.7 y posteriores usan un tokenizador más reciente que genera aproximadamente un 30% más de tokens para el mismo texto que el tokenizador de Sonnet 4.6 y anteriores. Comparar dos modelos sólo por el precio por millón de tokens favorece al más reciente, porque el mismo documento contiene más tokens en él. Compare el coste por tarea terminada y cuente sus prompts reales con el modelo que realmente piensa utilizar. qué valor tiene un millón de tokens de Claude en texto real explica cómo se ve ese volumen en la práctica.

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

Si la salida tiene un precio 5 veces superior al de la entrada, el punto de equilibrio es fácil de calcular mentalmente. Denominemos 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 corresponde a una proporción de 5 tokens de entrada por cada 1 token de salida.

Por tanto, si tu prompt es más de cinco veces más largo que la respuesta, la entrada representa la partida de mayor coste. 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, ambos costes son iguales. Con una proporción de 1 a 6, la salida representa el 96.8% y el coste del prompt es un error de redondeo. La mayoría de las personas calcula mal su propia proporción, así que extráela de los registros antes de optimizar nada.

Una carga de trabajo de agente: mucho contexto de entrada y 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, algo 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 (Aug)",
    "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 con la tarifa de agosto y $0.064 en Haiku 4.5. Doscientos de esos pasos al día en Opus 5 cuestan $64 al día.

La medida es evidente cuando se observa el desglose. Reducir la respuesta de 800 tokens a 400 ahorra aproximadamente el 3% de la llamada. Eliminar 20,000 tokens de contexto obsoleto del prompt ahorra aproximadamente un tercio de su coste. Ajustar la longitud de salida en un agente que lee mucho supone un esfuerzo casi inútil. en qué se emplean realmente los tokens de un agente de programación desglosa qué contiene ese prompt.

Una tarea de generación: solicitud breve y borrador extenso

Ahora invierta la proporción. Una especificación de 2,000 tokens, un borrador de 12,000 tokens y una proporció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 (Aug)",
    "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 con Haiku 4.5. Esta diferencia de cinco veces se debe casi por completo a la salida. Por eso un modelo más barato permite ahorrar más.

La última columna muestra el mismo trabajo mediante Batch API, que reduce un 50% el coste de entrada y de salida. Opus 5 baja a $0.155 por borrador. Batch devuelve los resultados en un plazo de 24 horas en lugar de hacerlo de inmediato. Por tanto, encaja con la generación nocturna de informes y la clasificación masiva. No es adecuado para tareas en las que una persona está esperando el resultado.

El enrutamiento entre modelos resulta útil en este caso, algo que no ocurre en el paso del agente. Si la parte extensa de la tarea es mecánica, como reformatear texto o ampliar un esquema que ya aprobó, el modelo barato genera esos tokens a una quinta parte del precio. cómo elegir entre Opus, Sonnet y Haiku explica dónde se encuentra realmente el umbral de calidad.

La caché reduce el coste de entrada, y sólo de entrada

La caché de prompts almacena un prefijo del prompt en el servidor y cobra una fracción de la tarifa de entrada para volver a leerlo. En agosto 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 para leer una coincidencia.

La salida no entra en ese acuerdo. No existe una salida en caché. Cada token que escribe el modelo se factura siempre con la tarifa completa de salida, independientemente de cuánto del prompt se haya recuperado mediante una coincidencia de caché.

Considere el mismo paso del 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 cambia: $0.02 antes y $0.02 después. La caché reduce la factura y cambia su composición. La salida representaba el 6.25% de esa llamada. Ahora representa más de una cuarta parte, lo que cambia qué palanca conviene ajustar a continuación.

La primera llamada paga la escritura. Escribir una caché de 5 minutos cuesta 1.25x la entrada base, por lo que se amortiza tras una sola coincidencia. Escribir una caché de 1 hora cuesta 2x, por lo que necesita dos coincidencias. los multiplicadores de escritura y lectura, y cuándo la caché deja de ser rentable desarrolla ese cálculo.

Cuatro palancas que puede controlar

1. Configure max_tokens en la longitud de salida del percentil 95, no en el máximo del modelo.
2. Encamine los pasos verbosos a un modelo más barato.
3. Procese por lotes todo aquello que no requiera que alguien espere.
4. Elimine las instrucciones que alargan las respuestas.

max_tokens es un límite estricto. Establecerlo alto no cuesta nada por sí mismo, porque se le factura por los tokens producidos, nunca por el límite. Un límite generoso elimina la restricción de una respuesta que se desvía. Extraiga la distribución de output_tokens de sus registros, establezca el límite un poco por encima del percentil 95 y gestione stop_reason: "max_tokens" en el código continuando la respuesta o reintentando. Detectar una truncación cuesta menos que pagar y descartar un monólogo de 4,000 tokens. El razonamiento extendido también se incluye en output_tokens, así que establezca ese presupuesto a partir de la misma evidencia.

El enrutamiento funciona cuando la parte costosa de un paso es el volumen y no el criterio. Mantenga el modelo más potente para la decisión y delegue la escritura a uno más barato. Mida primero la versión con enrutamiento en su propio conjunto de evaluación, porque un modelo barato que necesita dos intentos cuesta más que un intento con un modelo caro.

El procesamiento por lotes es la única palanca que aplica un descuento a la salida. Un descuento del 50% en ambos lados, resultados en un plazo de 24 horas y cualquier tarea programada cumplen los requisitos.

La última palanca es la que muchas personas omiten. Frases como "sea exhaustivo" y "explique su razonamiento" establecen la longitud de salida en todas las llamadas que hará. Sustitúyalas por la estructura que necesita: "Responda en un máximo de tres frases" o "Devuelva sólo el objeto JSON, sin introducción". Un prompt de 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 aborda la supervisión, y conviene resolver si la API o una suscripción plana es más barata para su patrón de uso antes de dedicar una semana a ajustar el gasto por token que una suscripción habría absorbido. Para un desarrollador, esto depende sobre todo de si los $20 al mes de Claude Pro y sus límites de uso cubren el trabajo que, de otro modo, mediría. Si ya alcanza esos límites a mitad de una sesión, lo primero es determinar qué ventana está esperando; después, la solución puede ser un modelo más pequeño, un contexto más ligero, créditos de uso adicionales o trasladar ese trabajo a la API con facturación por uso. Si la API con facturación por uso resulta ser la opción más barata para ese trabajo, cambiar a un plan más pequeño o cancelarlo mantiene intacto el mes que ya ha pagado, por lo que el cambio no le cuesta nada. Si el plan con el que está comparando Pro es el de ChatGPT y no la API con facturación por uso, las dos escalas de suscripción con los precios lado a lado muestran cuál resulta más barata para tareas de programación. Si la pregunta se plantea para un equipo y no para un solo desarrollador, tenga en cuenta que Claude Enterprise combina una tarifa por puesto con tokens medidos según estas mismas tarifas de la API, por lo que todas las palancas de esta página siguen aplicándose a la parte de la factura que se mide por uso.

FAQ

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

Generarlos requiere mucho más tiempo del acelerador por token. El prompt se procesa en un solo paso hacia delante sobre todo su contenido, por lo que una sola lectura de los pesos del modelo cubre miles de tokens y el hardware está limitado por el rendimiento de las operaciones de multiplicación. La respuesta se genera un token cada vez. Cada token requiere su propio paso hacia delante, que vuelve a leer todos los pesos del modelo. Por eso, el hardware está limitado por el ancho de banda de memoria. Anthropic cobra cinco veces más por la salida que por la entrada en todo el catálogo actual, desde Haiku 4.5 hasta Fable 5.

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

No. El almacenamiento en caché del prompt sólo se aplica a la entrada. En agosto de 2026, una lectura de la caché cuesta 0.1x la tarifa base de entrada, y las escrituras en la caché cuestan 1.25x durante 5 minutos o 2x durante 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 tanto la estructura de la factura como su importe: cuando el coste de entrada se reduce, la salida se convierte en la parte que conviene optimizar.

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

No. Se te facturan los tokens que el modelo produce realmente. Por tanto, max_tokens es un límite máximo, no una reserva. Aun así, importa porque es el único límite estricto para una respuesta que se alarga sin control. Establécelo un poco por encima del percentil 95 de tu output_tokens observado y gestiona stop_reason: "max_tokens" en el código, en lugar de enviar una respuesta truncada sin indicarlo.

¿Cómo puedo calcular mi propia proporción de tokens de entrada y salida?

Registra input_tokens, output_tokens, cache_read_input_tokens y cache_creation_input_tokens del objeto usage de cada respuesta y divide los totales obtenidos durante una semana. Si superas una proporción de 5 tokens de entrada por cada token de salida, el coste está en el prompt. Almacena en caché la parte estable y reduce el resto. Si estás por debajo de esa proporción, el coste está en la respuesta. Limita su longitud y traslada los pasos que generan la mayor parte de ella a un modelo más barato o a la Batch API.