Guides
Agent time limits
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 time the agent spends working, not time it spends waiting on you or on somebody's approval.
- If a turn does run out, the work it already finished is kept.
- Change it on the agent, under Advanced > Turn timeout.
If you're here because a long job keeps getting cut short, open that setting and put 30 in it.
What the clock actually counts
This is the part that surprises people, and it's the good news.
The clock runs while the agent is thinking, and while one of its tools is doing work on our side. It stops whenever the agent is waiting on something outside itself:
- Your own software is holding a request open and hasn't answered yet.
- Somebody has been asked to approve something and hasn't replied. See interactions.
- The agent is waiting for an event to arrive.
When the thing it was waiting for turns up, the turn carries on with the rest of its time still in hand.
We built it this way because a plain stopwatch can't tell the difference between an agent that's stuck and an agent that's politely waiting on a person. Only working time is the agent's to spend, so only working time counts against it.
Note: A turn that waits overnight for an approval hasn't used a minute of its limit, and it costs nothing while it waits.
Give an agent more time in the app
- Open Build > Agents in the sidebar, then click the agent.
- Click Advanced.
- In Turn timeout, enter the number of minutes. Enter
30for the maximum. - Click Save.
Every turn that agent takes from now on gets 30 minutes. Leave the field blank to go back to the 10-minute default.
Give an agent more time from the CLI
mobius agents update agt_scout --timeout-seconds 1800Updated agent agt_scoutThe 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 the extra room, and you'd rather everything else keep failing fast so you hear about problems sooner. That's a good instinct. You can set the limit on a single request instead of on 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
An agent's time limit can come from four places. The most specific one wins.
| Where it's set | Use when |
|---|---|
| One request | A single job needs longer than usual |
| A session | A whole conversation is doing long work |
| The agent | This agent's work is long by nature |
| A loop step | The step is the thing that needs the time |
When in doubt, set it on the agent. It's the one place that covers everything that agent does, and it's visible in the app where the next person will look for it.
Warning: A loop step's own time limit overrides the agent's in both directions. A step set to 5 minutes cuts short an agent set to 30. If you raised the agent's limit and a loop still stops early, the step is why. Loop step limits sit alongside the run-wide limits in guardrails.
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.
A timeout costs you the turn, not the work.
Reference
Everything above, with the exact names. This section is for setting the limit from your own software.
Endpoints
| What you're doing | Request |
|---|---|
| Create an agent with a limit | POST /v1/agents |
| Change an agent's limit | PATCH /v1/agents/{resource_id} |
| Set a limit while invoking an agent | POST /v1/agents/invoke |
| Set a limit on one turn in a session | POST /v1/sessions/{session_id}/turns |
| Read the limit a turn actually got | GET /v1/sessions/{session_id}/turns/{turn_id} |
Fields and schemas
| Field | Schema | What it does |
|---|---|---|
timeout_seconds | CreateAgentRequest, UpdateAgentRequest, Agent | Stored on the agent. 0 or omitted uses the platform default. |
timeout_seconds | AgentTurnOperationPolicy | This turn only, never saved. Minimum 1. |
effective_timeout_seconds | AgentTurn | Read-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": "trn_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
| Command | Flag |
|---|---|
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-turn | reads effective_timeout_seconds back |
Values
| Name | Value | Who sets it |
|---|---|---|
| Platform default | 600 seconds, 10 minutes | Mobius |
| Ceiling | 1800 seconds, 30 minutes | Mobius, through MOBIUS_AGENT_TURN_MAX_TIMEOUT_SECONDS |
The ceiling is a deployment setting rather than something you send, so you can't raise it from the API. Ask us and we'll raise it for your organization.
Precedence
For direct and session invocations:
operation.timeout_seconds > agent timeout_seconds > 600sFor loop agent steps:
steps[].timeout > agent timeout_seconds > 600sWhichever value wins is then reduced to the ceiling if it's above it, with no error. Read effective_timeout_seconds to see the result.
limits.wall_clock_timeout is a different limit. It bounds a whole run rather than one turn, and it's covered in guardrails.
FAQ
I raised the limit and nothing changed
Two usual causes. If the agent runs as part of a loop, check the step's own time limit, because it overrides the agent's. If you set a number above 30 minutes, see the next answer.
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 approval use up the time?
No. The clock stops while an interaction is waiting on a person, however long they take.
My agent needs more than 30 minutes
Get in touch. The 30-minute ceiling is a setting on our side rather than a hard limit, and raising it for your organization is a small change.
Before you ask, check effective_timeout_seconds on a few turns that ran long. Because waiting time doesn't count, turns often use far less than the clock on the wall suggests, and 30 real minutes of work goes further than people expect.
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
- Set spending caps and run-wide limits: guardrails.
- Understand turns and conversations: agent sessions.
- Set the limit from your own software: sessions and turns API.