Guides
Usage limits
Mobius applies billing and runtime limits to protect organizations from runaway usage. The exact numbers depend on the organization's plan and operator configuration, so treat the app and API as the source of truth for current values.
What can be limited
Limits can apply at several layers:
| Limit | What it prevents |
|---|---|
| Billing run access | Starting new automation work when the organization is out of plan or payment compliance. |
| Monthly credit cap | Unlimited model, action, or worker usage inside one billing period. |
| Per-run step cap | Infinite loops or runaway automation expansion. |
| Artifact quota | Unbounded durable file storage. |
| Rate limits | Bursty API clients overwhelming shared control-plane surfaces. |
What operators see
When billing access is paused, new automation starts are blocked until an org admin restores billing or plan status. Existing views should continue to make history readable where possible.
Usage attribution can name the API key, automation, or category that
drove consumption, depending on the endpoint and internal event shape.
For machine-driven usage, pair usage rows with
audit logs and API-key last_used_at
when investigating an incident.
What to do before production
- Give workers and CI narrow API clients.
- Set key expirations for temporary environments.
- Keep automation concurrency policies intentional.
- Add explicit stop conditions to loops and
wait_for_eventflows. - Delete old artifacts or set retention policies where available.
- Monitor run failures and suspended runs before increasing limits.
Related
- Artifacts include project artifact quota.
- Runs explain run state and event history.
- API keys help attribute machine usage.
- Audit logs show configuration changes that may explain unexpected usage.