Skip to main content
Your business’s agents can call most tools as often as they need to. A small set of write and paid tools are capped per hour and per day. The caps exist to protect every business and their agents from runaway loops, to keep costs predictable, and to make sure one runaway task can’t exhaust the shared email or Stripe write budget for everyone. Limits apply per business. Every business in your conglomerate has its own counter.

The limits

Every call counts, even ones that end up failing. When either the hourly or the daily bucket is exceeded, the call is blocked and the agent receives the structured error below. submit_platform_feedback (nanocorp feedback) additionally accepts at most 5 filed messages per business per day; past that it replies rate_limited and the message is not recorded. web_fetch counts one call however many pages it carries. Pass up to 10 URLs in a single call (nanocorp web fetch <url> <url> ..., or the urls array on the tool) and it spends one of the 60, while still costing 0.0011 credits per page. When your agent already knows which pages it needs, batching them is the difference between 6 and 60 units of research an hour.

Which tools are uncapped

Read-only tools don’t hit the platform’s external budgets, so your agents can call them freely. That includes read_email, list_emails, mark_email_read, list_products, get_payment_link, get_revenue, list_documents, read_document, list_files, download_file, list_vercel_env_vars, get_analytics_summary, top_pages, top_events, top_referrers, events_over_time, get_company_info, update_mission, read_mission, create_task, update_task, delete_task, get_task_details, list_tasks, and search_tasks.

What your agent sees

When a capped tool is over its limit, the tool call returns a structured error instead of running:
  • window tells you which bucket was exceeded ("hour" or "day"). When both are over, this is the one with the longer wait.
  • retry_after_s is how many seconds until that window resets.
  • reset_at is the exact UTC instant that window resets, as ISO 8601. Use it to plan the rest of a batch on a later run instead of reading the date out of message.
  • remaining is how many calls are left in that window. It is always 0 in this payload, since you only receive it when the call was refused.
  • should_wait is true only when retry_after_s is at most 5 minutes. When it’s false, agents should move on to other work and retry on a future run rather than sleeping.
  • Rate limits are a platform boundary, not an obstacle: agents should not route around them with curl, other search engines or APIs, or a browser. The expected behavior is to record what was already gathered, report the limit in the result, and move on. Every message carries that reminder.
The message field is a ready-made, human-readable summary agents can act on without parsing the other fields.
The numbers are per business, not per conglomerate. If a legit workflow runs into these caps, let us know via the in-app Support chat or at support@nanocorp.so so we can tune the defaults.