Request Timeouts
Per-request gateway limits and the timeout behavior clients should handle.
Request Timeouts
The gateway enforces hard time limits on every request. These protect the platform from stuck upstream connections, but they matter to you directly if you run long generations or agentic pipelines: a single completion that runs longer than the limit is terminated.
| Limit | Default | Applies to |
|---|---|---|
| Streaming | 20 minutes | Streaming completions (stream: true) |
| Non-streaming | 10 minutes | Non-streaming completions |
| End-to-end | 25 minutes | Overall ceiling for the whole request, including retries |
How the limits behave
- They are total-duration limits, not idle limits. The timer starts when the gateway opens the upstream provider request and keeps running for the entire response — a stream is cut at the limit even while it is actively producing tokens.
- They apply per request, not per session or conversation. Every completion call gets a fresh window. A long-running agent that makes many calls over hours is unaffected; only a single call exceeding the limit fails.
- Tool execution doesn't count. When a completion finishes with
tool_calls, the HTTP request ends. The time your application spends running tools (or coordinating subagents) between requests never consumes the window. - On timeout the gateway returns a
504with typetimeout_error(see Error Handling). If the limit is hit mid-stream, the stream terminates.
Long-running agentic workloads
Coordinator/subagent architectures often hold a "master" completion open while work happens elsewhere. To stay within the limits:
- Keep any single completion under 20 minutes. Structure the coordinator as a loop of discrete completions (the standard tool-calling pattern) rather than one long-lived request that spans the whole investigation.
- Stream long generations. Non-streaming requests are capped at 10 minutes; streaming raises the per-request budget to 20 minutes and delivers partial output as it is produced.
- Split very long outputs. If a single generation legitimately needs more than 20 minutes (very large outputs on slow models, extensive reasoning), break it into continuation requests.
Changing the limits
Custom timeout controls are not exposed in the first public preview. Build
clients against the published limits above and handle 504 responses through
the standard error path.
If your workload genuinely needs single completions longer than 20 minutes on the hosted platform, contact us at contact@offrail.ai — the ceiling is an infrastructure setting, not a per-model constraint.

