Safe measurement plan · Functional compatibility

Name continuation correctly

Compare resent history, emulated previous_response_id and the streaming limit.

Primary local sources: plan, model matrix, per-cell plan, manifest and sanitized inventory.

The idea in plain language

On the real Chat Completions path, the client resends history and the model must recover a nonce. On non-streaming Responses, the sidecar stores state in memory. On streaming, it does not persist that state: calling this supported continuation would be false.

Think of this measurement as a sealed scale: if you swap the scale or move the object midway, the number loses meaning. The analogy breaks because gateways can also transform the request, not merely weigh it.

The emulated map holds at most 200 states, is volatile and disappears when the sidecar restarts. The benchmark separates three chat turns, two linked Responses calls and streaming without persistence. Each mode gets its own label.

Verifiable excerpt

chat: history resent → supported path\nresponses: previous_response_id → emulated\nresponses stream: state not persisted

outputs/BENCHMARK-MEASUREMENT-PLAN.md · outputs/benchmark-cell-plan.csv · outputs/planned-run-manifest.json

The path in one picture

Warp → sidecar → CLIProxyAPI → provider → proof gate

Retrieval check

Does Responses streaming preserve a session today?