Timeline data does not accurately reflect actual usage patterns

[GalDayan]

Bug Report

Issue: The "Total Usage Over Time" chart does not accurately represent actual agent usage. Real work periods are shown as small spikes while other periods show disproportionately large activity.

Expected:
If significant work happened from 10:00-12:00 (Israel time), that period should show a prominent spike in the chart.

Actual:

• Heavy usage periods (10:00-12:00) show minimal activity
• The chart shows a large spike at Mar 12 05:00-07:00 instead
• Data distribution doesn't match actual usage patterns

Screenshot:
See image showing discrepancy - large spike at wrong time, minimal activity during actual heavy usage.

Possible causes:

1. Timezone handling issues (sessions recorded in UTC but displayed incorrectly)
2. Cost/token aggregation logic not reflecting actual session intensity
3. Session bucketing (hourly grouping) miscalculating totals
4. Chart data filtering excluding valid sessions

Priority: P1 — affects core analytics reliability

Related:

• PR fix: demo/mock data respects time window filters and zoom #57 fixed timezone issues in date parsing, but aggregation logic may still be off
• Should verify that session.cost and session.tokens are being summed correctly per time bucket
• Need to validate that all sessions in a time range are included in the bucket calculation

[GalDayan]

Root Cause Analysis

The bucketing logic in /api/analytics uses s.startedAt to assign each session to a single time bucket. This means a session that started at 05:00 UTC but ran until 10:00 UTC gets its entire cost and tokens attributed to the 05:00 bucket.

Why it looks wrong

If you worked heavily from 10:00–12:00 local time, but the underlying sessions were started earlier (e.g. long-running agent sessions), all cost/tokens show up at the start hour — not when the actual work happened.

The fix (two options)

Option A (simpler): Bucket by lastActivityAt instead of startedAt

• Attributes cost to when the session was last active
• More accurate for short sessions, still imprecise for long ones
• One-line change in getBucketKey(s.startedAt) → getBucketKey(s.lastActivityAt)

Option B (proper): Distribute cost across the session's active duration

• Calculate time span from startedAt to lastActivityAt
• Spread costUsd and tokenCount proportionally across all hourly buckets the session spans
• More accurate but more complex

I'd recommend Option A as a quick fix (ship in PR #57) and Option B as a follow-up if we need higher fidelity.

Both startedAt and lastActivityAt are already available on every session object (backend/src/sessions.ts:60-61).