Portal by Spotify cortó el consumo de tokens de Claude Code un 90%: el contexto era el sumidero

El blog de ingeniería de Spotify publica que su plugin shunt para Claude Code, apoyado en Portal, redujo ~90% el consumo de tokens en lecturas masivas. La medición compara los tokens que Claude gastaría leyendo archivos directo con los de consumir el resumen del modelo trabajador. El modelo principal no se tocó. Se tocó qué entra en su contexto.

Claude se queda con lo que necesita para decidir. El corpus, no.

El sumidero era el contexto

Si dejas a Claude Code suelto en un monorepo, lee. cat, head, tail, less, more. Cada archivo grande que entra en su ventana son tokens de entrada del modelo caro, antes de haber escrito una línea útil.

VentureBeat, el 17 de junio de 2026, recogió un síntoma parecido en otro producto. Un revisor de PCWorld agotó el 80% de su asignación semanal de Claude Pro en unos 25 minutos con Claude Design, en el lanzamiento de abril de 2026, y solo produjo tres variaciones de una web. Distinta herramienta. Misma quema de contexto.

Bajar el precio por token no arregla un contexto gordo. El coste del trabajo terminado no es la tarifa de catálogo: un tokenizador más goloso o un pensamiento encendido por defecto te dejan peor factura con el euro más bonito. Shunt no cambia de modelo. Cambia qué tokens existen.

Portal corre el trabajador y lo mata al terminar

Portal trata un modo de AiKA como un agente declarativo en un runtime efímero. El post lo compara con AWS Lambda para agentes. Tú declaras instrucciones, modelo, parámetros y herramientas MCP. Portal gestiona el resto, sin infraestructura y sin claves API. Se invoca por CLI o por API, público o privado.

En los ejemplos aparecen dos modos. bulk-reader hace la lectura masiva para analizar. code-writer saca código predecible, tests y stubs. Ambos corren con Gemini 2.5 Flash en esos ejemplos; el campo de modelo acepta cualquiera configurado en la instancia de Portal.

Cada delegación es de un solo uso. Nada se guarda en el servidor. Los archivos van al trabajador y no entran en el contexto de Claude. Un seguimiento puede reenviar el mismo corpus sin volver a pagarlo en el modelo caro.

El fichero bruto no entra en Claude. Entra un resumen. El hilo no reabre la lectura.

Un primo de ese aislamiento aparece cuando el código generado por agentes se deja crecer: un módulo de acceso a datos de 17.155 líneas, duplicación masiva de HTTP y JSON, y el mismo prompt representativo pasando de ~159k a ~27k tokens de entrada tras refactorizar. Menos basura en contexto, menos factura en el siguiente cambio. Shunt aplica la tijera antes: el sucio ni llega.

El modo code-write lleva la misma lógica a la escritura. Envía una spec y un archivo de referencia obligatorio al code-writer, quita las vallas markdown y puede escribir directo a disco. Claude no ve el código generado. La referencia es obligatoria para que el worker imite los patrones del proyecto. Orquestación por artefactos, no un chat donde el modelo caro se traga el diff.

El hook que CLAUDE.md no podía ser

La primera versión del enrutado eran reglas en CLAUDE.md. Consultivas. Claude podía ignorarlas. Cada proyecto necesitaba su copia.

shunt las sustituye aplicando el enrutado con hooks contra el registro de acciones del Portal CLI. El hook check-bash-read intercepta cat, head, tail, less y more sobre archivos grandes. Los comandos canalizados (cat file | grep) pasan porque son lecturas dirigidas.

Así va la lectura masiva:

1. Claude Code lanza cat, head, tail, less o more sobre un archivo grande.
2. El hook check-bash-read lo intercepta.
3. shunt delega al modo bulk-reader de Portal.
4. El worker lee el corpus y devuelve un resumen.
5. Claude consume ese resumen. El fichero bruto no ha entrado.

Un aviso no frena el "ya que está, que lo lea". Un hook que corta el cat convierte el recorte de contexto en el camino por defecto.

El 90% y lo que el banco no ve

El benchmark se hizo contra un monorepo Java en cuatro escenarios. El ahorro medio de bulk-read fue ~90%.

El escenario code-write, dice el propio post, es más difícil de medir en tokens: sin shunt, Claude lee las referencias y genera el código como tokens de salida caros. No hay cifra de ahorro para esa pata. Quien publique un porcentaje se lo está inventando.

En las fuentes consultadas no consta ninguna medición de precisión ni de calidad del código generado. El 90% habla de tokens de lectura. No dice si el test compila o si el worker ha copiado un antipatrón con más estilo.

Hacker News dejó el post en 81 puntos y 39 comentarios, con recepción escéptica. Varios comentaristas lo tildaron de implementación estándar de subagentes o multi-modelo. No hace falta que sea una innovación radical para que el dato de bulk-read aguante. El recorte de tokens y la calidad del output son preguntas distintas, y el post solo responde la primera.

VentureBeat enseña la quema. El blog de Spotify enseña un recorte medido en un banco concreto. Hacker News enseña que el banco no es un veredicto. Las tres piezas caben juntas. Convertir el 90% en "Claude Code ahora cuesta un 90% menos" no cabe.

El peaje de 10 a 30 segundos

Cada delegación es un round-trip de red: Claude Code, backend de Portal, modelo worker. Típicamente 10-30 segundos. Portal limita cada invocación a 30 segundos, así que las generaciones muy grandes hay que partirlas en llamadas menores.

Para una lectura pequeña ese peaje es contraproducente. El 90% vive en lecturas masivas, en un monorepo Java, en cuatro escenarios. Fuera de ese recuadro el número no viaja.

En las fuentes consultadas no consta el autor del post, ni que shunt sea una política oficial de Spotify, ni cifras de adopción interna.

Si copias algo, copia el criterio. Claude orquesta. El worker lee y, en code-write, escribe a disco. El corpus no vuelve al modelo caro. El 90% es el premio de ese diseño en un banco de pruebas concreto. El resto, a cronometrarlo y a mirar el diff.