Skip to main content

Usage and limits

Every AI verb in the API can be refused by a usage limit — post generation, image generation, and the knowledge/source ingests that summarise or transcribe. There are two: GET /v1/usage reports both before either fires, so a client never has to discover a limit by spending a job on it.

GET /v1/usage

Scope: workspace:read · Rate-limit bucket: read

Response

Read canGenerate first

canGenerate is false exactly when the next AI job would be refused, and blockedBy names the limit responsible (weekly_ai_budget or daily_api_spend_cap). It is worth preferring over the raw meters because two things about them are easy to get wrong:
  • A meter at 100% only refuses when ai.enforcement is block. The other modes (off, shadow, warn) meter without blocking.
  • The daily cap compares spent + the job's estimate against the cap, not spent against the cap — so a workspace with 2¢ of headroom is already blocked for a 5¢ post generation.
canGenerate considers usage limits only. A call can still fail for a missing scope or a plan that does not include the feature.

Why AI is a percentage and storage is bytes

The weekly AI budget is denominated in provider cost, so the number that means something to a customer is how much of the allowance is gone — the same figure the Scripe dashboard’s usage card shows. Storage is a plain quantity and is reported in bytes; the daily API cap is reported in cents because it already appears that way in the spend_cap_exceeded error body and in the published per-plan table.

Project vs pool

With projectId the answer is about that project’s weekly budget and ai.project names it. Without one, ai.project is null and the answer covers the workspace pool. A company page has no budget of its own — it spends from the workspace pool — so passing a company page’s projectId reports the pool, and ai.scope says ai_workspace_pool. That routing is the same one the gate performs, so this read and the refusal cannot disagree.

Field reference