Review do Factory Droid 1.0: harness mais enxuto, os mesmos limites

O Factory lançou o Droid 1.0 em 29 de outubro de 2026 com uma promessa clara: fazer mais com menos. Só o Script mode reduziu os custos em 15% no Claude Opus 5.5, enquanto o melhor confronto direto ficou 24% abaixo de um harness concorrente. O porém que realmente pesa na decisão de compra continua o mesmo: os limites de uso móveis e o trabalho de revisão que um harness mais rápido pode gerar.

O que o Factory Droid 1.0 traz de fato

O Factory Droid 1.0 é uma atualização do harness, não um novo modelo de base. O Factory Droid continua sendo um agente de programação independente de modelo, que envolve modelos de terceiros e modelos abertos com seus próprios prompts, ferramentas, tratamento de resultados e ciclo de execução. A versão 1.0 muda justamente esse ciclo.

O Droid 1.0 roda no Desktop, na CLI de terminal e no SDK. O mesmo agente também está disponível pela web, Slack, Microsoft Teams, Linear, Jira e pelo modo headless droid exec, para scripts e CI. A Factory lista o Script mode — nome dado pela empresa ao uso programático de ferramentas — como padrão para 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 e Kimi K3.

A escolha do modelo continua aberta. É possível selecionar um modelo manualmente, deixar a seleção automática por conta do Factory Router ou usar suas próprias chaves e endpoints locais, como Ollama, LM Studio e vLLM, por meio do BYOK.

Como o uso programático de ferramentas funciona na prática

Em vez de chamar uma ferramenta por vez, o modelo escreve um programa em JavaScript. Esse programa roda em um sandbox sem acesso próprio a arquivos, rede ou sistema, chama as ferramentas como variáveis, aplica filtros e loops de forma determinística e devolve ao contexto do modelo apenas o resultado selecionado.

Nos ciclos tradicionais de agentes, as respostas brutas são anexadas novamente ao contexto depois de cada chamada. O Script mode filtra esses dados no código antes de reinseri-los. Assim, as instruções são enviadas uma única vez, centenas de chamadas podem ser agrupadas em uma mesma requisição ao modelo e a saída exibida fica limitada por tamanho.

Dois exemplos práticos do post de pesquisa sobre frontier harnesses da Factory, publicado em 29 de outubro de 2026, deixam o mecanismo mais claro:

A Factory também repetiu a correção de um teste unitário no GPT-6.1 Sol. Com chamadas diretas, foram necessárias 10 chamadas ao modelo e 56,8 segundos. No Script mode, foram 5 chamadas e 41,6 segundos; o tempo gasto nas chamadas ao modelo caiu de 42,3 para 28,0 segundos. Os programas aguardam até 5 minutos antes de devolver o resultado disponível, podem continuar rodando em segundo plano e reativam o modelo quando terminam, em vez de depender de polling.

Terminal-Bench 4: comparação com Codex, Claude Code, Cursor, Devin e OpenCode

As comparações da Factory no Terminal-Bench 4 usaram os mesmos modelos em diferentes harnesses entre 23 e 28 de outubro de 2026. Todos os números abaixo são alegações divulgadas pela própria Factory, sem verificação independente. As pontuações absolutas e os custos em dólares não foram revelados — apenas as diferenças entre os resultados.

Antes de tratar essas diferenças como prova suficiente para uma compra, três ressalvas metodológicas são importantes. A Factory considerou algumas tarefas do Devin como concluídas quando o Codex também as concluía, porque o Devin parava para fazer perguntas — foram, em média, 4,7 tarefas por teste, com efeito apenas na precisão. A empresa estimou o uso de tokens ausente do Cursor a partir das transcrições em dois testes que tiveram reconexões no meio da tarefa. Além disso, algumas comparações com chamadas diretas são estimativas modeladas, e não execuções observadas. O Cursor ficou fora da comparação com o GPT-6.1 Sol porque, segundo a Factory, não tinha acesso a modelos da OpenAI durante os testes.

As pontuações antigas do Terminal-Bench, de setembro de 2025, citadas em análises anteriores do Droid e em benchmarks de harnesses, usaram outro conjunto de tarefas e outra versão do harness. Portanto, elas não confirmam nem contradizem as diferenças do 1.0 apresentadas acima.

O ciclo Agent Factory e a engenharia que passa despercebida

O post da Factory sobre frontier harnesses detalha o ciclo Agent Factory e a engenharia por trás dele: incorporar novos modelos, avaliar todos nos mesmos testes, rastrear falhas, testar cada mudança nos modelos afetados e só liberar uma versão depois da revisão dos engenheiros em mais de 20 modelos.

A Factory aponta o ajuste específico por modelo como o motivo desse processo. Um exemplo: adicionar números de linha a todos os arquivos lidos reduziu em 22% o custo do Opus em uma tarefa, com cerca de 2 tokens por linha. Porém, aumentou o custo em 8% no GLM e em 32% no Kimi. Por isso, a numeração de linhas virou uma opção, não um padrão.

As mudanças que não envolvem PTC se concentram em cache, tamanho dos prompts, recuperação de falhas e inicialização:

• Preservação do cache de prompts: anexar as ferramentas recém-descobertas ao fim das requisições, em vez do início, elevou o reaproveitamento para 98% da entrada normalmente vinda do cache nos sete dias encerrados em 22 de outubro de 2026. Considerando o peso dos tokens, o reaproveitamento ficou em 91,5% entre 20,4 milhões de requisições de produção da CLI.
• Redução do prompt-base: a entrada da primeira requisição caiu de 20.887 para 13.055 tokens (−37%) entre as versões 0.170.0 e 0.250.0, enquanto as definições de ferramentas passaram de 15.798 para 8.528 (−46%). O número de definições carregadas de uma vez caiu de 11 para 2 com o carregamento sob demanda.
• Autonomia com limites: quatro minutos sem resposta em streams da Anthropic gerenciados pela Factory acionam uma nova tentativa; três turnos sem saída visível encerram o ciclo; três chamadas idênticas de ferramenta geram um aviso e seis encerram o ciclo. Os resumos de compactação passaram de 8.000 para 16.000 tokens.
• Inicialização e latência: a primeira renderização mediana caiu de 1.839 ms para 488 ms (~3,8x), a aceitação do prompt foi de 1.876 ms para 618 ms (~3,0x) e o tempo até a primeira requisição ao modelo caiu de 1.741 ms para 646 ms. A Factory observa que a própria requisição ao modelo representa cerca de 97% da espera até o primeiro token.

Preços e limites: onde a eficiência pode desaparecer

Os preços do Factory Droid são públicos; a capacidade utilizável, não. Os planos são claros quanto ao valor cobrado, mas pouco transparentes sobre a quantidade disponível — justamente o ponto em que os ganhos de eficiência do 1.0 podem evaporar.

O uso é contabilizado em janelas móveis de 5 horas, 7 dias e 30 dias, com multiplicadores por modelo. A análise da CodeToolPilot de outubro de 2026 observa que a documentação e a página de preços divergem sobre qual plano inclui o Droid Computers — confirme antes de contratar. Quando o uso padrão se esgota, o trabalho passa para o pool gratuito de modelos abertos Droid Core ou para o Extra Usage pré-pago, com mínimo de US$ 10 e sem expiração. As Missions exigem que o Extra Usage esteja habilitado. As chaves BYOK ficam nas configurações locais e funcionam na CLI e no Desktop, mas não na web ou no mobile hospedados. Elas são gratuitas até o limite do plano e depois passam a ser cobradas conforme a tarifa do plano.

O vazamento prático é este: um multiplicador de “5x” não significa cinco vezes mais trabalho concluído. O resultado depende do modelo escolhido, do comportamento do cache, do tamanho do contexto, dos ciclos de ferramentas, do uso do computador e das trajetórias que falham. Usuários intensivos no Reddit relatam consumir a franquia do plano Max em poucas horas em tarefas pouco amigáveis ao cache. O Script mode reduz o problema, mas não o elimina.

O que os usuários estão apontando agora

A reação no X no dia do lançamento é positiva, mas ainda limitada. Já o histórico mais longo do Reddit, no r/FactoryAi, revela três queixas recorrentes que merecem entrar no cálculo de um teste: falta de transparência sobre a cota, lentidão e consumo de CPU, além do trabalho de revisão gerado por saídas autônomas.

“Se você está comparando o uso, o plano do Droid provavelmente não vai conseguir competir com os planos subsidiados da Anthropic e da OpenAI... Mas, como harness, eu pessoalmente achei superior ao Claude Code. No meu uso, ele simplesmente funciona (talvez por ter um system prompt melhor), tem um ótimo modo de especificação e todos os elementos de UX necessários.” — u/FahimAdib11, r/FactoryAi

Outros relatos nos mesmos tópicos descrevem:

• Consumo do plano Max em cerca de 4 horas em execuções pouco favoráveis ao cache (“O cache está realmente muito ruim”) — tópico sobre cota
• Uso de CPU em repouso na casa dos 101%, contra cerca de 6% no Claude Code, com suspeita de envolvimento do MCP — tópico sobre desempenho
• Reinícios de sessão que perdem o contexto e obrigam a reconstruir informações, gerando desperdício

Os primeiros relatos práticos no X também mostram essa divisão. Um usuário que portou uma integração no estilo t3code para o Claude Code relata consumo saudável no mission mode e chama o harness de “outro nível” (@Davidwuuu92), mas reconhece que o ambiente em nuvem do Devin e a flexibilidade multiplataforma continuam à frente.

A lição da avaliação da Continuum sobre o Factory continua válida no 1.0: meça alterações aceitas, minutos de revisão, defeitos que escaparam, intervenções, atingimentos de limite e custo total — não sessões iniciadas ou pull requests abertas. O ganho de autonomia também cria uma dívida de revisão.

Migrar ou continuar? Checklist de compra e teste de 2 semanas

O Droid 1.0 reforça o argumento a favor de um harness eficiente, mas não resolve o problema da previsibilidade das cotas. Quem mais tende a ganhar são as equipes que querem padronizar um único runtime entre modelos, interfaces e CI — e conseguem absorver o trabalho de revisão.

Faça um teste de 2 semanas no mesmo repositório antes de padronizar:

1. Escolha 20 tarefas reais com testes de aceitação definidos.
2. Rode primeiro a CLI do Droid localmente, usando o Specification Mode em trabalhos complexos.
3. Mantenha Claude Code ou Codex como controle, executando as mesmas tarefas.
4. Adicione a execução remota e depois uma Mission pequena com validadores determinísticos.
5. Registre cada limite atingido, fallback para o Droid Core, consumo de Extra Usage, minutos de revisão e custo por marco aceito. Reproduza uma tarefa concluída em uma máquina limpa para detectar diferenças de ambiente.

A questão que o 1.0 deixa em aberto é estrutural: a Factory aposta que o harness importa mais do que o modelo, ajustando o comportamento por modelo por meio do Agent Factory e mantendo a independência em relação ao modelo. Se os preços ou as estruturas de cobrança dos modelos de ponta mudarem, a vantagem de 12–24% do harness pode encolher mais rápido do que qualquer lote do Script mode consegue compensar. Por isso, os termos contratuais sobre limites, retenção e roteamento merecem o mesmo escrutínio que a tabela de benchmarks.

FAQ do Factory Droid 1.0

O plano Pro de US$ 20 do Factory Droid 1.0 vale a pena?

O Factory Droid 1.0 vale US$ 20 para desenvolvedores que executam trabalho suficiente com agentes de terminal para sentir o impacto de tokens e latência, especialmente em tarefas com vários arquivos ou baseadas em tickets, nas quais o Script mode agrupa chamadas de ferramentas. Para usos leves ou centrados em um único modelo, um agente já incluído em outra assinatura pode sair mais barato.

O Factory Droid tem teste grátis ou plano gratuito?

O Factory Droid não lista um plano gratuito convencional, e análises recentes observam que o cadastro pede um método de pagamento. Quando o plano pago se esgota, o uso passa para o pool gratuito de modelos abertos Droid Core, mas ainda é necessário ter um plano pago.

O Factory Droid 1.0 é melhor que o Claude Code?

Os resultados divulgados pela Factory no Terminal-Bench 4 afirmam que o Droid 1.0 marcou de 3,0 a 7,6 pontos a mais que o Claude Code usando Claude Opus 5.5, com custo até 24% menor e 26% menos tempo por tarefa concluída. São números informados pela própria Factory; os relatos práticos no Reddit se dividem entre quem prefere o harness do Droid e quem prefere a experiência e os preços do Claude Code.

Quais modelos têm o Script mode ativado por padrão?

A Factory 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 e Kimi K3. Os demais modelos usam chamadas diretas ou ajustes específicos.

O que são as Factory Missions e quanto elas custam?

As Factory Missions dividem objetivos grandes em marcos, com agentes trabalhadores e validadores para projetos com vários recursos. As Missions exigem o Extra Usage habilitado e consomem um valor variável pré-pago adicional ao uso padrão contabilizado nas janelas móveis.

O Factory Droid roda em CI e aceita minhas próprias chaves?

O Factory Droid roda sem interface por meio do droid exec, com saída em JSON para scripts e CI. O BYOK é compatível com Anthropic, OpenAI, endpoints compatíveis, Bedrock e ambientes locais como Ollama, LM Studio e vLLM na CLI e no Desktop. Modelos personalizados não funcionam nos aplicativos web hospedados ou mobile.

Leituras relacionadas: entenda os limites de uso do Codex para comparar cotas e entenda o harness do Microsoft Copilot para uma segunda referência sobre desenho de harnesses.