Context budget: offline estimates vs runtime data (re: #4)

[Nubaeon]

Following up on @larachan-dev's question about context budget numbers from #4.

You're right — they measure different things

Fair point. Let me be more precise:

CCO's 12.5K + 13.7K = Offline estimate of config/system prompt tokens that will be loaded. This is a planning tool — "how much space will my config take before I start working?"

The 343K cache_read_input_tokens = Runtime total including conversation history, tool definitions, system prompt, AND config. This is a measurement of what's actually in the context window right now.

These serve different purposes. The issue I should have framed better:

1. The offline estimate is valuable as-is for config planning
2. But it underestimates the config portion specifically because of the @ include issue (16 tokens shown vs 1.2K-6.3K actual)
3. The runtime data (context_window from statusline stdin) could augment the offline view with actual numbers when available

Breaking down the 343K

From our session data (approximate, we don't have per-component breakdown from Claude Code):

Component	Estimated Tokens	How We Know
Claude Code system prompt	~6.5K	Your estimate (reasonable)
Empirica system prompt (via @include)	~1.2K (lean) or ~6.3K (full)	We counted with tiktoken
Skills descriptions in skill list	~500	~30 tokens × 20 skills
MCP tool schemas	~3.1K	Your estimate
Conversation history (compacted)	~200K+	The bulk — this grows with session length
Hook outputs injected at events	~2-5K per event	SessionStart injects bootstrap context
Memory files auto-loaded	~1.6K	MEMORY.md

So the config-specific portion is roughly 15-20K — closer to your estimate than my 343K claim implied. The gap is mostly conversation history, not config underestimation.

What's new in the statusline stdin JSON

Fields beyond what's in the Claude Code docs:

• cost.total_cost_usd — API-equivalent cost (NOT actual spend on subscription plans). Useful for cost awareness but can be misleading.
• cost.total_lines_added / total_lines_removed — Code change metrics
• rate_limits.five_hour / seven_day — Rate limit consumption with reset timestamps
• exceeds_200k_tokens — Boolean, useful for the 200K/1M toggle

The context_window fields themselves appear to be documented, but we found them useful for real-time monitoring. The cache_read_input_tokens specifically tells you how much is being re-sent from cache (scaffolding) vs new content.

Practical suggestion

Rather than replacing the offline estimate with runtime data, consider showing both when available:

Config budget: 15.2K estimated (offline)
Actual context: 34% of 1M (runtime, if statusline data available)

The offline view helps with planning. The runtime view helps with monitoring.

[ithiria894]

Sorry for the late reply — been heads-down fixing bugs and issues from other users the past few days.

You're right that these measure different things, and I appreciate you breaking down the 343K to show the config portion is actually ~15-20K — much closer to our offline estimate than the raw number implied. That kind of honest re-examination is really helpful.

The statusline stdin fields are interesting, but CCO intentionally stays offline — no runtime coupling, no background polling. Adding runtime data would change the tool's architecture from "scan on demand" to "monitor continuously," which is a fundamentally different product.

The offline estimate already handles @ include expansion (recursive, up to 5 levels deep), so the main undercount scenario you described is already covered. Between that and the existing token estimation, I think we're in a good place for config planning accuracy.