Runtime limits

The runtime limits bound a run: how long an agent may run, how many times a loop may iterate, how many rows a database call may return, how much an agent definition may hold, and how much an agent may spend on LLM calls. Developers edit the limits in the GUI under Guardrails, and the limits apply to every agent in the account.

How the limits are checked

The limits are checked while the agent runs. Elapsed time is checked between commands, and inside loops every yield loops after iterations. A run past the limit ends with the result code timedOut. A long LLM or API call in progress ends only when the call's own timeout fires. A loop that exceeds the iteration limit fails the run. A db command returns at most the row limit. The LLM cost limit is checked after each call, against the prices in the LLM profile; a profile with no prices never trips the limit. The definition length applies to the JSONC text of a draft, comments included. The stream heartbeat sets how often a streamed response sends a keep-alive line.

Field	Type	Default	Description
`maxAgentRuntime`	integer	600	How long an agent may run before it is stopped.
`maxIterationLoops`	integer	1000000	The most iterations a 'while' or 'for' may run. A loop inside a loop is counted separately.
`yieldLoopsAfter`	integer	1000	How many iterations a loop runs before yielding, so the runtime limit can be checked.
`dbMaxRows`	integer	10000	The most rows a single db command may return.
`agentMaxLength`	integer	20480	The most characters an agent definition may contain.
`maxLlmPrice`	number	1	The agent is stopped once a call takes its spend past this amount.
`streamHeartbeat`	integer	15	How often a noop is sent on an idle output stream, so browsers and proxies do not close it while the agent works.
`checkSerializationErrors`	boolean	false	Every variable value must be JSON serializable. This is always checked while validating a draft; turning it on also checks it on every run and writes what it finds to the server log.