Comece pelo CLIProxyAPI
Separe a capacidade do proxy do que sidecar, harness e UI acrescentam ao caminho.
BENCHMARK-MEASUREMENT-PLAN.md · model-context-matrix.csv · planned-run-manifest.json
A ideia em linguagem simples
O produto sob teste é o CLIProxyAPI em 127.0.0.1:8317. Chat Completions, Responses e Messages diretos medem o proxy. Warp, Codex CLI e Claude Code medem lanes de harness pareadas. Se uma UI não mostra uma resposta que já passou pela rede, isso não vira falha do proxy.
Exemplo recorrente: envie o mesmo pacote lacrado — nonce, checksum e três needles — pelas seis lanes. Se o embrulho muda no harness, você mede a lane também. A analogia quebra porque contexto, tools e thinking têm semântica, não apenas tamanho.
A regra de atribuição usa o menor boundary onde a falha reaparece: provider → proxy → compatibility layer → harness → UI. Uma falha direta e no harness com o mesmo erro aponta para provider ou CLIProxyAPI; direto passa e sidecar falha aponta para compatibilidade; falha antes de transmitir pertence ao envelope do harness.
Trecho verificável
primary_boundary = CLIPROXYAPI_DIRECT_127.0.0.1_8317\nproduct_under_test = CLIProxyAPI routing + translation\nharnesses_are_separate_lanes = true
outputs/BENCHMARK-MEASUREMENT-PLAN.md · outputs/model-context-matrix.csv · outputs/planned-run-manifest.json
O caminho em uma imagem
Teste de recuperação
Qual boundary recebe o ranking principal?