Any model routed through /v1/responses (gpt-5.6+ with tools, i.e. the
default gpt-5.6-sol) reported 0 tokens for every call: both
AssistantTurn constructions omitted usage while every sibling adapter
populated TokenUsage. First consumer to notice was the Auto-Approve
reviewer metering; the 2026-08-13 eval report printed 'Tokens: 0 in /
0 out' across ~40 live calls.
_usage_from maps the Responses shape like the Chat Completions adapter:
fresh input = input_tokens - cached_tokens (input_tokens is INCLUSIVE
of the cached share), cached share -> cache_read, output_tokens as-is
(reasoning already included). Defensive reads: compat servers may omit
input_tokens_details; a missing usage object stays None, never a fake
zero. Wired in _parse_response, which both complete() and the stream's
terminal response.completed event flow through - one extraction, both
paths.
Tests: cache split, partial/missing degradation, stream terminal event,
stream-without-terminal stays None. Verified live against gpt-5.6-sol:
call 1 'in=1820 cache_read=0', call 2 'in=3 cache_read=1817' - the
0-token era ends and the cache split reports correctly.
_build_openai: no custom base_url -> OpenAIResponsesProvider; a custom
endpoint (Azure /openai/v1, vLLM, compat gateways) keeps the Chat
Completions OpenAIProvider, as do Ollama and every compat vendor. Verify
path (raw GET /models) and matrix ids are untouched.
/v1/chat/completions rejects function tools with any reasoning_effort
other than none on GPT-5.6, so native OpenAI has run with reasoning OFF.
OpenAIResponsesProvider speaks /v1/responses instead: reasoning + tools
at real effort, streamed reasoning summaries into the existing
reasoning_delta plumbing, and CoT continuity across tool round-trips via
store:false + encrypted reasoning replayed through a new _openai message
sidecar (same extras contract as _anthropic/_gemini). Not routed yet.
Rohit C Prasad