Limits & quotas - Komodor

The Komodor Agentic Operation Platform (KAOP) enforces the limits below and returns a specific status at each one. Some are firm; several are adjustable per account, and where a limit is a default you can be given more of, it says so.

There is no rate limiting on API requests. No endpoint throttles by request rate, and the control plane itself never returns 429. The one place 429 comes from inside KAOP is the managed LLM gateway, once an account’s gateway budget is spent — see Budgets below. Any other 429 reaching you came from an upstream provider one of your agents called directly. Quota exhaustion elsewhere is always 409; an oversized payload is always 413.

Agents

Limit	Value	Notes
Active agents per account	60	Adjustable per account.

The cap is enforced when an agent is created, so you get an immediate, explicit error rather than discovering the limit later:

account agent limit reached (maximum 60); archive or delete an agent before creating a new one

returned as 409. Three things soften it:

Archived agents do not count. Archiving frees a slot without deleting the agent’s history, so the way to make room is to archive rather than delete.
Reusing an existing agent does not consume another slot. Deploying again under a name that already exists reuses that agent — it rotates its token and redeploys, and the active-agent cap does not block it. Authentication, permissions, and validation still apply.
The check is at create time only. Nothing in the live registration or presence path is capped, so an agent at the boundary keeps running normally.

The cap applies to every creation route: creating an agent, minting a worker token, and creating a draft.

Runs

Runs have no count limit. What they have are timeouts, and each one exists to stop a different way a run can hang.

Limit	Default	What it does
Lease window	60 seconds	How long a claim on a queued run is held before it can be re-claimed. A run that sits past it unclaimed is what Stuck unclaimed reports.
Presence window	90 seconds	Nothing heard from a worker for this long and its agent reads offline.
Maximum queue wait	1 hour	A run nothing can serve is failed rather than queued forever. Adjustable per account.
Queue ceiling for batch work	12 hours	Schedule-driven and agent-to-agent runs get a longer ceiling when a healthy worker is simply busy. Adjustable per account.
Offline-agent grace	120 seconds	How long a run waits before failing fast when its agent is already known to be offline, a draft, or failed to deploy. Adjustable per account.
Absolute run wall clock	24 hours	A claimed or running run is failed at this point regardless. Adjustable per account.

The wall clock is a backstop, not a design target. An agent that legitimately needs hours should report progress rather than run silently — a run that produces nothing for hours is indistinguishable from a hang, to you and to the platform.

Per-worker concurrency

A worker runs one run at a time by default. Raise it with AGENTOPS_MAX_CONCURRENT on the worker.

AGENTOPS_MAX_CONCURRENT=4

A value of zero or less is clamped to one rather than rejected — zero does not mean unlimited. There is no account-wide concurrent-run cap; capacity is however many workers you run. An SDK-based worker also stops a single run after 100 model calls, which bounds a reasoning loop that will not terminate.

Knowledge base

Limit	Value	Response at the limit
Document size	10 MB	`413` — “Document exceeds 10 MB limit”
Files per upload batch	20	`413` — “Batch exceeds 20-file limit”
Documents per knowledge base	No cap	—

Ingested formats are PDF, Word (DOCX), Markdown, and plain text. Semantic search additionally requires an embedding provider configured for your deployment; until one is, nothing can be indexed or retrieved — see Troubleshooting.

Payload sizes

What	Limit
Run artifact content	6 MB (`413`)
Worker snapshot payload	6 MB
Evidence batch shipped by a worker	768 KB per batch
Inbound endpoint sample body captured for inspection	8 KB per sample, 50 samples retained

MCP Gateway and OpenAPI surfaces

What	Limit	Configurable
Operations parsed from one OpenAPI document	1,500	Yes, by environment variable
Operations you may enable from one document	200	Yes, by environment variable
OpenAPI document fetched over the network	5 MB	Yes
OpenAPI document stored	2 MB	Yes
Generated tool definitions per document	8 MB	Yes
Response returned from one OpenAPI-backed tool call	1 MB	Yes
Credential vends per run	5	No

Tool output returned to an agent is truncated rather than rejected: long text is cut at a fixed length, collections are capped, and nesting is bounded — so an enormous response degrades into a usable one instead of failing the run.

Credentials

The limits are on a credential’s shape, not on how many you may have:

Limit	Value
Keys in one multi-key credential	64
Key name length	128 characters
Value length	10 KB per key
Total credential size	64 KB

There is no cap on the number of credentials in an account.

Memory

Limit	Value
Memory title	200 characters
Memory body	4,000 characters
Memories created in one batch	200
Archived memory retention	90 days
Page size	200 maximum; 100 by default
Maximum offset when paging	10,000
Statistics window	90 days

Triggers and schedules

A cron expression is validated for syntax when you save it, and rejected with 422 and the expression quoted back if it is invalid. A cron-and-timezone pair with no single equivalent in UTC — a daylight-saving edge case — is rejected the same way.

No minimum interval is enforced, so a once-a-minute schedule is accepted. One minute is the practical floor: schedules are driven at minute granularity.

API keys and sessions

Limit	Value
API key expiry	Optional and caller-supplied. No default expiry and no maximum lifetime — a key created without one never expires.
API keys per account	No cap
Browser session lifetime	24 hours

An expiry must be an ISO 8601 timestamp, must carry a timezone offset, and must be in the future; each of those is a 400 with an explicit message.

A key with no expiry never expires. Set one deliberately on anything long-lived, and see API keys for rotation.

Reading and paging

Endpoint family	Default page size	Maximum
Runs	100	500
Chat sessions	100	500
Quality and evaluations	50–200	500
MCP Gateway listings	100	500
Notification sinks	50	500
Audit log	100	200
Memory	100	200

Two related bounds: a free-text search parameter is capped at 200 characters, and a bulk lookup by run id accepts up to 500 ids.

Analysis windows

Every endpoint that takes a window_days parameter — fleet activity, spend, quality, insights, per-agent observability — accepts 1 to 365 days and defaults to 30.

GET /api/v1/runs/activity/account?window_days=90

The authorization decision log is the exception: it is queryable over a window of up to 720 hours, which is 30 days.

Workflows

Limit	Value
Maximum duration of a step waiting on a human decision	30 days
Condition nesting depth in a workflow definition	32
Failure-reason text stored on a step	2,000 characters

Budgets

Budgets are the one limit on this page priced in dollars rather than a count or a size. Three cap the spend of everyday runs, each enforced in a different place:

Budget	Caps spend for	Where it’s enforced	Reaching the cap, with pausing on
Agent budget	One agent	Control plane, checked at dispatch and mid-run	New runs are cancelled before they execute; a running run is terminated
Workflow budget	One incident workflow	Control plane, checked when the workflow is about to start a run	New incidents are not investigated; a run already in progress is untouched
Account gateway budget	Every model call routed through the managed LLM gateway	The gateway itself	Every further model call is refused with `429`

Agent and workflow budgets

Both are configured the same way — a cap per time window and a choice of what happens when it is reached: keep running and notify, or pause. A pause is recorded, not returned as an HTTP error: a blocked agent run is cancelled before it executes, and its run page reads Blocked by budget before execution started; a blocked workflow start marks the incident as not investigated, naming the budget, its cap and its reset time. What differs is what blocking actually stops:

An agent budget exempts a manual run. Starting the agent yourself from the console still works while its budget is exhausted; only its triggers and API-driven runs are blocked. A workflow budget has no such exemption — an exhausted workflow budget blocks every way of starting it, manual invocation included.
An agent budget reaches into a run already underway: a background sweep cancels a running run within about a minute of spend crossing the cap. A workflow budget does not — it is checked only when a new run is about to start, so a run already in progress keeps going regardless of spend.
An incident pipeline’s run is skipped, not queued. When an incident fires against a workflow whose budget is exhausted, the incident is marked skipped with a note naming the budget and its reset time, instead of waiting for the window to turn over.

Choosing to notify and keep running blocks nothing: an alert goes to the budget’s notification sink at the threshold and again at exhaustion, and spend keeps being tracked against the cap. See Agent spend attribution for how to set either one.

Account gateway budget

Routing an agent’s model calls through Komodor’s managed LLM gateway, instead of a provider key you supply, means the account can carry a single spend cap across every agent that uses it. It is set by Komodor, not by you — see its spend and reset window, read-only, on Providers; ask Support to have it raised.

This is the one place 429 comes from inside KAOP. Once the account’s gateway spend reaches the cap, the gateway refuses every further model call routed through it with 429, until the window resets — a run making one fails at that call rather than being stopped by the control plane. Models registered under Your providers are priced at zero on the gateway, so they never draw this budget down, and an agent that calls an LLM gateway you manage never reaches it.

Asking for more

Several limits above are adjustable per account — the agent cap and the run timeouts in particular. If one is blocking you, work out which figure you are actually hitting first (a 409 on agent creation is the cap; a 413 is a payload; a 422 is validation), then see Support.

Next steps

Troubleshooting

What each status code means when you hit one.

Support

Requesting an adjustment, and what to include.

Agent spend attribution

Budgets — the one limit you set yourself.