AIREITERFactory lanzó Droid 1.0 el 29 de octubre de 2026 con una promesa muy concreta: hacer más con menos. Según la compañía, el modo Script redujo un 15 % el coste con Claude Opus 5.5, y su mejor comparación directa quedó un 24 % por debajo de otro arnés. La letra pequeña sigue siendo la misma que condiciona cualquier compra: los límites de uso móviles y todo el trabajo de revisión que puede generar un arnés más rápido.
Qué incluye realmente Factory Droid 1.0
Factory Droid 1.0 es una actualización del arnés, no un nuevo modelo fundacional. Droid sigue siendo un agente de programación independiente del modelo, capaz de envolver modelos propios y de terceros con sus prompts, herramientas, gestión de resultados y bucle de ejecución. La versión 1.0 modifica precisamente ese bucle.
Droid 1.0 funciona en Desktop, en la CLI de terminal y mediante el SDK. El mismo agente también está disponible desde la web, Slack, Microsoft Teams, Linear, Jira y el modo sin interfaz droid exec para scripts y CI. Factory indica que el modo Script —su nombre para las llamadas programáticas a herramientas— viene activado por defecto en GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5 y Kimi K3.
La elección del modelo sigue abierta. Es posible seleccionar uno manualmente, dejar que Factory Router lo escoja automáticamente o conectar claves propias y endpoints locales como Ollama, LM Studio y vLLM mediante BYOK.
Cómo funcionan en la práctica las llamadas programáticas a herramientas
En lugar de llamar a las herramientas una por una, el modelo escribe un programa JavaScript. Ese programa se ejecuta en un entorno aislado sin acceso propio a archivos, red ni sistema; utiliza las herramientas como variables, aplica filtros y bucles de forma determinista y devuelve al contexto del modelo únicamente el resultado seleccionado.
Los bucles de agentes tradicionales vuelven a añadir al contexto el resultado bruto después de cada llamada. El modo Script lo filtra mediante código antes de reincorporarlo. Así, las instrucciones se envían una sola vez, cientos de llamadas pueden agruparse dentro de una única solicitud al modelo y la salida impresa queda limitada por tamaño.
Dos ejemplos prácticos del artículo de investigación sobre frontier harnesses de Factory (29 de octubre de 2026) muestran mejor la diferencia:
| Flujo de trabajo | Llamadas directas a herramientas (estimación) | Modo Script |
|---|---|---|
| Mover y verificar 151 incidencias de Linear, 312 llamadas a herramientas y 15 campos comprobados por escritura | ~36 solicitudes al modelo, ~3,1 M de tokens de entrada | 2 solicitudes, ~61 K de tokens |
| Revisar 5.384 trabajos de escritorio en 547 ejecuciones, con 550 llamadas a herramientas agrupadas en lotes de 60 | ~59–187 solicitudes | 2 solicitudes, resumen de 5 cifras con 41 trabajos fallidos, <0,1 % de los resultados de herramientas llegó al contexto |
Factory también repitió una corrección de pruebas unitarias en GPT-6.1 Sol. Las llamadas directas necesitaron 10 llamadas al modelo y 56,8 segundos; el modo Script, 5 llamadas y 41,6 segundos. El tiempo dedicado a las llamadas al modelo bajó de 42,3 a 28,0 segundos. Los programas esperan hasta 5 minutos antes de devolver lo que tengan disponible, pueden continuar en segundo plano y despiertan al modelo al terminar, sin necesidad de consultar su estado continuamente.
Terminal-Bench 4 frente a Codex, Claude Code, Cursor, Devin y OpenCode
Las comparaciones de Factory en Terminal-Bench 4 ejecutaron los mismos modelos en distintos arneses entre el 23 y el 28 de octubre de 2026. Todas las cifras siguientes son afirmaciones de Factory sin verificación independiente. La empresa no publica las puntuaciones absolutas ni los costes en dólares, solo las diferencias.
| Modelo | Factory Droid 1.0 frente al arnés rival | Diferencia comunicada |
|---|---|---|
| GPT-6.1 Sol | frente a Codex | +3,5 puntos de precisión, −12 % de coste; Droid es un 10 % más lento por tarea superada |
| GPT-6.1 Sol | frente a OpenCode y Devin | +6,6 a +12,6 puntos; entre un 4 y un 11 % más rápido |
| Claude Opus 5.5 | frente a Claude Code, Cursor, OpenCode y Devin | +3,0 a +7,6 puntos; hasta un −24 % de coste; entre un 16 y un 26 % menos de tiempo por tarea superada |
| Claude Opus 5.5 | frente a Claude Code específicamente | −26 % de tiempo, −17 % de tokens por tarea superada; el modo Script por sí solo reduce el coste un −15 % |
Antes de interpretar estas diferencias como una prueba definitiva de compra conviene tener en cuenta tres matices metodológicos. Factory dio por superadas algunas tareas de Devin cuando Codex las había completado porque Devin se detuvo para hacer preguntas (una media de 4,7 tareas por prueba, con efecto únicamente sobre la precisión); estimó el uso de tokens de Cursor a partir de transcripciones en dos pruebas después de reconexiones durante la tarea; y algunas comparaciones de llamadas directas son estimaciones modeladas, no ejecuciones observadas. Cursor quedó fuera de la comparación con GPT-6.1 Sol porque, según Factory, no tenía acceso a modelos de OpenAI durante las pruebas.
Las puntuaciones de Terminal-Bench de septiembre de 2025 citadas en análisis anteriores de Droid y en benchmarks de arneses utilizan otro conjunto de tareas y otra versión del arnés. Por tanto, ni confirman ni desmienten las diferencias de la versión 1.0.
El ciclo Agent Factory y la ingeniería que no siempre se ve
El artículo de Factory sobre frontier harnesses describe el ciclo Agent Factory y el trabajo que lo sostiene: incorporar modelos nuevos, evaluarlos en las mismas tareas, rastrear los fallos, probar cada cambio en los modelos afectados y someter el lanzamiento a revisión de ingenieros en más de 20 modelos.
Factory justifica este proceso por la necesidad de ajustar el comportamiento de cada modelo. Un ejemplo: añadir números de línea a todos los archivos leídos redujo un 22 % el coste de Opus en una tarea, con unos 2 tokens por línea, pero elevó el coste un 8 % en GLM y un 32 % en Kimi. Por eso Factory dejó la numeración de líneas como opción, no como ajuste predeterminado.
Los cambios que no dependen del modo PTC se centran en la caché, el tamaño de los prompts, la recuperación y el arranque:
- Conservación de la caché de prompts: añadir las herramientas descubiertas al final de las solicitudes, en lugar de al principio, elevó la reutilización al 98 % habitual de entradas desde la caché durante los siete días que terminaron el 22 de octubre de 2026, y al 91,5 % de reutilización ponderada por tokens en 20,4 millones de solicitudes CLI de producción.
- Reducción del prompt base: la entrada de la primera solicitud pasó de 20.887 a 13.055 tokens (−37 %) entre las versiones 0.170.0 y 0.250.0, mientras que las definiciones de herramientas bajaron de 15.798 a 8.528 (−46 %). Además, las definiciones iniciales de herramientas pasaron de 11 a 2 gracias a la carga bajo demanda.
- Autonomía acotada: 4 minutos sin actividad en los streams de Anthropic gestionados por Factory activan un reintento; 3 turnos sin salida visible detienen el bucle; 3 llamadas idénticas a una herramienta generan un aviso y 6 lo detienen. Los resúmenes de compactación duplicaron su tamaño, de 8.000 a 16.000 tokens.
- Arranque y latencia: el primer renderizado mediano pasó de 1.839 ms a 488 ms (~3,8 veces más rápido), la aceptación del prompt de 1.876 ms a 618 ms (~3,0 veces más rápida) y el tiempo hasta la primera solicitud al modelo de 1.741 ms a 646 ms. Factory señala que la propia solicitud al modelo representa aproximadamente el 97 % de la espera hasta el primer token.
Precios y límites: dónde se escapa la eficiencia
Los precios de Factory Droid son públicos, pero no así la capacidad utilizable. Los planes tienen un precio fácil de entender y una cantidad de uso mucho menos transparente: justo el punto donde las mejoras de eficiencia de la versión 1.0 pueden evaporarse.
| Plan | Precio | Qué comunica Factory |
|---|---|---|
| Pro | $20/mes | Límites móviles de referencia; Desktop, CLI, SDK y seguimiento incluidos |
| Plus | $100/mes | ~5 veces el uso estándar de Pro; Droid Computers gestionados en la página de precios actual |
| Max | $200/mes | ~10 veces el uso estándar de Pro; funciones anticipadas |
| Teams | $60/mes + $40 por usuario (hasta 10 usuarios) | Límites Pro por usuario y facturación centralizada |
| Business / Enterprise | Consultar con ventas | Límites personalizados, SSO/SAML/SCIM, retención cero, auditoría, computación dedicada y uso local |
El uso se calcula en ventanas móviles de 5 horas, 7 días y 30 días, con multiplicadores según el modelo. Además, el análisis de CodeToolPilot de octubre de 2026 señala que la documentación y la página de precios no coinciden sobre qué nivel incluye Droid Computers: conviene confirmarlo antes de contratar. Cuando se agota el uso estándar, el trabajo pasa al grupo gratuito de modelos open-weight Droid Core o al uso adicional prepago (mínimo de $10, sin caducidad); las Missions requieren activar Extra Usage. Las claves BYOK se guardan en la configuración local y funcionan en CLI y Desktop, pero no en la web ni en el móvil alojados. Son gratuitas hasta el límite del plan y después se facturan a la tarifa del plan.
El problema práctico es que un multiplicador de «5x» no equivale a completar cinco veces más trabajo. El rendimiento depende del modelo elegido, el comportamiento de la caché, la longitud del contexto, los bucles de herramientas, el uso del ordenador y las trayectorias fallidas. Usuarios intensivos de Reddit aseguran haber agotado el cupo Max en cuestión de horas con trabajos poco favorables para la caché. El modo Script ayuda, pero no elimina el problema.
Qué están señalando los usuarios reales
La reacción de lanzamiento en X es positiva, aunque escasa. En Reddit, la trayectoria más larga de r/FactoryAi deja tres quejas recurrentes que conviene tener en cuenta durante una prueba: la opacidad de las cuotas, la lentitud y el consumo de CPU, y la carga de revisión que genera la salida autónoma.
«Si comparas el uso, lo más probable es que el plan de Droid no pueda competir con los planes subvencionados de Anthropic y OpenAI... Pero como arnés, personalmente me ha parecido superior a Claude Code; en mi caso, simplemente funciona (quizá por un mejor prompt de sistema), tiene un modo de especificaciones excelente y todos los elementos de UX necesarios». — u/FahimAdib11, r/FactoryAi
En los mismos hilos también aparecen informes menos favorables:
- Agotamiento del plan Max en unas 4 horas con ejecuciones poco compatibles con la caché («La caché está realmente muy mal») — hilo sobre cuotas
- Lecturas de CPU en reposo de alrededor del 101 %, frente a aproximadamente un 6 % en Claude Code, con los MCP como posible causa — hilo sobre rendimiento
- Reinicios de sesión que pierden el contexto y obligan a reconstruirlo de forma poco eficiente
Las primeras pruebas prácticas en X reflejan la misma división. Un usuario que está trasladando una integración de Claude Code al estilo t3code informa de un uso saludable en el modo Mission y califica el arnés de «otro nivel» (@Davidwuuu92), aunque reconoce que el entorno en la nube y la flexibilidad multiplataforma de Devin siguen por delante.
La lección de la evaluación de Continuum sobre Factory sigue siendo válida para la versión 1.0: hay que medir los cambios aceptados, los minutos de revisión, los defectos que llegan a producción, las intervenciones, los límites alcanzados y el coste total. No basta con contar sesiones iniciadas o pull requests abiertas, porque el rendimiento autónomo también genera deuda de revisión.
¿Cambiar o quedarse? Cómo decidir y probarlo durante 2 semanas
Droid 1.0 refuerza el argumento a favor de un arnés eficiente, pero no resuelve el problema de la previsibilidad de las cuotas. Quienes más pueden ganar son los equipos que quieran estandarizar un mismo entorno de ejecución entre modelos, superficies y CI, y que tengan capacidad para asumir el trabajo de revisión.
| Perfil | Veredicto sobre la versión 1.0 | Motivo |
|---|---|---|
| Desarrollador independiente que ya tiene incluido un único modelo puntero en otro servicio | Quedarse o probar un mes de pago | El ahorro del modo Script rara vez supera el precio subvencionado de una suscripción de un solo modelo con poco uso |
| Equipo que quiere unificar terminal, CI y delegación por chat entre varios modelos | Candidato para cambiar | Un solo arnés, Router/BYOK, Droid Computers, Missions y auditoría: la amplitud es su principal ventaja |
| Organización regulada o aislada | Incluirlo en la lista corta | Uso híbrido/local, SSO, auditoría y exportación de telemetría; el precio solo se obtiene mediante ventas |
| Usuario que busca autocompletado en el editor y no tiene capacidad de revisión | Descartarlo | Una salida más rápida sin revisores se convierte en cola de trabajo, no en velocidad real |
Haz una prueba de 2 semanas en el mismo repositorio antes de estandarizarlo:
- Elige 20 tareas reales con pruebas de aceptación fijadas.
- Ejecuta primero Droid CLI en local y activa Specification Mode para los trabajos complejos.
- Mantén Claude Code o Codex como control en tareas idénticas.
- Añade la ejecución remota y después una Mission pequeña con validadores deterministas.
- Registra cada límite alcanzado, cada cambio a Droid Core, cada consumo de Extra Usage, los minutos de revisión y el coste por hito aceptado. Repite una tarea completada en una máquina limpia para detectar diferencias de entorno.
La cuestión que la versión 1.0 deja abierta es estructural: Factory apuesta por que el arnés importa más que el modelo y ajusta el comportamiento de cada uno mediante Agent Factory, sin dejar de ser independiente del modelo. Si cambian los precios o las estructuras de tarifas de los modelos punteros, la ventaja actual del arnés, del 12 al 24 %, puede reducirse más rápido de lo que una ejecución por lotes del modo Script puede compensarlo. Por eso las condiciones sobre límites, retención y enrutamiento merecen tanta atención como la tabla de benchmarks.
Preguntas frecuentes sobre Factory Droid 1.0
¿Merece la pena el plan Pro de Factory Droid 1.0 por $20?
Factory Droid 1.0 puede justificar los $20 para desarrolladores que hagan suficiente trabajo con agentes de terminal como para notar el coste de tokens y la latencia, especialmente en tareas con varios archivos o basadas en incidencias donde el modo Script agrupa las llamadas a herramientas. Los usuarios ocasionales o centrados en un solo modelo quizá encuentren más barato un agente que ya esté incluido en otro servicio.
¿Factory Droid ofrece prueba gratuita o plan gratuito?
Factory no anuncia un plan gratuito convencional y análisis recientes señalan que el registro solicita un método de pago. Cuando se agota un plan de pago, el servicio pasa al grupo gratuito de modelos open-weight Droid Core, pero sigue siendo necesario tener un plan de pago.
¿Es Factory Droid 1.0 mejor que Claude Code?
Las pruebas de Factory en Terminal-Bench 4 afirman que Droid 1.0 obtiene entre 3,0 y 7,6 puntos más que Claude Code con Claude Opus 5.5, con hasta un 24 % menos de coste y un 26 % menos de tiempo por tarea superada. Son cifras comunicadas por Factory; las experiencias prácticas en Reddit se dividen entre quienes prefieren el arnés de Droid y quienes valoran más la menor fricción y el precio de Claude Code.
¿Qué modelos admiten el modo Script por defecto?
Factory incluye en la lista GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5 y Kimi K3. El resto utiliza llamadas directas o ajustes específicos por modelo.
¿Qué son Factory Missions y cuánto cuestan?
Factory Missions dividen objetivos grandes en hitos y utilizan agentes trabajadores y validadores para proyectos con varias funcionalidades. Las Missions requieren activar Extra Usage y consumen gasto variable prepago además del uso estándar móvil.
¿Puede Factory Droid ejecutarse en CI y utilizar mis propias claves?
Factory Droid funciona sin interfaz mediante droid exec, con salida JSON para scripts y CI. BYOK admite Anthropic, OpenAI, endpoints compatibles, Bedrock y los entornos locales Ollama/LM Studio/vLLM en CLI y Desktop. Los modelos personalizados no funcionan en las aplicaciones web o móviles alojadas.
Lecturas relacionadas: explicación de los límites de uso de Codex para comparar cuotas, y explicación del arnés de Microsoft Copilot como segunda referencia sobre diseño de arneses.