If Ollama answers {"error":"typical_p is no longer supported"}, your client is sending the typical_p parameter to a version between 0.34.1 and 0.34.4, which reject it with HTTP 400 even at 1.0. Nothing is wrong with the model. I reproduced it on 27 September 2026 with four Ollama versions in Docker and tested the four ways out that work: drop the field, go back to 0.34.0, use the /v1 endpoint, or move to 0.40.0, which only leaves a warning in the log. There is a Spanish version of this guide.

Key takeaways

  • Ollama 0.34.1 (14 September 2026) retired typical_p, and up to 0.34.4 any request to /api/chat or /api/generate that includes it in options gets a 400.
  • The value does not matter: 0.7 and 1.0 fail the same way. Only a missing or null typical_p passes.
  • SillyTavern 1.19.0 and the home-llm Home Assistant integration always send it; the ollama Python library only does if you set it.
  • The OpenAI-compatible endpoint (/v1/chat/completions) ignores typical_p, so those clients are not affected.
  • 0.40.0 (pre-release 0.40.0-rc0 since 25 September) accepts it per request again and only logs a warning, but ollama create still rejects it in a Modelfile.

What the typical_p is no longer supported error means

The message comes from Ollama, not from the model or the client. In the 0.34.4 code, server/routes.go defines the error typical_p is no longer supported and returns it before loading the model whenever options carries a typical_p key with any value other than null. The handler turns it into an HTTP 400 with the JSON body your client shows.

typical_p controls typical sampling, a token filter Ollama had applied for years with a default of 1.0, which means off. The Ollama 0.34.1 release notes[1] announce it in one line: "Deprecated typical_p: it can no longer be set when creating new models, existing GGUF models retain support".

The note talks about creating models, but PR #18448[2], by Daniel Hiltgen, also blocked the parameter on every API request. That is why the problem appeared on upgrade, with nothing else changed.

Which Ollama versions return the error

The affected versions are 0.34.1, 0.34.2, 0.34.3 and 0.34.4, released between 14 and 24 September 2026. Check yours with ollama -v or curl localhost:11434/api/version.

Version typical_p in a request PARAMETER typical_p in ollama create
0.34.0 and earlier Accepted Accepted
0.34.1 to 0.34.4 HTTP 400 Error
0.40.0-rc0 Accepted, with a log warning Error

On 24 September PR #18627[3] was merged, which undoes the block. Its description sums it up: "Switch from rejecting API requests to logging a warning. Model creation still rejects the deprecated param". It came too late for 0.34.4, released hours earlier that same day, and went into 0.40.0-rc0.

On 27 September the Ollama releases page[4] still listed 0.34.4 as the latest stable release and marked 0.40.0-rc0 as a pre-release. Check that page before you decide: if a final 0.40.0 is out, upgrading is the most direct fix.

How I reproduced the error in Docker

I ran four Ollama versions side by side with Docker Compose on an 18-core aarch64 machine without a GPU, all with the same gemma3:1b model. Each listens on its own port: 22101 for 0.34.0, 22102 for 0.34.4 and 22103 for 0.40.0-rc0. I tested 0.34.1 separately and it returns the same 400. This is one service from the compose.yaml; the others only change the image tag and the port:

services:
  ollama-0344:
    image: ollama/ollama:0.34.4
    ports: ["127.0.0.1:22102:11434"]
    volumes: ["./models:/root/.ollama/models"]
    environment: [OLLAMA_NOPRUNE=1]

The smallest failing request is a chat with typical_p at 1.0, the same value Ollama used as its default. Against 0.34.4 it returns a 400 before generating anything. If your Ollama uses the standard port, replace 22102 with 11434:

curl -s -i localhost:22102/api/chat -d '{"model": "gemma3:1b",
  "messages": [{"role": "user", "content": "hola"}],
  "options": {"typical_p": 1.0}}'
# HTTP/1.1 400 Bad Request
# {"error":"typical_p is no longer supported"}

I repeated the test with three values on the three versions. /api/generate and the streaming response return the same 400, and a null typical_p passes because the code treats it as unset:

options.typical_p 0.34.0 0.34.4 0.40.0-rc0
0.7 200 400 200
1.0 200 400 200
null 200 200 200

Which clients still send typical_p

The clients that break are the ones that put typical_p in options even if you never touched it. I checked their source code and their open issues; I did not run SillyTavern or Home Assistant:

  • SillyTavern: version 1.19.0 lists typical_p in the OLLAMA_KEYS array in src/constants.js and sends it with a default of 1. Ollama issue #18542[5] reports that after upgrading "all SillyTavern message generation requests" stopped working
  • home-llm (a local LLM integration for Home Assistant): issue #399[6] traces the field to backends/ollama.py, from version 0.4.6 to 0.4.11
  • Your own code: up to 0.34.0 the Ollama API documentation[7] had an every-option example that set "typical_p": 0.7, and that block has been copied into all sorts of scripts

The official Python library only sends it if you pass it. With ollama 0.6.2 and options={"typical_p": 1.0}, 0.34.4 raises ResponseError: 400 typical_p is no longer supported. Open WebUI does not send it by default: in its code it only reaches Ollama if you add it as a custom parameter.

The OpenAI SDK does not fail because it talks to /v1/chat/completions. Ollama’s compatibility layer only copies seven fields into options (stop, max_tokens, temperature, seed, frequency_penalty, presence_penalty and top_p), so typical_p is silently dropped. With openai 3.19.2 and extra_body={"typical_p": 0.7}, 0.34.4 answered with a 200.

How to fix the error: four tested ways out

The right fix depends on whether you control the client code. Dropping the field is the permanent fix; the other three hold while you wait for the client to be updated. If you installed Ollama with the guide to installing Ollama locally, all four apply the same way.

Drop typical_p from the options

If the code is yours, delete the key from options or set it to None. With the ollama Python library it looks like this, and the same call with typical_p is the one that returned the 400:

import ollama

client = ollama.Client(host="http://localhost:11434")
r = client.chat(model="gemma3:1b",
                messages=[{"role": "user", "content": "Di hola"}],
                options={"num_predict": 8})
print(r.message.content)

For home-llm, issue #399 confirms that deleting the "typical_p": typical_p line from both options.update(...) blocks in backends/ollama.py fixes it. SillyTavern has no switch to leave it out, which is exactly what issue #18542 is about.

Go back to Ollama 0.34.0

Pinning the image to 0.34.0 restores the old behaviour: in my test it accepted typical_p with all three values. Change the tag in your compose.yaml to ollama/ollama:0.34.0 and recreate the container.

The cost is losing the fixes from 0.34.1 to 0.34.4. One of them is the faster /api/tags on large libraries: 3.1 s to 294 ms cold, according to the 0.34.1 notes. That release also changed how you build a GGUF from safetensors, which now requires the llama.cpp tooling. I cover the process in the guide to importing a Hugging Face model into Ollama.

Use the OpenAI-compatible endpoint

If your client can talk to an OpenAI-compatible API, point it at http://localhost:11434/v1. Ollama ignores typical_p there, so the request passes on 0.34.4. SillyTavern has an OpenAI-compatible chat mode, although I have not tested it against Ollama.

The trade-off is that only those seven fields get through /v1: you lose min_p, top_k, repeat_penalty and the rest of the native options. If your workflow relies on tools, also check how they behave on that endpoint, as I cover in function calling with Ollama locally.

Put a proxy in front that drops the field

When you can change neither the client nor the Ollama version, a small HTTP proxy can delete typical_p from each request before forwarding it. I wrote this one with the Python 3.14 standard library; the first half reads the body, drops the key and builds the request:

import json, os, urllib.request
from http.server import ThreadingHTTPServer, BaseHTTPRequestHandler

UPSTREAM = os.environ.get("OLLAMA_UPSTREAM", "http://127.0.0.1:11434")
PORT = int(os.environ.get("PROXY_PORT", "11435"))

class Proxy(BaseHTTPRequestHandler):
    def do_POST(self):
        body = self.rfile.read(int(self.headers.get("Content-Length", 0)))
        try:
            data = json.loads(body)
            data.get("options", {}).pop("typical_p", None)
            body = json.dumps(data).encode()
        except (ValueError, AttributeError):
            pass
        req = urllib.request.Request(UPSTREAM + self.path, data=body or None,
            headers={"Content-Type": "application/json"},
            method=self.command)

The second half sends the request to Ollama and relays the response in chunks, so streaming keeps working. do_GET reuses the same method for /api/tags and /api/version:

        try:
            resp = urllib.request.urlopen(req)
        except urllib.error.HTTPError as e:
            resp = e
        self.send_response(resp.status)
        self.send_header("Content-Type", resp.headers["Content-Type"])
        self.end_headers()
        while chunk := resp.read1(8192):
            self.wfile.write(chunk)
            self.wfile.flush()

    do_GET = do_POST

ThreadingHTTPServer(("127.0.0.1", PORT), Proxy).serve_forever()

Start it pointing at your Ollama and configure the client against the proxy port. In my test, in front of 0.34.4, the same request with typical_p at 1.0 went from 400 to 200:

OLLAMA_UPSTREAM=http://127.0.0.1:22102 PROXY_PORT=22111 \
  python3 strip_typical_p.py
# 127.0.0.1 - - [27/Sep/2026 11:44:43] "POST /api/chat HTTP/1.1" 200 -

It is a stopgap: no TLS, no authentication, and it reads the whole body into memory. Bind it to 127.0.0.1 only and remove it once you upgrade.

What changes with Ollama 0.40.0

0.40.0-rc0 accepts typical_p on each request and writes a warning line to the log, which in my container was this: level=WARN source=routes.go:185 msg="deprecated option provided" option=typical_p. SillyTavern, home-llm and your script work again unchanged.

Creating models stays closed. A Modelfile with PARAMETER typical_p 0.9 fails on 0.40.0-rc0 with a new message, "typical_p is deprecated and cannot be set as a model parameter; pass it as a request option instead". Models that already had it keep working: one created on 0.34.0 with that parameter answered normally on 0.34.4.

The current API documentation also warns that "typical_p is deprecated and may be removed in a future release". Even if 0.40.0 gets you out of trouble, drop the field when you can. The Modelfile reference[8] now lists only eleven parameters: num_ctx, repeat_last_n, repeat_penalty, temperature, seed, stop, num_predict, draft_num_predict, top_k, top_p and min_p.

Frequently asked questions

Does setting typical_p to 1.0 avoid the error?

No. On 0.34.1 to 0.34.4 the error fires for any value, because Ollama only checks whether the key exists. The only thing that passes is not sending it, or sending it as null.

Do my models with typical_p in the Modelfile stop working?

No. A model created before 0.34.1 keeps the parameter and still answers. What fails is creating a new one with PARAMETER typical_p, on 0.40.0-rc0 as well.

Does it affect llama.cpp or LM Studio?

No. The error is a check in the Ollama server’s native API. If you use llama.cpp directly, llama-server exposes its own sampling options, as I explain in how to install llama.cpp.

Conclusion

The typical_p is no longer supported error is a 400 from Ollama 0.34.1 to 0.34.4 for a key your client sends even when you do not use it. If the code is yours, delete typical_p from options. If you use SillyTavern or home-llm, move to 0.40.0 once the final release is out, or in the meantime go back to 0.34.0 or put the proxy in front. Before you choose, check the releases page: on 27 September 2026 the latest stable release was still 0.34.4.

Sources

  1. Ollama 0.34.1 release notes
  2. PR #18448
  3. PR #18627
  4. Ollama releases page
  5. issue #18542
  6. issue #399
  7. Ollama API documentation
  8. Modelfile reference
  9. ollama/ollama tags on Docker Hub
  10. ollama library on PyPI