Lo que cuesta una sola sesión, medido de ambas formas
Toma una sesión de Droid con tres tareas: restablecer un sistema de contraseñas, agregar un encabezado de copyright y refactorizar el servicio de facturación. Ejecuta las tres en un modelo frontier como Opus y costarán $0.84, $0.62 y $1.41, un total de $2.87 por la sesión.
Enrútalas por complejidad en su lugar. Las dos primeras son rutinarias, así que bajan a $0.09 y $0.12 en modelos eficientes, mientras que la refactorización se queda en el modelo frontier a $1.41. La sesión suma $1.62, el mismo resultado por un 43% menos, y la única variable que cambió fue qué modelo manejó cada tarea.
La mayoría de los equipos de ingeniería eligen un modelo y lo dejan ahí. No porque sea óptimo. Porque cambiar a mitad de sesión implica perder contexto, fricción extra, una decisión que nadie quiere tomar 40 veces al día. Así que apuntan todo al modelo más capaz que pueden pagar y dejan de mirar la cuenta.
Ese default tiene un costo. El modelo caro no es la opción segura. Es solo la cara. Y la brecha de calidad en el trabajo rutinario se ha cerrado lo suficientemente rápido como para que las cuentas ya no cuadren.
Factory Router está dentro de su plataforma Droids y enruta cada tarea automáticamente: trabajo rutinario a modelos eficientes, trabajo complejo a modelos frontier, con todo el contexto preservado en cada cambio. Los números de la sesión anterior son de su benchmark de lanzamiento. Factory no vende modelos, lo que significa que no tienen incentivo estructural para mantenerte en el camino caro. Eso vale la pena notarlo cuando leas los números.
El problema que nadie mide
Cada sesión de Droid se ejecuta en un modelo, y la mayoría de los equipos eligen Opus y nunca revisan la decisión. El costo de ese default es invisible porque nunca aparece como un error. El trabajo se hace, el resultado es bueno, y la factura solo está silenciosamente más alta de lo necesario.
La sesión única anterior desperdicia unos $1.25. Eso parece nada hasta que lo multiplicas. Con 10,000 sesiones al mes, el mismo default convierte $16,400 de gasto necesario en $28,700 de gasto real, que son $147,600 al año pagados por enrutar trabajo rutinario a través de un modelo frontier que nunca fue necesario para hacerlo.
La mayoría de los equipos descubre que entre el 30 y el 50 por ciento de sus sesiones son trabajo rutinario que se ejecuta en su modelo más caro. Esa brecha es toda la oportunidad, y lo que sigue son quince reglas en tres secciones para cerrarla.
→ Regla 1: Clasifica los tipos de tarea antes que nada:
1Mira tus últimas 30 tareas de Droid. Divídelas en dos grupos:23Dignas de frontier: tareas que involucran arquitectura del sistema, autenticación, pagos, seguridad,4dependencias entre servicios, cualquier cosa donde equivocarse cueste tiempo de depuración o5reversiones. Refactorizaciones complejas de más de 100 líneas de lógica de negocio.67Rutinarias: actualizaciones de documentación, cambios de configuración, agregar tests a funciones existentes,8correcciones de bugs pequeños con especificaciones claras, encabezados de copyright, ediciones de README,9generación de boilerplate, migraciones simples.1011Cuenta cada grupo.1213Basado en los datos a nivel de sesión de Factory:14tareas tipo "restablecer mi contraseña": Opus $0.84 vs enrutado $0.09. 89% más barato.15tareas tipo "agregar encabezado de copyright": Opus $0.62 vs enrutado $0.12. 81% más barato.1617Multiplica la cantidad de tareas rutinarias por esa diferencia.18Esa brecha es tu impuesto actual de selección de modelo.
→ Regla 2: Mide el gasto real, no la suposición:
1Tus registros de sesiones de Droid del último mes.23Para cada sesión:4- Tipo de tarea (según la clasificación de la Regla 1)5- Modelo usado6- Costo78Calcula:9- Gasto total en tareas rutinarias usando modelos frontier10- Lo que costarían esas tareas en modelos eficientes (aplica una reducción del 80-90%)11- Ahorro mensual disponible gracias al enrutamiento1213Esta es tu línea base antes de habilitar Factory Router.14La mayoría de los equipos encuentra que entre el 30 y el 50% de las sesiones son trabajo rutinario ejecutándose en modelos frontier.
→ Regla 3: Escribe descripciones de tareas que señalen complejidad:
1La forma en que describes una tarea indica su complejidad a cualquier sistema de enrutamiento.23Señales de baja complejidad (enruta a modelos eficientes):4- "Actualización simple de configuración, sin lógica de negocio: cambia el timeout en config.yaml de 30 a 60"5- "Agrega comentarios JSDoc faltantes a las funciones de utilidad en /helpers"6- "Actualiza el README para reflejar los nuevos pasos de despliegue"78Señales de alta complejidad (enruta a frontier):9- "Refactoriza el middleware de autenticación para soportar nuestra nueva integración SSO en 3 servicios"10- "Depura la condición de carrera en el procesador de pagos que solo aparece bajo carga concurrente"11- "Rediseña el sistema de limitación de tasa para manejar umbrales por inquilino"1213Las descripciones de tareas específicas y ricas en contexto mejoran la precisión del enrutamiento.14Las descripciones vagas se enrutan de forma conservadora a modelos frontier.
→ Regla 4: Calcula tu ROI anual de enrutamiento:
1Fórmula para estimar los ahorros con Factory Router:23Sesiones mensuales: [N]4Costo promedio por sesión sin enrutamiento: [línea base de Opus en $]5Porcentaje de tareas rutinarias: [% de tu auditoría de la Regla 1]6Reducción de costo rutinario: 80-90%78Estimación de ahorro mensual:9N × línea base × %rutinario × 0.85 = dólares recuperados por mes1011Anual: multiplica por 12.1213Para un equipo que ejecuta 5,000 sesiones/mes a $2.87 promedio con 40% de trabajo rutinario:145,000 × $2.87 × 0.40 × 0.85 = $4,879/mes = $58,548/año1516Este es el mínimo. Las Missions (trabajo autónomo de larga duración) aumentan aún más los ahorros.
→ Regla 5: Documenta qué significa "solo frontier" para tu base de código:
1Antes de habilitar el enrutamiento, define qué debe permanecer en modelos frontier para tu base de código.23Escríbelo una vez. Pégalo como tu guía base de enrutamiento:45"Lo siguiente siempre requiere modelos frontier:6- Cualquier cambio que toque [capa de autenticación/pagos/seguridad]7- Refactorizaciones entre servicios con más de [N] archivos8- Cambios en la configuración del pipeline CI/CD9- Migraciones de esquema de base de datos10- Cualquier cosa marcada como [P0/crítico] en nuestro rastreador de incidencias1112Todo lo demás es elegible para enrutamiento a modelos eficientes."1314Este se convierte en tu documento de política de enrutamiento.15Lo actualizas a medida que aprendes qué necesita tratamiento frontier en tu base de código específica.
equipo de 10 desarrolladores, 1,000 sesiones/mes, 40% rutinario: $13,776/año recuperados equipo de 50 desarrolladores, 5,000 sesiones/mes, 40% rutinario: $58,548/año recuperados empresa (escala Nvidia, Adobe): ahorros anuales de seis cifras
error a evitar: no intentes clasificar manualmente cada tarea antes de habilitar Router. El Router se encarga de la clasificación. Tu trabajo es definir las reglas estrictas sobre lo que debe permanecer en frontier, y dejar que el sistema maneje todo lo demás.
0:28
→ Regla 6: Habilita Factory Router en un solo paso:
1En Factory CLI o la aplicación de escritorio:231. Abre el selector de modelos42. Selecciona "Factory Router"53. Listo.67No se requiere configuración para empezar. Router usa la lógica de enrutamiento predeterminada de inmediato.89Para verificar que está activo:10Ejecuta una tarea simple ("actualiza un comentario en este archivo").11Revisa el registro de sesión para ver la atribución del modelo.12Deberías ver un modelo eficiente manejándola, no Opus.1314Si ves Opus en una tarea simple, verifica que Router esté seleccionado y no una anulación de modelo específica.
→ Regla 7: Configura la guía de enrutamiento para tu base de código:
1La guía de enrutamiento es de carácter consultivo. Ayuda a Router a tomar mejores decisiones2para tu base de código específica. No fuerza un modelo.34Pega esto como punto de partida de tu guía de enrutamiento y edítalo para tu stack:56"Cambios de autenticación, pagos y seguridad: modelos frontier.7Migraciones de base de datos y cambios de esquema: modelos frontier.8Cambios en contratos de API que afecten a consumidores externos: modelos frontier.910Actualizaciones de documentación: modelos eficientes.11Agregar tests a funciones existentes: modelos eficientes.12Cambios de configuración y variables de entorno: modelos eficientes.13Generación de boilerplate y scaffolding: modelos eficientes.14Comentarios de código y JSDoc: modelos eficientes.15Actualizaciones de README y changelog: modelos eficientes.1617Todo lo demás: Router decide según el contexto de la tarea."
→ Regla 8: Configura la guía de enrutamiento para gobierno empresarial:
1Para equipos que ejecutan agentes a escala, la guía de enrutamiento se convierte en un documento de gobierno.23Plantilla estándar para industrias reguladas (banca, salud, SaaS empresarial):45"Reglas de enrutamiento de alta sensibilidad:6- Cualquier cosa que toque [datos personales / datos financieros / autenticación] = solo frontier7- Cualquier cambio en API externa = solo frontier8- Scripts de despliegue en producción = solo frontier9- Tareas de respuesta a incidentes = solo frontier1011Enrutamiento estándar:12- Entornos de desarrollo, staging y prueba = Router decide13- Herramientas internas y automatización = se prefieren modelos eficientes14- Documentación, informes y comunicación = modelos eficientes1516Política de anulación:17Cualquier desarrollador puede solicitar frontier para una tarea.18Router trata esto como una anulación estricta, no consultiva.19Registra todas las anulaciones a frontier para revisión mensual."2021Guárdalo como ROUTING_POLICY.md en la raíz de tu proyecto.22Referéncialo en tu CLAUDE.md o archivo de contexto equivalente.
→ Regla 9: Ejecuta Missions con enrutamiento habilitado:
1Las Missions son las tareas autónomas de larga duración de Factory.2Horas o días de trabajo. Sin supervisión requerida.34Con Factory Router habilitado, las Missions se benefician de la misma lógica de enrutamiento.5Cada paso en una Mission se enruta de forma adecuada.6Los pasos simples en una Mission compleja se ejecutan en modelos eficientes.7La Mission paga tarifas frontier solo cuando realmente se necesita razonamiento frontier.89Para configurar:10Habilita Factory Router antes de iniciar cualquier Mission.11Agrega una guía de enrutamiento que refleje el perfil de complejidad de la Mission:1213"Esta Mission implica [trabajo central de alta complejidad] y [tareas de soporte rutinarias].14Trabajo central (decisiones arquitectónicas, análisis de seguridad): frontier.15Trabajo de soporte (documentación, configuración, boilerplate): modelos eficientes.16Usa el modelo más eficiente disponible para cualquier paso17que no requiera el razonamiento especificado anteriormente."1819Las Missions largas ven ahorros proporcionalmente mayores porque acumulan más pasos rutinarios.
→ Regla 10: Configura la política de conmutación por error de proveedores:
1Factory Router enruta entre proveedores para mayor confiabilidad.2Si una ruta de proveedor se degrada, las sesiones continúan a través de un proveedor saludable.34Para equipos empresariales con requisitos de tiempo de actividad:56"Política de enrutamiento de confiabilidad:7- Proveedor principal por modelo: [lista tus proveedores preferidos]8- Disparador de conmutación por error: cualquier solicitud que falle o exceda [N] segundos de latencia9- Comportamiento de conmutación por error: mismo modelo, proveedor diferente si está disponible.10 Si el mismo modelo no está disponible, escalar al siguiente modelo frontier.11- TPM dedicado: confirma con el equipo de cuenta de Factory para tu nivel.12- Objetivo: 99.9%+ de confiabilidad en las solicitudes.1314Registra todos los eventos de conmutación por error. Revisa semanalmente para detectar patrones de salud de proveedores."
Terminal-Bench 2: 99% de la tasa de aprobación de Opus con un 20% menos de costo Legacy-Bench: 96% de la tasa de aprobación de Opus con un 25% menos de costo 99.9%+ de confiabilidad en las solicitudes mediante enrutamiento entre proveedores
3 / 3 | EL SISTEMA: ejecutando Factory a la escala donde los ahorros se acumulan
La historia de ahorro de costos es interesante a nivel de desarrollador individual. Se vuelve significativa a nivel de equipo. A escala empresarial, es una línea del presupuesto.
Nvidia. Adobe. EY. Palo Alto Networks. Adyen. Estos son los clientes empresariales de Factory.
Un equipo que ejecuta 5,000 sesiones por mes recupera $58,548 al año solo con el enrutamiento, con una tasa de tareas rutinarias del 40%. Un equipo con 50,000 sesiones recupera $585,480. La matemática escala linealmente con el volumen. Las facturas de tokens empresariales no son lineales.
El punto más profundo es sobre la arquitectura. La mayoría de las plataformas de agentes de IA se basan en un supuesto de modelo único. Un equipo, un modelo, un proveedor. La plataforma de Factory es agnóstica respecto al modelo por diseño: cualquier LLM (Claude, GPT, Gemini, Llama, código abierto), cualquier interfaz (CLI, Escritorio, VS Code, Slack, GitHub, Linear, Jira, pipelines CI), cualquier etapa del ciclo de vida del software.
Router es una capa de esa arquitectura. Es la capa de control de costos. El mismo contexto de Droid que funciona en tu terminal funciona en Slack. La misma política de enrutamiento que se aplica a sesiones individuales se aplica a Missions que duran días.
Las cinco reglas finales construyen el sistema completo de Factory alrededor de Router.
→ Regla 11: Mide los ahorros de enrutamiento semanalmente:
1Establece una rutina semanal para rastrear el rendimiento de Router.23Revisa en los registros de sesión de Factory:41. Total de sesiones esta semana52. Distribución de modelos (qué % fue a cada modelo)63. Costo con enrutamiento vs línea base (Opus en todo)74. Cualquier sesión donde Router escaló a frontier (señal de calidad)89Formato del informe:10> sesiones: [N]11> uso de modelos eficientes: [%]12> uso de modelos frontier: [%]13> gasto real: $[monto]14> línea base (todo Opus) habría sido: $[calculado]15> ahorro semanal: $[monto]16> escalamientos a frontier: [N] (revisar para mejorar la guía de enrutamiento)1718Si la tasa de escalamiento supera el 10%, revisa tu guía de enrutamiento.19Demasiados escalamientos significa que las tareas rutinarias se están describiendo como complejas.
→ Regla 12: Evaluación de preparación para agentes antes del despliegue completo:
1Antes de implementar Factory Router para todo tu equipo, ejecuta la evaluación de preparación para agentes de Factory.23Evalúa más de 100 señales en:4- Salud de la base de código (cobertura de tests, confiabilidad de CI, documentación)5- Madurez del flujo de trabajo (proceso de PR, estándares de revisión de código, pipeline de despliegue)6- Preparación del equipo (familiaridad con herramientas de agentes, automatización existente)78Usa el resultado para priorizar qué flujos de trabajo enrutar primero.910Flujos de trabajo de alta preparación: implementa Router de inmediato, enrutamiento completo habilitado.11Flujos de trabajo de preparación media: implementa Router con guía conservadora, más tareas en frontier.12Flujos de trabajo de baja preparación: desarrolla preparación antes de enrutar.13Las herramientas de agentes en bases de código no preparadas pasan más tiempo en modelos frontier corrigiendo errores.1415Los ahorros de Router son más altos en entornos de alta preparación.
→ Regla 13: Construye tu grupo de modelos deliberadamente:
1Factory Router se alimenta de un grupo de modelos frontier y eficientes.2El grupo que configures afecta las opciones de enrutamiento disponibles.34Grupo inicial recomendado:56Nivel frontier (trabajo complejo):7- Claude Opus (última versión)8- GPT-5.2 (si está en tu lista de proveedores aprobados)910Nivel eficiente (trabajo rutinario):11- Kimi K2.6 (mejor valor por punto F1 para tareas de código)12- MiniMax M2.7 (costo más bajo para tareas simples)1314Agrega modelos a medida que valides su rendimiento en tu base de código.15Comienza con la estructura de dos niveles.16Expande a tres niveles (frontier / medio / eficiente) una vez que tengas datos de enrutamiento.1718Documenta qué modelos están aprobados para cada requisito de cumplimiento.19Si tu empresa restringe ciertos proveedores de modelos, configura el grupo en consecuencia.20Los modelos de código abierto alojados en EE. UU. están disponibles a través de Factory para entornos que requieren residencia de datos.
→ Regla 14: Integra el enrutamiento en tu pipeline de CI:
1Factory funciona en pipelines de CI. El enrutamiento también se aplica allí.23Agrega Factory Router a tu flujo de trabajo de GitHub Actions:45Para revisiones de pull request:6"Enruta las tareas de revisión de PR según el alcance de los cambios de archivo.7- Cambios en archivos de seguridad y autenticación: modelos frontier8- Archivos de test: modelos eficientes9- Cambios de documentación: modelos eficientes10- PRs mixtos: enruta sección por sección si es posible, de lo contrario frontier para la revisión completa"1112Para QA automatizado:13"Enruta las tareas de QA según la complejidad del test.14- Tests de extremo a extremo de ruta crítica: modelos frontier15- Generación de tests unitarios: modelos eficientes16- Suites de tests de regresión: modelos eficientes"1718El enrutamiento de CI acumula ahorros porque se ejecuta en cada commit.19La diferencia de costo entre Opus y Kimi K2.6 en la generación de tests en 100 commits diarios es significativa.
→ Regla 15: Establece revisiones mensuales de la política de enrutamiento:
1La guía de enrutamiento debe evolucionar a medida que tu base de código y equipo crecen.23Agenda de revisión mensual (30 minutos):451. Informe de costos: real vs línea base, tendencia de ahorros62. Análisis de escalamientos: qué tareas escalaron y por qué73. Actualización de la guía de enrutamiento: ¿la guía actual sigue reflejando la complejidad de la base de código?84. Evaluación de nuevos modelos: ¿hay algún modelo nuevo en el grupo que valga la pena agregar?95. Comentarios del equipo: ¿los desarrolladores están anulando Router con frecuencia? ¿Por qué?1011Preguntas que indican que tu guía de enrutamiento necesita actualización:12- Tasa de escalamiento superior al 15%: la guía es demasiado agresiva hacia modelos eficientes13- Tasa de escalamiento inferior al 2%: la guía puede ser demasiado conservadora, dejando ahorros sobre la mesa14- Tasa de anulación por desarrollador superior al 20%: Router no está coincidiendo con las expectativas de los desarrolladores1516Actualiza ROUTING_POLICY.md después de cada revisión.
sin Factory Router: cada sesión se ejecuta en frontier, independientemente del tipo de tarea con Factory Router: tareas rutinarias en modelos eficientes, tareas complejas en frontier resultado: reducción de costo del 20-43% manteniendo el 96-99% del rendimiento de referencia de frontier
CONCLUSIÓN
Aquí es donde aterrizan las cuentas.
El 40-60% de las sesiones de ingeniería de Droid son tareas rutinarias en la mayoría de los equipos esas sesiones en Opus: $2.87 promedio por sesión esas sesiones con enrutamiento: $1.62 promedio con 10,000 sesiones por mes: $147,600 recuperados por año
Los números de referencia se sostienen: 99% de la tasa de aprobación de Opus en Terminal-Bench 2 con un 20% menos de costo. 96% en Legacy-Bench con un 25% menos de costo. La caché de prompt permanece intacta entre cambios de modelo, por lo que la calidad no baja cuando el router cambia de modelo a mitad de sesión. La conmutación por error de proveedores mantiene las sesiones funcionando con una confiabilidad del 99.9%+.
Factory Router está en vista previa de investigación privada. Lo seleccionas una vez en el selector de modelos. No requiere configuración adicional.
Lo que todavía estoy tratando de entender: qué tan bien funciona la guía de enrutamiento consultiva en diferentes tipos de bases de código. Establecer reglas como "cambios de autenticación = frontier, ajustes de documentación = rutinario" suena limpio en papel. ¿Qué sucede cuando una tarea está en el medio? Ese es el caso límite que vale la pena observar a medida que más equipos comienzan a usar esto.
Las 15 reglas anteriores son el sistema de configuración. Comienza con las Reglas 1 y 6.
P.D.: la línea que la mayoría pasará por alto: Factory no vende modelos. No se benefician de tu factura de tokens. Esa diferencia estructural es la razón por la que existe un sistema de enrutamiento como este en primer lugar. Curioso por ver qué sucede a medida que se agregan más modelos al grupo.
Guarda esto antes de que se entierre
Si te fue útil, compártelo con una persona que lo necesite.
