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

marsbitPublicado em 2026-06-22Última atualização em 2026-06-22

Resumo

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

Criptomoedas em alta

Perguntas relacionadas

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.

Leituras Relacionadas

Foundation Steps Back, Ethlabs Steps Forward: Ethereum Undergoes Its Largest Restructuring in History

On June 23rd, the Ethereum ecosystem witnessed two major shifts, signaling a significant governance realignment. First, former Ethereum Foundation researchers established Ethlabs, a new independent non-profit. Backed by major ETH holders like Bitmine and SharpLink, Ethlabs aims to address practical needs for institutional adoption, including faster settlement, native asset issuance, cross-chain transactions, and mainnet scaling. Secondly, the Ethereum Foundation announced a major restructuring, laying off 54 employees (20% of its staff) to become a leaner entity focused on protocol governance and maintenance rather than being the primary builder. This move represents a pivotal correction. Criticisms had mounted over the Foundation's perceived slowness, lack of clear strategy, and over-reliance on Vitalik Buterin's influence. Ethlabs emerges as a more execution-oriented, "industrialized" layer focused on market adoption—bridging the gap between research and real-world use. Notably, Vitalik Buterin is absent from its list of supporters, interpreted as an intentional step to avoid excessive personal endorsement and allow the organization to build independent credibility. The Ethereum Foundation's downsizing and redefinition mark a retreat from its former central coordinating role. It now aims to share the "privilege of stewarding Ethereum" with other emerging groups like Ethlabs, the Ethereum Applications Guild, and The Ethereum Economic Zone. Analysts frame this dual shift as the Foundation ensuring Ethereum remains "correct" (credibly neutral), while Ethlabs must prove it remains "effective" (competitive and attractive for capital and adoption). This addresses community "shareholder-like anxiety" about ETH's market performance. While risks exist—such as concerns over shifting from Foundation centrality to large-holder influence—the consensus is that the greater risk for Ethereum was inaction, caught between technical idealism and organizational inertia. These steps aim to create a more multi-stakeholder, execution-driven future for the network.

链捕手Há 5h

Foundation Steps Back, Ethlabs Steps Forward: Ethereum Undergoes Its Largest Restructuring in History

链捕手Há 5h

Second Half of U.S. Crypto Policy: The Clarity Act Aims for 60 Votes, CFTC's "One-Person Commission" Becomes Biggest Variable

In a pivotal year for US crypto policy, the "CLARITY Act" is advancing in the Senate but faces a high hurdle, needing 60 votes to pass. Key challenges include bridging partisan divides on ethics and swaying undecided Republican senators within a tight legislative calendar of only about 40 working days. The policy "second half" involves intense negotiations on a broader framework for Web3 and DeFi, including crypto tax reforms and the Blockchain Regulatory Certainty Act. A significant uncertainty is the understaffed CFTC, operating with four commissioner vacancies, which complicates regulatory clarity. Meanwhile, the departure of key "crypto champions"—SEC Commissioner Hester Peirce and Senator Cynthia Lummis—will impact ongoing policy efforts. Industry experts are cautiously optimistic but realistic. Sara K. Weed notes that while progress is being made, CLARITY is unlikely to pass this Congress, pushing agencies like the SEC and CFTC to provide more guidance. Sulolit Mukherjee suggests meaningful crypto tax legislation is more likely to be attached to larger must-pass bills. Rashan Colbert discusses the jurisdictional debate over prediction markets, emphasizing the need for a regulatory framework that fosters their development as financial tools rather than treating them broadly as gambling. The clock is ticking, but opportunities remain for substantive progress through continued bipartisan dialogue and pragmatic efforts.

marsbitHá 8h

Second Half of U.S. Crypto Policy: The Clarity Act Aims for 60 Votes, CFTC's "One-Person Commission" Becomes Biggest Variable

marsbitHá 8h

Research Report Analysis: Morgan Stanley Details SanDisk SNDK, The Truth About Cloud Data Center Pricing Power and AI Inference Benefits

Morgan Stanley raised its price target for SanDisk (SNDK) from $1100 to $1750 on June 22, maintaining an Overweight rating. The upgrade is driven by AI inference demand reshaping the NAND market, particularly for KV Cache and context window storage in cloud data centers. These cloud clients exhibit price inelasticity and sign long-term contracts, granting SanDisk significant pricing power. SanDisk's New Business Model (NBM) agreements, covering over one-third of FY27 bit shipments with 3-5 year terms and fixed price/price collar structures, are crucial. They are projected to sustain gross margins around 80% even at floor prices, providing a buffer against cyclical downturns. Morgan Stanley forecasts gross margins to surge from 30.3% in FY25 to 86.7% in FY27e. With NAND supply expected to remain tight into 2026/2027 and cloud/data centers becoming the largest end-market, SanDisk holds supply-side pricing power. The company targets 15-19% bit growth via technology transitions, not capacity expansion. Revenue is projected to grow ~6.6x from FY25 to FY27, with EPS rising from $2.74 to $14.73, driven by high-margin cloud business. Key upside catalysts include faster enterprise SSD adoption and edge AI growth. Downside risks involve slower industry growth, competitor capex increases, market share loss, and competition from Chinese players like YMTC. The investment thesis rests on AI-driven structural demand, NBM's margin protection, and sustained supply tightness. The $1750 target implies ~28x FY27e P/E.

marsbitHá 9h

Research Report Analysis: Morgan Stanley Details SanDisk SNDK, The Truth About Cloud Data Center Pricing Power and AI Inference Benefits

marsbitHá 9h

Trading

Spot
Futuros

Artigos em Destaque

Como comprar MOVE

Bem-vindo à HTX.com!Tornámos a compra de Movement (MOVE) simples e conveniente.Segue o nosso guia passo a passo para iniciar a tua jornada no mundo das criptos.Passo 1: cria a tua conta HTXUtiliza o teu e-mail ou número de telefone para te inscreveres numa conta gratuita na HTX.Desfruta de um processo de inscrição sem complicações e desbloqueia todas as funcionalidades.Obter a minha contaPasso 2: vai para Comprar Cripto e escolhe o teu método de pagamentoCartão de crédito/débito: usa o teu visa ou mastercard para comprar Movement (MOVE) instantaneamente.Saldo: usa os fundos da tua conta HTX para transacionar sem problemas.Terceiros: adicionamos métodos de pagamento populares, como Google Pay e Apple Pay, para aumentar a conveniência.P2P: transaciona diretamente com outros utilizadores na HTX.Mercado de balcão (OTC): oferecemos serviços personalizados e taxas de câmbio competitivas para os traders.Passo 3: armazena teu Movement (MOVE)Depois de comprar o teu Movement (MOVE), armazena-o na tua conta HTX.Alternativamente, podes enviá-lo para outro lugar através de transferência blockchain ou usá-lo para transacionar outras criptomoedas.Passo 4: transaciona Movement (MOVE)Transaciona facilmente Movement (MOVE) no mercado à vista da HTX.Acede simplesmente à tua conta, seleciona o teu par de trading, executa as tuas transações e monitoriza em tempo real.Oferecemos uma experiência de fácil utilização tanto para principiantes como para traders experientes.

319 Visualizações TotaisPublicado em {updateTime}Atualizado em 2026.06.02

Como comprar MOVE

Discussões

Bem-vindo à Comunidade HTX. Aqui, pode manter-se informado sobre os mais recentes desenvolvimentos da plataforma e obter acesso a análises profissionais de mercado. As opiniões dos utilizadores sobre o preço de MOVE (MOVE) são apresentadas abaixo.

活动图片