El contador se movió. No desapareció.

La generación corre una vez y produce lo que querías. La verificación es opcional, repetible e invisible cuando funciona. Bajo cobro por token, cada chequeo adicional es un costo marginal sin retorno visible, y los costos marginales sin retorno visible son justo donde se asienta la presión de presupuesto. Eso es un argumento sobre incentivos, no un relevamiento de la industria; no tenemos datos de entrevistas y no vamos a fingir que sí. Lo que sí podemos reportar es nuestro propio libro de cuentas. Cuando auditamos nuestro pipeline este trimestre, los chequeos que no estábamos corriendo se agrupaban exactamente donde predice el análisis de incentivos: la segunda opinión, la relectura adversarial, la suite de evals que corría antes de cada release en lugar de en cada commit. Nadie lo decidió en una junta. Se asentó ahí solo.

Los números absolutos enmarcan la decisión. Claude Fable 5 cuesta 10 dólares por millón de tokens de entrada y 50 por millón de salida en la API. Claude Opus 5, anunciado el 24 de julio de 2026, cuesta 5 y 25. El overhead es más chico y más fácil de olvidar: en Opus 5, una solicitud con herramientas carga 286 tokens de system prompt de tool-use con tool_choice en auto o none, 406 con any o tool, y otros 325 tokens de entrada si se adjunta la herramienta bash. Claude Managed Agents cobra 0.08 dólares por hora-sesión encima de las tarifas de tokens de Opus 5. La cuenta nunca fue solo tokens, y un fan-out de llamadas de verificación chicas paga el overhead fijo en cada una.

Cuatro prácticas están más cerca de ese margen. Verificación redundante: el mismo chequeo por dos caminos independientes. Segundas opiniones: otro modelo, con otro corte de entrenamiento y otros modos de falla, revisando el mismo artefacto. Autorrevisión adversarial: el sistema instruido a atacar su propio output en lugar de resumirlo. Evaluación continua: la suite en cada commit en vez de antes de cada lanzamiento. Cada una es barata aislada. Cada una es cara como default, en cada cambio, indefinidamente, y por eso cada una es lo primero que se deja de hacer en silencio.

A partir del 20 de julio de 2026, Anthropic incluyó Claude Fable 5 sin costo adicional en los planes Max, en los asientos Team Premium y en los asientos premium de Enterprise por asiento. El centro de ayuda lo dice sin rodeos: hasta 50 por ciento del límite semanal de uso puede ir a Fable 5 sin costo adicional. No es universal. Pro y los asientos Team Standard quedan excluidos; en esos planes Fable 5 no está incluido en los límites de uso del plan y se paga con créditos de uso. La inclusión nombra específicamente los asientos premium de Enterprise por asiento, no los estándar. Sobre el crédito de transición las fuentes no coinciden: la cuenta oficial @claudeai, citada por Simon Willison el 18 de julio de 2026, dijo que los usuarios excluidos recibirían un crédito único de 100 dólares, y PCWorld reportó la misma cifra; el centro de ayuda de Anthropic solo dice que hay un crédito único y no da el monto.

El cambio tiene fecha, no promesa. El artículo del centro de ayuda da una fecha de inicio, el 20 de julio de 2026, y ninguna fecha de término, y no usa la palabra permanente. Varios medios leyeron la ausencia de fecha de término como permanencia; esa es su inferencia, no el texto de la empresa. Un equipo que planea capacidad sobre un compromiso cuando solo tiene una fecha de inicio está cometiendo un error de pronóstico. Para dimensionar: Max arranca en 100 dólares al mes, Team Premium cuesta 100 dólares por asiento anual o 125 mensual, Pro cuesta 17 anual o 20 mensual, Team Standard 20 o 25. La inclusión sigue a los asientos caros. Tampoco reemplazó la nada: una promoción previa de acceso gratis corrió hasta el 19 de julio de 2026 a las 11:59:59 PM PT, después de la cual Fable 5 siguió disponible bajo los nuevos términos.

Ahora la mecánica. La cifra de 50 por ciento es un tope sobre una porción, no una suma adicional. El centro de ayuda es explícito: usar otros modelos consume del mismo límite de uso y nunca puedes exceder el límite semanal. El bote es compartido: todo lo demás que hace ese asiento gasta de la misma asignación. El cambio te da permiso de meter la mitad del bote por el carril más fuerte; no te da un bote más grande. El artículo describe el cambio del 20 de julio y no dice nada sobre Claude Opus 5, y no encontramos ninguna declaración publicada sobre cómo interactúa con la asignación el modelo que se volvió el default de Max cuatro días después. Por la redacción general, consume del mismo bote, pero esa es nuestra lectura, no una documentada.

Dos vacíos más. Primero, ningún nivel de plan publica valores de límite semanal en ninguna unidad que hayamos encontrado: ni mensajes, ni tokens, ni horas. No puedes presupuestar contra un número que nadie publicó; solo puedes medir tu propio agotamiento. The-decoder reportó que el 50 por ciento aplica sobre límites ya reducidos en cerca de un tercio cuando terminó la fase de bono; no pudimos verificarlo contra una fuente primaria y lo marcamos como su reporte. Segundo, no existe una solicitud de baja intensidad de Fable 5 a la cual recurrir. El pensamiento adaptativo está siempre activo; el tipo de pensamiento deshabilitado no es soportado y el chain-of-thought crudo nunca se devuelve. Y si tus intuiciones de tokens se formaron con modelos más viejos, recalíbralas: Fable 5 usa el tokenizador introducido con Claude Opus 4.7, y la documentación de Anthropic señala que, comparado con modelos anteriores a Opus 4.7, el mismo texto produce cerca de 30 por ciento más tokens.

El 24 de julio de 2026 Anthropic anunció Claude Opus 5 a 5 dólares por millón de tokens de entrada y 25 por millón de salida. Eso es la mitad de la tarifa de Fable 5 y el mismo precio que su antecesor Opus 4.8, así que es un cambio de capacidad, no una rebaja de precio. Anthropic lo posiciona como algo que se acerca a la inteligencia de frontera de Fable 5 a la mitad del precio y lo recomienda como el modelo de arranque por default; se volvió el default en Claude Max y el modelo más fuerte disponible en Claude Pro. La jerarquía no cambia en la cima: Fable 5 sigue siendo, según la propia documentación de Anthropic, su modelo ampliamente disponible más capaz, y Opus 5 sigue por detrás de Claude Mythos 5 en trabajo de ciberseguridad y biología.

Sobre capacidad, cuidado con lo que repites. Ambos lanzamientos presentan sus resultados de benchmark como gráficas y no como tablas de texto, y no pudimos extraer ni una sola cifra absoluta para ninguno de los dos modelos de ninguna fuente que revisamos. Lo que existe es la redacción comparativa del propio Anthropic: que Opus 5 supera a todos los demás modelos en Frontier-Bench v0.1, queda a 0.5 por ciento del puntaje máximo de Fable 5 en CursorBench 3.2 a la mitad del costo, y supera el mejor resultado de Fable 5 en OSWorld 2.0 a poco más de un tercio del costo. Esas son afirmaciones del proveedor sobre posición relativa. Una comparación que no puedes reproducir es una afirmación, no una medición, y la citamos como tal.

El carril medido también trae controles que la superficie de planes no documenta. El esfuerzo se fija por output_config con cinco niveles, de low a max, con default en high en la API de Claude y en Claude Code; el pensamiento no se puede deshabilitar en xhigh ni max, y la documentación de Anthropic señala que en Opus 5 cambiar el esfuerzo no acorta de forma confiable la respuesta visible, así que hay que pedir la extensión directamente en el prompt. El prompt caching pone precio a la redundancia de forma directa: los aciertos y refrescos de caché cuestan 0.50 dólares por millón de tokens de entrada contra una base de 5 dólares, las escrituras de caché de cinco minutos cuestan 6.25, las de una hora 10. La Batch API vuelve a partir la tarifa a la mitad: 2.50 y 12.50. El contexto largo se cobra a tarifa estándar sin recargo arriba de 200k tokens en Claude 4.6 y posteriores, y los fallbacks automáticos salieron como beta de API junto con el lanzamiento. No encontramos nada que documente un juego equivalente de perillas en los asientos de suscripción.

Ponle un solo marco a la semana. El 20 de julio, la verificación con el modelo fuerte se volvió un consumo de cuota en los asientos caros. El 24 de julio, llegó un modelo medido a la mitad de la tarifa de frontera con controles de caché, batch y esfuerzo. Cualquier práctica de verificación soldada a la tarifa de un solo carril necesitó redecidirse en esa misma semana. Una práctica construida sobre una rúbrica, un gate determinista y un carril intercambiable solo necesitó un cambio de configuración.

Antes de que se abra un pull request en nuestro pipeline, un cambio pasa por un verificador determinista y un panel de revisión con varios modelos. El verificador es el gate: build, type check, tests, lint, checks de migración y las propias aserciones del proyecto. Es lo único con permiso para reprobar un cambio. El panel es asesor. Varios carriles de modelo revisan el mismo diff contra la misma rúbrica con el mismo contexto del repositorio, y escriben hallazgos. No hacen merge, no aprueban, y no pueden marcar sus propios criterios de aceptación como verificados.

La señal por la que ruteamos es el desacuerdo. Donde el panel converge, una persona lo hojea. Donde se divide, una persona lo lee con cuidado. Esa es una regla de trabajo, no un hallazgo validado: no hemos medido si las divisiones predicen defectos mejor que el ranking de severidad de un solo revisor, y hasta que publiquemos esos registros de corridas, trata la heurística como nuestra apuesta y no como nuestro recibo. La versión honesta de la economía es parecida. Un panel solo vale la pena correrlo si la redundancia es barata, y barata tiene dos caminos: un carril de suscripción cuya capacidad no está publicada, o un carril medido con precio hecho justo para este tipo de trabajo. Dentro de un mismo carril de modelo, un panel es inusualmente amigable con el caché, porque cada revisor lee el mismo contexto y solo difiere en la rúbrica. Fable 5 conserva el descuento de 90 por ciento en tokens de entrada por prompt caching; la tarifa de acierto de caché de Opus 5 es una décima parte de su precio base de entrada. Si una entrada de caché se puede compartir entre modelos distintos no está documentado, así que presupuesta la escritura de contexto de cada carril por separado, y recuerda que cada revisor de todos modos paga sus propios tokens de salida.

Un contraargumento merece la palabra: puede que los tokens no sean tu restricción vinculante. Cada revisor que agregas produce hallazgos que una persona tiene que triar, y los falsos positivos gastan el recurso más escaso en un equipo chico, que es la atención. Nuestras mitigaciones son topes y cubetas: un techo de revisores por corrida, hallazgos que obligatoriamente cargan un archivo, una línea y un escenario de falla concreto, y todo lo que no tenga una ruta de reproducción se desvía a una cubeta de baja señal que una persona puede ignorar. Si el panel hace la revisión más lenta sin atrapar una clase de defecto que tu gate se pierde, el panel es teatro. Mide eso, no la cuenta de tokens.

Dos precauciones operativas de correr esto. Desactualización: el corte de conocimiento confiable de Fable 5 es enero de 2026, el de Opus 5 es mayo de 2026, y un revisor que va meses atrás en la API de una librería va a marcar con toda confianza código correcto como incorrecto. Elige los carriles de revisión por lo que saben, no solo por lo que cuestan. Rechazos: Fable 5 trae clasificadores de seguridad que pueden declinar una solicitud, y un rechazo llega como un HTTP 200 con stop_reason en refusal; las solicitudes rechazadas antes de producir output no se cobran. Un harness que trata HTTP 200 como éxito va a registrar un rechazo como revisión aprobada. Verifica sobre stop_reason, y cuenta un rechazo como una no-revisión que reduce visiblemente la cobertura.

Una suscripción por asiento no es un acuerdo de nivel de servicio de API, y el historial de este modelo en particular vuelve concreta la diferencia. Entre el 9 de junio y el 20 de julio de 2026, Anthropic revisó el acceso de Fable 5 en los planes al menos cuatro veces: una ventana gratis del 9 al 22 de junio, un cambio a créditos de uso el 7 de julio, una extensión el 12 de julio, y el cambio de inclusión el 20 de julio. Anthropic dijo por qué: la demanda de Fable había sido difícil de predecir, por lo que el acceso se extendió varias veces conforme se aseguraba capacidad adicional. Léelo como un hecho de ingeniería. Los términos del carril son consecuencia de la capacidad, y la capacidad no es un compromiso que tú sostengas.

La disponibilidad tiene un precedente más duro que la deriva de términos. Fable 5 fue sacado de línea a la fuerza el 12 de junio de 2026 por una directiva de control de exportaciones de Estados Unidos. Los controles se levantaron y el modelo volvió globalmente el 1 de julio de 2026. Diecinueve días, durante los cuales ninguna política de reintentos, ninguna configuración de fallback y ningún monto de presupuesto de tu lado habría restaurado ese modelo específico. No fue un rate limit ni una caída. Fue regulación, y un mapa de dependencias que nunca consideró una remoción regulatoria tiene un punto ciego del tamaño de junio de 2026.

Una restricción viaja con el modelo, no con el plan. Fable 5 está designado Covered Model con retención de datos de 30 días y no está disponible bajo un acuerdo de retención cero de datos. Si el contrato de un cliente exige ZDR, Fable 5 queda fuera de la mesa para ese engagement en cualquier carril, suscripción o API. Eso no tiene nada que ver con el precio y no va a aparecer en ninguna revisión de costos, que es justo por qué pertenece a la regla de ruteo y no a la memoria de alguien.

La regla que usamos tiene cuatro condiciones, y el trabajo debe cumplir las cuatro para vivir en un carril de suscripción. Asesor: nada hace merge ni se despacha por su palabra. Reintentable: una corrida fallida simplemente puede volver a correr después. Asíncrono: nadie le está sosteniendo un presupuesto de latencia. Con humano de por medio: una persona acepta o rechaza el output antes de que tenga cualquier efecto. Las condiciones se pegan a cómo corre el trabajo, no a cómo se llama. Un panel de revisión de pull requests corrido como el nuestro, pre-merge pero asesor y con humano de por medio, califica; el mismo panel cableado para bloquear merges no, y una revisión que un cliente está esperando tampoco. La generación de evals, la crítica de specs, el red-teaming, la planeación de migraciones y los borradores de documentación normalmente califican tal como los corremos, pero revisa las condiciones, no la categoría.

El otro lado de la línea es todo lo que el usuario de un cliente espera, todo lo cubierto por un compromiso de soporte, todo lo que tiene un modo de falla visible al cliente, y todo lo gobernado por un término de procesamiento de datos que la suscripción no carga. Eso se queda en la API, donde los controles están documentados y son contractuales: identificadores de modelo fijados, con claude-opus-5 siendo una cadena sin fecha pero un snapshot fijado y no un alias móvil; fallbacks automáticos, lanzados como beta de API; precio de batch para trabajo que tolera latencia; y un costo que aterriza en una factura donde una función de finanzas lo puede ver y cuestionar.

El modo de falla a vigilar no es una mala decisión en la frontera. Es una dependencia no declarada que se cuela cruzándola. Un panel que empieza como un hábito útil se vuelve esperado en un trimestre, y entonces una suscripción por asiento con límites no publicados y términos que se movieron cuatro veces en seis semanas termina sentada en tu ruta de entrega sin que nadie lo haya escrito. El arreglo no tiene nada de glamoroso: declara el carril en el mismo lugar donde declaras tu proveedor de CI, dale un spillover documentado hacia un carril medido con modelo fijado, y obliga a que el spillover se dispare en un calendario para saber que funciona.

¿Qué carril debería alojar el panel por default? No vamos a fingir que este artículo lo resuelve. El precio marginal del carril de suscripción es cero, pero su capacidad no está publicada y sus términos tienen cinco días de vigencia. El carril medido tiene precios publicados, caché, batch y controles de esfuerzo, y Opus 5 movió su economía de forma sustancial el 24 de julio. La comparación depende de tus tamaños de diff, tus tasas de acierto de caché y tu volumen de corridas, nada de lo cual podemos saber por ti. Lo que sí podemos decir es que la regla de cuatro condiciones y el spillover sobreviven cualquiera de las dos respuestas, y una práctica que necesita relitigarse cada vez que se mueve un tarifario nunca fue una práctica.

Empieza por el libro de cuentas. Escribe cada paso de verificación que tu pipeline no corre, y junto a cada uno la razón. Algunas razones van a ser juicio de ingeniería. Otras van a ser una estimación de costo de un tarifario distinto que nadie ha vuelto a revisar. Recalcula cada entrada de demasiado caro contra las tarifas de este artículo antes de aceptarla, porque esas tarifas cambiaron dos veces en la semana previa a la publicación. Esa lista, no una gráfica de benchmark, te dice cuánto vale un carril de verificación barato para tu equipo.

Después construye en el orden correcto. El verificador determinista va primero; es lo que hace seguro correr siquiera un panel asesor, porque un panel que puede bloquear un merge sin un criterio reproducible hace la entrega más lenta y no más correcta. Una vez que el gate es lo único que puede reprobar un cambio, agrega revisores, ponles tope, y trata su desacuerdo como señal de ruteo para la atención humana mientras juntas los registros de corridas que te van a decir si la señal es real.

Trata la cuota como un presupuesto que tienes que descubrir. Los límites semanales no están publicados, así que apréndelos de tu propio lado: registra qué ruteas por el carril, registra cuándo se agota, proyecta el agotamiento a partir del consumo observado, y decide de antemano qué se degrada cuando se acaba la asignación. La degradación debe ser un spillover declarado hacia un carril medido con modelo fijado, visible en el registro de corrida, nunca una caída silenciosa a un solo revisor que nadie nota hasta que un defecto llega a producción.

Y fecha todo. Los términos descritos aquí entraron en vigor el 20 de julio de 2026 y tenían cinco días de vigencia cuando se escribió esto; ya habían cambiado al menos cuatro veces en seis semanas, y el panorama de modelos se volvió a mover el 24 de julio. Reverifica contra las fuentes primarias de abajo antes de que cualquier plan dependa de una afirmación de este artículo. Le exigimos a nuestra propia escritura la misma regla que le exigimos a los hallazgos de un modelo: una afirmación sin fuente verificable es un pasivo, sin importar quién la haya producido.