Skip to main content
Guild enforces hard runtime limits that act as runaway backstops. They protect against infinite loops, unbounded state growth, and runaway LLM billing costs. These are not normal-traffic thresholds — a healthy agent run stays well below them. This page describes each limit, the error you receive when you cross it, how usage is counted, and how to diagnose and configure it.

​
State size

Every call to task.save() serializes your agent’s state and persists it through the runtime. The serialized state has a maximum size of 8 MiB.
  • The SDK checks the serialized size before sending it and fails fast with a local error when the state exceeds 8 MiB, so you see the problem in your agent code rather than as a network error.
  • The runtime enforces the same 8 MiB ceiling on the save-state endpoint and returns HTTP 413 Request Entity Too Large when a request exceeds it. The runtime limit is authoritative.
If you hit this limit, reduce what you persist. Store identifiers or summaries instead of full payloads, and avoid accumulating large arrays or message histories in state. See State for guidance on what to persist.

​
LLM execution budgets

Guild meters LLM usage per execution and stops an agent that exceeds any of these budgets. When a budget is exceeded, the LLM proxy returns HTTP 429 Too Many Requests and the call fails.

​
How usage is counted

  • The token budget counts input and output tokens only. Cache-read and cache-write tokens are excluded. Reusing a cached prompt across many calls does not consume the token budget, so prompt caching both lowers cost and keeps you under the limit.
  • The counting window depends on how the execution started. Chat and agent-test roots count from the latest user message, so the call and token budgets reset on each user turn. Trigger roots count across the full execution tree for the entire run.

​
Spend budgets

The LLM execution budgets above are automatic runaway backstops: they always apply and they are scoped to a single execution. Spend budgets are a different mechanism — opt-in, set by an admin, denominated in USD, and measured across a calendar month. They can be configured at three scopes: workspace, agent, and user. The user scope applies to the session’s accountable user — the person who initiated the chat or agent test, or who created the firing trigger. Spend accrues per user per cycle, and before an LLM call the proxy blocks it when that user’s budget is enabled and exhausted. When any enabled budget — workspace, agent, or user — reaches its ceiling, the LLM proxy returns HTTP 429 Too Many Requests for further calls until the cycle resets or an admin raises the ceiling. Admins are warned at 80%. See Spend budget. Sessions that cannot be attributed to a human — API-key-initiated chats, API triggers, and legacy creatorless triggers — carry no user scope, so user budgets fail open and do not block those calls.

​
Unlimited power mode

Large execution trees can hit the default runaway fan-out limits before finishing legitimate work. Enabling unlimited_power_mode on a workspace raises four of those limits to their platform ceilings. Turn it on from the workspace’s Settings.
The raised token limit is not a cost guard. Cache tokens are excluded from the count, so billed spend can exceed it, and 20 billion input tokens is on the order of tens of thousands of dollars. Bound spend with an account budget instead.
The setting raises fan-out and execution-tree limits only. The 8 MiB single-request payload limit still applies to every LLM call.

​
Synchronous step budget

If an agent runs too many synchronous steps in a tight loop without yielding — for example, a while (true) loop with no await or async operations — the runtime triggers a circuit breaker to prevent an out-of-memory crash. By default, the runtime limits consecutive budget refreshes to 10, which corresponds to 10,000 synchronous steps without yielding.

​
Error message and stack trace

When the limit is exceeded, execution stops with a UserError:
The runtime stack trace shows named frames with the original function name and source line number for each active scope, along with snapshots of local variables:
  • at functionName() — the original name of a function scope. Anonymous block, loop, and try scopes fall back to scope(id).
  • step=N — the compiled step index within that scope.
  • line L — the source code line number the frame maps to.
  • { variable=value } — a snapshot of local variables in that scope when execution stopped. Values are summarized safely: long strings are truncated (for example, "yyy..."), objects are masked as {...}, and so on, so credentials or large datasets do not clutter or leak into the trace. Use this to identify which variables are growing or where the loop is stuck.

​
If you hit this limit

The budget exists to catch runaway loops, so the usual fix is in the agent: yield at an await, or move heavy pure computation into a synchronous helper, which runs off the meter entirely. See Keep heavy work in synchronous helpers. If an agent genuinely needs a higher cap, contact Guild support — the ceiling is managed by the platform and is not configurable from your account.

​
Turn timeout

A single agent communicate() turn has a wall-clock ceiling. Without it, a turn that backgrounds a command, polls for a result, or runs a wedged tool or command could wait indefinitely and keep the entire session stuck. The default ceiling is 3,600 seconds (1 hour). When a turn exceeds the timeout, the runtime terminates the in-progress command and completes the turn with a TURN_TIMEOUT: result that contains the last-seen session ID. The calling agent resumes the container session with a follow-up message instead of the run failing. The ceiling is managed by the platform and is not configurable from your account.

​
Error reference