Usage

/app/usage draws one bar per day for the last 30 days and puts the month's total against your cap above it. A day with no bar had no calls. The label under the chart names the first day, the peak, and the last day.

Where the numbers come from

The live counter is in Redis, one key per scope per window, incremented by the rate limiter on the call itself. That is the number that decides whether a call is allowed. Once an hour a job copies those counters into Postgres, which is what the dashboard reads.

Two consequences follow. Today's bar grows through the day and can be up to an hour behind the calls your agent has actually made. And a call that the limiter refused was never counted, so the chart shows served calls, not attempts.

Every rollup write is an absolute count rather than an increment, so a job restart replays the hour instead of double counting it.

What a row holds

Because the limiter only keeps a month counter for an organization, the daily row is the month total minus the days already closed. That makes each day correct once the day is over and the running day a partial figure until it is.

The per-tool breakdown lives in a separate table, call_stats, folded from the MCP call log with the same hourly job: day, client name, client version, tool, scope kind, calls, and the sum and median of characters returned. It is not on the dashboard yet.

Month boundaries

Windows are UTC. The daily counter for a no-key caller expires at 00:00 UTC the next day, and the monthly counter for an organization expires at 00:00 UTC on the first of the next month. The dashboard builds its month label the same way, so if you are in UTC+9 your usage resets in the middle of your working morning.

Credits do not reset. Only the plan cap does.

What is not recorded

No prompt, no argument, no code, no file. See what is logged for the exact list of fields.