Limits & quotas
Server-enforced resource bounds and browser lifecycle limits in one place. Each section states where enforcement occurs.
Multipart uploads
Within one renderer, all multipart files share four active client part slots, with Desktop limited to two. Round-robin waiting is bounded to 64 attempts and 45 minutes per queued attempt; expiry fails that upload for an explicit retry. The bundled nginx body-idle backstop is 150 seconds, above the backend's 120-second idle bound. Other clients and platform-edge timeouts still require deployment qualification.
| Bound | Default | Setting |
|---|---|---|
| Concurrent part PUTs holding a PostgreSQL transaction, across API replicas | 2 (range 1–32) | MULTIPART_PART_DB_CONNECTION_BUDGET |
| Admitted part bodies per API replica, through storage persistence | 8 | Fixed |
| Admitted part bodies for one verified member per API replica, across sessions | 4 | Fixed |
| Idle time without a nonempty part-body chunk | 120 seconds | Fixed |
| Total time to receive a part body | 30 minutes | Fixed |
When the budget is full, a part PUT returns 429 upload_busy so the client
can retry it. The limit applies to object-store part calls holding a database
connection, after the entire body is received. A separate memory gate rejects
excess body readers, or more than four for one verified member, with the same
429. Nonempty progress refreshes the idle deadline but never extends the separate
30-minute hard limit. Either deadline returns 503 upload_timeout, which the
supported browser and Desktop multipart transports can retry. A budget rejection may require resending the whole
16 MiB part; sustained contention can exhaust bounded browser retries. Configure one
value across replicas and size it from measured database headroom; see
Capacity.
Multipart upload cleanup
| Bound | Value |
|---|---|
| Session expiry | 24 hours after creation |
| Required idle time before cleanup | 1 hour |
| Candidate scans per cleanup pass | At most 64 |
| Scheduled cleanup cadence | Every 15 minutes |
| Candidate scans per day at uninterrupted cadence | At most 6,144 per worker scheduling cleanup |
| Provider-failure retry deferral | Expiry moved to 1 hour after the failed cleanup |
The daily scan ceiling is not a guarantee of distinct removals: provider failures, revisited sessions and slow passes reduce reclamation. Cleanup is scheduled only with document import enabled. Follow the multipart writer cutover procedure for upgrades and rollback; plan retained bytes from Capacity.
Browser session
| Bound | Default | Setting |
|---|---|---|
| Kaizen inactivity timeout | Disabled; follow Kamiwaza | MEMBER_SESSION_IDLE_TIMEOUT_MINUTES |
| Configurable range | 1 minute to 7 days | MEMBER_SESSION_IDLE_TIMEOUT_MINUTES |
This is a browser-side inactivity policy, not a backend authorization ceiling. On expiry, the SPA removes member data and invokes Kamiwaza logout. A modified client or direct API caller can ignore the timer and remain authorized until Kamiwaza expires or revokes the platform session; Kamiwaza can always end that session sooner.
Chat presence in a background tab
| Bound | Value | Setting |
|---|---|---|
| Hidden-tab grace before an open chat stops counting as watched | 10 seconds | Fixed in the browser client |
| Presence lease time to live | 30 seconds | SHARED_CHAT_PRESENCE_TTL_SECONDS |
An open chat holds a presence lease through its live event stream, and a completion is not added to the member's notifications while that lease exists. Once the tab has been hidden for the grace, the client closes the stream, which deletes the lease, and reopens it from the durable cursor when the tab is shown again. Enforcement is in the browser: the decision rests on the page's visibility state, so a window that is on screen but unfocused still counts as watched, and a browser that freezes a background tab before the grace elapses keeps the lease until the tab is unfrozen or the lease expires. In shared chats, collaborators see the member leave the room's presence after the grace.
Embedded browser sessions
Distinct from the member login policy above: these bound a Chromium instance running server-side in a sandbox worker.
| Bound | Default | Setting |
|---|---|---|
| Egress grant lifetime | 600 seconds | SANDBOX_EGRESS_TOKEN_TTL_SECONDS |
| Idle reap | 900 seconds | Not configurable |
| Worker memory required | 1.5 GB (ships at 4 GiB) | SANDBOX_RESOURCE_MEMORY_LIMIT |
| Captured screen | 800×600 to 3840×2160 | Not configurable |
A session that stays open past the grant lifetime keeps its page but loses network access, because the egress proxy refuses an expired grant. The grant is issued once when the session opens and is not renewed, so with the shipped defaults a session can be reaped for idleness (900s) later than it can stop loading pages (600s). It fails closed rather than open. Raising the TTL widens the window in which a tightened egress policy still applies to an already-open session, so prefer restarting a long session over a long TTL.
The captured screen follows the driver's pane, measured in that member's own device pixels and clamped to the range above. Encoder bitrate scales with the captured area, so a member on a large high-density display costs more to serve than one on a laptop. Size capacity for the displays your members actually use, not for the floor.
Chromium runs without its own sandbox here, because the worker
keeps RuntimeDefault seccomp, drops every capability, and forbids privilege
escalation. Members no longer see Chromium's warning bar about it; the trade
and its consequences are in
Isolation boundaries, which is the page to act on.
Chromium's own service calls — account consistency, autofill,
optimization hints, network time — are disabled at launch. They are not
merely noise: they opened an HTTP/2 session to a vendor front end that a
member's navigation to the same front end then reused, and when that pooled
session aborted the navigation was cancelled with no visible reason. Do not
re-enable them to make some vendor integration work; the browser has no
account and nothing to report. Run SANDBOX_EGRESS_MODE=host_allowlist where
a session must reach only named hosts.
A browser session holds one sandbox worker for its entire life, drawn from the same pool as code execution — unlike a code run, which returns its worker in seconds. Size the pool for concurrent browser sessions. See Capacity.
Chat turns
| Bound | Default | Setting |
|---|---|---|
| General tool-bearing model rounds per turn | 10 | AGENT_LOOP_MAX_CYCLES |
| Additional staged-artifact protocol rounds | 52 | Conservative recovery allowance derived from the 400,000-character total, 8,000-character baseline, begin, and finalize |
| Maximum inactivity during a turn | 120 s | AGENT_LOOP_BUDGET_MS |
| Concurrent tool calls | 1 | AGENT_LOOP_MAX_PARALLEL_TOOLS |
| Conditional correction attempts | 1 (maximum 3) | AGENT_STREAM_CORRECTION_MAX_ATTEMPTS |
| Per-member daily tokens | Unlimited (0); set a positive cap to enforce | LLM_PER_USER_DAILY_TOKENS |
| Assist-path latency | 5.0 s | LLM_LATENCY_BUDGET_SECONDS |
| Pi model output ceiling | 65,536 tokens | PI_MODEL_MAX_OUTPUT_TOKENS |
| Pi model output ceiling range | 1–1,048,576 tokens | PI_MODEL_MAX_OUTPUT_TOKENS |
| Maximum Pi output share of context | 25% | PI_MODEL_MAX_OUTPUT_CONTEXT_SHARE |
| Pi output share range | 1%–90% | PI_MODEL_MAX_OUTPUT_CONTEXT_SHARE |
| Pi answer reserve | 4,096 tokens | PI_MODEL_ANSWER_RESERVE_TOKENS |
| Pi answer reserve range | 1–1,048,576 tokens | PI_MODEL_ANSWER_RESERVE_TOKENS |
| Collaborative input lease | 180 seconds | SHARED_CHAT_INPUT_LEASE_SECONDS |
| Collaborative input lease range | 30–3,600 seconds | SHARED_CHAT_INPUT_LEASE_SECONDS |
Current Kext installs fix the collaborative chat bounds at
their application defaults. Local Compose deployments can override them
through .env; the current Kext environment limit does not expose them.
Exhausting the step budget grants one forced synthesis step rather than failing the run.
The Pi output ceiling applies to every selected deployment. Every request uses
the lower of this operator-owned bound, the authenticated concrete deployment's
declared output capacity when present, and
PI_MODEL_MAX_OUTPUT_CONTEXT_SHARE of its resolved context window. The same
effective value is reserved during prompt admission and bound into the Pi run
manifest, so input plus requested output cannot exceed the deployment window.
A generated compatibility profile cannot widen or narrow that authority. At
the default 25%, a 32,768-token deployment reserves at most 8,192 tokens for
output and retains 24,064 input tokens after the 512-token safety margin.
When an exact authenticated declaration, or its exact canonical-ID operator fallback, enables a reasoning budget, Kaizen caps that budget below the effective output ceiling by the answer reserve. If the reserve is greater than or equal to a selected deployment's effective ceiling, reasoning receives no separate token budget and the full ceiling stays available to the answer. Active collaborative turns heartbeat their input lease, so this ownership window bounds crash recovery rather than turn length.
An exact new-artifact request may use the full existing model-step ceiling even when its selected specialist normally has a smaller discovery allowance. This does not add ordinary action steps. One append's schema is derived from the selected deployment's effective output ceiling after reserving answer space, then capped by the 400,000-character artifact total. The separate 52-round allowance preserves recovery headroom when a model emits smaller pieces. Every append remains sequence-, digest-, owner-, turn-, and execution-fenced.
Context
| Bound | Default | Setting |
|---|---|---|
| Assumed model window | 8192 tokens | CHAT_CONTEXT_DEFAULT_WINDOW_TOKENS |
| Reserved for output | 1024 tokens | CHAT_CONTEXT_RESERVED_OUTPUT_TOKENS |
| Safety margin | 512 tokens | CHAT_CONTEXT_SAFETY_MARGIN_TOKENS |
| Retrieval's share | 0.5 | CHAT_CONTEXT_RETRIEVAL_TOKEN_SHARE |
| Compact when above | 0.78 | CONTEXT_COMPACTION_EAGER_RATIO |
| Compact down to | 0.50 | CONTEXT_COMPACTION_TARGET_RATIO |
Search
| Bound | Default | Setting |
|---|---|---|
| Results returned | 10 | SEARCH_DEFAULT_LIMIT |
| Candidate pool | 50 | SEARCH_POOL_SIZE |
| Results per document | 3 | SEARCH_MAX_PER_DOCUMENT |
| Snippet length | 280 chars | SEARCH_SNIPPET_CHARS |
| Query-embedding latency | 5.0 s, and at most half the per-branch latency | SEARCH_EMBED_LATENCY_BUDGET_SECONDS |
| Per-branch latency | 8.0 s | SEARCH_BRANCH_LATENCY_BUDGET_SECONDS |
| Vector recall factor | 80 | HNSW_EF_SEARCH |
Document uploads
| Bound | Default | Setting |
|---|---|---|
| Uploaded file size | 10 GiB | DOCUMENT_MAX_BYTES |
| New uploads attached to one conversation | 20 | DOCUMENT_MAX_PER_CONVERSATION |
| Documents in one member's library | 200 | DOCUMENT_LIBRARY_MAX_COUNT |
| Stored upload bytes in one member's library | 20 GiB | DOCUMENT_LIBRARY_MAX_BYTES |
Library count and byte quotas are enforced per owner across concurrent uploads,
including uploads from different tabs or devices and multipart completion. If
only one of two distinct files fits the remaining allowance, one is accepted
and the other receives library_quota_exceeded (HTTP 507). This is a terminal
quota rejection, so the browser does not automatically retry it. The member
must make room by deleting documents before retrying; if allowance remains,
fewer or smaller files can fit it. Existing documents keep working.
An exact retry with the same owner, bytes, file name, folder path, and sharing reuses its existing document even at the quota. A different source requires new allowance, and a retry cannot change the existing document's sharing. These library limits govern new uploads; selecting existing library documents for retrieval does not create another upload. See Documents for the member workflow.
Ingestion
| Bound | Default | Setting |
|---|---|---|
| Mini-chunk target | 64 tokens | INGEST_MINI_CHUNK_TARGET_TOKENS |
| Mini-chunk overlap | 16 tokens | INGEST_MINI_CHUNK_OVERLAP_TOKENS |
| Embedding input | 240 tokens | INGEST_EMBED_MAX_INPUT_TOKENS |
| Embedding batch | 16 | INGEST_EMBED_BATCH_SIZE |
| Connector embedding concurrency | 2 lanes | KAMIWAZA_CONNECTOR_SYNC_INGEST_CONCURRENCY |
| Uploaded-document embedding batch | 4 | DOCUMENT_DENSE_INDEX_BATCH_SIZE |
| Batch token ceiling | 4096 | INGEST_EMBED_MAX_BATCH_TOKENS |
| Bulk embedding latency | 120 s | INGEST_EMBED_LATENCY_BUDGET_SECONDS |
| Embedded HTML structured data | 64 MiB | DOCUMENT_HTML_STRUCTURED_DATA_MAX_BYTES |
| Pictures read inside one document | 20 | DOCUMENT_EMBEDDED_FIGURE_MAX_COUNT |
| Text recovered from those pictures | 20,000 characters | DOCUMENT_EMBEDDED_FIGURE_TEXT_MAX_CHARS |
| Embedding cache TTL | 7 days | EMBEDDING_CACHE_TTL_SECONDS |
| Embedding cache rows | 100,000 | EMBEDDING_CACHE_MAX_ROWS |
Live connected-source queries
These are fixed server bounds rather than member- or operator-selected values.
| Bound | Value |
|---|---|
| Requested results | 1–20; default 8 |
| Browse page size | 50 nodes |
| Navigation requests per surface | 32 |
| Opaque-container depth | 4 levels |
| Time per surface | 30 s |
| Concurrent Core requests | 8 |
| Evidence text per result | 12,000 characters |
| Evidence text per call | 40,000 characters |
Reaching a navigation, time, or provider bound returns a partial result. It never widens the member's connector selection or authorization.
External capability broker
These are fixed fail-closed server contracts.
| Bound | Value |
|---|---|
| Sources per owner and workroom | 100 |
| Visible source scan | 1,000; exact endpoint selection queries only its encoded source ids |
| OpenAPI document | 16 MiB |
| Admitted operations per source | 2,000 |
| Concurrent schema refreshes per discovery | 16 |
| Fresh schema metadata | 60 seconds |
| Bounded stale metadata | 15 minutes |
| Signed invocation plan | 512 KiB and 5 minutes |
| Credential form fields | 32 |
| One credential value or certificate field | 1 MiB |
| External request timeout | 30 seconds |
| Browser-result JSON or text | 256 KiB |
| DataHub reference response | 16 KiB |
The schema and result bounds are byte limits, not authorization. Source and endpoint selection, role/workroom checks, approval, signed egress, and the destination service's own authorization still apply below every cap.
Advertised length bounds in a tool schema
| Bound | Value |
|---|---|
Largest maxLength / minLength / maxItems / minItems sent to a model | 1,999 |
A tool parameter's declared limit is a storage bound and may be far larger; this is the largest one Kaizen will advertise. Anything above it is dropped from the schema the model receives, because a locally served model compiles that schema into a grammar and refuses the whole grammar — every tool in the turn — over a single bound that reaches its threshold of 2,000, then answers without it. The rule covers every length and item-count keyword, minimums as well as maximums. Bounds below 2,000 are passed through and can constrain a locally served model. The declared limit is unchanged and is still enforced when the tool runs.
the strip covers length and item counts only. A regular-expression
pattern carrying a large {n,m} quantifier can break the same grammar and
is not rewritten, so keep quantifiers in a published pattern small.
Code execution
| Bound | Default | Setting |
|---|---|---|
| Execution wall-clock | 30 s | SANDBOX_MAX_WALL_SECONDS |
| Output | 1 MiB | SANDBOX_MAX_OUTPUT_BYTES |
| Artifact size | 10 MiB | SANDBOX_MAX_ARTIFACT_BYTES |
| Workspace size | 8 MiB | SANDBOX_WORKSPACE_MAX_BYTES |
| Hashline text file | 2 MiB | server contract |
| Hashline trusted state | 64 MiB | SANDBOX_HASHLINE_STATE_MAX_BYTES |
| Hashline retained paths / versions | 256 / 4 per path | server contract |
| Hashline patch sections / file operations | 32 / 64 | server contract |
| Hashline named registers / register text | 64 / 8 MiB aggregate | server contract |
| Concurrent per member | 2 | SANDBOX_MAX_CONCURRENT_PER_MEMBER |
| Pool ceiling | 32 | SANDBOX_POOL_MAX_ALLOCATED |
| Warm minimum | 3 | SANDBOX_WARM_POOL_MIN |
| Acquire wait | 30 s | SANDBOX_ACQUIRE_WAIT_SECONDS |
| Acquire queue depth | 256 | SANDBOX_ACQUIRE_QUEUE_MAX |
| Lease TTL | 900 s | SANDBOX_LEASE_TTL_SECONDS |
| Dependency install timeout | 120 s | SANDBOX_DEPENDENCY_INSTALL_TIMEOUT_SECONDS |
run_code tool bound | Wall time + install timeout + RPC head-room + 30 s for workspace handling, capped at 240 s | derived; see below |
| Admitted package tool | 180 s, capped at 240 s | PKG_RUNNER_TIMEOUT_SECONDS |
| Package index size | 8 MiB (64 MiB maximum) | SANDBOX_PACKAGE_MAX_INDEX_BYTES |
| Package file size | 100 MB | SANDBOX_PACKAGE_MAX_FILE_BYTES |
| Package broker token TTL | 300 s | SANDBOX_PACKAGE_TOKEN_TTL_SECONDS |
| Egress token TTL | 10 min (4 h compatibility maximum) | SANDBOX_EGRESS_TOKEN_TTL_SECONDS |
| Projected Library documents | 20 | server contract |
| Aggregate projected document bytes | 8 MiB | server contract |
These code-execution bounds do not limit a document selection in Chat.
Selection passes identifiers to query_document, which retrieves only
relevant, authorized chunks. DOCUMENT_MAX_PER_CONVERSATION limits new
uploads accepted into a conversation, not existing Library documents
selected for retrieval. The member's library upload-count and byte
quotas still apply to new files.
The two projection bounds are the sandbox-input envelope, and they apply to the whole set a turn is authorized to read rather than to one file. They are deliberately smaller than the Documents upload limit, because every projected file is materialized for a single run. A member who exceeds either bound is told which bound they reached and which of their files is the largest, rather than being told that code execution is unavailable; a still-processing, failed, or no-longer-readable file is reported the same way. Kaizen never answers a raw-file request from the extracted text instead.
The run_code tool's own bound is derived from the two settings above rather
than configured separately, because it has to outlast the whole run it awaits:
a run that installs a dependency can legitimately take the sandbox wall time
plus the whole install timeout, and the same call restores the workspace before
the run and snapshots the workspace and its artifacts after it. A bound shorter
than that cancels work the worker is still finishing, discards the result it
was about to return, and reports the assistant as unavailable for a run that
succeeded. The fixed 30 s covers the workspace handling, which no setting
governs. Raising the install timeout past the 240 s ceiling therefore does not
extend the tool: the turn's own deadline is the limit, and such a deployment
should lower the install timeout or pre-build the dependency into the sandbox
image instead.
An admitted package tool uses PKG_RUNNER_TIMEOUT_SECONDS for both the package
runner request and the outer agent invocation. While that bounded invocation is
active, it holds the turn's inactivity lease. This gives a cold dependency
install its documented 120-second window instead of cancelling it at the
generic 60-second tool default or 120-second inactivity budget. The shared
240-second tool ceiling still applies.
Table and preview row bounds
Results are trimmed for display, and each of these bounds is reported rather than applied quietly. A trimmed table says how many rows it is showing out of how many exist, and names any column it left out; the model summarizing a chat-canvas table is told the same thing, so it cannot describe a fragment as the whole answer.
This covers the row and column bounds below. Other bounds — the per-cell and per-table character limits, the number of outputs one canvas carries — still apply quietly, so absence of a notice is not by itself a guarantee that nothing was shortened.
| Bound | Value |
|---|---|
| Rows rendered per run-output table | 500 |
| Rows projected into a chat-canvas table | 1,000 |
| Columns projected into a chat-canvas table | 12 |
| Rows read per spreadsheet sheet in a preview | 500 |
A run-artifact preview stopped at the per-sheet row limit says so explicitly, because nothing else in the rendering reveals it; one cut for length instead reports how many bytes of the file it is showing. (The uploaded-document preview is a different surface, paginated by cursor, with no per-sheet bound.)
These are display bounds, not query bounds. The full result is still in the produced file, so downloading it returns everything the tool retrieved. A truncation the retrieval service reported upstream is carried through to the assistant with the result, so it cannot summarize a partial answer as a whole one, and a result already marked incomplete upstream is never re-reported as complete.
Document preview
Text and CSV preview targets 128 KiB pages, with both the range read and a page that must finish one CSV record capped at 256 KiB. An oversized CSV record is reported and omitted rather than split across pages. Browser search applies only to the loaded page.
Pool ceiling, warm minimum, queue depth, and concurrent-per-member bounds apply once per deployment, not once per API replica. Valkey is the authority that preserves those bounds during horizontal scaling.
Document export images
A Word or PDF export embeds pictures the exporting member already owns: an uploaded image, or a file one of their own code runs produced. A reference in the content selects a picture; it never authorizes one.
| Bound | Value |
|---|---|
| Image references resolved per export | 8 |
| Bytes per image | DOCUMENT_IMAGE_MAX_BYTES (5 MiB default) |
| Accepted types | PNG, JPEG, GIF, decided by sniffing the bytes |
| Embedded in PDF | JPEG, and 8-bit PNG without transparency |
| Placed width | The section's printable width (DOCX), 487 pt (PDF) |
A reference past the eighth resolves to nothing, and so does one that is
oversized, unreadable, of an unsupported type, or owned by someone else. Each
renders as its description text and the export still succeeds, so a crafted
document cannot fail an export or turn one into unbounded work. No reference
produces an outbound request: a remote or data: target is dropped before
resolution rather than fetched or decoded.
Renderable artifacts
These are fixed server bounds rather than configurable settings. They apply when the shared runtime normalizes a trusted producer's renderable envelope; validating only the published JSON Schema does not enforce the annotated context-size and depth limits.
| Bound | Value |
|---|---|
| Canonical envelope | 400,000 JSON characters |
| Canonical provenance context | 64,000 JSON characters |
| JSON nesting depth | 12 levels |
| Fields per JSON object | 256 |
| Items per JSON array | 2,000 |
| Characters per JSON string | 100,000 |
| Integer range | -9,007,199,254,740,991 to 9,007,199,254,740,991 |
| Native table rows | 1,000 |
| Native table columns | 24 |
| Security markings or portions | 16 |
Tasks
| Bound | Default | Setting |
|---|---|---|
| Definitions per owner | 100 | TASKS_MAX_DEFINITIONS_PER_OWNER |
| Active Agent loops per owner | 25 | TASKS_MAX_ACTIVE_AGENT_LOOPS_PER_OWNER |
| Agent loop lifetime | 7 d | TASKS_AGENT_LOOP_MAX_LIFETIME_SECONDS |
| Agent loop occurrences | 100 | TASKS_AGENT_LOOP_MAX_OCCURRENCES |
| List page size | 100 | TASKS_MAX_LIST_PAGE_SIZE |
| Dispatch cadence | 5 s | TASKS_DISPATCH_CADENCE_SECONDS |
| Dispatch batch | 100 | TASKS_DISPATCH_BATCH_SIZE |
| Handoff repair batch | 100 | TASKS_HANDOFF_REPAIR_BATCH_SIZE |
| Wait for platform execution authority | 1 hour | TASKS_BLOCKED_RUN_EXPIRY_SECONDS |
| Maximum interval | ~366 d | TASKS_MAX_INTERVAL_SECONDS |
| Misfire grace | 7 d | TASKS_MAX_MISFIRE_GRACE_SECONDS |
| Backfill window | 30 d | TASKS_MAX_BACKFILL_WINDOW_SECONDS |
| Backfill count | 100 | TASKS_MAX_BACKFILL |
| Queued runs per owner | 1000 | TASKS_MAX_QUEUED_RUNS_PER_OWNER |
| Concurrent runs per owner | 10 | TASKS_MAX_CONCURRENT_RUNS_PER_OWNER |
| Retry attempts | 10 | TASKS_MAX_RETRY_ATTEMPTS |
| Retry delay | 24 h | TASKS_MAX_RETRY_DELAY_SECONDS |
| Run runtime | 24 h | TASKS_MAX_RUNTIME_SECONDS |
| Run tokens | 1,000,000 | TASKS_MAX_TOKENS |
| Run cost | 1e9 microunits | TASKS_MAX_COST_MICROUNITS |
| Durable output | 100 MB | TASKS_MAX_OUTPUT_BYTES |
| Test grant TTL (also the draft test model grant's lifetime at rest) | 1 h | TASKS_LOCAL_TEST_GRANT_TTL_SECONDS |
| Execution grant TTL | 30 d | TASKS_LOCAL_GRANT_TTL_SECONDS |
Current Kext installs fix the three Agent loop bounds above
at their application defaults. Local Compose deployments can override them
through .env; the current Kext environment limit does not expose them.
Workers
| Bound | Default | Setting |
|---|---|---|
| Jobs per worker | 4 | WORKER_CONCURRENCY |
| Job timeout | 12 h | WORKER_JOB_TIMEOUT_SECONDS |
| Health interval | 30 s | WORKER_HEALTH_CHECK_INTERVAL_SECONDS |
Corpus Tasks
| Bound | Default | Setting |
|---|---|---|
| Sources | 100,000 | TASKS_CORPUS_MAX_SOURCES |
| Aggregate source bytes | 50 GB | TASKS_CORPUS_MAX_SOURCE_BYTES |
| Aggregate rows/chunks | 100,000,000 | TASKS_CORPUS_MAX_SOURCE_ROWS |
| Partition bytes | 256 KiB | TASKS_CORPUS_PARTITION_BYTES |
| Partition rows/chunks | 1,000 | TASKS_CORPUS_PARTITION_ROWS |
| Partition tokens | 16,000 | TASKS_CORPUS_PARTITION_TOKENS |
| Partitions | 250,000 | TASKS_CORPUS_MAX_PARTITIONS |
| Concurrent partitions in one run | 1 (operator ceiling: 64) | TASKS_CORPUS_MAX_CONCURRENCY |
| Attempts per partition | 3 | TASKS_CORPUS_MAX_PARTITION_ATTEMPTS |
| Model calls | 250,000 | TASKS_CORPUS_MAX_MODEL_CALLS |
| Admitted input tokens | 500,000,000 | TASKS_CORPUS_MAX_INPUT_TOKENS |
| Canonical records | 10,000,000 | TASKS_CORPUS_MAX_OUTPUT_RECORDS |
| Canonical output | 100 MB | TASKS_CORPUS_MAX_OUTPUT_BYTES |
| Combined export storage | 500 MB | TASKS_CORPUS_MAX_STORAGE_BYTES |
| Elapsed time | 24 h | TASKS_CORPUS_MAX_ELAPSED_SECONDS |
Every coverage and provenance API page is capped at 100 records; the Tasks UI
requests 20. The graph Artifact stores no source-derived records. Its viewer
pages the whole graph from /api/task-runs/{run_id}/corpus/graph — at most
1,000 records per page — and checks source access on every page. An unavailable
run cannot supply graph records. The complete ordered JSONL and GraphML remain
streamed downloads. No graph-node ceiling is hard-coded below the record, byte,
model, storage, and elapsed budgets.
Agent grants
| Bound | Value |
|---|---|
| Kamiwaza tools granted to one agent | 100 |
| Connectors granted to one agent | 100 |
| Kaizen's own tools granted to one agent | No fixed ceiling |
These are fixed server bounds on a saved agent definition rather than configurable settings, and they are checked on every save. Exceeding one is refused with the specific list and its ceiling named, and the member sees that text on the agent's build step.
The tool ceiling arrives sooner than its number suggests, because the two sides of the grant chain count different things. An administrator's allow-list in Platform capability tools is written in selectors — one entry can admit a whole surface. An agent grant is written in individual tool names, so when a member turns a surface on in Agent Studio, every operation that surface exposes becomes its own entry. A 32-operation surface is one line for the administrator and 32 of the member's 100 slots, and three such surfaces exhaust the agent before the member has chosen anything else.
Size an agent's grant by counting operations, not surfaces. A member who needs more than a hundred is almost always better served by several narrow agents than by one that can reach everything; see Agent Studio.
Collaboration
| Bound | Behavior |
|---|---|
| Project invitation expiry | 7 days |
| Participant limit | Server-capped; exceeding it fails closed with participant_limit |
| Presence expiry after disconnect | ~30 seconds |
| Active runs per room | Exactly 1 |
| Project pointers per chat | Exactly 1 |
Member circle pictures
These are fixed server contracts rather than configurable settings. The browser refuses the first two before uploading, so a member learns about them immediately; the server enforces all of them regardless of what the browser did.
| Bound | Value |
|---|---|
| Accepted types | PNG, JPEG, WebP |
| Upload size | 4 MiB |
| Source dimensions | 8192 pixels on a side |
| Stored renditions | Square WebP at 512 and 128 pixels |
| Rows per member | 1, keyed on the platform subject |
| Read cache | public, max-age=31536000, immutable, keyed by version |
Resource envelope
Per-service CPU and memory limits are in Deployment topology.
Which bounds to lower first
To reduce blast radius without disabling a feature:
LLM_PER_USER_DAILY_TOKENS— defaults to 0 (unlimited). Set a positive cap to bound daily member model usage.AGENT_LOOP_MAX_CYCLES— bounds general tool-bearing rounds; include the fixed staged-artifact allowance when sizing creation-heavy traffic.TASKS_MAX_*caps — dispatch batch, backfill, queue, concurrency, runtime, tokens, cost, output.SANDBOX_POOL_MAX_ALLOCATED— bounds burst compute.SANDBOX_MAX_CONCURRENT_PER_MEMBER— fairness under contention.
Lowering caps is usually better than turning a feature off: the feature keeps working, with less exposure.