litellm - ✅(Solved) Fix [Bug]: Ollama get_model_info constructs redundant path .../api/chat/api/show, causing 404s on remote instances [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25567Fetched 2026-04-12 13:24:49
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Participants
Timeline (top)
labeled ×3cross-referenced ×1referenced ×1

Root Cause

  1. Configure LiteLLM to use a remote Ollama instance via OLLAMA_API_BASE.
  2. Use the ollama_chat/ provider.
  3. Trigger a completion.
  4. Observe the background call to api/show failing with a 404 because of the redundant /api/chat prefix in the middle of the URL.

Fix Action

Fixed

PR fix notes

PR #25596: fix(ollama): strip provider suffix from api_base before /api/show call

Description (problem / solution / changelog)

Summary

Fixes #25567

get_model_info receives api_base that may already contain a provider suffix like /api/chat (appended by the completion path). Appending /api/show to this produces /api/chat/api/show, which returns 404 on the Ollama server.

Ollama logs showing the bug:

POST "/api/chat"         → 200
POST "/api/chat/api/show" → 404

Fix

Strip known provider suffixes (/api/chat, /api/generate) from api_base before constructing the /api/show URL:

_base = api_base.rstrip('/')
for _suffix in ('/api/chat', '/api/generate'):
    if _base.endswith(_suffix):
        _base = _base[:-len(_suffix)]
        break
url = f'{_base}/api/show'

Changed files

  • litellm/llms/ollama/completion/transformation.py (modified, +9/-1)

Code Example

# Strip existing provider suffixes from api_base before appending /api/show
sanitized_base = api_base.rstrip("/")
for suffix in ["/api/chat", "/api/generate"]:
    if sanitized_base.endswith(suffix):
        sanitized_base = sanitized_base[:-len(suffix)]
url = f"{sanitized_base}/api/show"

---

... 
time=2026-04-11T17:48:12.002+02:00 level=INFO source=server.go:1390 msg="llama runner started in 2.83 seconds"
[GIN] 2026/04/11 - 17:48:14 | 200 |  5.663452542s |   192.168.2.122 | POST     "/api/chat"
[GIN] 2026/04/11 - 17:48:14 | 404 |       3.667µs |   192.168.2.122 | POST     "/api/chat/api/show"
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

Description

In litellm/llms/ollama/completion/transformation.py, the get_model_info method incorrectly uses a "polluted" api_base that already contains a provider suffix (like /api/chat), resulting in malformed URLs like: http://<IP>:11434/api/chat/api/show

This causes 404 errors for background tasks like cost calculation or capability checking, especially when Ollama is running on a remote host.

Proposed Fix

The issue is in litellm/llms/ollama/completion/transformation.py within the get_model_info method. The api_base can be sanitized with the following logic:

# Strip existing provider suffixes from api_base before appending /api/show
sanitized_base = api_base.rstrip("/")
for suffix in ["/api/chat", "/api/generate"]:
    if sanitized_base.endswith(suffix):
        sanitized_base = sanitized_base[:-len(suffix)]
url = f"{sanitized_base}/api/show"

Steps to Reproduce

  1. Configure LiteLLM to use a remote Ollama instance via OLLAMA_API_BASE.
  2. Use the ollama_chat/ provider.
  3. Trigger a completion.
  4. Observe the background call to api/show failing with a 404 because of the redundant /api/chat prefix in the middle of the URL.

Relevant log output

... 
time=2026-04-11T17:48:12.002+02:00 level=INFO source=server.go:1390 msg="llama runner started in 2.83 seconds"
[GIN] 2026/04/11 - 17:48:14 | 200 |  5.663452542s |   192.168.2.122 | POST     "/api/chat"
[GIN] 2026/04/11 - 17:48:14 | 404 |       3.667µs |   192.168.2.122 | POST     "/api/chat/api/show"

What part of LiteLLM is this about?

SDK (litellm Python package)

What LiteLLM version are you on ?

1.82.6

Twitter / LinkedIn details

No response

extent analysis

TL;DR

Sanitize the api_base in get_model_info method by removing existing provider suffixes to fix malformed URLs.

Guidance

  • Identify the get_model_info method in litellm/llms/ollama/completion/transformation.py and apply the proposed fix to sanitize api_base.
  • Verify the fix by checking the URLs generated for background tasks like cost calculation or capability checking.
  • Test the fix by triggering a completion and observing the background call to api/show to ensure it no longer fails with a 404 error.
  • Ensure the OLLAMA_API_BASE is correctly configured to use the remote Ollama instance.

Example

The proposed fix provides a code snippet to sanitize api_base:

sanitized_base = api_base.rstrip("/")
for suffix in ["/api/chat", "/api/generate"]:
    if sanitized_base.endswith(suffix):
        sanitized_base = sanitized_base[:-len(suffix)]
url = f"{sanitized_base}/api/show"

This code removes existing provider suffixes from api_base before appending /api/show.

Notes

This fix assumes that the issue is solely caused by the malformed URLs generated by the get_model_info method. If the issue persists after applying the fix, further investigation may be necessary.

Recommendation

Apply the proposed workaround to sanitize api_base in the get_model_info method, as it directly addresses the identified cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING