Ollama API: 'time: missing unit in duration' from keep_alive

{"error":"time: missing unit in duration \"10\""} — the Ollama API rejected the keep_alive value in your request with HTTP 400. A string needs a unit Ollama accepts, such as "10m"; a plain number without quotes is read as seconds.

Write "keep_alive":"10m" or "keep_alive":600. Both set an expiry ten minutes ahead in /api/ps in the test. Units such as min and d are refused with a related message, unknown unit.

The error

PS> curl.exe -s -i http://127.0.0.1:15190/api/generate -d '@ka-nounit.json'   (ka-nounit.json: {"model":"qwen2.5:0.5b","prompt":"Say hi.","stream":false,"keep_alive":"10"})
HTTP/1.1 400 Bad Request
{"error":"time: missing unit in duration \"10\""}

The same request with two other units people try:

{"error":"time: unknown unit \"min\" in duration \"10min\""}
{"error":"time: unknown unit \"d\" in duration \"1d\""}

The runner printed only the status line and the last line of each reply; the other headers are left out.

Why it happens

keep_alive says how long the model stays in memory after the request. In the test it accepted a string with a unit and a bare number, and refused a string without a unit or with an unknown unit: "10m", "30s" and "24h" worked, "10min" and "1d" did not. Nothing was generated: the whole request was refused, so an application that sends a bad value on every call gets no answers at all.

The trap is the difference between "10" and 10. Quoted, it is a duration string without a unit and fails; unquoted, it is a number of seconds and works.

The fix

PS> curl.exe -s -i http://127.0.0.1:15190/api/generate -d '@ka-good.json'   (ka-good.json: {"model":"qwen2.5:0.5b","prompt":"Say hi.","stream":false,"keep_alive":"10m"})
HTTP/1.1 200 OK
{"model":"qwen2.5:0.5b","created_at":"2026-11-06T07:32:57.3709458Z","response":"Hello! How can I assist you today?","don ... (cut)
PS> curl.exe -s http://127.0.0.1:15190/api/ps
{"models":[{"name":"qwen2.5:0.5b", ... "expires_at":"2026-11-06T13:12:57.3719727+05:30", ...

The request was sent at 13:02:57 local time and /api/ps shows the model expiring at 13:12:57, ten minutes later. The number form, "keep_alive":600, gave the same ten-minute expiry a moment earlier. Further checks in the same session: "30s" set an expiry 30 seconds ahead, and both "24h" and 86400 set one a day ahead, so write a day as "24h", since d was refused.

How it was reproduced

Ollama 0.40.14 on Windows 11, against a separate test server started with ollama serve on 127.0.0.1:15190 with its own models folder and qwen2.5:0.5b. Five request bodies (the file names are the test's own) were written to files by a PowerShell script and sent to /api/generate with curl.exe -i, each followed by a call to /api/ps: "10", "10min" and "1d" failed, 600 and "10m" worked.

Frequently asked

What does 'time: missing unit in duration' mean in Ollama?

The keep_alive value was a string without a unit, such as "10". Add a unit, as in "10m", or send a plain number without quotes, which Ollama reads as seconds.

How do I keep an Ollama model loaded for a day?

Use "keep_alive":"24h" or the number 86400. Both set an expiry one day ahead in the test, while "1d" was refused with unknown unit "d".

Is keep_alive in Ollama seconds or minutes?

A bare number is seconds: 600 set an expiry ten minutes ahead in /api/ps in the test. A string carries its own unit, so "10m" means the same ten minutes.

More decoded errors in the Fixes category. Every field of a request body, keep_alive included, is shown in the Ollama API post.