[FEATURE]: split token usage inside a step (system, schemas, each tool result, reasoning, output) #58716

Today I can see per-step and per-turn cost in debug.turn_tokens (#53121), and every assistant message carries an aggregate tokens object with input, output, reasoning, cache read and cache write. What I cannot see is which part of a single step produced those tokens.

That gap gets expensive at the sizes I run. Last seven days on this machine: 16,910 requests, average context 126,169 tokens, 2.13B cached tokens against 92.9M fresh. Once the context is that big, the only question I actually have is "what is inside the 126k", and the aggregate cannot answer it. A step that fetched one web page and a step that carried 180 unused tool schemas look identical.

A concrete example from this week. One MCP server here advertises 207 tools and its tools/list payload is 1,033,358 tokens. With codemode on that never enters my context; with it off it enters all of it. From inside the session I could not tell which was happening: the per-step numbers looked similar, and I had to measure the server separately over stdio to find out. That measurement should not be necessary.

Code Mode makes the blind spot worse, which is why I am filing this separately from #58708. One execute step can hold fifty tool calls run in the sandbox. The step total stays small, the work was large, and nothing in the transcript says which tool returned the 40k.

What would be enough

Smallest useful increment first:

1. Bytes per tool result. Every tool part already stores its content. Exposing its byte count through the API (and in debug.turn_tokens) would let me estimate tokens without a tokenizer, and it is cheap to record.
2. Tokens per part when the provider reports them. Input before and after, cache read and cache write, attached to the part rather than the message.
3. A per-step attribution line: system, tool_schemas, context_replayed, tool_results[n], reasoning, output. That is the shape of the question I am actually asking.

Item 1 alone would have answered my case.

Questions

• Is the per-part byte count already stored somewhere I have not found? session_message.data has the content, so the data exists; it just is not surfaced.
• Would adding a tokens field to the part (or a bytes field for tool results) fit the current schema, or is the preference a separate read endpoint? [FEATURE]: /context — detailed token/cost breakdown panel per session component #41908 asked for a /context panel and was closed as not planned, so I would rather build on what the API already returns.

Related: #58708, #53121, #42295.