Lição 6 · Comportamento funcionalÍndiceEN
Benchmark CLIProxyAPI · Comportamento funcional

Meça a continuação real de cada lane

Reenvio, estado remoto, resume local e compaction não são a mesma forma de memória.

Fontes locais primárias: BENCHMARK-MEASUREMENT-PLAN.md, model-context-matrix.csv e planned-run-manifest.json.
BENCHMARK-MEASUREMENT-PLAN.md · model-context-matrix.csv · planned-run-manifest.json

A ideia em linguagem simples

Chat e Messages diretos reenviam histórico. Responses usa previous_response_id quando realmente suportado. Warp mede sua sessão real e, à parte, a emulação do sidecar. Codex usa codex exec resume; Claude Code usa --resume ou --continue.

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.

Três turnos recuperam nonce e checksum; o tap prova quantos tokens foram enviados. Compaction, mapa volátil, estado local e reenvio total recebem rótulos distintos. O benchmark não promove um mecanismo a outro só porque a resposta final parece correta.

Trecho verificável

direct_chat/messages = explicit_history\ndirect_responses = previous_response_id when proved\ncodex = exec resume · claude = --resume/--continue

outputs/BENCHMARK-MEASUREMENT-PLAN.md · outputs/model-context-matrix.csv · outputs/planned-run-manifest.json

O caminho em uma imagem

UI / CLIobserved outputharnessWarp · Codex · Claudecompatibilitysidecar / envelopeCLIProxyAPI127.0.0.1:8317providerdirect Chat · Responses · MessagesPRIMARY BOUNDARY
Exemplo recorrente: o mesmo nonce + checksum percorre cada lane; a falha pertence ao menor boundary onde reaparece.

Teste de recuperação

O que o tap deve provar na continuação?