AI Model Intelligence
Share
Local Deployment & Hardware

Ollama Model Not Found: Check Tags, Server and API Paths

Updated · Sources & corrections

In this guide
  1. Identify which failure you have
  2. Query the server your application actually uses
  3. Use an exact installed name, then make one small request
  4. If the model is missing, install it in the right place
  5. Check the API family when the route is wrong
  6. Sources and verification scope

Quick answer: When Ollama returns “model not found,” compare the requested model name with the model list from the same server your application calls. Downloading a model on your laptop will not fix a request sent to a different container or remote machine. A 404 caused by an incorrect API route needs a different correction.

This guide covers local Ollama API diagnosis. For a stopped server, GPU failures or port conflicts, start with our general troubleshooting guide.

Identify which failure you have

Ollama documents 404 as a possible response for a model that does not exist, but the number alone does not identify the cause. Read the response body alongside the URL. The official error reference describes JSON errors and their error property.

Checks to perform before reinstalling or downloading again
ObservationNext check
No HTTP response; connection refusedCheck the server process and address first.
Model-list request works, but the requested tag is absentCorrect the requested tag or install it on that server.
HTML error page instead of Ollama JSONInspect the proxy route and upstream destination.
Model appears in a terminal but not through the app’s API addressCompare the server destinations before changing model files.

Query the server your application actually uses

Find the configured API address in your client. From the same network environment, request its model list. The model-list endpoint is a GET request:

curl --show-error --include http://127.0.0.1:11434/api/tags

That example is for a local server on macOS or Linux. In Windows PowerShell, use:

$baseUrl = 'http://127.0.0.1:11434'
$models = Invoke-RestMethod -Uri "$baseUrl/api/tags"
$models.models | Select-Object name, size

Replace the address with your actual destination. Inside a container, the loopback address refers to that container. A successful request on the host does not establish that a container reaches the same service. See our frontend and container connection guide for that distinction.

Use an exact installed name, then make one small request

Copy a returned model name rather than guessing a parameter size or tag. The following PowerShell example deliberately requires you to select an installed name; it does not automatically download weights.

$modelName = Read-Host 'Paste an exact model name from the returned list'
if ($modelName -notin @($models.models.name)) {
    throw 'That name is absent from this server model list.'
}
$body = @{
    model = $modelName
    prompt = 'Reply with one short greeting.'
    stream = $false
} | ConvertTo-Json
Invoke-RestMethod -Uri "$baseUrl/api/generate" -Method Post -ContentType 'application/json' -Body $body

The generate endpoint accepts the model and prompt. Setting stream to false makes this diagnostic easier to inspect as one response. This still loads a model and consumes memory; use a suitable installed text-generation model.

If the model is missing, install it in the right place

First choose a real tag from its official model page and check its requirements. The CLI reference documents pulling models. Run the command against the intended Ollama server, then repeat that server’s model-list request:

ollama pull <valid-model-name:tag>

The angle-bracket value is a placeholder, not a command to paste unchanged. If the pull fails, record that separate error. Do not delete the model directory to fix a naming mismatch. Our storage guide explains why different services or accounts can use different model locations; configuration details are also covered in the Ollama FAQ.

Check the API family when the route is wrong

A native request uses routes such as /api/generate. An OpenAI-compatible client uses its own API convention. Confirm the client’s expected base URL using the compatibility documentation; avoid adding an API prefix twice. When a proxy is involved, compare the upstream path with the direct server request.

If the exact installed name works directly but the app fails, save the two request URLs, model fields and error bodies. That comparison narrows the problem to client configuration or routing more effectively than another installation attempt.

Sources and verification scope

Documentation-based guidance reviewed on 21 October 2026. Commands are illustrative and were syntax-checked where applicable; they were not executed against an Ollama installation for this article. No runtime results or hardware measurements are claimed. The featured image is an original generated illustration, not a software screenshot. See our sourcing and corrections policy.