Claude Fable 5.2 creó un shooter para navegador en 8 horas por unos $550

Dejar que una IA construya un prototipo durante la noche resulta tentador, hasta que llega la factura por la mañana. La historia del shooter para navegador Saltline muestra qué conviene vigilar de antemano: el agente necesita recibir muchas veces el contexto de la tarea, y ese flujo de entrada puede costar más que el código que escribe. Para un equipo que experimenta con el desarrollo autónomo, es una partida presupuestaria muy concreta.

Según Felix Rieseberg, ingeniero de Anthropic, Claude Fable 5.2 creó Saltline en unas ocho horas a partir de una única instrucción inicial, sin comentarios humanos durante el proceso. El coste declarado a las tarifas de la API es de unos $550. El autor también indicó aproximadamente 2,7 millones de tokens de salida y 445 millones de entrada, una parte considerable de los cuales pasó por la caché. El mensaje original incluye enlaces a la publicación del autor y al juego; no disponemos de un desglose detallado y verificado de los gastos.

Qué se consiguió en ocho horas

Saltline es un shooter en primera persona para navegador con una sola misión. Según la descripción del experimento, el modelo creó el código, los modelos, los sonidos y las texturas. Es un ejemplo interesante de una tarea que exige coordinar varios componentes: los gráficos, los controles, la mecánica de juego y el sonido deben funcionar juntos.

El titular «Call of Duty por $550» genera expectativas demasiado amplias. Una sola misión no permite calcular el coste de un juego de gran escala con campaña, modos multijugador, compatibilidad con distintos dispositivos y pruebas exhaustivas. Resulta más útil entender el experimento como un intento de obtener un prototipo de juego de alcance limitado en una única ejecución prolongada.

Un matiz más: una sola instrucción no equivale a una sola respuesta del modelo. Incluso sin comentarios humanos, el agente puede realizar muchos pasos, invocar herramientas, recibir resultados y seguir trabajando. Las cifras facilitadas no permiten saber qué comprobaciones se hicieron en esta ejecución. Por eso, antes de trasladar el resultado a un proyecto propio, conviene hacer una pequeña prueba.

Por qué hubo 165 veces más tokens de entrada que de salida

Imaginemos que el agente añade una puerta al juego. Recibe la tarea y el código pertinente. Tras modificarlo, recibe el resultado de una herramienta y después corrige un error o pasa al siguiente objeto. La siguiente solicitud vuelve a incluir parte del material anterior junto con datos nuevos. A lo largo de una sesión extensa, el volumen de entrada facturado se acumula.

Dividir 445 millones entre 2,7 millones da aproximadamente 165 tokens de entrada por cada token de salida. Es la proporción entre los volúmenes totales de la ejecución. No demuestra que el modelo recibiera el proyecto completo en cada paso ni que el contexto creciera continuamente: para llegar a esa conclusión haría falta un registro de las solicitudes.

La caché permite procesar a menor coste la parte repetida de la entrada. Eso no proporciona al modelo una memoria automática a largo plazo: el desarrollador sigue teniendo que gestionar qué materiales se incluyen en cada solicitud. La utilidad práctica de la caché es especialmente evidente cuando el agente trabaja muchas veces con las mismas instrucciones y grandes fragmentos de contexto.

Qué se puede calcular realmente

Anthropic indica para Fable 5.2 unas tarifas base de $8 por millón de tokens de entrada y $40 por millón de tokens de salida. Con esas tarifas, 2,7 millones de tokens de salida cuestan $108. Si los 445 millones de tokens de entrada se facturaran íntegramente a la tarifa base, sumarían otros $3560. El total sería de $3668, unas 6,7 veces los $550 declarados.

Pero este es un cálculo hipotético sin caché, no una reconstrucción de la factura del experimento. Si aceptamos el importe total de $550 y el coste de salida de $108, quedan unos $442 para la entrada, es decir, una media aproximada de $0,99 por millón de tokens. No se puede deducir la tasa exacta de aciertos de caché sin un desglose de las lecturas, las escrituras y las tarifas aplicadas.

Antes de una ejecución así, conviene que el desarrollador active el seguimiento de estas categorías de gasto y establezca un límite monetario. El responsable de producto debe definir de antemano los criterios de finalización: si la misión se inicia, si se puede completar y en qué dispositivos funciona. Para el fundador, el siguiente paso útil es repetir varias veces una tarea de alcance limitado y comparar el coste de un resultado aceptado. Una ejecución exitosa demuestra que es posible; el presupuesto de un producto también exige previsibilidad.