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

[GH-ISSUE #16045] web_search/web_fetch return 200 OK with empty body when Cloud usage is exhausted #87901

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

Originally created by @mightymatth on GitHub (May 8, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/16045

Originally assigned to: @ParthSareen on GitHub.

What is the issue?

When Ollama Cloud weekly usage is exhausted, the Web Search / Web Fetch APIs return:

HTTP/2 200
content-type: application/json
content-length: 0

with an empty body.

This causes clients that correctly expect JSON from these endpoints to fail with JSON parse errors, e.g.:

Unexpected end of JSON input

This was observed both through the local experimental proxy endpoints and by calling the cloud API directly with an API key.

Expected behavior

When usage/quota is exhausted, the API should return a non-2xx status and JSON error body, for example:

HTTP/2 429
content-type: application/json

{"error":"weekly usage limit exceeded"}

or 402 if that is the intended billing/credits status.

Actual behavior

Direct cloud API calls return empty 200 OK responses:

POST https://ollama.com/api/web_search
HTTP 200
content-type: application/json
content-length: 0
x-request-id: 5710814b-5072-4ae4-b6e9-a55bdad29d26
body: <empty>

POST https://ollama.com/api/web_fetch
HTTP 200
content-type: application/json
content-length: 0
x-request-id: a0d006e3-c948-4388-96e1-81ce53e42b1a
body: <empty>

The local proxy endpoint shows the same behavior:

curl -i http://127.0.0.1:11434/api/experimental/web_fetch \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com"}'

returns:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 0

Reproduction

With an account whose Cloud Usage page shows:

Weekly usage: 100% used

run:

curl -i https://ollama.com/api/web_search \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"query":"what is ollama?","max_results":1}'

and:

curl -i https://ollama.com/api/web_fetch \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com"}'

Impact

This breaks integrations such as @ollama/pi-web-search, because it calls:

const data = await response.json()

after checking response.ok. Since the response is 200 OK but body is empty, clients see a misleading parse error instead of a quota/usage error.

Environment

  • Ollama: 0.23.2
  • OS: macOS
  • Account plan: Free
  • Cloud usage: weekly usage exhausted (100% used)
Originally created by @mightymatth on GitHub (May 8, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/16045 Originally assigned to: @ParthSareen on GitHub. ### What is the issue? When Ollama Cloud weekly usage is exhausted, the Web Search / Web Fetch APIs return: ```http HTTP/2 200 content-type: application/json content-length: 0 ``` with an empty body. This causes clients that correctly expect JSON from these endpoints to fail with JSON parse errors, e.g.: ```txt Unexpected end of JSON input ``` This was observed both through the local experimental proxy endpoints and by calling the cloud API directly with an API key. ### Expected behavior When usage/quota is exhausted, the API should return a non-2xx status and JSON error body, for example: ```http HTTP/2 429 content-type: application/json {"error":"weekly usage limit exceeded"} ``` or `402` if that is the intended billing/credits status. ### Actual behavior Direct cloud API calls return empty `200 OK` responses: ```txt POST https://ollama.com/api/web_search HTTP 200 content-type: application/json content-length: 0 x-request-id: 5710814b-5072-4ae4-b6e9-a55bdad29d26 body: <empty> POST https://ollama.com/api/web_fetch HTTP 200 content-type: application/json content-length: 0 x-request-id: a0d006e3-c948-4388-96e1-81ce53e42b1a body: <empty> ``` The local proxy endpoint shows the same behavior: ```bash curl -i http://127.0.0.1:11434/api/experimental/web_fetch \ -H 'Content-Type: application/json' \ -d '{"url":"https://example.com"}' ``` returns: ```http HTTP/1.1 200 OK Content-Type: application/json Content-Length: 0 ``` ### Reproduction With an account whose Cloud Usage page shows: ```txt Weekly usage: 100% used ``` run: ```bash curl -i https://ollama.com/api/web_search \ -H "Authorization: Bearer $OLLAMA_API_KEY" \ -H 'Content-Type: application/json' \ -d '{"query":"what is ollama?","max_results":1}' ``` and: ```bash curl -i https://ollama.com/api/web_fetch \ -H "Authorization: Bearer $OLLAMA_API_KEY" \ -H 'Content-Type: application/json' \ -d '{"url":"https://example.com"}' ``` ### Impact This breaks integrations such as `@ollama/pi-web-search`, because it calls: ```ts const data = await response.json() ``` after checking `response.ok`. Since the response is `200 OK` but body is empty, clients see a misleading parse error instead of a quota/usage error. ### Environment - Ollama: `0.23.2` - OS: macOS - Account plan: Free - Cloud usage: weekly usage exhausted (`100% used`)
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#87901
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?