github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-15 12:48:05 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #15973] Cloud API: 182-second hard timeout kills agent workflows — no way to extend #87860

New Issue
Open
opened 2026-05-10 06:27:33 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-10 06:27:33 -05:00
Owner
Copy Link

Originally created by @willificent on GitHub (May 5, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/15973

Summary

Paying Ollama Cloud subscribers hit a hard 182-second timeout on LLM requests. This makes tool-heavy agent turns impossible — the model can be actively generating and making progress, but the connection is killed at exactly ~182 seconds. For agent use cases, this is a dealbreaker.

Description

When using Ollama Cloud models (e.g., glm-5.1:cloud, qwen3.5:cloud, deepseek-v4-pro:cloud) through the API, requests are terminated at exactly ~182 seconds regardless of:

  • Whether the model is still actively generating tokens
  • The user's subscription tier (Pro or Max)
  • The complexity of the request

This is distinct from the 502/503 reliability issues documented in #15453 and #14673 — those are transient capacity failures. This is a hard timeout that kills successful, in-progress generations.

Impact on Agent Workflows

Tools like OpenClaw run AI agents that perform multi-step reasoning with tool calls. A single agent turn can easily exceed 180 seconds when:

  • The model reasons through a complex problem before responding
  • Multiple tool calls are chained in a single turn
  • A large codebase is being analyzed

The timeout doesn't just fail the request — it loses all progress. There's no way to resume or checkpoint. Worse, because the timeout consumes all fallback options, it's catastrophic for agent workflows (see Evidence below).

Reproduction

# Any prompt that takes >182s to complete will be killed
curl -s --max-time 300 http://localhost:11434/api/chat \
  -d '{"model":"glm-5.1:cloud","messages":[{"role":"user","content":"Analyze this large codebase and provide a detailed refactoring plan..."}],"stream":false}'
# Connection drops at exactly ~182s

Evidence

Three identical failures within 30 minutes on 2026-05-04, each timing out at almost exactly 182 seconds:

# Start Time (CDT) End Time (CDT) Duration (ms) Model
1 2026-05-04 21:30:36 2026-05-04 21:33:38 182,043 deepseek-v4-pro:cloud
2 2026-05-04 21:43:44 2026-05-04 21:46:46 182,043 deepseek-v4-pro:cloud
3 2026-05-04 21:51:14 2026-05-04 21:54:15 181,997 deepseek-v4-pro:cloud

Note: The duration is consistently 182,xxx ms (±50ms) across all three failures. This is clearly a hard-coded server-side timeout, not a network issue.

Gateway Log Entries

Each failure produces the same log pattern:

[agent/embedded] embedded run agent end: isError=true model=deepseek-v4-pro:cloud error=LLM request timed out. rawError=This operation was aborted
[model-fallback/decision] decision=candidate_failed reason=timeout next=none detail=LLM request timed out.

The next=none in the fallback decision means the timeout exhausted all fallback options. OpenClaw's fallback system — designed to try alternative models when one fails — has no candidates left because every cloud model hits the same hard timeout. For agent workflows, this means the entire turn is dead with no recovery path.

Cross-Reference

  • openclaw/openclaw#77626 — OpenClaw implemented liveness-based timeouts to work around this, but the Ollama hard timeout is the upstream root cause. No amount of client-side timeout management can fix a server that kills the connection at 182s regardless of whether the model is still actively generating tokens.

Request

  1. Raise the timeout significantly for paying customers — 182 seconds is too short for agent use cases. A 10-minute timeout (600s) would be more appropriate for Pro/Max tiers.
  2. Make the timeout configurable — Allow users to set their own timeout via a request parameter or account setting.
  3. At minimum, document the limit — There is no mention of a ~182-second timeout in the Ollama Cloud documentation, making it impossible to design around.

Environment

  • Plan: Ollama Pro
  • Ollama version: Latest
  • Models affected: All cloud models
  • Endpoint: /api/chat, /api/generate, /v1/chat/completions

Related Issues

  • #15453 — Ollama Cloud reliability (502/503 failures)
  • #14673 — High timeout rates on Ollama Cloud
  • #13770 — Cloud model connection timeout
  • openclaw/openclaw#77626 — Client-side liveness timeouts (workaround, not fix)
Originally created by @willificent on GitHub (May 5, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/15973 ## Summary Paying Ollama Cloud subscribers hit a **hard 182-second timeout** on LLM requests. This makes tool-heavy agent turns impossible — the model can be actively generating and making progress, but the connection is killed at exactly ~182 seconds. For agent use cases, this is a dealbreaker. ## Description When using Ollama Cloud models (e.g., `glm-5.1:cloud`, `qwen3.5:cloud`, `deepseek-v4-pro:cloud`) through the API, requests are terminated at exactly ~182 seconds regardless of: - Whether the model is still actively generating tokens - The user's subscription tier (Pro or Max) - The complexity of the request This is distinct from the 502/503 reliability issues documented in #15453 and #14673 — those are transient capacity failures. This is a **hard timeout** that kills **successful, in-progress** generations. ### Impact on Agent Workflows Tools like [OpenClaw](https://github.com/nicholasgriffintn/openclaw) run AI agents that perform multi-step reasoning with tool calls. A single agent turn can easily exceed 180 seconds when: - The model reasons through a complex problem before responding - Multiple tool calls are chained in a single turn - A large codebase is being analyzed The timeout doesn't just fail the request — it loses all progress. There's no way to resume or checkpoint. Worse, because the timeout consumes all fallback options, it's catastrophic for agent workflows (see Evidence below). ### Reproduction ```bash # Any prompt that takes >182s to complete will be killed curl -s --max-time 300 http://localhost:11434/api/chat \ -d '{"model":"glm-5.1:cloud","messages":[{"role":"user","content":"Analyze this large codebase and provide a detailed refactoring plan..."}],"stream":false}' # Connection drops at exactly ~182s ``` ## Evidence Three identical failures within 30 minutes on 2026-05-04, each timing out at almost exactly 182 seconds: | # | Start Time (CDT) | End Time (CDT) | Duration (ms) | Model | |---|---|---|---|---| | 1 | 2026-05-04 21:30:36 | 2026-05-04 21:33:38 | 182,043 | deepseek-v4-pro:cloud | | 2 | 2026-05-04 21:43:44 | 2026-05-04 21:46:46 | 182,043 | deepseek-v4-pro:cloud | | 3 | 2026-05-04 21:51:14 | 2026-05-04 21:54:15 | 181,997 | deepseek-v4-pro:cloud | **Note:** The duration is consistently 182,xxx ms (±50ms) across all three failures. This is clearly a hard-coded server-side timeout, not a network issue. ### Gateway Log Entries Each failure produces the same log pattern: ``` [agent/embedded] embedded run agent end: isError=true model=deepseek-v4-pro:cloud error=LLM request timed out. rawError=This operation was aborted [model-fallback/decision] decision=candidate_failed reason=timeout next=none detail=LLM request timed out. ``` The `next=none` in the fallback decision means the timeout exhausted all fallback options. OpenClaw's fallback system — designed to try alternative models when one fails — has no candidates left because **every cloud model hits the same hard timeout**. For agent workflows, this means the entire turn is dead with no recovery path. ### Cross-Reference - [openclaw/openclaw#77626](https://github.com/nicholasgriffintn/openclaw/issues/77626) — OpenClaw implemented liveness-based timeouts to work around this, but the Ollama hard timeout is the **upstream root cause**. No amount of client-side timeout management can fix a server that kills the connection at 182s regardless of whether the model is still actively generating tokens. ## Request 1. **Raise the timeout significantly for paying customers** — 182 seconds is too short for agent use cases. A 10-minute timeout (600s) would be more appropriate for Pro/Max tiers. 2. **Make the timeout configurable** — Allow users to set their own timeout via a request parameter or account setting. 3. **At minimum, document the limit** — There is no mention of a ~182-second timeout in the Ollama Cloud documentation, making it impossible to design around. ## Environment - **Plan**: Ollama Pro - **Ollama version**: Latest - **Models affected**: All cloud models - **Endpoint**: `/api/chat`, `/api/generate`, `/v1/chat/completions` ## Related Issues - #15453 — Ollama Cloud reliability (502/503 failures) - #14673 — High timeout rates on Ollama Cloud - #13770 — Cloud model connection timeout - [openclaw/openclaw#77626](https://github.com/nicholasgriffintn/openclaw/issues/77626) — Client-side liveness timeouts (workaround, not fix)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#87860
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?