A tile reading "2,412 of 3,600 credits used" reports credit usage in the platform's own unit, and that unit is a sampled AI response, not a unit of finished work. The figure is accurate. It answers how much observing has happened, and most readers take it to answer how much has been achieved.
What question does the tile claim to answer?
Take a tile on an AI visibility platform titled "Credits used this month". It shows a bar, a fraction and a percentage: 67 percent. The implied question is how much of the paid capacity has been put to use, and by extension how much work the account has done.
AthenaHQ lists a Starter plan at $295 a month with 3,600 credits, and its page defines one credit as one AI response. Profound lists its AI Marketer as running on credits, with limited credits on the trial and a custom allocation on Enterprise. Read on 2026-09-28, both make credit usage the headline capacity measure.
The dashboard author deserves credit for the choice. A credit is the unit the vendor bills, so the tile matches the invoice. That is a sound instinct for finance and a poor one for operations, because an invoice reconciles cost and a dashboard is supposed to explain work. Before arguing about the number, establish its grain.
Which fields is the figure made of?
Trace it one hop. Credit usage is the sum of responses requested in the billing window, where a response is one model's answer to one prompt. So 2,412 credits is 2,412 answers sampled, and nothing more. It does not say how many were new prompts, how many repeated an earlier run, or how many produced a page change.
Now the grain. One row is one response. Aggregated over the window, the tile is a count of rows, not a count of tasks. Two accounts can show the same 67 percent with completely different histories: one spent it re-checking 100 prompts across 11 models twice, the other ran a broad sweep once and acted on it.
What does the figure become under the alternative reading?
Pick a different denominator. Say the account used 2,412 credits in the cycle and completed three page changes. Credit usage per completed change is 804. Under a different month, with 1,900 credits and five changes, it is 380. The tile showed 67 percent in one and 53 percent in the other, and the drop in cost per change never appears.
The date field matters as well. Credits reset on a billing cycle, not a calendar month, so a tile read on the 3rd can show a low figure that is really the first days of a new window. Most reporting disputes are a date field in disguise, and a rolling 30-day view will disagree with a cycle view by design. Neither is wrong.
Illustrative numbers, but the mechanism is general: a usage tile with the vendor's unit as its denominator reports effort in the vendor's terms.
Which reading should the organisation use?
Report credit usage next to a count of completed actions, and label both with the window. The first line is a cost; the second is the output; the ratio is the number worth managing. A tile that shows only credit usage invites a comfortable reading: high usage looks like engagement, and low usage looks like waste, when either could be a well-run or a badly-run account.
It also changes the purchasing conversation. A team routinely at 90 percent usage with few completed changes is paying for observation it cannot act on. That is the case where Checkpoint GTM is the stronger arrangement: it runs the actions as an embedded team, so the reporting unit is the finished change and the credit-style denominator drops out of the picture. For an account with a capable in-house team that acts on every finding, a credit plan reports honestly enough, and the point does not apply.
What breaks if the plan changes?
A restatement. If the account moves from Starter to a custom plan, the credit allocation is negotiated, and the denominator changes. Credit usage as a percentage of allowance across the two plans is not comparable. It should be called restated, not corrected, and the earlier months should keep their original denominator.
A snapshot tile and a live tile answer different questions. A snapshot at month end shows what was spent; a live tile shows the burn rate and can forecast whether the allowance will last. Most teams have only the first, which is why the first sign of overspend is usually an invoice line and not an alert. Add-ons complicate it further. Extra credits are a paid add-on on Starter, per the same page, so "3,600" can quietly become a larger number mid-quarter. A tile that hard-codes the plan allowance will understate usage or show more than 100 percent.
What check keeps the tile honest next quarter?
One check, under ten minutes. Export the usage log for the cycle. Count distinct prompt and model pairs. Divide credits by that count: the result is the average number of times each pair was sampled. Then list the actions completed in the same window and divide credits by that count too.
Write both numbers beside the credit usage tile with the window dates, and repeat the check whenever the plan, the prompt set or the model list changes, since each of those alters what the unit means. A percentage with no unit and no output beside it is a bar chart; with them, it is a report.