Phase 3: Fix Local Window Estimation — Stop Using now-5h as Fallback Start #38

New Issue

Closed

opened 2026-05-21 00:49:37 -05:00 by null · 0 comments

null commented

2026-05-21 00:49:37 -05:00

Owner

References: remaining-usage-accuracy-review-plan.md — Phase 3

Summary

Pipeline's _build_window() fallback sets started_at = now - 5h, then resets_at = started_at + 5h, which makes reset_in_ms effectively zero whenever gateway status lacks explicit window fields. The reference dashboard uses the oldest recent message timestamp plus five hours, which produces a believable reset time.

Acceptance Criteria

With recent JSONL usage and no gateway status window, reset_in_ms is nonzero and matches oldest included event + 5 hours
Local reset data is labeled as an estimate unless gateway/provider status explicitly provides it

Work

Pass session timestamps into _build_window() or move window construction after session filtering
Fallback reset should be oldest_event_in_window + window_duration, not now
Keep local reset data labeled as estimate unless provider-native reset is explicitly available

Do Not

Do not use backend request time as a synthetic window start when event timestamps exist
Do not present local window reset as provider-native reset
Do not assume every provider uses a five-hour rolling window unless the source says so
Do not include events outside the active window when estimating reset time

Priority: High
Phase: 3

References: [`remaining-usage-accuracy-review-plan.md`](docs/remaining-usage-accuracy-review-plan.md) — Phase 3 ## Summary Pipeline's `_build_window()` fallback sets `started_at = now - 5h`, then `resets_at = started_at + 5h`, which makes `reset_in_ms` effectively zero whenever gateway status lacks explicit window fields. The reference dashboard uses the oldest recent message timestamp plus five hours, which produces a believable reset time. ## Acceptance Criteria - With recent JSONL usage and no gateway status window, `reset_in_ms` is nonzero and matches oldest included event + 5 hours - Local reset data is labeled as an estimate unless gateway/provider status explicitly provides it ## Work 1. Pass session timestamps into `_build_window()` or move window construction after session filtering 2. Fallback reset should be `oldest_event_in_window + window_duration`, not `now` 3. Keep local reset data labeled as estimate unless provider-native reset is explicitly available ## Do Not - Do not use backend request time as a synthetic window start when event timestamps exist - Do not present local window reset as provider-native reset - Do not assume every provider uses a five-hour rolling window unless the source says so - Do not include events outside the active window when estimating reset time **Priority:** High **Phase:** 3