OpenAI's "Most Open" Move: Codex No Longer Exclusively Favors GPT

marsbitPublished on 2026-06-22Last updated on 2026-06-22

Abstract

OpenAI has significantly opened up its Codex programming agent by introducing a "model provider" configuration layer that allows users to connect it with various open-source models, not just its proprietary GPT. Through a configuration file or a simple `--oss` command-line flag, Codex can now route requests to local services like Ollama or LM Studio, or to third-party APIs such as Mistral or DeepSeek. This move is seen as one of OpenAI's most "open" steps, potentially lowering costs and enhancing privacy for developers who can run code generation offline. However, integration isn't seamless for all models. Codex primarily uses OpenAI's newer Responses API, while many open-source models rely on the older Chat Completions interface. This creates compatibility issues, especially for advanced features like function calling. The developer community is already building "routing" or adapter layers (e.g., CC Switch, LiteLLM) to translate between these protocols, enabling hybrid setups where GPT handles planning and open-source models handle execution. Analysts interpret this as a strategic shift for OpenAI: from competing solely on model superiority to controlling the platform and interface standards. By making Codex a flexible, pluggable entry point for AI-assisted programming, OpenAI aims to become the central hub in the developer toolchain ecosystem, even as users gain the freedom to switch underlying models.

Some cheered, calling this OpenAI's "most open" move. By equipping Codex with a plug socket for freely swappable models, they essentially filled the moat protecting their own models. What's their motive?

Overnight, OpenAI's coding agent Codex stopped recognizing only its own GPT models and opened up to all open-source models.

The developer community was the first to notice this signal.

A developer discovered a strange "open-source mode" (OSS mode) in Codex's command-line interface (CLI) and software development kit (SDK) configuration, officially referred to as "local providers."

By adding a --oss flag in the command line, it can run open-source models locally; to connect to others, just change one field.

In the past, OpenAI was almost synonymous with "closed source," with Codex exclusively recognizing OpenAI's own GPT.

But now it's different. With just a single line of configuration, you can switch to local model services like Ollama and LM Studio.

This news quickly exploded within developer circles.

Tibo, the lead of the OpenAI Codex team, personally reminded everyone on X:

Codex's App, CLI, and SDK can be used with any open-source model, not just OpenAI's own.

This reminder was quickly retweeted by Thomas Wolf, co-founder of Hugging Face, who added: "Just learned today that Codex can actually use open-source models now."

Some netizens exclaimed that this might be the most "open" move ever by OpenAI, a remarkable event.

The community moved even faster.

As soon as the official documentation was released, developers immediately tried integrating some open-source models and casually discussed more token-efficient hybrid solutions.

But some hit a wall quickly.

Developer Filip Baturan wanted to set up a hybrid solution in Codex: let GPT handle planning and let an open-source model act as the executor.

After testing, he found that Codex requires connected models to also use the same tool calling protocol, which open-source models might not have.

On one side, cheers for the "most open ever" move; on the other, protocol incompatibility preventing integration.

How far has OpenAI truly opened up this time?

How Are Open-Source Models Integrated into Codex?

OpenAI's opening of Codex this time is essentially not about opening the model itself but about opening the "model integration layer."

In other words, it hasn't opened the GPT model but has added a "pluggable model interface layer" to Codex.

This capability is accomplished through a configuration called "model_providers."

Developers can register multiple "model providers" in the configuration file, each containing four types of information:

Access address (base_url), communication protocol (wire_api), authentication method (env_key), and model mapping (model).

When Codex starts, it selects the corresponding model provider based on the configuration, routing requests to different model services, including OpenAI's own models, local Ollama models, or third-party APIs like DeepSeek.

Example of Codex's model_providers configuration. base_url is the model address, and the protocol field wire_api only recognizes one value: 'responses'.

Mistral, company self-built proxies, third-party gateways—all can be integrated into Codex this way.

A netizen summarized the highlights of this capability as: "Not locked to one vendor, switchable on demand, with privacy and costs under your own control."

More conveniently, you can save all these settings as "configuration profiles." When debugging, just click its name in the command line to switch.

Compared to manual configuration above, there's an even more direct switch: --oss. Adding this parameter makes Codex directly connect to local open-source model services.

By default, there are two: Ollama and LM Studio. The former is the most popular tool for running large models locally, and the latter is a desktop alternative with a graphical interface.

Practical screenshot of Codex --oss connecting to local models: On the left, Codex CLI (v0.92.0) uses --oss to call a local model. On the right, LM Studio loads openai/gpt-oss-20b (12.11GB) on the local machine's port 1234 to provide services. The entire process is offline and local.

This means that through local model services and network permission configuration, you can have Codex perform code generation and inference on your machine, achieving a degree of offline operation and local processing.

Codex CLI interface: The startup information shows the current model (gpt-5.2-codex) in the 'model' line, followed by "/model to change." A single command can switch models, with the entire agent running locally on the machine.

However, just because a socket is installed doesn't mean any appliance plugged in will work.

Integrated models typically need to be compatible with the Chat Completions interface format. As for whether more complex capabilities like function calling can fully work, OpenAI hasn't guaranteed it—you'll have to test them one by one.

It's precisely because protocols often don't align perfectly that the community has to write their own routing tools for translation in the middle. These are solutions currently explored by the community, not yet endorsed by OpenAI.

When GPT and Open-Source Models Mix

Working Together in Codex

While OpenAI just opened a crack, the community is already having a blast.

The reason is simple: Codex is good, but using OpenAI's models with token-based billing is too expensive.

Thus, many developers have turned their attention to open-source models.

DeepSeek is one of the most familiar open-source models for many Chinese developers. A natural question is: Can Codex directly use DeepSeek?

The answer from CC Switch is: Yes, but not directly; it needs an extra layer of "gateway."

CC Switch community tutorial: "Running DeepSeek with Local Routing in Codex"

Their community tutorial "Running DeepSeek with Local Routing in Codex" points out that the reason is the new version of Codex is mainly based on OpenAI's Responses API, while DeepSeek and most open-source model interfaces are still based on Chat Completions.

The two interface sets are not entirely consistent in request structure, streaming output methods, and function calling mechanisms.

So directly entering DeepSeek's address into Codex doesn't work smoothly. Common situations include mismatched request parameters or unparseable return results, leading to call failures or abnormal outputs, not just simple "connection failure."

The community's solution is to add a local "routing layer" or "protocol converter" in the middle.

The basic process is as follows:

1. Codex sends requests according to the Responses API;

2. The routing layer converts it to Chat Completions format;

3. Forwards it to open-source models like DeepSeek;

4. Converts the returned results back to the Responses format recognizable by Codex.

Similar capabilities aren't offered only by CC Switch.

LiteLLM, claude-code-router, and various proxy services built by developers essentially solve the same problem: enabling interaction between different models through a unified interface standard.

OpenAI opened a crack this time, but true implementation still requires the community to "add bricks and tiles."

Behind all this is a hybrid routing approach.

For example, let GPT handle planning: decomposing tasks, designing architecture, figuring out what needs to be done. Let open-source models handle execution: turning solutions into runnable code, batch editing files.

Through such mixing, for the same task, costs might be slashed by more than half.

Besides being more cost-effective, pairing Codex with local open-source models means not a single line of code leaves your own computer.

For individual developers who don't want to upload private projects to the cloud or keep paying API fees, this temptation is no small matter.

The Model War is Over

The Interface War Has Begun

For the past few years, everyone thought the moat was the model. Whoever had the largest model parameters, highest benchmark scores, and smartest answers would win.

But this time, OpenAI made Codex into a pluggable interface layer, and the value it provides is shifting towards an ecosystem gateway.

OpenAI's plan is likely to pivot from being a model-selling vendor to becoming a platform and framework player: you can swap models as you like, but the tools must be mine.

Whoever occupies the entry point developers open every day holds the distribution and sits at the core of the ecosystem.

This isn't the first time OpenAI has made moves in the open-source ecosystem.

Although it hadn't released open-weight large language models for a long time since GPT-2 in 2019, under the rapid development of the open-source ecosystem (models like Llama, DeepSeek), it re-launched the gpt-oss series of open-weight models in August 2025.

These models were quickly integrated and supported by community toolchains (like Ollama, LM Studio), precisely what Codex --oss now connects to by default.

At the configuration layer, OpenAI indeed opened the model integration capability, allowing third-party models to connect through the model provider abstraction layer. However, not any model can be used directly; it must comply with their interface protocol or be converted through an adaptation layer.

At the protocol layer, it retains a key constraint: using the Responses API as the main interaction standard while allowing support for other model interfaces like Chat Completions through compatibility layers.

In other words, regardless of which model is integrated, it must align with the request and response structure defined by OpenAI. Its ultimate goal is to keep the interface standard in its own hands.

From this perspective, this previously easily overlooked interface protocol is becoming a new competitive focus.

Perhaps, this time OpenAI wants to use an inconspicuous configuration switch to start an entry-point war for AI programming, making its next phase of competition with Anthropic not about models.

For developers who open Codex every day, this is real convenience: able to run open-source models, save on tokens, and work locally offline.

But the more smoothly you use it, the deeper you delve, the harder it becomes to leave this gateway.

References:

https://x.com/thsottiaux/status/2067181377028538431

https://developers.openai.com/codex/config-advanced#oss-mode-local-providers

https://www.ccswitch.io/en/tutorials/codex-deepseek-routing-guide

This article is from the WeChat public account "New Zhiyuan," author: ASI Apocalypse, editor: Yuanyu

Trending Cryptos

Related Questions

QWhat is the major change OpenAI has made to its Codex agent regarding model usage?

AOpenAI has opened up its Codex agent to work with open-source models, not just its own GPT models. This is done through a configurable 'model providers' layer and a new 'OSS mode' (or local providers) that allows developers to switch the underlying model powering Codex, such as to local models served by Ollama or LM Studio.

QWhat are the two primary methods mentioned for configuring Codex to use non-OpenAI models?

A1. Using the `--oss` flag in the CLI, which automatically connects Codex to default local model services like Ollama and LM Studio. 2. Manually configuring a 'model_providers' section in the settings file, where developers can specify the base URL, protocol, authentication, and model mapping for their chosen model provider (e.g., Mistral, DeepSeek, or custom endpoints).

QWhat is a key technical challenge developers face when trying to integrate models like DeepSeek into Codex, and what is the common community solution?

AA key challenge is protocol incompatibility. Newer Codex versions primarily use OpenAI's 'Responses API' format, while most open-source models (like DeepSeek) use the 'Chat Completions' API. The common community solution is to add a local routing or protocol conversion layer (e.g., using tools like CC Switch or LiteLLM) that translates requests and responses between the two formats.

QAccording to the article, what strategic shift might OpenAI be attempting with this move, moving beyond just selling models?

AThe article suggests OpenAI is shifting from being primarily a model vendor to becoming a platform and framework provider. By making Codex's interface 'pluggable', OpenAI aims to make its tool the essential daily entry point for developers. Even if developers use different models, they do so through Codex, allowing OpenAI to control the interface standard and become the central hub of the development ecosystem.

QWhat are two main practical benefits for developers in using open-source models with Codex, as highlighted in the article?

A1. **Cost Reduction:** Using local or cheaper open-source models can significantly lower costs compared to paying per token for OpenAI's API. 2. **Privacy & Offline Capability:** Running models locally means code generation and reasoning can happen entirely on the developer's machine, keeping proprietary code private and enabling a degree of offline operation.

Related Reads

Soaring Export Data for Memory Chips, Market Is Redefining the Valuation Anchor for Memory Stocks

Korean storage export data for the first 20 days of June shows substantial year-on-year increases in both value and price-per-kilogram for categories like DRAM, NAND, and SSDs. This signals a potential shift beyond simple demand recovery, indicating rising prices and a product mix shift towards higher-value items, possibly influenced by AI infrastructure needs. A key point is that the surge in price-per-kilogram is not simply a uniform chip price hike. It reflects a combination of actual price increases and, more importantly, an export structure increasingly dominated by high-value-density products like HBM (High-Bandwidth Memory) and advanced DRAM, which are critical for AI servers. This suggests AI-driven demand may be spilling over from just HBM into broader memory markets. SK Hynix stands to benefit directly due to its leading HBM position. For Samsung and Micron, the implication is potential for greater margin elasticity if the tightness in high-end memory spreads to enterprise SSD and NAND prices. However, the storage sector remains cyclical. Risks include supply expansion, inventory changes, and potential slowdowns in broader AI capital expenditure. Ultimately, while the strong export data supports upward revisions for storage company earnings and fuels discussion of an "AI infrastructure bottleneck premium," a definitive valuation shift from a cyclical to a structural story depends on upcoming quarterly reports. Investors need confirmation from SK Hynix, Samsung, and Micron that improvements in average selling prices, product mix, and, crucially,毛利率 are sustained over multiple quarters.

marsbit46m ago

Soaring Export Data for Memory Chips, Market Is Redefining the Valuation Anchor for Memory Stocks

marsbit46m ago

Why Does SpaceX Have Such a High Valuation Ceiling? The Answer Lies in Musk's Business Blueprint

SpaceX achieved a record-breaking IPO on June 12, 2026, with its market cap surging past $2.1 trillion. This valuation reflects its central role within Elon Musk's expansive, interconnected technological ecosystem. The article details how four core components form a synergistic closed-loop system: 1) **The "Brain" (xAI & Orbital Compute):** xAI provides AI models and massive ground/space-based supercomputing for simulation and decision-making across the system. 2) **The "Neural Logistics Core" (Starlink & Starship):** Starlink's low-latency satellite network enables global data transmission, while Starship's low-cost, reusable launch capacity aims to make large-scale space deployment economically viable. 3) **The "Physical Body" (Tesla & Optimus):** Tesla's manufacturing prowess and energy products support hardware production and power, pivoting toward mass-producing the Optimus humanoid robot for terrestrial and potential space-based labor. 4) **The "Human Interface" (Neuralink & X):** Neuralink seeks direct brain-computer communication, and the X platform provides real-time societal data. Together, these elements create three reinforcing "flywheels": manufacturing/logistics, data-driven iteration, and energy/compute/network synergy. This integrated approach promises lower costs, faster innovation cycles, and potential infrastructure-as-a-service offerings. However, it also concentrates technical, regulatory, and corporate governance risks. Ultimately, SpaceX's high valuation stems from its position as the indispensable infrastructural backbone—handling space transport, global communications, and future orbital computing—tying together Musk's entire vision for a self-reinforcing technological empire.

marsbit51m ago

Why Does SpaceX Have Such a High Valuation Ceiling? The Answer Lies in Musk's Business Blueprint

marsbit51m ago

Snap, Unprofitable for Nine Years, and a Decade-Long AR Obsession Without Return

Snap's AR Obsession: A Decade of Betting Against the Odds On June 16, Snap CEO Evan Spiegel unveiled the new AR glasses, Specs, priced at $2,195, causing the company's stock (SNAP) to plummet nearly 10%. The launch was met with intense criticism online, with investors questioning why a consistently unprofitable company would stake its future on an expensive product its core young user base can't afford. Snapchat, known for pioneering features like ephemeral Stories and popular AR lenses (like the iconic dog filter), has a history of innovation often copied by rivals like Instagram and Meta. Despite this, it has struggled to translate first-mover advantage into commercial success. Since its 2017 IPO, Snap has reported annual net losses, with a Q1 2026 loss of $89 million. Its stock is down 94% from its 2021 peak, hampered by iOS privacy changes, competition, and a young demographic less attractive to major advertisers. In this challenging context, Spiegel is doubling down on AR. He calls 2026 a "crucible moment," having recently laid off 16% of staff while reportedly investing over $3.5 billion cumulatively in its AR glasses line over nearly a decade. The new Specs represent a significant leap from the 2016 camera-focused Spectacles, offering true AR overlays, gesture control, and standalone operation. However, at $2,195, it faces tough comparisons. While more advanced than Meta's $799 Ray-Ban smart glasses, critics point to its heavier weight, short battery life, and features largely replicable by a smartphone. Facing pressure from investors to cut losses on the Specs project, Spiegel has refused, framing it as essential to Snap's long-term vision. The company finds itself in a paradoxical position: cutting costs while heavily funding a decade-long, unproven bet. Some see Specs as an awkward but necessary step in AR's evolution, akin to early mobile phones. Whether Spiegel is a visionary outlier or a gambler destined to fail remains an open question, highlighting the tension between long-term ambition and short-term market demands.

marsbit1h ago

Snap, Unprofitable for Nine Years, and a Decade-Long AR Obsession Without Return

marsbit1h ago

Annualized Revenue Exceeds $20 Billion, Kalshi Aims to Become the First Prediction Platform IPO?

Kalshi, a leading U.S. prediction markets platform, is reportedly in early, informal discussions for an Initial Public Offering (IPO). The company's annualized revenue now exceeds $2 billion, fueled by its dominance of over 90% of the domestic prediction market activity. This growth stems from a surge in trading volume—reaching a total of $52.7 billion—and an increase in fee rates, largely driven by sports event contracts like the NBA playoffs and the 2026 FIFA World Cup. Monthly active users are approximately 2 million. Kalshi recently raised $1 billion in a funding round led by Coatue Management, valuing the company at $22 billion. It has also expanded its offerings to include Bitcoin perpetual contracts and plans to launch a dedicated trading platform, Kalshi Pro. However, Kalshi's path to an IPO faces significant regulatory hurdles. The core risk involves jurisdictional conflicts, as multiple U.S. states are challenging its operations under local gambling laws. For instance, Arizona has filed criminal charges against the platform, while states like Kentucky have filed lawsuits. Kalshi and the Commodity Futures Trading Commission (CFTC) argue that its event contracts fall under exclusive federal jurisdiction as "swaps." The outcomes of these ongoing legal battles could critically impact Kalshi's core revenue and its IPO timeline. Analysts suggest that while an IPO could theoretically occur by late 2026, a more likely timeframe is late 2027 or 2028, contingent on resolving legal issues and favorable market conditions. If successful, its fundraising could significantly exceed $1 billion, given its current valuation and revenue multiple.

Foresight News1h ago

Annualized Revenue Exceeds $20 Billion, Kalshi Aims to Become the First Prediction Platform IPO?

Foresight News1h ago

Trading

Spot
Futures

Hot Articles

How to Buy MOVE

Welcome to HTX.com! We've made purchasing Movement (MOVE) simple and convenient. Follow our step-by-step guide to embark on your crypto journey.Step 1: Create Your HTX AccountUse your email or phone number to sign up for a free account on HTX. Experience a hassle-free registration journey and unlock all features.Get My AccountStep 2: Go to Buy Crypto and Choose Your Payment MethodCredit/Debit Card: Use your Visa or Mastercard to buy Movement (MOVE) instantly.Balance: Use funds from your HTX account balance to trade seamlessly.Third Parties: We've added popular payment methods such as Google Pay and Apple Pay to enhance convenience.P2P: Trade directly with other users on HTX.Over-the-Counter (OTC): We offer tailor-made services and competitive exchange rates for traders.Step 3: Store Your Movement (MOVE)After purchasing your Movement (MOVE), store it in your HTX account. Alternatively, you can send it elsewhere via blockchain transfer or use it to trade other cryptocurrencies.Step 4: Trade Movement (MOVE)Easily trade Movement (MOVE) on HTX's spot market. Simply access your account, select your trading pair, execute your trades, and monitor in real-time. We offer a user-friendly experience for both beginners and seasoned traders.

4.5k Total ViewsPublished 2024.12.10Updated 2026.06.02

How to Buy MOVE

Discussions

Welcome to the HTX Community. Here, you can stay informed about the latest platform developments and gain access to professional market insights. Users' opinions on the price of MOVE (MOVE) are presented below.

活动图片