level=WARN ... msg="invalid option provided" option=num_ctxx in the Ollama server log means a key in the request's options object is not an option name the server knows. The request still succeeds with HTTP 200 and the setting is not applied. Fix the spelling (here num_ctx) and check that it took effect with /api/ps.

The client gets no error, so the only signs are the warning in the server log and a model that behaves as if you never set the option. In the test, "num_ctxx":8192 left the context at 4096; "num_ctx":8192 gave 8192.

The error

The body file ctx-typo.json, the request, then the server log line:

{"model":"qwen2.5:0.5b","prompt":"Say hello.","stream":false,"options":{"num_ctxx":8192}}
PS> curl.exe -s -i -d "@ctx-typo.json" http://127.0.0.1:15191/api/generate
HTTP/1.1 200 OK
...
{"model":"qwen2.5:0.5b","created_at":"2026-11-10T03:27:28.8986353Z","response":"Hello! It's a pleasure to say hello to you. How can I assist you today?","done":true,"done_reason":"stop",...}

time=2026-11-10T08:57:27.373+05:30 level=WARN source=types.go:1131 msg="invalid option provided" option=num_ctxx

Why it happens

The server answered the request and wrote one warning naming the unknown key. The warning is stamped 08:57:27 local time (UTC+05:30) and the reply's created_at is 03:27:28 UTC, one second later, so the two belong together. Nothing in the reply body mentions it. The model then loaded with the context it would have had without the option; the log and /api/ps after that request both show 4096: 

llama_context: n_ctx                 = 4096
PS> curl.exe -s http://127.0.0.1:15191/api/ps
{"models":[{"name":"qwen2.5:0.5b",...,"expires_at":"2026-11-10T09:02:28.8996695+05:30","size_vram":483645193,"context_length":4096,"runner":"llamacpp"}]}

A misspelling in options is easy to miss: both short prompts in this test got a normal greeting, with or without the typo.

The fix

{"model":"qwen2.5:0.5b","prompt":"Say hello.","stream":false,"options":{"num_ctx":8192}}
PS> curl.exe -s -i -d "@ctx-ok.json" http://127.0.0.1:15191/api/generate
HTTP/1.1 200 OK
...
PS> curl.exe -s http://127.0.0.1:15191/api/ps
{"models":[{"name":"qwen2.5:0.5b",...,"expires_at":"2026-11-10T09:02:31.5101223+05:30","size_vram":583805173,"context_length":8192,"runner":"llamacpp"}]}

With the correct name no warning was written, /api/ps reported "context_length":8192 and the server log showed llama_context: n_ctx = 8192. The model's memory size went from 483,645,193 to 583,805,173 bytes. Two habits catch this early: search the server log for invalid option after changing options, and read context_length from /api/ps when the option is num_ctx.

How it was reproduced

Ollama 0.40.14 (ollama --version) on Windows 11, run as a separate ollama serve on 127.0.0.1:15191 with its own models folder and qwen2.5:0.5b, its standard error redirected to a file with Start-Process -RedirectStandardError; that file is the server log quoted above. The two requests went through curl.exe from Windows PowerShell 5.1 with ASCII body files, three seconds apart, each followed by /api/ps.

Frequently asked

What does invalid option provided mean in the Ollama log?
A key in the options object of a request is not an option name the server knows, for example num_ctxx. The request still returns 200 and the option is not applied.
How do I check that num_ctx took effect in Ollama?
Call /api/ps after the request and read context_length for the model. In the test num_ctx 8192 showed context_length 8192; the misspelled num_ctxx left it at 4096.
Does Ollama return an error for an unknown option?
Not to the client in the test. Ollama 0.40.14 answered HTTP 200 and wrote a WARN line with msg="invalid option provided" and the option name to the server log.

More decoded errors in the Fixes category. When num_ctx is spelled right but too small, the log says something else: see 'truncating input prompt'.