Ollama 0.40.16の/v1/responsesは、コンテキスト長を超える入力に400エラーを返す｜0.40.15との比較と、Codexがエラーで止まったときの直し方

2026年11月11日

Ollama 0.40.16で、/v1/responsesが長い入力を黙って短くしなくなった

手元のパソコンでAIモデルを動かすツール「Ollama」の0.40.16が、2026年11月10日（日本時間）に公開されました（v0.40.16のリリースノート）。変更点の1つが、OpenAIの「Responses API」と同じ形で呼べる/v1/responsesの扱いです。リリースノートには「truncationの指定を守り、既定では黙って切り詰めない」とあります。

AIモデルが一度に読める長さ（コンテキスト長）を超える入力が来たとき、0.40.15の/v1/responsesは、入りきらない部分を捨てたうえでHTTP 200の答えを返していました。0.40.16からは、捨てずに400エラーで止めます。truncationは、入力がコンテキスト長を超えたときに、入力の先頭を落として続けるか（"auto"）、エラーで止めるか（"disabled"）を選ぶ、リクエストの項目です。OpenAIのPython SDKでclient.responses.create()を呼んでいるプログラムや、OllamaにつないだCodex（OpenAIのコーディング用AIツール）は、この/v1/responsesを使います。

この記事では、0.40.15と0.40.16をDockerの公式イメージで並べて、同じリクエストを送りました。エラーになる条件、OpenAI SDKとCodexでの見え方、コンテキスト長を広げる直し方を、実際の応答とログで確かめた結果をまとめます。

要点

0.40.16の/v1/responsesは、コンテキスト長を超える入力を400エラーで止める

6040トークンの入力を、コンテキスト長4096のOllamaへ/v1/responsesで送って比べました。

0.40.15

2050トークンに短くして答える

入力の先頭にあった情報が消えた状態で、HTTP 200が返ります。

0.40.16

HTTP 400で止める

truncationを省いたときも"disabled"のときも、同じエラー文が返ります。

切り詰めの扱いが変わったAPI

/v1/responsesだけ

/v1/chat/completionsと/api/chatは、両方の版で今までどおり短くします。

直し方

コンテキスト長を広げる

16384に広げると、同じ入力を6040トークンのまま読んで正しく答えました。

0.40.15の/v1/responsesは、コンテキスト長に入りきらない入力の先頭を黙って捨てていた

比べた入力は、先頭に「The secret word is BLUEBIRD.」（秘密の単語はBLUEBIRD）と書き、続けて「filler record.」という埋め草の文を2000回並べ、最後に「秘密の単語は？」と聞く英文です。全体で6040トークンあります。先頭の1文が読めていれば「BLUEBIRD」と答えられ、捨てられていれば答えられない作りです。

Ollamaは既定のまま起動しました。今回のDocker（GPUなし）では、読み込んだモデルのコンテキスト長がollama psで4096と表示されます。モデルは小さいqwen3:0.6bを使いました。

0.40.15の応答

HTTP 200・答えは「filler」

statusはcompleted、errorはnull
usage.input_tokensは2050（ログのlimit=2050。4096のほぼ半分）
応答のtruncation欄は、切り詰めない設定を表す"disabled"のまま
答えは「filler」

0.40.16の応答

HTTP 400・エラー文で理由を返す

答えは返らない
エラー文に入力のトークン数（6040）とコンテキスト長（4096）が入る
typeはinvalid_request_error

短い入力（35トークン）には、両方の版が「BLUEBIRD」と答えました。0.40.15の長い入力への応答だけを見ると、入力が短くされたことは分かりません。短くされたかどうかは、送った長さより小さいusage.input_tokensと、Ollamaのサーバーのログに出る警告で分かります。

level=WARN source=llama_server.go:344 msg="truncating input prompt" limit=2050 prompt=6040 keep=4 new=2050

0.40.16が返したエラーは次のとおりです。

HTTP/1.1 400 Bad Request
{"error":{"message":"request (6040 tokens) exceeds the available context size (4096 tokens), try increasing it","type":"invalid_request_error","param":null,"code":null}}

0.40.15で見た、黙って短くして200を返す動きは、利用者が11月3日にIssue #19492で報告していました。0.40.13と0.40.14で、truncationに"disabled"を指定しても6166トークンの入力が1026トークンに短くなった、という内容です。原因は、/v1/responsesで受け取ったtruncationを、Ollamaの内部の処理へ渡していなかったことでした。渡されないと内部の処理は「短くしてよい」を既定にします。修正はPR #19501で入りました。

0.40.16の/v1/responsesは、truncationが"auto"のときだけ短くする

OpenAIのResponses APIのtruncationには"auto"と"disabled"の2つの値があり、"disabled"が既定です。OpenAIのPython SDKの型の説明では、"disabled"のときは入力がコンテキストを超えると400エラーで失敗し、"auto"のときは会話の先頭から項目を落として収めます。0.40.16は、この仕様に合わせました。同じ6040トークンの入力で、値ごとに比べた結果です。

送ったtruncationの値	0.40.15	0.40.16
書かない（省略）	200（2050トークンに短縮）	400（コンテキスト超過）
`"disabled"`	200（2050トークンに短縮）	400（コンテキスト超過）
`"auto"`	200（2050トークンに短縮）	200（2050トークンに短縮）
`"foo"`（決められた値以外）	200（値は無視して短縮）	400（`unknown truncation strategy: "foo"`）

入力は6040トークン、コンテキスト長は4096。Docker Desktop 4.79.0、ollama/ollama:0.40.15と0.40.16、qwen3:0.6bで2026年11月11日に確認。

OllamaのOpenAI互換APIのドキュメントでは、2026年11月11日の時点で/v1/responsesで使える項目の一覧で、truncationには未対応の印が付いたままです。0.40.16でのtruncationの扱いは、上の表のとおりです。

決められた値以外を送ったときは、短い入力（35トークン）でも0.40.16では400になりました。0.40.15では無視されていた値なので、プログラムに"none"のような値を書いていると、0.40.16へ上げたあとは、その値を付けた/v1/responsesのリクエストが、短い入力でもすべて400になります。

stream: trueで送った場合も、0.40.16は400のJSONを1つ返し、ストリーム（response.createdなどのイベント）を始めません。OpenAIのPython SDKでストリームなしにresponses.create()を呼ぶと、その時点でopenai.BadRequestErrorが出ます。0.40.16で実行した結果は次のとおりです。

[truncation省略] BadRequestError status=400 message=Error code: 400 - request (6040 tokens) exceeds the available context size (4096 tokens), try increasing it
[truncation="auto"] OK input_tokens=2050 text='The secret word is **"filler"**.'

/v1/chat/completionsと/api/chatは、0.40.16でも長い入力を短くして答える

0.40.16で切り詰めの扱いが変わったのは/v1/responsesだけです。同じ入力をほかの2つのAPIへ送ると、0.40.15と0.40.16の結果は同じでした。

0.40.16で変わった

/v1/responses

既定で400。短くしたいときだけtruncation: "auto"を送る。

両方の版で同じ

/v1/chat/completions

200で返り、usage.prompt_tokensは2050。答えは「filler」。

両方の版で同じ

/api/chat（Ollama独自）

既定は200で2050に短縮。"truncate": falseを付けると、両方の版で、0.40.16の/v1/responsesと同じエラー文の400。

OpenAIのChat Completions APIの形で呼ぶツールは、0.40.16へ上げても、入りきらない入力を黙って短くしたまま答えます。入力の先頭が消えていないかを確かめるには、応答のusage.prompt_tokensが送った長さに見合うかを見ます。Ollama独自の/api/chatに"truncate": falseを付けて呼ぶと、超えた時点でエラーになります。

コンテキスト長4096の0.40.16では、Codexが最初の依頼で止まることがある

Codexには、手元のOllamaにつなぐ組み込みのollamaプロバイダーがあり、codex --oss --local-provider ollamaのように指定して使えます。Codexのソースでは、このプロバイダーはhttp://localhost:11434/v1/responsesを使います。Codexが送るリクエストの定義（ResponsesApiRequest）にはtruncationの項目がないので、Ollamaからは「省略」に見えます。0.40.16では、省略は"disabled"と同じ扱いです。

Codex CLI 0.165.0でcodex exec --oss --local-provider ollama -m qwen3:0.6bを実行し、コンテキスト長4096のOllamaへ1行の依頼「Reply with exactly one word: READY」を送りました。まず、AGENTS.md（作業の決まりを書いたファイル。Codexが作業フォルダーと、その上のリポジトリから読み込む）のない、リポジトリの外の空のフォルダーで実行すると、0.40.16でも「READY」と答えました。ただし、Codexの表示した使用トークン数は4,039で、4096のほぼ上限です。Codexは依頼文に加えて、自分の指示文などを毎回送るためです。

次に、AGENTS.md（今回は約6.7KB）があるフォルダーで同じ依頼を送りました。Codexはこのファイルの内容も入力に加えるので、全体が5354トークンになり、0.40.16では最初のリクエストで止まりました。

ERROR: Reconnecting... 1/5
ERROR: Reconnecting... 2/5
ERROR: Reconnecting... 3/5
ERROR: Reconnecting... 4/5
ERROR: Reconnecting... 5/5
ERROR: stream disconnected before completion: request (5354 tokens) exceeds the available context size (4096 tokens), try increasing it

Codexは5回つなぎ直したあと、終了コード1で終わりました。同じフォルダーから0.40.15へ送ると、Codexは「READY」と答えて終了コード0で終わります。0.40.15をOLLAMA_DEBUG=1で起動し直して同じ依頼を送ると、詳しいログにtruncating input messages which exceed context lengthと出ました。Codexが残す会話記録（CODEX_HOMEのsessionsフォルダーのJSONLファイル）では、0.40.16が5354トークンとして受け取った同じ依頼を、0.40.15は3658トークンで処理しています。落とされたのは、AGENTS.mdの内容を入れたメッセージ（約1,700トークン）です。0.40.15のこの処理は、systemメッセージと最後のメッセージを残し、その間の古いメッセージから捨てます（server/prompt.go）。

Codexへの依頼	0.40.15（コンテキスト長4096）	0.40.16（コンテキスト長4096）	0.40.16（コンテキスト長16384）
1行の依頼（空のフォルダー）	—	「READY」と答えた（tokens used 4,039）	—
1行の依頼（AGENTS.mdのあるフォルダー、5354トークン）	「READY」と答えた（AGENTS.mdのメッセージを落とし、3658トークンで処理）	5回つなぎ直して終了コード1	「READY」と答えた（tokens used 5,460）
秘密の単語の長文（最初の検証と同じ文。Codexの指示文などを含めて11372トークン）	「fill」と答えた（AGENTS.mdのメッセージを落とし、残りの9676トークンをさらに2050に短縮）	5回つなぎ直して終了コード1	「BLUEBIRD」と答えた（tokens used 11,453）

Codex CLI 0.165.0、qwen3:0.6b。1行目以外はAGENTS.mdのあるフォルダーで実行。16384の列は、1行の依頼がModelfileで作った別名のモデル、長文がOLLAMA_CONTEXT_LENGTHで広げたサーバー。「tokens used」はCodexが表示した入力と出力の合計。3658・9676・2050はOllamaのログとCodexの会話記録の入力トークン数。2026年11月11日に確認。

止まるかどうかは、手元のOllamaのコンテキスト長と、Codexが送る入力の長さで決まります。Ollamaの公式ドキュメントによると、既定のコンテキスト長はGPUのメモリ（VRAM）の量で変わり、24GiB未満なら4k、24〜48GiBなら32k、48GiB以上なら256kです。Codexのようなコーディングツールには64000以上が勧められています。

メモリ32GBのMac（Apple M4）でHomebrewのOllama 0.40.15を起動すると、ログにtotal_vram="25.0 GiB" default_num_ctx=32768と出て、ollama psのCONTEXTは32768でした。AGENTS.mdのあるフォルダーで5354トークンだった最初の依頼は、このMacの32768に収まります。会話が長くなって32768を超えると、0.40.16では同じ400になります。変更はOpenAI互換のAPIの処理（openai/responses.go）にあり、ollama psのRUNNERがllamacppのモデル（今回のqwen3:0.6bのようなGGUFのモデル）なら、MacでもDockerと同じです。MacでMLXのランナーで動くモデルは、どちらの版でも黙って短くせず、input length (N tokens) exceeds the model's maximum context length (M tokens)という別のエラーを返します（server/routes.go）。自分の環境の値は、モデルを一度動かしてからollama psのCONTEXTの列で確かめられます。

コンテキスト長を広げると、入力を切らずに答える

エラー文の最後にある「try increasing it」のとおり、コンテキスト長を広げると0.40.16でも答えが返ります。0.40.16のサーバーをOLLAMA_CONTEXT_LENGTH=16384で起動し直して同じ6040トークンの入力を送ると、usage.input_tokensは6040のままで、答えは「BLUEBIRD」でした。/v1/chat/completionsと/api/chatも、6040トークンを読んで「BLUEBIRD」と答えました。Codexも、秘密の単語の長文に「BLUEBIRD」と答えています。

exceeds the available context sizeが出たときの直し方

1. 今のコンテキスト長を確かめる

モデルを動かした直後にollama psを実行し、CONTEXTの列を見ます。エラー文の「available context size」も同じ値です。

2. サーバー全体で広げる

ollama serveで起動しているならOLLAMA_CONTEXT_LENGTH=16384 ollama serve、Dockerなら-e OLLAMA_CONTEXT_LENGTH=16384を付けます。Macのアプリでは、設定画面のコンテキスト長のスライダーで変えます。16384は今回の検証で使った値で、Codexのようなコーディングツールには、公式ドキュメントが64000以上を勧めています。メモリが足りるなら、その値にします。

3. モデルごとに広げる

ModelfileにPARAMETER num_ctx 16384を書いて別名のモデルを作り、その名前で呼びます。OpenAI互換のAPIにはコンテキスト長を指定する項目がないため、この方法をOllamaのドキュメントが案内しています。Codexで使うなら、手順2と同じく64000以上を目安にします。

4. 広げられないときは、短くしてよいと伝える

自分のプログラムならtruncation: "auto"を送ると、0.40.15と同じく先頭を落として答えます。先頭にある指示や資料が消えてもよい用途に限ります。

Modelfileの方法は、既定の4096のまま動いている0.40.16のサーバーで試しました。

FROM qwen3:0.6b
PARAMETER num_ctx 16384

このファイルでollama create qwen3-0.6b-16k -f Modelfileを実行し、modelにqwen3-0.6b-16kを指定して送ると、200で返ってusage.input_tokensは6040、答えは「BLUEBIRD」でした。元のqwen3:0.6bの名前で送ると、同じサーバーでも400のままです。

Codexでこの別名を使うときは、-m qwen3-0.6b-16k:latestのように:latestまで書きます。-m qwen3-0.6b-16kだけだと、Codexはモデルが見つからないと判断して取得を始め、Pull failed: pull model manifest: file does not existで終わりました。:latestまで書くと、AGENTS.mdのあるフォルダーでも「READY」と答えました。

コンテキスト長を広げると、モデルが使うメモリが増えます。今回のDocker（GPUなし）では、qwen3:0.6bのollama psのSIZEが4096のとき1.0GB、16384のとき2.5GBでした。広げたあとはollama psのPROCESSORの列で、モデルがGPUに収まっているか（100% GPU）も確かめます。

0.40.16では、モデルを1つも入れていないときの/v1/modelsが空の配列を返す

0.40.16には、もう1つOpenAI互換のAPIの変更があります。モデルを1つも入れていないOllamaの/v1/modelsが返すdataが、nullから空の配列に変わりました（PR #19539）。モデルなしで起動した2つの版で確かめた結果です。

0.40.15: {"object":"list","data":null}
0.40.16: {"object":"list","data":[]}

モデルの一覧をdataの配列としてそのまま回すプログラムは、0.40.16では空の一覧として扱えます。0.40.15などの前の版のOllamaにもつなぐプログラムなら、nullのときも空の一覧として扱う書き方を残しておきます。

0.40.16へ上げる前に確かめる4つのこと

どのAPIで呼んでいるか：OpenAI SDKのresponses.create()やCodexの--ossは/v1/responsesを使います。Chat Completionsの形で呼ぶツールの入力は、0.40.16でも黙って短くされます。
コンテキスト長はいくつか：ollama psのCONTEXTが4096なら、AGENTS.mdを読み込むフォルダーのCodexは最初の依頼から止まることがあります。
送っているtruncationの値："auto"と"disabled"以外の値は、短い入力でも400になります。
400を受け取ったときの処理：openai.BadRequestErrorを受けて、コンテキスト長を広げるよう表示するか、会話を要約して短くしてから送り直す処理を用意します。

0.40.15では、コンテキスト長が足りなくても答えが返るので、先頭の指示や資料が抜けたまま使っていたことに気づきにくい状態でした。0.40.16でコンテキスト長の超過のエラーが出た場面は、0.40.15なら入力の一部が消えたまま答えていた場面です。エラーが出たら、まずollama psで値を確かめて、コンテキスト長を広げます。