feat: use context_window data from Claude Code input for context widgets

[Jaahuo]

Summary

• Extract token metrics from the context_window object provided by Claude Code v2.0.65+ instead of parsing transcript JSONL files
• Add input-parsers.ts utility with extractTokenMetricsFromContextWindow() function
• Update ContextPercentage and ContextPercentageUsable widgets to use new data source
• Fall back to JSONL parsing when context_window is not available for backward compatibility

Test plan

• Unit tests added for extractTokenMetricsFromContextWindow() in input-parsers.test.ts
• Updated tests for ContextPercentage and ContextPercentageUsable widgets
• Manual testing with bun run example using updated payload
• Verify backward compatibility with older Claude Code versions (no context_window)

Closes #126

🤖 Generated with Claude Code

[EthanJStark]

This PR addresses a critical need: using Claude Code's native context_window data instead of parsing transcripts. The work is solid, but I'd like to propose a consolidation with PR #172 that addresses all 7 related issues in a single, unified effort.

Context

PR #172 fixes the [1m] suffix check to be model-agnostic (currently hardcoded to Sonnet 4.5), which is complementary to your context_window support. Together, they can close:

• Bug: Sonnet 4.6 with [1m] suffix reports wrong context percentage (uses 200k instead of 1M) #180, Context percentage for Opus 4.6 1M #164, Context percentage incorrect for non-Sonnet models with [1m] suffix #171: Wrong context % for non-Sonnet 1M models (fixed by PR fix: recognize [1m] suffix on all models, not just Sonnet 4.5 #172)
• Feature request: use context_window from Claude Code input when available #126: Use native context_window data (fixed by this PR)
• Context tokens and context percent are underreported #109, [BUG] Statusline always showing 100% usable context and 0 context #140, High CPU usage due to full transcript file parsing on every status line render #137: Context underreporting, CPU usage (both)

Architectural Feedback

Your PR's approach (computing percentages in extractTokenMetricsFromContextWindow and changing getContextConfig return type to a bare number) works, but I'd suggest a slightly different layering:

Your approach:

• Bakes percentages and contextWindowSize into TokenMetrics at parse time
• Changes getContextConfig from {maxTokens, usableTokens} to number (API churn)

Proposed approach:

• Add contextWindow as a separate optional field on RenderContext
• Widgets check contextWindow first, then fall back to tokenMetrics + getContextConfig
• Preserves existing APIs and maintains cleaner separation of concerns
• Easier to reason about: "this is raw data from Claude Code" vs "this is calculated metrics"

Next Steps

PR #181 is now open on fix/1-million-ctx-bug and incorporates:

• Your formatDurationMs extraction
• Your cost.total_duration_ms session clock optimization
• A cleaner contextWindow integration that avoids API changes
• Comprehensive test coverage for all scenarios

Proposing to close both PRs in favor of PR #181.