Extend `usage` schema with cache / reasoning / duration / cost fields
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Current state
The protocol's usage object is defined at spec/protocol.md lines 262-264:
usage:
input_tokens: number # already documented
output_tokens: number # already documented
total_tokens: number # already documented
These cover the minimal token accounting needed for cost display. They are too thin for current mainstream providers:
- Anthropic reports prompt caching under separate fields (
cache_read_input_tokens,cache_creation_input_tokens). For long-running agents that hit cache 90%+ of the time, ignoring cache vs. non-cache input token counts misrepresents cost by an order of magnitude. - OpenAI o-series (
o1,o1-mini,o3, …) reportscompletion_tokens_details.reasoning_tokensseparately from output_tokens — billing is different. - Anthropic Claude with extended thinking also splits reasoning tokens.
- Turn duration (
duration_ms) is something the bridge/agent can measure locally more accurately than the host (host wall-clock includes spawn + IPC overhead). - Estimated cost (
cost_usd) lets bridges that ship a pricing file surface a single cost number; hosts that don't have a pricing source can ignore it.
Proposal
Add the following recommended keys to the usage schema, all optional:
usage:
# Existing (lines 262-264)
input_tokens: number
output_tokens: number
total_tokens: number
# New recommendations:
cache_read_input_tokens: number # Anthropic cache hits
cache_creation_input_tokens: number # Anthropic cache writes (first-write cost)
reasoning_tokens: number # o1 / Claude thinking
duration_ms: number # Agent-measured wall-clock for the turn
cost_usd: number # Estimated cost; bridge may compute from input/output/cache/reasoning + model pricing
Document them as:
- Optional, forward-compatible. Hosts that don't recognise them MUST ignore them (already a property of the existing recommendation).
- Recommended semantics:
cache_*_tokenscount towardinput_tokensonly if the implementation chooses to. The standard convention isinput_tokens = non-cached input + cache_read_input_tokens + cache_creation_input_tokens, so totals stay consistent. Document this convention explicitly.reasoning_tokensis a subset ofoutput_tokens(when applicable), not additive.duration_msexcludes spawn/IPC overhead — measures the CLI's own work.cost_usdis best-effort; bridges without a pricing source emit no value rather than guess.
Why now
The Node runner currently drops usage entirely (separate bug report). Once that bug is fixed and usage is plumbed through, the field becomes usable. Adding the additional keys now — alongside the plumbing fix — keeps us from having to bump the spec again in six months when Anthropic ships a new token type.
Compatibility
Purely additive. Hosts that already understand the three documented keys continue to work. Hosts that don't understand the new keys ignore them (per the existing forward-compatibility rule).
Cross-SDK
This is a spec change, so it should mirror across both the Node and Python SDKs. The Node fix is the trigger; Python follows.
Suggested labels
spec, enhancement, sdk/python, sdk/node
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with spec/protocol.md lines 262-264, then inspect the Node runner's usage handling and the Python SDK's corresponding schema or serialization path. Add the optional fields with the stated token, duration, cost, and forward-compatibility semantics, and ensure both SDKs preserve them once usage is plumbed through.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, python
- Domain
- api, documentation
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100