Status: Runnable

Verification runtime limits

These limits protect a server that runs Verifiers for many tenants. They are environment variables on wyrd-server, read once at startup. They have no TOML equivalent. Configure the verification runtime covers installing the worker and sizing a deployment.

Settings

Startup rules

• Limits are positive integers. _MIB and _KIB are binary units (1 MiB = 1,048,576 bytes); _MS is milliseconds.
• An unset variable uses its default. Changing any value takes a restart.
• The server refuses to start, naming the variable, when a value is empty, is not a positive integer, or overflows once scaled to bytes. WYRD_VERIFICATION_ENABLED accepts only 1 or 0.
• It also refuses to start when settings contradict each other:
  • MONTY_MIN_WORKERS above MONTY_MAX_WORKERS;
  • MONTY_MEMORY_MIB at or above MONTY_PROCESS_MEMORY_MIB;
  • MONTY_POOL_MEMORY_MIB below MONTY_PROCESS_MEMORY_MIB;
  • MONTY_PROCESS_MEMORY_MIB too small for MONTY_MEMORY_MIB plus Monty’s 4 MiB allocator headroom;
  • FILE_MAX_MIB above FILES_MAX_MIB;
  • WORK_WRITE_MAX_MIB above SCRATCH_MAX_MIB.
• When the runtime is enabled, the server refuses to start with hosted Verifier blocks could not start if the worker binary is missing or the first MONTY_MIN_WORKERS workers cannot start.
• No setting disables a limit or an isolation protection.

A Verifier can lower a limit for one slot, such as max_bytes on a media slot, never raise it. Step, Agent, and request deadlines apply too; the earliest one wins.

Which processes run Verifiers

A process hosts the runtime when WYRD_VERIFICATION_ENABLED is 1 and its role serves the API. Every other process starts no worker, and its verification routes answer WYRD_SERVER_503_SERVICE_UNAVAILABLE. Each hosting process has its own limits, workspaces, and worker pool.

Python workers

code actions and checks, and an Agent’s code.run calls, run in a pool of wyrd-server subprocess worker processes. There is one pool per server process, shared by every tenant; no interpreter state is shared. Agent checks, model calls, and other tools never hold a worker.

• Each Python operation gets a fresh worker, which is killed when the operation ends. Files in /work persist across the code.run calls of one step attempt; nothing persists across attempts, steps, or executions.
• At most MONTY_MAX_WORKERS operations run, after the memory cap below, and MONTY_MAX_WAITERS more wait. An operation beyond that is refused at once; nothing queues in memory.
• An operation waits for a worker only within its own remaining deadline, at most CODE_TIMEOUT_MS.
• A refused operation, one that found no worker in time, or a step that found every workspace (MAX_WORKSPACES) taken means the process is busy, not that the code failed. Nothing is judged and no retries are spent: the whole execution stops. A queued execution stays queued under the same ID, its attempt is not counted, and it runs again when capacity frees. A direct verify call answers WYRD_SERVER_503_SERVICE_UNAVAILABLE; retry it later or on another process. An Agent’s code.run refusal ends the Agent step the same way, cancelling its other pending tool calls.
• AGENT_CODE_BUDGET_MS is reserved before each code.run call waits, and does not reset across tool calls or step retries. Once it is spent, code.run returns an error to the Agent.
• A Python exception, memory exhaustion, a timeout while running, or a crashed worker fails the operation without a retry. The server keeps running.

Memory

Memory is bounded the same way on every platform, without OS limits:

• Each worker’s allocator stops its heap at MONTY_MEMORY_MIB plus Monty’s 4 MiB headroom above the worker’s own baseline. Code that allocates past it raises MemoryError and the operation fails, never passes.
• The server counts every live worker, idle or busy, at MONTY_PROCESS_MEMORY_MIB, and keeps at most MONTY_POOL_MEMORY_MIB / MONTY_PROCESS_MEMORY_MIB alive, rounded down. At the defaults that is 2048 / 384, so 5 workers live at once even though MONTY_MAX_WORKERS is 8. MONTY_MIN_WORKERS is lowered to the same cap.

Memory used by the server itself, by extraction, by model responses, and by file and tool buffers is outside the pool ceiling: give the server headroom beyond it.

Isolation

Always on, whatever the settings, and identical on macOS and Linux:

• Workers start with an empty environment, so no credential reaches them.
• Sandboxed Python has no host files, network, subprocesses, environment variables, host packages, or callbacks into the server. Every operating-system call is a request the server answers or refuses.
• The server answers file calls only from the step’s own workspace: /inputs is read-only, and /work writes stop at the space left under WORK_WRITE_MAX_MIB and SCRATCH_MAX_MIB.
• A worker serves one operation and exits.

Errors

Last updated October 18, 2026