Prueba flujos de reducción de tokens de Claude Code en TypeScript
Realiza una auditoría repetible de costo, latencia y modos de fallo antes de que un modelo worker más barato de Claude Code se convierta en el predeterminado del equipo.

La demo no es tu repositorio
Tu equipo está mirando una factura de Claude Code y un modelo worker más barato que podría reducir el gasto en tokens. No lo hagas predeterminado hasta que tu repositorio de TypeScript haya pasado por una auditoría acotada. Se proyecta que los costos de codificación con IA superarán el salario promedio de un desarrollador para 2028. Una cuarta parte de los líderes de ingeniería ya pagan $200 a $500 por desarrollador al mes en tokens, y algunos superan los $2,000.
Los ejemplos utilizaron Gemini 2.5 Flash como modelo worker, aunque el campo de modelo de Portal puede aceptar otros modelos configurados. El plugin shunt impide que Claude lea un archivo cuando su longitud supera un umbral ajustable por el usuario, fijado en 350 líneas a menos que se modifique. Ejecuta esas mecánicas en tu repositorio de TypeScript antes de hacerlo predeterminado.
El modo de fallo es la otra mitad de la factura. El modelo worker no detectó un defecto de seguridad de hilos, mientras que Claude lo encontró en segundos tras recibir el contexto relevante. Si la ruta barata ahorra tokens y luego publica ese defecto, el ahorro se convierte en un problema que es tuyo.
Ejecuta la auditoría en un orden repetible
- Establece la línea base de uso de tokens, latencia y costo de Claude Code para un ciclo de trabajo normal en tu repositorio de TypeScript. Registra la línea base en una hoja de cálculo con fecha, tipo de tarea, modelo, tokens, dólares y tiempo real. Incluye sesiones interactivas y ejecuciones por lotes, porque un flujo de ahorro de tokens puede verse bien en algunos modos y mal en otros. No optimices un número que no puedes ver.
- Reproduce el enrutamiento del modelo worker en una rama o un entorno de staging. Usa el mismo campo de modelo, el mismo umbral de shunt y la misma ruta de lectura por lotes que la configuración de referencia. La rama debe permitir a un desarrollador activar la ruta barata sin cambiar el comportamiento del agente principal. Registra el umbral y la elección de modelo en las notas de la rama para que la siguiente persona pueda repetir la configuración. No mezcles otro cambio con el cambio de enrutamiento; cambia solo la variable de enrutamiento, o la tabla de deltas se convierte en un resultado que no puedes defender.
- Mide las mismas tareas a través de las rutas principal y barata, luego compara tokens, costo y latencia. Produce una tabla de deltas: tokens ahorrados, dólares ahorrados, latencia mediana y de peor caso, y tasa de timeout. Las respuestas delegadas generalmente tomaban de 10 a 30 segundos, y Portal limita una sola invocación a 30 segundos. Si tus tareas alcanzan ese límite, divide el trabajo antes de celebrar el ahorro.
- Ejecuta pruebas de calidad de código y modos de fallo con tus propios patrones de TypeScript. Incluye concurrencia, estado asíncrono y archivos largos. Registra defectos en una lista corta con severidad, pasos de reproducción y si la ruta barata lo detectó. Pide a la ruta barata que explique su razonamiento en un ejemplo conocido como defectuoso. Si no puede decir por qué un patrón es inseguro, trátalo como una señal, no como una curiosidad. Si la ruta barata pasa por alto la clase de bug que tu equipo publica, el recorte de tokens no es gratis.
- Establece una regla de predeterminado o sin predeterminado por escrito. Redacta una nota de política: qué tipos de tarea pueden usar el modelo worker, cuáles deben permanecer en el modelo principal y qué métrica dispara un rollback.
La evaluación utilizó una base de código Java con cuatro casos de prueba e informó reducciones promedio de tokens de aproximadamente 90% para la ruta de lectura por lotes. Trata el recorte como un resultado de enrutamiento, no como una garantía de calidad.
Haz la decisión de predeterminado explícita
El predeterminado debe coincidir con el riesgo medido. Si la ruta barata ahorra dinero significativo en tareas de bajo riesgo y no aumenta la tasa de fallo en tu código TypeScript, hazla predeterminada solo para esas tareas. Si ahorra dinero pero pasa por alto defectos sutiles, mantenla como opt-in para lecturas por lotes y deja el trabajo sensible a la corrección en el modelo principal.