all docs
/ errors · HTTP 400

agent_loop_halted

multi_agent_guard refused a runaway agent loop.

What it means

multi_agent_guard in prod refused the turn: the trajectory the caller sent shows a runaway loop — the same tool call answered with the same result max_repeats times with no progress in between, or max_stalled_steps tool steps in a row that observed nothing new, or, when a tenant or deployment set one, more tool steps than max_depth. Nothing was sent upstream. 400, not 429: a retry resends the same trajectory and is refused the same way, so the remedy is the agent changing course (or the limits being raised), never waiting. The body wears the surface's own envelope — type: agent_loop_halted on the OpenAI surfaces, invalid_request_error on Anthropic, INVALID_ARGUMENT on Gemini, ValidationException on Bedrock — and x-ace-multi-agent-halt names the reason.

How to recognise it

The gateway answers HTTP 400 with x-ace-error: agent_loop_halted on the response, and a body in the shared error envelope:

{
  "error": {
    "message": "...",
    "type": "agent_loop_halted",
    "code": 400
  }
}

On a vendor-shaped surface (/anthropic/…, /gemini/…, /bedrock/…) the body wears that vendor's error envelope instead; the x-ace-error header is the same everywhere.

Is it ACE or the provider?

x-ace-error is present only on errors ACE originated. A vendor error relayed from upstream — a real provider 429, a provider 401 for a bad pass-through key — carries no x-ace-error, and its own type and code mean what the provider says. Read the header before deciding whether to retry, re-mint a key or surface the error.

Other 400 errors

  • guardrail_violation: Prompt-injection or jailbreak guardrail tripped (names detected rule).
  • request_error: The request was refused as sent — a body that does not parse, a missing or malformed field, a /v1/execute validation failure, an unknown x-ace-skills pair, a Bedrock path/body modelId mismatch, an API key sent beside an access-key pair, a mode this deployment cannot serve.