Tokens de entrada y salida: por qué Claude cobra más

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 pasada por el modelo. Escribir 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 elegido no cambia qué parte de la factura corresponde a la salida. Eso depende de la estructura de la carga de trabajo. Un paso de 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 calculan ambos casos con las tarifas publicadas por Anthropic en 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 distintos. 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 se mantienen ocupadas, por lo que 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 siguiente paso, 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 alto 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 sólo produce un token.

Los sistemas de serving compensan esta limitación mediante 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 resulta viable. El límite vuelve a estar en la memoria. Cada solicitud activa mantiene una KV cache (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 más.

Nada de esto proporciona una cifra exacta, y no debe interpretar 5x como una relación de hardware medida. Es un precio fijado por Anthropic e informado por 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 latencia de entrada y salida

Instale las herramientas en cualquier equipo con 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 de llegada.

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

Ahora invierta el patrón. 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 delta tarda más que con la solicitud breve porque el prefill tiene mucho más texto que leer. Después de recibirlo, 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 que no usa streaming 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 no tiene coste. No es la única parte de la API que no tiene coste, y conviene consultar qué partes de Claude API nunca se facturan antes de presupuestar el 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 por la entrada y $5 por la salida. Opus 5 cobra $5 y $25. Fable 5, el más caro, cobra $10 y $50; conviene leer qué compran esas tarifas de Fable 5 antes de descartar esa fila superior. Al subir de nivel, 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 lados. Todos los ejemplos desarrollados a continuación usan la tarifa de agosto.

Las tarifas cambian, y esta página no es el lugar adecuado para consultarlas. claude.com/pricing es la fuente oficial. Lo que permanece después de un cambio de precio es el método.

Hay una salvedad que la lista de precios no muestra. 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 más reciente, porque el mismo documento contiene más tokens en él. Compare el coste por tarea terminada y cuente sus mensajes reales con el modelo que realmente piensa utilizar. El mismo problema existe entre proveedores, cuyos tokenizadores difieren entre sí incluso más que eso. Por tanto, calcular el coste de un trabajo real en Claude y ChatGPT informa más que colocar las dos tarifas una junto a otra. 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 cuesta 5 veces más que la entrada, el punto de equilibrio es fácil de calcular mentalmente. Llame 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 cada 1 token de salida.

Por tanto, si el prompt es más de cinco veces más largo que la respuesta, la entrada representa el concepto de mayor coste. Por debajo de esa proporción, lo representa 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 lados 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áigala 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.

El factor decisivo resulta evidente al ver la distribución. 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 inútil. dónde se utilizan realmente los tokens de un agente de programación explica qué elementos ocupan ese prompt.

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

Ahora invierta la proporción. Un resumen 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 este importe. Opus 5 cuesta $0.31 por borrador, frente a $0.062 en Haiku 4.5. Esa diferencia de cinco veces procede casi por completo de la salida, que es precisamente donde 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 lo que sirve para generar informes durante la noche y clasificar grandes volúmenes. No sirve para tareas en las que una persona está esperando el resultado.

El enrutamiento entre modelos resulta útil aquí de una forma que no se da 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. elegir entre Opus, Sonnet y Haiku explica dónde se sitúa realmente el umbral de calidad.

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

La caché de prompts almacena un prefijo del prompt en el servidor y cobra una fracción de la tarifa de entrada al 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 escribe el modelo se factura siempre con la tarifa completa de salida, independientemente de cuánta parte del prompt se haya servido desde la caché.

Tome 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 después de una sola lectura. Escribir una caché de 1 hora cuesta 2x, por lo que necesita dos lecturas. los multiplicadores de escritura y lectura, y cuándo la caché deja de ser rentable desarrolla ese cálculo.

Cuatro palancas bajo tu control

1. Configura max_tokens según la longitud p95 de tus respuestas, no según el máximo del modelo.
2. Dirige los pasos verbosos a un modelo más barato.
3. Agrupa todo aquello por lo que nadie esté esperando.
4. Elimina las instrucciones que alargan las respuestas.

max_tokens es un límite estricto. Establecerlo alto no cuesta nada por sí mismo, porque se te factura por los tokens generados y nunca por el límite. Un límite generoso elimina la restricción de una respuesta que se descontrola. Extrae la distribución de output_tokens de tus registros, fija el límite un poco por encima del percentil 95 y gestiona stop_reason: "max_tokens" en el código continuando la respuesta o reintentándola. Una truncación que detectas cuesta menos que una divagación de 4,000 tokens que pagas y descartas. El razonamiento extendido también se incluye en output_tokens, así que fija ese presupuesto con la misma evidencia.

El enrutamiento funciona cuando la parte costosa de un paso es el volumen y no el criterio. Mantén el modelo potente para tomar la decisión y delega la redacción en uno más barato. Mide primero la versión con enrutamiento en tu propio conjunto de evaluación, porque un modelo barato que necesita dos intentos cuesta más que un único intento con uno caro.

El procesamiento por lotes es la única palanca que descuenta el coste de la salida. Un 50% de descuento en ambos lados, 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 "sé exhaustivo" y "explica tu razonamiento" fijan la longitud de salida en todas las llamadas que hagas. Sustitúyelas por la estructura que quieras: "Responde en un máximo de tres frases" o "Devuelve sólo el objeto JSON, sin introducción". 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 el coste de un agente que se ejecuta continuamente cubre el aspecto de la supervisión, y si la API o una suscripción plana resulta más barata para tu patrón de uso conviene resolverlo antes de pasar una semana ajustando un 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ías por consumo. Si ya alcanzas esos límites a mitad de la sesión, lo primero es determinar qué ventana estás esperando, porque a partir de ahí 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 consumo medido. Si la API con consumo medido resulta ser la opción más barata para ese trabajo, bajar a un plan más pequeño o cancelarlo mantiene intacto el mes que ya has pagado, así que cambiar no te cuesta nada. Si el plan con el que comparas Pro es el de ChatGPT y no la API con consumo medido, las dos escalas de suscripción con los precios comparados muestran cuál resulta más barata para trabajos de programación. Si la pregunta se plantea para un equipo y no para un solo desarrollador, ten en cuenta que Claude Enterprise combina una tarifa por puesto con tokens medidos según estas mismas tarifas de API, por lo que todas las palancas de esta página siguen aplicándose a la parte de la factura que se mide por consumo.

FAQ

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

Generarlos requiere mucho más tiempo de acelerador por token. El prompt se procesa en una sola pasada hacia delante sobre todo su contenido, de modo que una sola lectura de los pesos del modelo cubre miles de tokens y el hardware está limitado por el rendimiento de las multiplicaciones. La respuesta se genera un token cada vez. Cada token requiere su propia pasada hacia delante, que vuelve a leer todos los pesos del modelo, por lo que 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 su 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 caché cuesta 0.1x de la tarifa base de entrada. Las escrituras en caché cuestan 1.25x para una duración de 5 minutos o 2x para una 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 la 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 conviene optimizar.

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

No. Se le cobran 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. Establezca max_tokens un poco por encima del percentil 95 de su output_tokens observado y gestione 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?

Registre input_tokens, output_tokens, cache_read_input_tokens y cache_creation_input_tokens del objeto usage de cada respuesta y divida los totales correspondientes a una semana. Por encima de 5 tokens de entrada por cada token de salida, el coste está en el prompt: almacene en caché la parte estable y reduzca el resto. Por debajo de esa proporción, el coste está en la respuesta: limite su longitud y traslade los pasos que generan la mayor parte de ella a un modelo más barato o a la Batch API.