Welcome

Who can see my usage

Shown rather than hidden, on purpose. The chain of managers above you decides who may read your numbers and set your budget, and somebody being measured is entitled to know by whom.

Weekly limit reminders

An email when your Claude or ChatGPT weekly window rolls over, so you know you have your allowance back. mint cannot read these limits: neither company publishes a subscription's weekly allowance to any key mint holds. So you tell it when your window last reset, and it counts forward a week at a time. It never claims to know how much you have left.

Machine tokens

A token lets another application read what you can read here, or push usage into one account. It is shown once, when you create it, and never again: only a hash of it is kept, so it can be revoked or replaced but not recovered. What a read token sees is worked out afresh every time it is used, so if you are moved in the org chart or lose access, it loses it too. The API reference lists every route and which ones a token can reach.

Name

What it can do Read what I can see Push usage into one account

Expires after, in days

Create token

Configured accounts

One row per credential. The last four characters are the only part of a credential this page is ever sent.

People and their token managers

Who reports to whom. Somebody sees their own usage; a manager sees everybody beneath them, and the chain carries on upward, so a manager of managers sees the whole tree under them and the person at the top sees everyone. Usage that cannot be tied to a row here stays "unattributed" on the dashboard rather than being given to somebody.

Add a person

A person here is a consumer of tokens, which is not the same as a sign-in. Adding one does not let anybody in, and it does not move any usage on its own.

Name

Email

Token manager

They see this person's usage, and so does everybody above them.

Add person

name,email,manager
Ada Whitfield,ada@example.com,
Ben Ortiz,ben@example.com,ada@example.com

Set a budget

A budget is an intention somebody stated, not a ceiling a provider enforces, so passing one is a fact to notice rather than an error. Leave a field empty for no budget: an empty field reads "not set" everywhere and never as zero. A typed zero is kept as a zero, because "spend nothing" is a real instruction.

Person

Monthly token budget

Monthly spend cap, in dollars

Save budget

What each provider actually reports

The three providers do not answer the same questions, and this table is the same data the gauges are drawn from. Where a cell says no, the matching figure on the dashboard reads "not reported" rather than zero.

How the numbers are made

Requests per minute

The last complete one-minute bucket from the provider's own usage report, divided by the configured limit. The minute in progress is never used: it reads low for most of its length and then jumps, which looks like traffic collapsing and recovering once a minute.

Input tokens per minute

Uncached input plus cache writes. Tokens read from the cache are excluded, because on every current Claude model except Haiku 3.5 they do not count toward the input limit. Including them would overstate the pressure on a well-cached workload several times over.

Cost

The provider's own cost report, not a price list multiplied by token counts. The two do not reconcile exactly and the providers say so, so this app stores what it was told rather than what it could infer.

The rollup across every account

The panel at the top of the dashboard is one row per model, summed across every enabled account, so the same model called from two accounts appears once. Three things it deliberately does not do. It does not present a total over a mixture of reported and unreported figures as though it were complete: every total says how many accounts it covers and is marked partial when that is fewer than all of them. It does not attribute cost to a model the provider did not attribute it to, because a share worked out from token counts would look like an invoice line and would not be one. And it does not roll up rate limits at all: two accounts at half their limits are not one account at its limit, so headroom stays on the cards, where a number and its own limit sit together.

Nothing here costs you anything

This app never sends a request to a model endpoint. Rate limit headroom could be read from the response headers of a one-token call, and that is deliberately not done: a monitor that spends the budget it monitors is a bug with a good excuse.

Sign-in and roles

Sign-in is decided by my.thermals.app. What somebody may do once they are in is decided here, from this app's own table. The identity token carries no role and none is read from it. Who they are in the org chart, and whose usage that lets them see, is on the People tab.

Audit