A maioria das ferramentas de codificação AI são ferramentas de automação: um ciclo em torno de um modelo, além de ferramentas para ler e escrever arquivos e executar comandos. Claude Code, Codex, OpenCode e Pi são todas ferramentas de automação, criadas para um desenvolvedor que trabalha no terminal.
Coroid não utiliza nenhuma delas. Ele roda suas próprias ferramentas.
Por que não usar uma já existente?
As ferramentas acima foram projetadas para uma sessão supervisionada. Alguém está observando, pode responder perguntas, interromper o processo ou perceber quando algo dá errado. Essa premissa é lógica e influencia tudo — como os erros são exibidos, quanto contexto é mantido e o que acontece quando o modelo retorna algo inesperado.
A premissa de Coroid é o oposto: ninguém está supervisionando. O trabalho roda na nuvem, acionado por agendamento, monitoramento ou evento, e deve chegar a um resultado passível de revisão ou a uma falha clara sem que ninguém intervenha durante a execução.
São problemas distintos. Vários elementos abaixo existem justamente por causa dessa diferença e não fariam sentido em uma sessão de terminal.
O que o runtime faz de diferente?
Ele foi feito para operar de forma autônoma. Quando o modelo retorna uma resposta inválida ou uma chamada de ferramenta corrompida, o ciclo corrige e tenta novamente em vez de exibir um prompt para o qual ninguém está disponível para responder. Uma execução autônoma que pare para fazer uma pergunta que poderia ser resolvida é um desperdício de recurso.
Ele é multiagente por design. O ciclo é construído em torno de funções com permissões distintas, passando o trabalho entre eles em uma ordem fixa ou sob a supervisão de um coordenador que determina o próximo passo, em vez de um único agente realizar todas as tarefas. A verificação é feita por um agente que não escreveu o código, e um coordenador não pode anulá-la, uma característica garantida pela arquitetura, e não por um simples pedido. Um coordenador também pode constatar que o código já atende ao que a tarefa solicita e pedir que o agente de QA verifique isso sem alterações. Todos os caminhos terminam nos mesmos pontos de controle.
Ele possui orçamentos explícitos e limites de profundidade. Cada execução respeita um limite de tokens e um número máximo de etapas. Sem esses limites, um agente autônomo que tenha interpretado mal sua tarefa continuará operando indefinidamente.
Ele incorpora a governança diretamente no processo. Políticas, portas de qualidade e pontos de aprovação fazem parte do caminho de execução, e não são apenas camadas adicionais sobre ele. Por isso, uma porta de bloqueio pode interromper o trabalho durante a execução, em vez de só após sua conclusão.
O caching é uma prioridade fundamental.
O contexto representa a maior parte do custo de execução dos agentes, e em um ambiente de nuvem o mesmo contexto do projeto é lido repetidamente em diversas tarefas.
Por esse motivo, o runtime depende muito do caching de prompts. Você pode ver isso em ação no registro de execução, onde as etapas informam a eficiência do cache:
9.1k used (90% cached)Uma alta taxa de acertos no cache faz a diferença entre uma execução cara e uma barata. É também por isso que um projeto bem estruturado com especificações claras Contexto É menos custoso trabalhar com um contexto estável — cache de contexto funciona bem, ao contrário de contextos que mudam a cada execução.
Isso se combina com Habilidades progressivas, o que mantém o contexto carregado pequeno desde o início.
O que isso significa na prática
- Sem configuração local. Sem CLI, sem plug-in de editor, sem runner para hospedar. O Coroid é baseado em API e roda na nuvem.
- Sem assinaturas de ferramentas de terceiros. Você não compra licenças para um assistente de codificação adicional ao Coroid. O uso do modelo é cobrado como créditos ou por meio de suas próprias chaves de provedor.
- O trabalho roda sem supervisão. Agendas e hooks são possíveis porque nada depende da máquina do desenvolvedor estar ativa.
- O comportamento é consistente. O trabalho de todos roda no mesmo ambiente de execução com as mesmas políticas, em vez de depender do que cada desenvolvedor instalou e configurou. O que está instalado está documentado em suporte a linguagens e o ambiente do agente.
O que não muda
O harness decide como o trabalho é feito. Ele não altera os limites: toda alteração ainda chega como um pull request em um branch; nada é mesclado automaticamente, e suas regras de proteção de branch e revisão se aplicam exatamente como para colaboradores humanos.