fix(dashboard): scale usage calendar intensity by daily volume#425
fix(dashboard): scale usage calendar intensity by daily volume#425SantiagoDePolonia wants to merge 2 commits into
Conversation
The overview contribution calendar bucketed each day by its rank among non-zero days (quartiles), so cell intensity reflected ordering rather than magnitude — a 10K-token day and a 1M-token day could render at the same shade. Compute each day's level relative to the busiest day in the displayed period instead, using a log scale (log(value+1)/log(max+1)). Token counts span orders of magnitude, so a linear ratio would collapse every quiet day to the lightest shade; the log curve compresses busy days and spreads quiet ones, keeping low-volume days distinguishable. Applies to both the tokens and costs views. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe contribution calendar's intensity-level algorithm is refactored: ChangesContribution Calendar Intensity Algorithm
Sequence Diagram(s)Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Confidence Score: 5/5This looks safe to merge, with one small follow-up for tests.
internal/admin/dashboard/static/js/modules/contribution-calendar.js Reviews (1): Last reviewed commit: "fix(dashboard): scale usage calendar int..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| calendarLevel(value, max) { | ||
| if (value <= 0 || max <= 0) return 0; | ||
| // Log scale against the busiest day: token counts span orders of | ||
| // magnitude, so a linear ratio collapses every quiet day to the | ||
| // lightest shade. Logs compress the busy days and spread the quiet | ||
| // ones, keeping low-volume days distinguishable. | ||
| var ratio = Math.log(value + 1) / Math.log(max + 1); | ||
| if (ratio <= 0.25) return 1; | ||
| if (ratio <= 0.5) return 2; | ||
| if (ratio <= 0.75) return 3; | ||
| return 4; |
There was a problem hiding this comment.
0.25, 0.5, or 0.75 cutoffs, or to the value + 1 normalization, can silently shift both token and cost cells into different CSS levels without failing any existing test. Please add tests that cover zero, the max day, and values around each new threshold.
Context Used: CLAUDE.md (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Address review feedback: add unit tests for the new contribution-calendar level math. Covers zero/negative/maxless guards, the busiest day landing at the darkest level, and values probed just around each 0.25/0.5/0.75 log cutoff (using max=65535 so the cutoffs fall on clean value boundaries). Also exercises buildCalendarGrid end to end: levels scale against the busiest day across the whole period, no-usage days stay at level 0, and the costs view uses the same log scaling as tokens. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 participants
Summary
The overview page's contribution calendar (the GitHub-style daily usage grid) shaded each day by its rank among non-zero days (quartile bucketing), so cell intensity reflected ordering rather than magnitude. A day with 10K tokens and a day with 1M tokens could render at the same shade — there was no visual difference between a light day and a heavy one.
This changes the level calculation to be relative to the busiest day in the displayed period, using a log scale:
Token counts span orders of magnitude, so a plain linear ratio would collapse every quiet day to the lightest shade. The log curve compresses busy days and spreads out quiet ones, so low-volume days stay distinguishable while the busiest day is always the darkest.
User-visible impact
Example (max = 1M tokens):
Notes
+1offset suits token magnitudes; for very small cost values (sub-dollar) the curve behaves closer to linear. Flagging in case we later want unit-independent normalization across the log range.🤖 Generated with Claude Code
Summary by CodeRabbit