Rate limits
Each API key is rate-limited independently, across three buckets.
| Bucket | Default (per hour) | Tools |
|---|---|---|
| Builds | 30 | build_system, update_asset |
| Reads | 300 | list_my_assets, describe_my_workspace, query_records, check_enrichment |
| Operates | 60 | confirm_save, add_record, update_record, trigger_workflow, send_via_integration, run_agent, run_enrichment |
When you hit a limit
A throttled call returns a tool failure with code rate_limited and a retry_after (seconds):
{
"status": "failed",
"error": { "code": "rate_limited", "message": "Operate limit reached. Try again in 42s.", "retry_after": 42 }
}
A well-behaved host waits retry_after seconds before retrying. Reads are deliberately generous so your AI can explore the workspace freely; operates are tighter because they have real side effects.
Raising the limits
A workspace Admin or Owner can override the per-bucket limits on any key: set them in the Advanced section of the key wizard when generating, or contact support for a workspace-wide increase.
Rate limits protect both your workspace and the third parties you operate through. send_via_integration, for example, is also subject to the sending limits of the provider behind it (Gmail and Slack enforce their own quotas), so a generous Tiny Command limit won't bypass those.