DocsGuides

Agent time limits

Set how long one agent turn can run, and know what happens when it runs out.

Every reply an agent gives runs under a time limit. If the agent is still working when that time is up, Mobius stops it.

Most days you'll never notice. A ticket gets sorted in twenty seconds. But when Scout goes off to prepare the monthly review for Ridgeline Dental, reads through a dozen pages, and pulls the numbers together, it can be working for a quarter of an hour. That's the job where the limit starts to matter.

The thing being limited is a turn: one round of an agent taking a message and working until it has an answer. Turns live inside agent sessions.

The two-minute version

  • A turn gets 10 minutes by default.
  • You can raise it to 30 minutes.
  • The limit counts active execution segments. Time in a durable suspended wait does not count.
  • If a turn does run out, the work it already finished is kept.
  • Change it on the agent, under Advanced > Turn timeout.

What the clock actually counts

The clock runs while the model is working and while an ordinary tool call is in progress, including the time spent waiting for that call to return. It pauses only after the runtime records a durable suspension, such as:

  • an event wait on the answer to an interaction, when the instructions tell the assistant to wait for a person;
  • an event wait waiting for a matching source event; or
  • a long-running job that has moved into the durable wait path.

When the wait resolves, the turn resumes with the active time it had left. A slow synchronous HTTP or provider call remains part of the active segment; it does not become free waiting merely because the response comes from another system.

Note: A turn that waits overnight for a review hasn't used a minute of its active-work limit. The interaction still has its own deadline, which you choose when the request is created.

Give an agent more time in the app

  1. Open Build > Agents in the sidebar, then click the agent.
  2. Click Edit, then open Advanced.
  3. In Turn timeout, enter the number of minutes. Enter 30 for the maximum.
  4. Click Save.

New turns use the saved 30-minute limit unless a request supplies its own operation.timeout_seconds. Leave the field blank to return to the 10-minute default.

Give an agent more time from the CLI

mobius agents update agent_scout --timeout-seconds 1800
Updated agent agent_scout

The app asks for minutes and the CLI asks for seconds, so 30 minutes is 1800 here.

Give one job more time without changing the agent

Sometimes only one kind of work needs extra time. Set the limit on that request instead of changing the agent.

Set operation.timeout_seconds when you start a turn. It applies to that one turn and isn't saved to the agent or the session. The sessions and turns API covers the request in full.

We recommend the agent setting when the agent's whole job is long research, and the per-request setting when one occasional task runs long inside an otherwise quick agent.

Which setting wins

For direct app, API, messaging, and routine turns, a limit on one request wins over the assistant's saved limit. The saved limit wins over the 10-minute platform default. Read effective_timeout_seconds on the turn when you need to confirm the limit Mobius applied.

When a turn runs out of time

The work the agent already finished is kept.

When time runs out, we save what the turn produced up to that moment, which is the text it had written and the result of every tool that finished, into the conversation. Those entries are marked so you can tell them apart from a normal reply. Anything still half-done when the clock stopped is closed out and marked as unfinished.

What that means for you:

  • Finished work survives. A report the agent had already pulled together is still in the conversation.
  • The turn itself is over. It can't be resumed.
  • Sending another message carries on from there. The agent reads back a conversation that already holds the finished work, so it continues rather than starting again.

Reference

Everything above, with the exact names. This section is for setting the limit from your own software.

Endpoints

What you're doingRequest
Create an agent with a limitPOST /v1/agents
Change an agent's limitPATCH /v1/agents/{resource_id}
Set a limit while invoking an agentPOST /v1/agents/invoke
Set a limit on one turn in a sessionPOST /v1/sessions/{session_id}/turns
Read the limit a turn actually gotGET /v1/sessions/{session_id}/turns/{turn_id}

Fields and schemas

FieldSchemaWhat it does
timeout_secondsCreateAgentRequest, UpdateAgentRequest, AgentStored on the agent. 0 or omitted uses the platform default.
timeout_secondsAgentTurnOperationPolicyThis turn only, never saved. Minimum 1.
effective_timeout_secondsAgentTurnRead-only. The limit the turn actually got, after any reduction.

On the invoke request and StartTurnRequest, AgentTurnOperationPolicy arrives as operation.

Example

{
  "content": [{ "type": "text", "text": "Prepare the monthly review." }],
  "operation": { "timeout_seconds": 1800 }
}
{
  "turn": {
    "id": "turn_01J8...",
    "status": "queued",
    "effective_timeout_seconds": 1800
  }
}

The response reports effective_timeout_seconds, so a single request both sets the limit and tells you what you got.

CLI flags

CommandFlag
mobius agents create--timeout-seconds
mobius agents update <resource-id>--timeout-seconds
mobius sessions invoke-agent--operation, as JSON
mobius sessions start-turn--operation, as JSON
mobius sessions get-turnreads effective_timeout_seconds back

Values

NameValueWho sets it
Platform default600 seconds, 10 minutesMobius
Ceiling1800 seconds, 30 minutesMobius, through MOBIUS_AGENT_TURN_MAX_TIMEOUT_SECONDS

The ceiling is a deployment setting rather than something you send, so you cannot raise it from the API.

Precedence

For direct and session invocations:

operation.timeout_seconds > agent timeout_seconds > 600s

Whichever value wins is then reduced to the ceiling if it's above it, with no error. Read effective_timeout_seconds to see the result.

FAQ

I raised the limit and nothing changed

Check effective_timeout_seconds on the turn. A request-level operation can override the assistant setting, and any value above the deployment ceiling is reduced to 30 minutes.

I set an hour and got 30 minutes

30 minutes is the current maximum. Anything higher is quietly reduced to it, with no error to tell you so. This catches people out, so treat 30 minutes as the ceiling rather than a suggestion.

Every turn reports the limit it actually got, as effective_timeout_seconds, on the turn itself. If you want to confirm a change took effect, that's the number to read.

Does waiting for an interaction use up the time?

No. Asking a person doesn't hold the turn at all. When the instructions tell the assistant to wait for the answer, the clock stops while it waits. The interaction keeps its own deadline, independent of the active-work limit.

My agent needs more than 30 minutes

Check effective_timeout_seconds on a few turns that ran long. Because waiting time does not count, turns often use far less than the clock on the wall suggests. If the work uses the full 30 active minutes, split it into smaller requests with durable intermediate results.

Is the limit per model call or for the whole turn?

The whole turn. A turn that thinks twenty times and runs thirty tools shares one budget across all of it.

Next