Warning: This file is auto-generated by
mix ptc.gen_docsfrom the Kernel limit catalog. Manual edits will be overwritten. Editlib/ptc_runner/kernel/limit_catalog.exinstead.
Every limit is a positive enforced ceiling; there is no disabled or infinite form. Two documents decide one number. The host document installs the outer ceiling; the application manifest requests the enforced value inside it. With no manifest request the enforced value is the smaller of the effective default listed below and the installed ceiling — which is the installed default below only while the host document does not configure a different one. A manifest may then request any value up to the installed ceiling for the application-narrowable rows — above the effective default as well as below it — and a request above that ceiling is refused rather than clamped.
To raise a limit, edit limits in the manifest. Raising the installed ceiling alone moves the enforced value only while that ceiling is the binding one, and with the installed defaults listed below it is not: a host-only edit leaves the run at the effective default. A run that needs longer than the 30,000 ms run_duration_ms default therefore asks for it in the manifest — ptc.json — and nowhere else:
{ "limits": { "run_duration_ms": 120000, "workflow_timeout_ms": 120000 } }Only when the application needs a value above the installed ceiling — here, above the 1,800,000 ms run_duration_ms ceiling — does the host document, ptc-host.json, need a matching edit, alongside the same request in the manifest:
{ "install": {}, "limits": { "run_duration_ms": 3600000 } }The four heap and concurrency rows are the exception: their installed default equals their effective default because live memory is live_provider_tasks multiplied by a heap ceiling. Raising them is a resource decision, so it requires both a host ceiling above the compiled default and a matching manifest request. A limits-only host document — {"install": {}, "limits": {...}} — is enough; it does not need a fabricated provider.
A breached ceiling names itself, its configured value, and the manifest key that raises it, so the error at the point of failure carries this rule too. A request above the ceiling is refused by name, with both numbers.
An agent loop spends two budgets at once, and only one of them is a clock. max_turns bounds the agent protocol: it limits how many model-and-program turns the loop may attempt, and reserves no elapsed time to finish them. The complete run, including active preflight and every provider wait, must fit inside run_duration_ms; the workflow evaluation that owns the loop must also fit inside workflow_timeout_ms. Raising only run_duration_ms leaves the workflow clock as a separate boundary, so a live agent requests explicit values for both from its expected turn count and model latency.
Time values are milliseconds. Heap values are BEAM process heap words, not bytes. The catalog range is the accepted structural range; practical installations should choose ceilings appropriate to their resources and trust boundary.
Application-narrowable limits
| Name | Meaning | Unit | Effective default | Installed default | Inclusive range |
|---|---|---|---|---|---|
capability_argument_bytes | Encoded arguments crossing a capability boundary. | bytes | 262,144 | 4,000,000 | 1–2,592,000,000 |
capability_result_bytes | Encoded result crossing a capability boundary. | bytes | 1,000,000 | 16,000,000 | 1–2,592,000,000 |
entry_source_bytes | Workflow entry source accepted at the application boundary. | bytes | 262,144 | 4,000,000 | 1–2,592,000,000 |
evaluation_admission_timeout_ms | Wait for the single subordinate-evaluation lease before execution begins. | milliseconds | 10,000 | 600,000 | 1–2,592,000,000 |
evaluation_heap_words | Heap of each subordinate evaluator process. | BEAM heap words | 1,250,000 | 1,250,000 | 1–2,592,000,000 |
evaluation_history_bytes | Each value and the aggregate exact three-value continuation history. | bytes | 1,000,000 | 16,000,000 | 1–2,592,000,000 |
evaluation_memory_bytes | Retained mission definitions across successful turns. | bytes | 2,000,000 | 32,000,000 | 1–2,592,000,000 |
evaluation_timeout_ms | One subordinate mission evaluation, and one interactive REPL form. | milliseconds | 30,000 | 600,000 | 1–2,592,000,000 |
event_payload_bytes | One trace event payload. | bytes | 262,144 | 4,000,000 | 1–2,592,000,000 |
live_provider_tasks | Concurrent provider callback processes and Kernel-owned parallel Lisp workers. | count | 8 | 8 | 1–2,592,000,000 |
mission_capability_calls | Total mission capability calls in one run. | count | 256 | 4,096 | 1–2,592,000,000 |
mission_capability_calls_per_name | Mission capability calls to any one public name in one run. | count | 128 | 2,048 | 1–2,592,000,000 |
normal_event_bytes | Aggregate encoded trace events retained under the normal policy. | bytes | 4,000,000 | 64,000,000 | 1–2,592,000,000 |
normal_event_count | Trace events retained under the normal policy. | count | 256 | 4,096 | 1–2,592,000,000 |
parallel_timeout_ms | One pmap or pcalls operation, clamped by the run deadline. | milliseconds | 60,000 | 600,000 | 1–2,592,000,000 |
protocol_errors | Recoverable agent protocol errors in one run. | count | 64 | 512 | 1–2,592,000,000 |
provider_heap_words | Heap of each provider callback process. | BEAM heap words | 5,000,000 | 5,000,000 | 1–2,592,000,000 |
run_duration_ms | Complete ordinary run after optional provider application admission, including active preflight and Kernel execution. | milliseconds | 30,000 | 1,800,000 | 1–2,592,000,000 |
subordinate_evaluations | Subordinate mission evaluations in one run. | count | 128 | 2,048 | 1–2,592,000,000 |
subordinate_source_bytes | Source accepted by one subordinate check or evaluation. | bytes | 131,072 | 2,000,000 | 1–2,592,000,000 |
subordinate_source_checks | Advisory subordinate source checks in one run. | count | 128 | 2,048 | 1–2,592,000,000 |
terminal_result_bytes | Encoded terminal workflow or mission-session result. | bytes | 1,000,000 | 16,000,000 | 1–2,592,000,000 |
workflow_capability_calls | Total workflow capability calls in one run. | count | 256 | 4,096 | 1–2,592,000,000 |
workflow_capability_calls_per_name | Workflow capability calls to any one public name in one run. | count | 128 | 2,048 | 1–2,592,000,000 |
workflow_heap_words | Heap of the workflow evaluator process. | BEAM heap words | 8,000,000 | 8,000,000 | 1–2,592,000,000 |
workflow_timeout_ms | One workflow evaluation. | milliseconds | 30,000 | 1,800,000 | 1–2,592,000,000 |
Installed-only limits
These operational timeouts belong only to the host document. A manifest cannot declare them.
| Name | Meaning | Unit | Installed default | Inclusive range | Effective identity |
|---|---|---|---|---|---|
doctor_connectivity_timeout_ms | One doctor --connect provider health check. | milliseconds | 10,000 | 100–30,000 | no |
local_preflight_timeout_ms | Whole audited local-preflight phase across selected providers. | milliseconds | 5,000 | 100–30,000 | yes |
provider_cleanup_timeout_ms | Kernel-owned provider cleanup after execution. | milliseconds | 5,000 | 100–30,000 | yes |
selection_validation_timeout_ms | Active validation of selected provider declarations. | milliseconds | 5,000 | 100–30,000 | yes |
Related documentation
- Application-manifest reference explains application narrowing.
- Host-configuration reference explains outer installed policy.
- Building agents distinguishes agent-loop options from Kernel limits.