I opened SpiderGate's usage page and read a budget of $2,000, a plan called Pro at $49.00 a month, and a ceiling of 1,000 requests per minute.
None of it was real. There is no budget column. There is no Pro plan. Nothing in the database has ever held those numbers. They were placeholders written into a component months earlier, and they shipped, and clients read them.
That is the small problem. Here is the bigger one.
A 200 is not an answer
The same page showed a success rate. It came from the HTTP status code.
A gateway call that returns 200 with an empty body counted as a success. So did a call that returned two thousand useful characters. On a chart they were the same green.
That is not a rounding error. It is the difference between an alias that works and an alias that is dead, and the page could not tell you which one you had.
Then I made the same mistake
When I wrote the plan to fix it, I put a number in it. I said one alias, agent/chat, returned nothing on 62.2% of its requests.
The engineer who wrote the query refuted it.
OpenAI sets the response content to null when tool calls fire. A correct tool-calling turn has zero output characters, by construction. My predicate counted 12,780 healthy turns as failures. The real figure for that alias is 13 requests. Not 62.2%. 0.06%.
Three candidate predicates were measured before one was chosen. They differed by 23 times. I had picked the loosest one, in a plan whose entire premise was that a metric was lying.
The alias that was actually failing was one nobody had looked at. Measured over seven days on 2026-08-24:
alias | requests | hollow | share |
|---|---|---|---|
| 76 | 62 | 81.6% |
| 56 | 27 | 48.2% |
| 1,847 | 400 | 21.7% |
| 20,353 | 13 | 0.06% |
Tiny volume, near-total failure, invisible behind an aggregate that said 81% delivered.
Four states, and one of them is "I don't know"
Every chat turn now lands in exactly one of four states, and the four sum to the total:
delivered — something came back that you can use
hollow — the call succeeded and returned nothing
failed — the call errored
unknown — we cannot tell
The fourth one is the one I care about. Requests older than 2026-08-13 predate the column that records whether anything came back. We could fold them into delivered. Every dashboard I have ever used would.
We do not. They read unknown, the page says so, and the delivered percentage tells you it was computed over the classifiable rows only.
An alias with no classifiable rows reads UNKNOWN with a dash. It does not read 0.0%. A confident zero and a missing measurement look identical on a chart and mean opposite things.
A rolling 30 days is not this month
The old page offered a lookback. Seven days, thirty days.
Nobody thinks in lookbacks. You think in months, because that is how you are invoiced.
This month is now a calendar range, and the totals differ from a rolling thirty days because they are different windows. You can set any custom range, put the previous period beside it, and the page prints back what it resolved in UTC so you can check that it measured what you meant.
While we were there we found the right rail was ignoring the picker entirely. It printed "34,567 of your requests were rate-limited in this window". The measured answer for that window was 32. A factor of 1,080, in a sentence a client reads.
A recommendation that is allowed to say no
The right rail tells you whether to buy more provider keys.
The easy version of that panel always says yes. Errors are up, so add capacity. It is also an upsell wearing a recommendation's clothes.
Each provider now gets a verdict in words. One of them recommends keys and shows a target number. Four of them refuse, each with a reason:
not a quota problem — errors are high but they are not rate limits, so keys will not fix it
the account is capped — the ceiling is on the account, not the key; one more key is refused identically
over-provisioned — you already hold more than the traffic needs
unmeasurable — we cannot tell, and you should not infer either way
The target number is null on every verdict except the one that recommends keys. There is nothing to render on a refusal, because a recommendation that cannot say no is not a recommendation.
Where a provider publishes no limit, the panel labels its own ceiling an estimate rather than presenting a guess as a published fact.
What it still does not know
Three panels report that something is not measured, in those words.
The free, subscription and pay-as-you-go split is not measured, because no endpoint returns a per-key-type request count for one brand. Per-hour latency is not measured, because the hourly series carries no latency field and an hourly line would be one number repeated. A key without a package assigned shows the tokens it has counted and says the window is unmeasurable, instead of drawing an empty gauge.
I left those in deliberately. An empty gauge and "we cannot measure this" look the same and mean opposite things, and one of them is a lie.
Your agent can read all of it
The page is not the only reader. gate_usage, gate_capacity and gate_flow return the same numbers over the same window, so an agent can ask the same questions you can and act on the answers.
That needed @spideriq/mcp-gate 1.10.0, @spideriq/mcp 1.89.0 and @spideriq/cli 1.71.0. On an older pin those two newer tools do not exist and nothing tells you so, which is its own small version of the same problem.
Open Gate → Usage, set the range to This month, and add up the four outcome numbers. They will equal your turn count exactly. That is the whole point: a page you can check.