Monthly allowance
100,000 requests a month, free. The allowance resets each month, so it is a recurring budget rather than a one-off trial. To keep going once it is spent, buy a credit package in the console — that is also where your current allowance and remaining balance are shown. Quoting it in requests works because a credit is a request for the two operations that matter here: search and fetch each cost one. Anything priced differently draws more than one credit per call, which is why the rule below still holds — read what a call cost from the response rather than counting calls. Unauthenticated requests are not metered at all. They are capped by the request limits instead, so evaluating without a key does not draw on the allowance.What a call costs
Each billed operation has its own credit price, keyed by SKU:
Two things to keep in mind when you budget against these:
- Prices are per-organization. Read what a call actually cost from the response rather than assuming a flat rate.
- Search mode is not a request parameter. Over MCP an integrator can pin it with
_meta["keenable/overrides"]; otherwise the mode — and therefore which of the two search SKUs applies — is decided per call.
Reading usage per call
Over MCP, every authenticated tool call reports its cost under_meta["keenable/usage"], alongside the result rather than inside the model-visible content:
credits is what the call cost, and paid tells you which bucket it came from — false for the free monthly allowance, true for purchased credits. This is what to attribute cost against per call; see Metadata for integrators for the full field list.
Unauthenticated calls are unbilled and omit the block entirely.
When credits run out
With the allowance spent and no purchased credits remaining,/v1/search and /v1/fetch return 402. Buy a package in the console to resume, or wait for the allowance to reset.