> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Limits & quotas
> The caps, sizes, timeouts, and page limits KAOP enforces — what each one is, and what happens when you reach it.
This page lists the limits the Komodor Agentic Operation Platform (KAOP) actually enforces, together
with the response you get at each one. Some are firm; several are adjustable per workspace. Where a
limit is a default you can be given more of, it says so.
**There is no rate limiting.** No endpoint throttles, and nothing in KAOP returns `429`. If a `429`
reaches you it came from an upstream provider one of your agents called. Quota exhaustion is always
`409`; an oversized payload is always `413`.
## Agents
| Limit | Value | Notes |
| --------------------------- | ------ | ------------------------- |
| Active agents per workspace | **60** | Adjustable per workspace. |
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 workspace. |
| 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 workspace. |
| 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 workspace. |
| Absolute run wall clock | **24 hours** | A claimed or running run is failed at this point regardless. Adjustable per workspace. |
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.
```bash theme={null}
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 workspace-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](/reference/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 a workspace.
## 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 workspace | 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](/security-and-governance/identity-and-access/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**.
```bash theme={null}
GET /api/v1/runs/activity/workspace?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 |
## Asking for more
Several limits above are adjustable per workspace — 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](/reference/support).
## Next steps
What each status code means when you hit one.
Requesting an adjustment, and what to include.
Archiving to free an agent slot.
Budgets — the one limit you set yourself.
## Related topics
- [Troubleshooting](/reference/troubleshooting.md)
- [Support](/reference/support.md)
- [What's new](/reference/changelog.md)
- [APIs](/developer-tools/apis.md)
- [Optimize — how it works](/manage-your-agents/optimize/how-it-works.md)