Lição 3 · Medição comparávelÍndiceEN
Benchmark CLIProxyAPI · Medição comparável

Separe rede de experiência

TTFT, TTFE, TPS e latência só são comparáveis quando começam e terminam no mesmo boundary.

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

Na rede, o relógio começa em t_send. No harness, começa no processo ou no submit. Por isso TTFT de rede e TTFO do harness não são o mesmo número. O overhead do cliente é uma diferença pareada, nunca uma culpa automática 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.

TTFT de rede = t_first_visible − t_send; TTFE = t_first_event − t_send; TPS visível = tokens visíveis ÷ intervalo visível; latência total de rede = t_done − t_send. TTFO e latência total do harness usam process start/exit. Non-streaming não recebe TTFT.

Trecho verificável

network_TTFT = t_first_visible - t_send\nharness_TTFO = t_harness_first_output - t_process_start\noverhead_harness = E2E_harness - network_at_proxy_input

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

Como o overhead do harness é reportado?