data-centered journal all entries ›
Field Note / Keith Binkly / June 2026

I Hit My Claude Usage Cap and Built the Dashboard Anthropic Didn't Ship

I hit my weekly Claude cap two days early — and the interface could only tell me that I was out, not why. So I built the instrument I actually wanted: historical pace, the heaviest sessions, and a guided tour wired into the page.

Anthropic shows you a usage number. It does not show you the shape of how you got there.

The first time I hit my Claude weekly cap, I hit it two days early — and the only thing the interface could tell me was that I was, in fact, out. Not why. Not which sessions did it. Not whether I'd been creeping toward the edge for a week or fell off it in one heavy afternoon.

That's an instrumentation problem — and instrumentation problems have a fix.

I've built dashboards for a living for more than a decade — first at a tech startup in LA, then inside a traditional financial-services company — so the reflex is automatic. If I can't see the thing, I build the instrument that lets me see it.

The questions I actually had

I wasn't after a sentence that said "usage is high." I knew usage was high. I wanted the shape of it:

That last one turned out to be the interesting one.

The number Anthropic doesn't publish

Anthropic exposes a utilization percentage in a local OAuth endpoint — the same number the Claude app shows in settings — but only as a point-in-time snapshot. No historical series. It's published as an integer, not a decimal. There's no weekly dollar budget, token budget, or quota value handed to you directly.

But store enough point-in-time snapshots, line them up against the usage metrics you already know, and you can approximate the denominator. You can estimate the weekly ceiling the percentage implies.

The number that stopped me: in one weekly window, with no reset in between, my estimated ceiling moved from roughly $6,000 to roughly $4,500.

I can't prove a policy from one account — this is one user's behavior, inferred from local telemetry, observational and not canonical, and I'd treat anyone who quoted it as gospel with suspicion. But it changed how I read the cap. My usage had genuinely gone up, mostly from heavier context-window turns. The ceiling had moved too. I only know that because I'd been storing the snapshots — a live status number would have hidden it completely.

A visual instrument beats a text box right here. I didn't need a paragraph — I needed pace lines, thresholds, the outlier sessions, the shape of the burn.

A dashboard isn't done when the pixels render

Every dashboard builder knows the next part. You ship the thing — filters, charts, cards, controls — and the person you built it for opens it and asks the natural question:

Can you put time on my calendar and walk me through this?

They haven't failed at anything — they've put their finger on something real: a dashboard carries two kinds of work. The first is measurement — the data, the calculations, the encoding. The second is interpretation — where to look first, what a threshold means, what's normal, what changed, what to ignore.

Most dashboards ship the measurement and outsource the interpretation to a meeting. The explanation lives in the analyst's head.

So I tried something simple: what if the walkthrough was part of the dashboard? Not a help doc. Not a Loom that goes stale. Not a wiki page nobody finds. A guided tour built into the page itself — ten stops, each one pinned to the component it explains. Pacing, heaviest sessions, the KPI tiles, comparison windows, historical zoom, context-depth bands, trend toggles, export. It highlights the area and explains the read at the moment you're looking at the thing. Any user, any time, no calendar invite.

Product tours aren't new. But internal dashboards almost never get treated this way — "show the chart" is usually where the job ends, and the explanatory layer stays in the builder's head.

The part that got me: I could just build it.

The self-guided tour, wired directly into the Claude Usage Monitor. The dummy-data demo is live at data-centered.com.

This is the small version of a bigger story

I'll say plainly what I think this is: a tiny example.

I didn't wait for a BI vendor to add the pacing model I needed. I didn't post on a forum asking for a guided-tour component. I had a concrete pain point and enough dashboard scar tissue to know what should exist — and the build path was short enough that trying it was worth it.

No manifesto here — just a working dashboard with a tour button. That's enough, because the argument is in the artifact.

But there's a bigger argument sitting underneath it — about what happens when a dashboard builder is no longer boxed in by the tool's menu. For years the menu was the imagination. That's the part that changed, and it deserves its own piece.

That one's next. Follow along if you build these things too — I want to hear which missing affordance you'd build first.

Technical notes

data-centered.com — field note — published 2026-06-12