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

marsbitPubblicato 2026-06-22Pubblicato ultima volta 2026-06-22

Introduzione

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

Crypto di tendenza

Domande pertinenti

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.

Letture associate

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 News11 min fa

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

Foresight News11 min fa

Financing Weekly Report | 11 Public Financing Events, Stablecoin Payment Infrastructure Company Trace Finance Completes $32 Million Series A Round Led by CoinFund

Financing Weekly Report | 11 public funding events recorded, with a total scale exceeding $264 million. The stablecoin payment infrastructure sector remains a hot spot. Key Deals: - Trace Finance, a stablecoin payment infrastructure firm, raised $32 million in a Series A round led by CoinFund to expand in Latin America and Asia-Pacific. - Galaxy Ventures co-led a $140 million Series A round for Karta, a US credit card provider for global travelers without requiring an SSN. - Instant payment platform Interchecks completed a $50 million Series C round. - Paradigm led a $9 million Series A for Latin American cross-border payment app El Dorado. - Range, a stablecoin compliance startup, raised $8.3 million in an oversubscribed Series A. - RWA infrastructure project Renaiss raised $1.5 million to expand its on-chain collectibles platform. Sector Breakdown: - Infrastructure & Tools: 6 deals, including the above-mentioned Trace Finance, Range, and Renaiss. - Centralized Finance (CeFi): 3 deals, led by Karta's $140 million round. - DeFi: 1 deal – reinsurance protocol Re secured strategic investment from Coinbase Ventures. - Prediction Markets: 1 deal – K25.ai completed a $10 million Pre-A round from NewGen. Other notable transactions include digital asset depository RDC raising $7 million, ad-tech startup EarnOS securing $6 million, and a $1 million strategic investment in LitVM, a ZK Layer 2 for Litecoin. The report highlights sustained investor interest in stablecoin payment infrastructure, compliant on-chain finance, and real-world asset (RWA) tokenization.

marsbit53 min fa

Financing Weekly Report | 11 Public Financing Events, Stablecoin Payment Infrastructure Company Trace Finance Completes $32 Million Series A Round Led by CoinFund

marsbit53 min fa

When Transfers Become Truly Frictionless: How Sui Uses 'Zero Gas' to Become the Underlying Infrastructure for Stablecoin Payments

Title: Sui Launches Zero-Gas Stablecoin Transfers to Become the Foundation for Stablecoin Payments Sui has introduced a zero-gas fee feature for peer-to-peer stablecoin transfers, eliminating the need for users or businesses to hold separate SUI tokens to pay transaction costs. This innovation, built on a new underlying account architecture called Address Balances, significantly reduces validator processing costs for eligible transactions. Currently, the feature applies to a whitelist of stablecoins for transfers meeting a minimum amount, effectively preventing spam. This development aims to unlock mainstream payment use cases for stablecoins—such as everyday purchases, remittances, and subscriptions—by removing cost and complexity barriers. It is also positioned to benefit high-frequency micro-payments for AI agents and institutional B2B payments, reducing operational friction. Major custody provider Fireblocks has already announced support. The move follows Sui processing over $1 trillion in stablecoin transfer volume since August 2025. Looking ahead, Sui plans to enhance this infrastructure with protocol-level confidential transactions later in 2026, aiming to provide scalable, free, and privacy-preserving payments. Together, these advancements strengthen Sui's goal of becoming the default settlement layer for stablecoin payments.

marsbit55 min fa

When Transfers Become Truly Frictionless: How Sui Uses 'Zero Gas' to Become the Underlying Infrastructure for Stablecoin Payments

marsbit55 min fa

Ethereum Is Retracing the Path of the Internet and Linux: No One Yields, and the Neutral Party Ultimately Prevails

This article argues that Ethereum is following the historical path of open, neutral systems like the Internet and Linux, which eventually triumphed over proprietary, centrally-controlled alternatives. Major financial institutions like JPMorgan, Stripe, and Circle are building their own proprietary blockchains or networks (e.g., Tempo, Arc), but will never agree to build on a competitor's controlled infrastructure. This creates the perfect opportunity for Ethereum as the only neutral, credibly neutral settlement layer that no single entity controls. The piece draws parallels to the 1990s, when experts like Bill Gates predicted proprietary networks (from Microsoft, Oracle) would win over the open Internet, and when Sun Microsystems' Unix lost to the open-source "bazaar" development model of Linux. This model, described in Eric Raymond's "The Cathedral and the Bazaar," thrives on permissionless innovation where countless contributors improve the system, outpacing any centralized competitor. Ethereum embodies this through its decentralized development, broad validator distribution, and credible neutrality—rules that are transparent, equally applied, hard to change, and open to all. This has attracted over a million developers and major institutions like Coinbase, BlackRock, and JPMorgan, who choose Ethereum for its security, ecosystem, and sovereignty (the inability of any single party to change the rules). While proprietary chains offer initial speed and control, they inherit the downsides of both centralization and decentralization without the long-term innovation benefits. The article concludes that, just as open systems historically win, Ethereum is poised to become the foundational, neutral settlement layer for global finance.

marsbit1 h fa

Ethereum Is Retracing the Path of the Internet and Linux: No One Yields, and the Neutral Party Ultimately Prevails

marsbit1 h fa

Trading

Spot
Futures

Articoli Popolari

Come comprare MOVE

Benvenuto in HTX.com! Abbiamo reso l'acquisto di Movement (MOVE) semplice e conveniente. Segui la nostra guida passo passo per intraprendere il tuo viaggio nel mondo delle criptovalute.Step 1: Crea il tuo Account HTXUsa la tua email o numero di telefono per registrarti il tuo account gratuito su HTX. Vivi un'esperienza facile e sblocca tutte le funzionalità,Crea il mio accountStep 2: Vai in Acquista crypto e seleziona il tuo metodo di pagamentoCarta di credito/debito: utilizza la tua Visa o Mastercard per acquistare immediatamente MovementMOVE.Bilancio: Usa i fondi dal bilancio del tuo account HTX per fare trading senza problemi.Terze parti: abbiamo aggiunto metodi di pagamento molto utilizzati come Google Pay e Apple Pay per maggiore comodità.P2P: Fai trading direttamente con altri utenti HTX.Over-the-Counter (OTC): Offriamo servizi su misura e tassi di cambio competitivi per i trader.Step 3: Conserva Movement (MOVE)Dopo aver acquistato Movement (MOVE), conserva nel tuo account HTX. In alternativa, puoi inviare tramite trasferimento blockchain o scambiare per altre criptovalute.Step 4: Scambia Movement (MOVE)Scambia facilmente Movement (MOVE) nel mercato spot di HTX. Accedi al tuo account, seleziona la tua coppia di trading, esegui le tue operazioni e monitora in tempo reale. Offriamo un'esperienza user-friendly sia per chi ha appena iniziato che per i trader più esperti.

273 Totale visualizzazioniPubblicato il 2024.12.13Aggiornato il 2026.06.02

Come comprare MOVE

Discussioni

Benvenuto nella Community HTX. Qui puoi rimanere informato sugli ultimi sviluppi della piattaforma e accedere ad approfondimenti esperti sul mercato. Le opinioni degli utenti sul prezzo di MOVE MOVE sono presentate come di seguito.

活动图片