Request Timeouts

Halfbill 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.

How the limits behave

• They are total-duration limits, not idle limits. The timer starts when Halfbill 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 Halfbill returns a 504 with type timeout_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

The defaults above are the platform ceiling and cannot be raised per project.