ollama_oss: default WireApi to Responses, fall back to Chat #8227

drifkin · 2025-12-18T01:24:16Z

In Ollama v0.13.4 /v1/responses support was added. When Ollama is used via --oss, it now defaults to Responses. At runtime we do a version check and if the version is older than when Responses support was added, we fall back to /v1/chat/completions.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

codex-rs/core/src/model_provider_info.rs

etraut-openai · 2025-12-18T21:43:19Z

@drifkin, thanks for the PR. There were some merge conflicts. I attempted to address them in the github merge UI, but I apparently missed something because I'm seeing build errors. Please pull the latest changes and fix them up on your branch (or have codex do it) and push the change.

In Ollama v0.13.4 `/v1/responses` support was added. When Ollama is used via `--oss`, it now defaults to Responses. At runtime we do a version check and if the version is older than when Responses support was added, we fall back to `/v1/chat/completions`.

drifkin · 2025-12-19T00:18:04Z

no worries! I think when I was originally making this change I just happened to be 30m away from another config change that conflicted a bit. I had codex rebase it against main, and have just pushed up a new version.

Previously we were only downgrading to chat for older `ollama`s when using `--oss`, but you can also use the built-in ollama provider via `model_provider = "ollama"` in your config

etraut-openai · 2025-12-19T00:19:40Z

@drifkin, looks like there are formatting issues. A quick just fmt should clean it up.

drifkin · 2025-12-19T00:20:20Z

@drifkin, looks like there are formatting issues. A quick just fmt should clean it up.

oops, had those formatting changes staged, but not committed. Just pushed them up as well

etraut-openai · 2025-12-19T00:27:07Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2025-12-19T00:32:45Z

codex-rs/core/src/model_provider_info.rs

        ("openai", P::create_openai_provider()),
        (
            OLLAMA_OSS_PROVIDER_ID,
-            create_oss_provider(DEFAULT_OLLAMA_PORT, WireApi::Chat),
+            create_oss_provider(DEFAULT_OLLAMA_PORT, WireApi::Responses),
        ),


Ensure Ollama fallback runs in all entrypoints

Switching the built‑in Ollama provider default to WireApi::Responses means any binary that loads a Config but does not call detect_ollama_wire_api_if_needed will now send /v1/responses to older Ollama servers (<0.13.4) and fail instead of falling back to /v1/chat/completions. I checked codex-rs/app-server/src/lib.rs and codex-rs/mcp-server/src/lib.rs (and several CLI subcommands) and they load config without the new detection call, so those entrypoints regress while exec/tui do not. Consider moving the detection into a shared config loading path or wiring it into other entrypoints so all Ollama uses get the same compatibility fallback.

Useful? React with 👍 / 👎.

codex-rs/common/src/oss.rs

bolinfest · 2025-12-19T01:22:55Z

codex-rs/exec/src/lib.rs

        Config::load_with_cli_overrides_and_harness_overrides(cli_kv_overrides, overrides).await?;

+    if !oss {
+        detect_ollama_wire_api_if_needed(&mut config).await;


I'll be honest: I don't love this idea that we have to know to mutate Config after it is constructed in these cases. Ideas:

If there is an issue where we detect a runtime mismatch that the user can fix by modifying their config.toml, could we return an error that asks them to do that?

Should we move this logic inside Config's constructor so we don't have to post-process this here?

Yeah I don't super love this either, I'll look into doing the constructor change (though is it surprising to have the constructor make a network call?). I think the main motivation behind doing this kind of involved change is I don't know how people can edit any of the built-in ollama flows to change the wire format in config.toml (either via --oss or the model_provider = "ollama" path, the latter of which I learned from codex's review above). Do you know if that's even currently possible?

And the intent is to remove all of this code once the chat completions wire format is hard deprecated

codex-rs/ollama/Cargo.toml

drifkin · 2025-12-19T07:27:48Z

@bolinfest: thanks for the review, I can make those code changes tomorrow. I think the main point of conversation is around configuring built-in providers (I might just not understand how they interact with the config.toml)

Co-authored-by: Michael Bolin <[email protected]>

devdev-automation · 2025-12-29T18:12:23Z

It appears that the failing check had an error that was fixed in the lastest release. Might be worth re-running the checks.

EmbarkStudios/cargo-deny-action#101

bolinfest

@drifkin OK, so we still haven't addressed the fundamental issue, which is that now Config is mut in a bunch of places where it really should not be.

One of my original suggestions was:

If there is an issue where we detect a runtime mismatch that the user can fix by modifying their config.toml, could we return an error that asks them to do that?

and you rightfully pointed out that this is a bit tricky given how the built-in ollama provider created by built_in_model_providers() works today.

What if we took a different approach where:

The built-in ollama is updated to assume the Responses API by default.
We introduce an additional built-in provider, ollama-chat, that is the same as ollama except it uses the chat wire format.
At runtime, if someone tries using ollama and the server doesn't support the Responses API, we error and tell them to set model_provider = "ollama-chat" in config.toml, but maybe also point them to #7782 that chat API support is going away in Codex in February 2026.

bolinfest · 2026-01-05T21:39:16Z

codex-rs/ollama/src/lib.rs

+    if *version == Version::new(0, 0, 0) {
+        return WireApi::Responses;
+    }
+    if *version >= min_responses_version() {


Suggested change

if *version == Version::new(0, 0, 0) {

return WireApi::Responses;

}

if *version >= min_responses_version() {

if *version == Version::new(0, 0, 0) {

WireApi::Responses

} else if *version >= min_responses_version() {

Though this should probably be combined with ||?

drifkin · 2026-01-06T09:38:44Z

What if we took a different approach where:

The built-in ollama is updated to assume the Responses API by default.

We introduce an additional built-in provider, ollama-chat, that is the same as ollama except it uses the chat wire format.

At runtime, if someone tries using ollama and the server doesn't support the Responses API, we error and tell them to set model_provider = "ollama-chat" in config.toml, but maybe also point them to Deprecating `chat/completions` support in Codex #7782 that chat API support is going away in Codex in February 2026.

I like this! I'll try out a new PR with that approach.

This is an alternate PR to solving the same problem as <openai#8227>. In this PR, when Ollama is used via `--oss` (or via `model_provider = "ollama`), we default it to use the Responses format. At runtime, we do an Ollama version check, and if the version is older than when Responses support was added to Ollama, we print out a warning. Because there's no way of configuring the wire api for a built-in provider, we temporarily add a new `oss_provider`/`model_provider` called `"ollama-chat"` that will force the chat format. Once the `"chat"` format is fully removed (see <openai#7782>), `ollama-chat` can be removed as well

drifkin · 2026-01-06T22:53:55Z

What if we took a different approach where:

The built-in ollama is updated to assume the Responses API by default.

We introduce an additional built-in provider, ollama-chat, that is the same as ollama except it uses the chat wire format.

At runtime, if someone tries using ollama and the server doesn't support the Responses API, we error and tell them to set model_provider = "ollama-chat" in config.toml, but maybe also point them to Deprecating chat/completions support in Codex #7782 that chat API support is going away in Codex in February 2026.

I like this! I'll try out a new PR with that approach.

@bolinfest: here's a new PR that implements the ollama-chat provider approach: #8798

etraut-openai · 2026-01-09T16:45:42Z

Closing this PR in favor of #8798.

chatgpt-codex-connector bot reviewed Dec 18, 2025

View reviewed changes

codex-rs/core/src/model_provider_info.rs Show resolved Hide resolved

etraut-openai added the needs-response Additional information is requested label Dec 18, 2025

drifkin force-pushed the drifkin/ollama-oss-responses branch from 4c088dd to 21c37a1 Compare December 19, 2025 00:16

also detect Ollama version for the built-in, non---oss case

d6d0347

Previously we were only downgrading to chat for older `ollama`s when using `--oss`, but you can also use the built-in ollama provider via `model_provider = "ollama"` in your config

drifkin force-pushed the drifkin/ollama-oss-responses branch from 21c37a1 to d6d0347 Compare December 19, 2025 00:19

etraut-openai removed the needs-response Additional information is requested label Dec 19, 2025

chatgpt-codex-connector bot reviewed Dec 19, 2025

View reviewed changes

bolinfest reviewed Dec 19, 2025

View reviewed changes

etraut-openai added the needs-response Additional information is requested label Dec 19, 2025

drifkin and others added 4 commits December 19, 2025 10:01

Update codex-rs/common/src/oss.rs

3f183b6

Co-authored-by: Michael Bolin <[email protected]>

fix formatting

18807ce

rename detect_ollama_wire_api_if_needed to update_...

013c289

ollama/Cargo.toml: fix alpha sort

1473fa4

etraut-openai mentioned this pull request Dec 22, 2025

Add support for using WireAPI:Responses with Ollama #8408

Open

etraut-openai removed the needs-response Additional information is requested label Dec 25, 2025

Merge branch 'main' into drifkin/ollama-oss-responses

f0ea623

bolinfest reviewed Jan 5, 2026

View reviewed changes

drifkin mentioned this pull request Jan 6, 2026

ollama: default to Responses API for built-ins #8798

Open

etraut-openai closed this Jan 9, 2026

ollama_oss: default WireApi to Responses, fall back to Chat #8227

ollama_oss: default WireApi to Responses, fall back to Chat #8227

Conversation

drifkin commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

etraut-openai commented Dec 18, 2025

Uh oh!

drifkin commented Dec 19, 2025

Uh oh!

etraut-openai commented Dec 19, 2025

Uh oh!

drifkin commented Dec 19, 2025

Uh oh!

etraut-openai commented Dec 19, 2025

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bolinfest Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

drifkin Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

drifkin commented Dec 19, 2025

Uh oh!

devdev-automation commented Dec 29, 2025

Uh oh!

bolinfest left a comment

Choose a reason for hiding this comment

Uh oh!

bolinfest Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

bolinfest Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

drifkin commented Jan 6, 2026

Uh oh!

drifkin commented Jan 6, 2026

Uh oh!

etraut-openai commented Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

drifkin commented Dec 18, 2025 •

edited

Loading