Description
event_msg:token_count carries the full rate-limit block including used_percent, window, reset time, plan type and credit balance. It fires very frequently, so a record per event is waste.
token_usage_record gives three pre-computed rollups: this response, this turn so far, and this thread so far. Diffing cumulative counters by hand is work the transcript already did.
Acceptance Criteria
- #1 Rate limits and credits populate model.Limits for primary and secondary windows
- #2 token_count is sampled for metrics rather than emitted per event, and the sampling rule is documented
- #3 token_usage_record populates per-response usage and carries response_id
- #4 The turn and thread rollups are used rather than re-derived, and a test proves per-response values are not double counted against them
- #5 A session whose cli_version emits no token_usage_record is a finding, not a silent zero
Definition of Done
- #1 just check passes: fmt-check, lint, build, test-short, probe-ci, dashboard-check and docs-links all clean
Implementation Plan
Wave 1 lane 6: write focused tests first, implement Codex limits/agents/compaction only in the assigned files, and return any shared-helper requirement to root; root integrates and runs the final gate.
Final Summary
Rate limits, credits, sampled token counts, per-response usage, and authoritative rollups are implemented with missing-version findings; tests passed.