Tokens de entrada y salida: 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 es la estructura del cálculo. Leer un prompt requiere una sola pasada por el modelo. Generar una respuesta requiere una pasada por token, y cada pasada debe esperar a que termine la anterior.

Esa 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 estructura de su carga de trabajo. Un paso de agente que lee 60,000 tokens y responde con 800 gasta muy poco en salida. Un trabajo de redacción que lee 2,000 tokens y genera 12,000 gasta muy poco en entrada. A continuación se calculan ambos casos con las tarifas publicadas por Anthropic para agosto de 2026.

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

Un servidor de inferencia procesa una solicitud en dos fases con costes muy diferentes. El prellenado lee el prompt. La decodificación genera la respuesta.

El prellenado procesa todo el prompt de una vez. Todos los tokens del prompt entran en la red en la misma pasada hacia delante, por lo que el trabajo de atención y de las capas feed-forward se convierte en un número reducido de multiplicaciones de matrices grandes que abarcan miles de tokens cada 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 prellenado está limitado por el cómputo: el límite es la velocidad a la que el chip puede multiplicar.

La decodificación no puede funcionar así, porque el token 2 depende del token 1. El token que el modelo acaba de generar 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 propia pasada hacia delante, y cada una de esas pasadas lee el conjunto completo de pesos del modelo desde la memoria de gran ancho de banda para producir un solo token. Por eso la decodificación está limitada 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 la decodificación, el mismo tráfico de pesos que procesó un prompt completo durante el prellenado permite generar un token.

Los sistemas de serving compensan esta limitación mediante el batching. Muchas solicitudes se decodifican juntas, de modo que una lectura de los pesos produce un token para cada solicitud del batch. Por eso la decodificación es viable. El límite vuelve a estar en la memoria. Cada solicitud en curso mantiene una caché KV (caché de clave/valor, el estado de atención almacenado para cada token generado hasta ese momento). Esa 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 establecido por Anthropic a partir de esa asimetría. Lo que sí puede comprobar por su cuenta es la dirección de la diferencia, y hacerlo lleva aproximadamente un minuto.

Mida usted mismo la diferencia entre entrada y salida

Instale las herramientas en cualquier equipo Ubuntu:

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

Ahora transmita una solicitud breve que pida una respuesta larga y añada a cada línea la hora en 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 el inicio del comando. Hay dos datos importantes en esa salida. La primera línea content_block_delta indica el tiempo hasta el primer token, y todo el prellenado se completó dentro de ella. Cada línea posterior corresponde a un pequeño paso de decodificación, y las marcas de tiempo siguen aumentando hasta que llega message_stop.

Ahora invierta la forma. Incluya un documento largo en la solicitud 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 intervalo tarda más que con la solicitud breve porque el prellenado 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 funcionó durante todo el proceso.

Toda respuesta que no se transmite termina con los números que determinan 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 a la tarifa de salida. Para calcular el precio de una solicitud antes de enviarla, POST /v1/messages/count_tokens acepta el mismo cuerpo de solicitud, devuelve {"input_tokens": N} sin ejecutar el modelo y es gratuito.

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 por la entrada y $5 por la salida. Opus 5 cobra $5 y $25. Fable 5, el modelo más caro, cobra $10 y $50; conviene leer qué ofrecen esas tarifas de Fable 5 antes de descartar esa fila superior. Al subir en la gama, ambos lados 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 por la entrada y $10 por la salida. Desde el 1 de septiembre de 2026 se aplica la tarifa estándar de $3 y $15, 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 aunque cambien los precios es el método.

La lista de precios no muestra un detalle importante. La documentación de Anthropic indica que Claude 4.7 y los modelos posteriores usan 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 versiones anteriores. Comparar dos modelos sólo por el precio por millón de tokens favorece al modelo 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é representa un millón de tokens de Claude en texto real explica cómo se ve ese volumen en la práctica.

¿Cuándo empieza a dominar la salida tu factura?

Si la salida cuesta 5 veces más que la entrada, el punto de equilibrio es fácil de calcular mentalmente. Llama I a tus tokens de entrada y O a tus 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. Esto equivale a una proporción de 5 tokens de entrada por 1 token de salida.

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

[
  {
    "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 el único trabajo 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 error de redondeo. La mayoría de las personas calcula mal su propia proporción, así que extráela de tus registros antes de optimizar nada.

Carga de trabajo de un agente: mucho contexto de entrada y una respuesta breve

Ejecute 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 proceso 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 diferencia es evidente cuando se separan ambos componentes. Reducir la respuesta de 800 tokens a 400 ahorra aproximadamente un 3% del coste de la llamada. Eliminar del prompt 20,000 tokens de contexto obsoleto ahorra aproximadamente un tercio. Ajustar la longitud de salida en un agente con mucha lectura supone un esfuerzo casi desperdiciado. dónde se usan realmente los tokens de un agente de programación desglosa qué ocupa ese prompt en primer lugar.

Una carga de generación: prompt corto y borrador largo

Ahora invierta la proporción. Un resumen de 2,000 tokens, un borrador de 12,000 tokens y 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 (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 este importe. Opus 5 cuesta $0.31 por borrador, frente a $0.062 con Haiku 4.5. Esa diferencia de cinco veces procede casi por completo de la salida. Es precisamente donde un modelo más barato permite ahorrar más.

La última columna muestra el mismo trabajo mediante la Batch API, que reduce un 50% los costes de entrada y 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 lo que sirve para generar informes durante la noche y para la clasificación masiva. No sirve para tareas en las que una persona está esperando el resultado.

El enrutamiento entre modelos resulta útil en este caso, a diferencia de lo que ocurre en el paso del agente. Si la parte extensa del trabajo es mecánica, como reformatear texto o ampliar un esquema que ya ha aprobado, el modelo barato genera esos tokens por una quinta parte del precio. cómo elegir entre Opus, Sonnet y Haiku explica dónde se sitúa realmente el límite de calidad.

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

La caché de prompts almacena un prefijo de tu 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 forma parte de ese acuerdo. No existe una salida almacenada en caché. Cada token que genera el modelo se factura siempre con la tarifa completa de salida, independientemente de cuánto del prompt se haya recuperado como una coincidencia de caché.

Toma 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 distribución. La salida representaba el 6.25% de esa llamada. Ahora representa más de una cuarta parte, por 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 después de una sola lectura coincidente. Escribir una caché de 1 hora cuesta 2x, por lo que necesita dos. los multiplicadores de escritura y lectura, y cuándo deja de ser rentable usar la caché desarrolla ese cálculo.

Cuatro palancas que puede controlar

1. Establezca max_tokens en la longitud de salida p95, 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 esté esperando.
4. Elimine las instrucciones que alargan las respuestas.

max_tokens es un límite estricto. Establecerlo alto no tiene ningún coste por sí mismo, porque se le factura por los tokens generados y nunca por el límite. Lo que hace un límite generoso es eliminar la restricción de una respuesta que se descontrola. 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. Una truncación que detecta cuesta menos que una divagación de 4,000 tokens que paga y descarta. El razonamiento extendido también se incluye en output_tokens, por lo que debe establecer ese presupuesto a partir de la misma información.

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

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

La última palanca es la que más se omite. 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 desea: "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 lo que cuestan esos mismos 300 tokens en el prompt. mantener bajo control los costes de un agente que se ejecuta continuamente 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.

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. Un prompt se procesa en un único paso forward 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. Una respuesta se genera un token cada vez. Cada token requiere su propio paso forward, que vuelve a leer todos los pesos del modelo. Por eso, en este caso, el hardware está limitado por el ancho de banda de memoria. Anthropic aplica a la salida un precio cinco veces superior al de la entrada en todo el catálogo actual, desde Haiku 4.5 hasta Fable 5.

¿El almacenamiento en caché del prompt reduce el precio de los tokens de salida?

No. El almacenamiento en caché del prompt sólo se aplica a la entrada. En agosto de 2026, una lectura de caché cuesta 0.1x de la tarifa base de entrada. Las escrituras en 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 como el importe de la factura: cuando el coste de entrada se reduce casi por completo, la salida se convierte en la parte que más conviene optimizar.

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

No. Se te factura por los tokens que el modelo produce realmente, por lo que max_tokens es un límite máximo y no una reserva. Aun así, es importante porque es el único límite estricto para una respuesta que se alarga sin control. Configúralo 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 entre tokens de entrada y de 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 de una semana. Si superas una proporción de 5 tokens de entrada por 1 de salida, el coste está en el prompt. Almacena en caché la parte estable y recorta el resto. Si la proporción es inferior, 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.