↩ Comparativo · Benchmark — avaliações

HARNESS_EVAL — Traycer (Traycer AI) #

Rodada ext-3 (2026-08-02) — terceira promoção Radar→corpus (spec 074). Leitura sistemática de código no fork congelado.

Metadados #

• Repositório / versão ou commit avaliado: github.com/traycerai/traycer · fork GHDaru/traycer, commit 65fc3d7 (shallow clone)
• Linguagem / stack: TypeScript, monorepo Bun 1.3.12 + Nx (workspaces protocol/ e clients/*), Electron + React 19 + Yjs no desktop, zod para todo o contrato de wire. ~513k linhas de TS/TSX (2.741 arquivos): clients/gui-app 204k, protocol 111k, clients/desktop 80k, clients/traycer-cli 72k, clients/shared 46k. 1.416 arquivos de teste.
• Licença: MIT (LICENSE, 2026 Traycer AI)
• Data da avaliação: 2026-08-02 (app desktop aberto ~junho/2026; a empresa tem produto comercial anterior — extensão VS Code de planejamento)
• Posicionamento declarado: "open-source AI orchestration app for advanced agent orchestration" com BYOA — "Bring Your Own Agent" (README.md)
• Arquétipo observado: cockpit multiplayer para harnesses alheios — o repo aberto é o cliente (GUI/desktop/CLI) e o contrato de wire de um orquestrador cujo processo central (o "Host") e todo o backend são fechados. O próprio AGENTS.md da raiz declara: "Open-source clients, CLI, and protocol. The Traycer Host and cloud backends are not here — the CLI provisions a signed host from GitHub Releases."

Onde o cérebro mora (leitura estrutural, antes das dimensões) #

O teste de inclusão exige loop + ferramentas + contexto + controle no código aberto. Medido:

• Zero código de loop de agente: nenhuma chamada a provedor LLM no repo (grep -rn "anthropic|api.openai" protocol/src clients → só uma string de argv de UI). Nenhum SDK de harness como dependência (grep "claude-agent-sdk|@cursor/sdk|@openai/codex|opencode-ai" **/package.json → nada). Os adapters que dirigem Claude Code/Codex/Cursor/OpenCode/ACP vivem no binário fechado do Host.
• Host = binário assinado provisionado de Releases, construído no repositório interno da Traycer (docs/DEVELOPMENT.md: "Releases are built and signed in Traycer's internal repository"); o CLI verifica assinatura minisign com chave embutida (clients/traycer-cli/src/config.ts, hostTrustedPubkeys).
• Nuvem obrigatória: endpoints authn.traycer.ai / platform.traycer.ai estampados no build (clients/traycer-cli/src/config.ts, clients/desktop/src/config.ts); o override de dev é validado loopback-only e vira código morto em builds shipped. Até o RPC com o Host local exige bearer semeado por traycer login (clients/traycer-cli/src/internal/host-rpc.ts: "The bearer comes from the stored credentials, seeded by traycer login"). AGENTS.md: "make dev-desktop talks to the production cloud — no local backends."
• Inferência própria = SaaS: a assinatura nativa Traycer roteia por um servidor OpenCode por usuário para a rota /inference do backend Traycer (protocol/src/common/schemas.ts:70-76, ACCOUNT_CONTEXT_HEADER).

As dimensões abaixo pontuam somente o que está implementado no repo aberto; contrato de wire que descreve comportamento do Host fechado é citado como evidência de design, não de implementação.

Dimensões #

1. Loop do agente — Nota: 1 #

Não há loop no código aberto: prompt→tool→resultado acontece dentro dos coding agents de terceiros, mediados pelo Host fechado. O que o repo tem é o contrato de eventos de um loop maduro — RuntimeEvent com 30+ tipos (turn.started/completed, tool_call.started/progress/errored com terminationReason, steer.submitted com modos safe_point/interrupt_restart, compaction.*, session.created/resumed — protocol/src/host/agent/gui/agent-runtime.ts, 1.165 linhas) e um acumulador de replay testado (agent-runtime-accumulator.ts). O lado cliente implementa fila de turnos com edição/steer e retry de wake (clients/gui-app/src/stores/chats/chat-session-store.ts, chat-session-wake-retry.ts). Streaming, retry, limite de turnos e detecção de loop: todos delegados ao harness de baixo e ao Host. Nota 1 pelo contrato e pela orquestração cliente de fila/steering; a implementação do ciclo é 100% fechada ou alheia.

2. Entrega de contexto — Nota: 1 #

System prompt, descoberta de AGENTS.md e cache-awareness pertencem aos harnesses dirigidos — o repo não monta prompt nenhum. O que está aberto são os formatadores de texto voltado a agente: mensagens A2A com protocolo de reply explícito (protocol/src/agent/a2a-message-format.ts — "only a reply carrying the responseId completes the request"), comentários de código serializados em XML (protocol/src/comments/comments-xml-formatting.ts), o guia de seleção de agentes injetado com invariante de permissão anexada (protocol/src/agent/agent-selection-guide-format.ts) e o serializador de menções (protocol/src/common/json-content-serializer.ts). O mecanismo central do slogan "Unified Context" — o fake-context seed, arquivo derivado do prefixo do chat que semeia a sessão do harness destino ao trocar de modelo/harness — está apenas descrito no schema (activeSessionChainSchema.coveredUntilMessageId, protocol/src/persistence/epic/senders.ts:105-135); quem o escreve é o Host fechado.

3. Compactação / janela de contexto — Nota: 1 #

Nenhuma compactação própria: o repo apenas transporta e renderiza os eventos compaction.started/completed/errored (com trigger: auto|manual, preTokens/postTokens — agent-runtime.ts:497-529) emitidos pelos harnesses que compactam sozinhos. A contribuição aberta real é a normalização de contabilidade de tokens entre SDKs: contextTokens como numerador canônico do chip "% context left", com o comentário mais preciso do corpus sobre por que Anthropic (cache aditivo) e OpenAI (cache subconjunto) não podem compartilhar denominador (runtimeTokenUsageSchema, agent-runtime.ts:74-80; tokenUsageSchema, protocol/src/persistence/epic/foundation.ts:30-55). Caminho reativo para "prompt too long": inexistente aqui.

4. Design de ferramentas — Nota: 1 #

Traycer não define ferramentas de trabalho — elas vêm dos 18 harnesses. As tools que o produto injeta nos agentes (traycer_a2a/traycer_send_message, traycer_get_transcript, traycer_get_self, traycer_list_comment_threads — nomes visíveis em clients/gui-app/src/components/chat/segments/__tests__/tool-segment.test.tsx:107 e protocol/src/host/agent/contracts.ts) são implementadas no Host fechado. O código aberto faz o trabalho inverso, e bem: normalização da babel de tools alheias — 17 aliases de tools de todo list mapeados a 6 ações (TASK_TODO_ACTION_BY_TOOL_NAME, protocol/src/host/agent/gui/task-todo-tools.ts), tools de entrevista de Claude/OpenCode unificadas (interview-tools.ts), sumário de input de tool por heurística (tool-input-summary.ts) e a regra de que o resultado formatado é byte-idêntico entre tool result do GUI e saída do CLI (protocol/src/agent/agent-roles-format.ts:13-17 — "contract requirement").

5. MCP — Nota: 1 #

Nem cliente nem servidor MCP no código aberto (o servidor traycer_a2a é do Host fechado). O que existe é uma peça incomum: uma superfície de administração remota do MCP dos harnesses subordinados — schemas para listar/mutar servidores MCP do Claude Code/Codex/etc. com transportes, status, deny por tool e fluxo OAuth completo (providerMcpServerSchema, providerMcpAuthTypeSchema, providers.mcpAuth/providers.awaitMcpAuth/providers.cancelMcpAuth — protocol/src/host/provider-native-schemas.ts, provider-native-contracts.ts; painéis em clients/gui-app/src/components/settings/). Traycer gerencia o MCP dos outros sem falar MCP ele mesmo — a execução, de novo, no Host.

6. Permissões e sandboxing — Nota: 1 #

Três modos por agente — supervised/auto_accept_edits/full_access (permissionModeSchema, protocol/src/persistence/epic/foundation.ts:93-107) — mapeados pelos adapters fechados aos sistemas nativos de cada harness, e aprovações relayadas como eventos (approval.requested/resolved, agent-runtime.ts:424-440) com UI de aprovação no chat tile. Sem parsing de comandos, sem allowlist, sem sandbox de SO para os agentes (rodam no PTY/processo do usuário, com a política de quem estiver por baixo). O achado desconfortável: a instrução A2A embutida manda agentes derivados usarem full_access por default — "never infer a more restrictive permission mode from the task" (A2A_PERMISSION_MODE_INSTRUCTION, protocol/src/agent/agent-selection-guide-format.ts:3-5) — escalação por conveniência assumida como norma. Onde o repo é excepcional é na segurança da cadeia de instalação, não do agente: verificação minisign do Host, atestação de install com generation encoding (clients/traycer-cli/src/host/attested-install-runtime.ts), evidência de spawn identity-aware por dev/inode (spawn-evidence.ts) e renderer Electron endurecido (contextIsolation: true, sandbox: true, nodeIntegration: false — clients/desktop/src/electron-main/windows/window-factory.ts:110-122).

7. Memória e estado — Nota: 2 #

A dimensão mais implementada no aberto. Persistência do "epic" (workspace de trabalho) como CRDT Yjs versionado com disciplina de compatibilidade documentada (protocol/src/persistence/, COMPATIBILITY.md): chats, agentes TUI, artefatos com corpos em rooms separados, role claims com normalização Unicode anti-spoofing (role-claims.ts:27-45). Checkpoints por turno com manifesto de arquivos (beforeHash/afterHash, undoable, revert em massa com opt-out por artefato — checkpoint-manifests.ts) e snapshots locais com diff (snapshots.* RPC). Resume/fork por harness com âncoras de sessão específicas por fornecedor (claude --resume <id> --fork-session, codex resume, opencode --session — protocol/src/host/agent/tui/unary-schemas.ts:48-80) e cadeia de sessão ativa que autoriza resumes (activeSessionChainSchema, senders.ts). Worktrees git por agente com scripts de setup por repo (worktree.setRepoScripts; o próprio repo dogfooda em .traycer/environment.json) e binding tab↔host vitalício com clone-not-migrate entre máquinas (protocol/src/persistence/epic/chat.ts:34-41). Sem memória de longo prazo de qualquer espécie — nenhum arquivo auto-gerenciado, nenhuma consolidação.

8. Planejamento — Nota: 2 #

A pergunta desta avaliação: o marketing é "planning layer", e a dimensão 8 é a mais fraca da indústria. Resposta com medida: o repo aberto tem o esqueleto artefatual do planejamento, não o cérebro. Existe e é real: artefatos persistidos spec/ticket/story/review com status versionado e assignee (agente) (protocol/src/persistence/epic/artifacts.ts), hierarquia por parentId, edição colaborativa Yjs e um board visual (clients/gui-app/src/components/epic-canvas/, tiles de review e artefatos); eventos plan.delta/updated/completed com máquina de estados drafting→ready→awaiting_approval→approved/rejected/superseded e approvalId gatekeando (runtimePlanStatusSchema, agent-runtime.ts:255-495); RPC agent.gui.getPlan; todos normalizados de 18 harnesses (todo.updated). O que não existe no aberto: nenhum prompt de planejamento, nenhum código de decomposição spec→tickets, nenhum plan mode imposto (read-only), nenhuma dependência entre tickets (só parent/child). Os planos chegam dos harnesses subjacentes (runtimePlanSourceSchema.harnessId) ou do harness Traycer fechado. Nota 2 pelo modelo de artefatos persistido e aprovação com gate — mais do que quase todo o corpus — mas o "planning layer" anunciado não está neste repositório.

9. Subagentes / orquestração — Nota: 2 #

A identidade do produto, e a razão de estar no Radar. 18 harnesses no enum canônico (guiHarnessIdSchema, protocol/src/host/agent/shared.ts): Claude Code, Codex, OpenCode, Cursor, Traycer, Grok, Qwen Code, Kiro, Droid, Kimi, Copilot, Kilo Code, OpenRouter, Amp, Devin, Pi, Hermes Agent, Oh My Pi (PROVIDER_DISPLAY_NAMES, protocol/src/host/provider-schemas.ts:164-183). Mecanismos documentados no contrato: PTY interativo com resume por CLI para os TUI; SDK/JSON-RPC para GUI (Claude via SDK, Codex via codex app-server, Cursor via @cursor/sdk local — shared.ts:35-43); e ACP como via de entrada em massa — grok agent stdio, qwen --acp, kiro-cli acp, kimi acp, copilot --acp, kilo acp, devin acp, hermes acp (agent-runtime.ts:854-941). A2A implementado no lado aberto: traycer agent create/send/inbox/monitor com threads por responseId (clients/traycer-cli/src/commands/agent-send.ts), inbox durável, role claims ("Planner — authentication migration") e grafo de comunicação com timeline de playback (epic.communicationGraph.subscribe, protocol/src/host/epic/communication-graph.ts; tile em epic-canvas/comm-graph/). Isolamento por worktree por agente. A mediação (entrega, capability matrix, spawn) roda no Host fechado — sem ele, nada disso liga; e a leitura de transcript é capability-gated por harness (protocol/src/host/agent/contracts.ts:223-225).

10. Verificação / evals — Nota: 2 #

1.416 arquivos de teste para ~513k linhas, com preferência declarada por testes integrados sobre unidades isoladas (clients/gui-app/AGENTS.md). O destaque, plausivelmente único no corpus: o gate de compatibilidade de protocolo contra todo baseline já lançado, resolvido em runtime das tags de release (um PR não consegue encolher o conjunto protegido) com tripwire de label para edição dos arquivos de governança — projetado explicitamente contra o anti-padrão "fixture congelada editada no mesmo PR que a quebrou" (.github/workflows/protocol-compat.yml, incidente terminal.defaultCwd #227 citado no próprio YAML). Some-se: testes de supervisor real launchd com filosofia anti-decoração ("a gate that cannot fail is a decoration", real-supervisor.yml), testes de packaging (vitest.config.packaging.ts), CodeQL, OSSF Scorecard, gitleaks, DCO — 11 workflows, 1.328 linhas. O teto é estrutural: sem um único caminho de código que chame um modelo, não há eval comportamental possível — o repo verifica exaustivamente o cockpit, nunca o voo.

11. Extensibilidade — Nota: 1 #

Sem hooks, sem plugins, sem sistema de skills próprio no código aberto. Adicionar um harness exige bump de versão major do protocolo e adapter no Host fechado — os seis enums congelados v1.0→v6.0 (provider-ids.ts, provider-schemas.ts) são a prova de que a extensão é um ato do vendor, não do usuário. O que o usuário estende: binário custom por provider (providers.addCustomPath), args extras de terminal, overrides de env e shell (config-env-*/config-shell-* no CLI), e a gestão dos MCP/plugins/skills dos harnesses subordinados via providers.nativeMutate. BYOA é configuração, não extensibilidade.

12. Interfaces — Nota: 3 #

Onde o repo aberto é de fato o produto. Desktop Electron multi-janela com tray, deep links e updater (clients/desktop, 80k linhas); GUI com canvas de epic — board xyflow com tiles de chat, terminal xterm real (PTY via terminal.* RPC), git diff, PR, review, snapshots e grafo de comunicação (clients/gui-app/src/components/epic-canvas/renderers/ — 204k linhas no pacote); colaboração multi-usuário em tempo real sobre Yjs com ACL owner/editor/viewer (epic.grantAccess/batchUpdateRoles); CLI headless com envelope NDJSON progress/result discriminado (clients/traycer-cli/src/runner/output.ts); ditado por fala com modelo local (speech.ensureModel/speech.dictate); e um transporte remoto E2E-criptografado cliente↔host — Noise-NK sobre mux multiplexado via relay, com o relay cego ao conteúdo (clients/shared/host-client/REMOTE-TRANSPORT.md, protocol/src/crypto/). ACP é consumido como cliente, não ofertado; sem TUI própria — coerente, os TUIs são os harnesses. 177 métodos RPC no registro (protocol/src/host/registry.ts, 5.932 linhas).

Dimensões suplementares (não entram no total 0–36) #

13. Aprendizado / auto-melhoria — Nota: 0 #

Nada no produto aberto: nenhum mecanismo de o agente capturar procedimentos da própria experiência. Dois fatos adjacentes valem registro: (1) a superfície providers.* gerencia skills dos harnesses subordinados (instalar/remover skills no Claude Code de dentro do Traycer — providerSkillSchema, provider-native-schemas.ts), curadoria humana de skill alheia; (2) o processo de desenvolvimento do próprio repo é agent-native — skills-lock.json na raiz pina 12+ skills de registries externos por hash (anthropics/skills, vercel-labs/agent-skills, shadcn/ui…), materializadas em .agents//.claude/ para os agentes contribuidores (clients/gui-app/AGENTS.md, seção "Skills"). O produto não aprende; a fábrica dele, sim.

14. Proatividade / agendamento — Nota: 1 #

Um mecanismo real e um vizinho: claudePendingWakes — wakes agendados persistidos por chat (sessionId, toolUseId, scheduledFor, prompt, reason — protocol/src/persistence/epic/chat.ts:25-33), permitindo a um agente Claude marcar a própria retomada futura, com retry de wake no cliente (chat-session-wake-retry.ts); e os loops agente-a-agente do README, em que agentes se acordam mutuamente por mensagens com expectReply. Sem cron, sem rotinas, sem webhooks no código aberto; a entrega dos wakes é do Host fechado.

Síntese #

Tabela de notas #

Leitura #

• Perfil/arquétipo: cockpit colaborativo de orquestração para 18 harnesses de terceiros, cujo código aberto é a cabine (GUI/desktop/CLI, ~513k linhas de engenharia de altíssima disciplina) e cujo motor — Host, adapters, semeadura de contexto, mediação A2A, inferência — é binário assinado + SaaS fechados.

• VEREDITO DO TESTE DE INCLUSÃO: não passa — é uma casca de orquestração open-source com o cérebro em SaaS. Das quatro peças exigidas, nenhuma está implementada no repo: o loop pertence aos coding agents de terceiros mediados pelo Host fechado (zero chamadas LLM, zero SDKs de harness no package.json); as ferramentas injetadas (traycer_a2a/*) são do Host; a gestão de contexto (fake-context seed do "Unified Context") só existe como comentário de schema; o controle (permission modes, aprovações) é relay para enforcement alheio. A evidência é confessa e verificada: AGENTS.md raiz ("The Traycer Host and cloud backends are not here"), Host provisionado como binário minisign-assinado de Releases construído em repo interno (docs/DEVELOPMENT.md), endpoints authn.traycer.ai/platform.traycer.ai estampados no build com override dev loopback-only (clients/*/src/config.ts), bearer de conta Traycer exigido até para o RPC com o host local (clients/traycer-cli/src/internal/host-rpc.ts), dev contra nuvem de produção ("no local backends"). Offline/self-hosted: não existe caminho — não há backend no repo para hospedar. A avaliação permanece como registro: é o caso mais bem documentado do corpus de "open source" como estratégia de distribuição de cliente, não de harness.

• 3 pontos mais fortes: engenharia de contrato versionado como disciplina de produto (177 métodos RPC com {major,minor} por método, seis enums congelados v1.0→v6.0 com bridges de downgrade, CI que testa contra todo baseline lançado resolvido em runtime — protocol/src/host/registry.ts, protocol-compat.yml); estado colaborativo durável (checkpoints por turno com hashes e revert, âncoras de resume/fork por harness, worktrees por agente, Yjs multiplayer — protocol/src/persistence/); a normalização da babel de 18 harnesses (17 aliases de todo tools, tools de entrevista, semânticas de token Anthropic-vs-OpenAI, supressão de eventos de subagente — protocol/src/host/agent/gui/).

• 2 pontos mais fracos: o cérebro inteiro é fechado — toda dimensão nuclear do benchmark (loop, contexto, compactação, tools, permissões) pontua 1 por procuração, e o "planning layer" que dá nome ao produto não tem uma linha de inteligência no repo; e a postura de segurança de agente é permissiva por design — full_access como default instruído para agentes derivados via A2A com proibição explícita de inferir modo mais restritivo (A2A_PERMISSION_MODE_INSTRUCTION), sem sandbox nem política de comandos própria em nenhuma camada aberta.

• Recurso distintivo: a âncora de sessão por harness — para cada um dos 18 fornecedores, o schema persiste o identificador nativo de resume daquele CLI/SDK (claudeMessageUuid, codexTurnId, grokSessionId de ACP, opencodeUserMessageId… — senders.ts, agent-runtime.ts:790-960), tornando sessões de harnesses alheios retomáveis, forkáveis e re-semeáveis a partir de um único registro colaborativo. Nenhum outro avaliado cataloga a semântica de sessão de 18 concorrentes no próprio contrato de wire.

• "O que roubar": (1) o gate de compat que resolve os baselines protegidos das tags de release em runtime + tripwire de label para tocar em fixtures congeladas (protocol-compat.yml) — a defesa mais honesta do corpus contra regressão de contrato; (2) contextTokens como numerador canônico adapter-normalizado, com a distinção cache-aditivo vs. cache-subconjunto documentada no schema (agent-runtime.ts:74-80) — todo harness multi-provider tem esse bug latente; (3) o protocolo A2A de reply com responseId nomeando o thread e não a mensagem ("one reply with it answers everything on the thread" — a2a-message-format.ts) — semântica anti-spam de conversas entre agentes; (4) default-nest na supressão de eventos de subagente, para que um tipo de evento novo nunca vaze despareado à timeline do pai (subagent-nesting.ts).

• Cláusula de expiração: metade do valor do repo é tradução entre dialetos que só existem por imaturidade do ecossistema — os 17 aliases de todo tools, as tools de entrevista por fornecedor e as âncoras de sessão sob medida já estão sendo comidos pelo próprio ACP que o Traycer adota (8 dos 18 harnesses já entram por * acp); se ACP consolidar sessão/resume/plan como padrão, o catálogo de adapters — o principal ativo do Host fechado — vira commodity, e a casca aberta fica a um passo de servir qualquer mediador. A aposta inversa também vale: o negócio depende de os harnesses continuarem permitindo ser dirigidos por hooks e flags de resume não documentados como estáveis (claude --resume --fork-session, codex app-server) — qualquer vendor que feche essa porta quebra o produto por fora.

Apêndice — Cadeia de suprimentos (dependências sobre membros do corpus) #

Direção: Traycer consome; nada no corpus consome o Traycer. Sem SDKs de harness no package.json aberto — todo consumo ocorre via spawn de CLI/ACP/SDK no Host fechado, mas com o mecanismo documentado no contrato aberto:

Fora do corpus mas no catálogo (registro): Qwen Code, Kiro, Droid (@factory/droid-sdk), Copilot, Kilo Code, OpenRouter, Amp (resume via execute options.continue), Devin — agent-runtime.ts:859-931, provider-schemas.ts:164-183. Sem evidência de qualquer relação com: Goose, Aider, OpenHands, OpenClaw, IronClaw, n8n, QM, LangGraph, CrewAI, OpenAI Agents SDK, software-agent-sdk, Grok Build (o provider grok é o CLI da xAI via ACP, não o Grok Build).