It’s nearly 2027, and the closest thing we have to a universally supported wire format for language models is still Chat Completions. That’s a little depressing considering how far the models themselves have come. We’ve standardized how agents talk to tools through MCP, google is trying to standardize how agents talk to each other through A2A, and we’ve even found a portable format for packaging skills. Sadly agreeing on how to talk to the model itself is a bridge too far.
From a wire format perspective: OpenAI has Responses, Anthropic has Messages, and Google has Parts / Generate content. The rest of the industry supports some combination of those wire formats, usually alongside Chat Completions. The pain point is that the two more mature designs are capable of expressing things that the common denominator struggles with. It’s an odd place to be when customers increasingly want the freedom to choose between the frontier labs or a mixture.
Two good APIs, with one annoying customer problem
Anthropic’s Messages API deserves credit. Its content blocks, tool use and streaming have held up across multiple generations of models, and the design has aged well. OpenAI’s Responses API is also a good design, with explicit items for messages, reasoning and tool calls, and a more ambitious execution and transport model. I don’t particularly care which one wins, and I certainly don’t want to pretend that Messages is broken simply because Responses has some newer capabilities.
The problem starts when a customer wants options. One model might perform better on a particular workload, another might be cheaper or faster, and the balance can change with the next release. Customers should be able to evaluate the two behemoths without turning model selection into an architectural commitment. Today, the deeper an application integrates with either API, the harder it becomes to move.
And then there’s Google. Gemini’s models have proven to be so-so in my experience, but Google has nevertheless managed to introduce yet another message format with Content and Parts. It’s another proprietary format with little apparent appetite for adoption outside Google’s ecosystem. Google offers Chat Completions compatibility too, which brings us neatly back to the format everyone supports and nobody should be treating as a sufficient answer in 2026.
The false comfort of Chat Completions
Chat Completions has been enormously successful, and it was a sensible interface for its time (2024). But it was designed around a simpler exchange of messages and generated output, with tool calling added along the way. Modern models expose structured reasoning, hosted tools, richer multimodal content and increasingly complex execution semantics. Providers can squeeze some of this into Chat Completions, but often through extensions and conventions that aren’t consistently understood elsewhere.
The result can be worse than having no standard at all, because it creates the appearance of portability. Endpoints accept familiar requests, SDKs connect and smoke tests pass, so customers assume the integration is interchangeable. The illusion tends to disappear when an application starts using the capabilities it really needs. A common wire format isn’t much use if the semantics on either end aren’t common.
Translation is not just JSON
I’ve worked on canonical model abstractions before, and the easy part is usually getting a basic message through. The difficult part is preserving behavior across two contracts that were never designed to be equivalent. Reasoning items, tool-call lifecycles, streaming events, citations, error behavior and turn boundaries aren’t necessarily interchangeable. An adapter can appear perfectly healthy until a production conversation exercises a combination nobody anticipated.
Neither provider has to break its contract for the adapter to break. Each can introduce a new capability or extend its own semantics in a perfectly legitimate way, while the translation layer quietly mishandles the result. The customer owns that layer, its tests and the production failures. Restricting everything to the lowest common denominator avoids some of the risk, but also means deliberately giving up the features that made the model attractive in the first place.
This is a major headache for AI gateways, inference routers and the libraries promising a single interface to every model. Their value proposition depends on hiding the differences between providers, but every new capability introduces more translation rules, more edge cases and another round of regression testing. A gateway can handle thousands of ordinary requests before a particular combination of reasoning, hosted tools and streaming exposes a semantic mismatch. Both vendors can be behaving correctly, while the intermediary (us) is responsible for the failure. There’s a certain irony in how much engineering effort goes into maintaining the abstraction that’s supposed to save everyone else from maintaining abstractions.
Web search is a particularly good example because it’s already table stakes. OpenAI exposes search calls as Responses output items with citation annotations; Anthropic uses server-side tool-use and result blocks within Messages; Google returns grounding metadata through its own tool interface. The user requirement is the same, but configuration, execution events, citations, timing, controls and accounting differ. This isn’t an obscure experimental feature. If we struggle to represent a web search consistently, the next generation of agent capabilities isn’t going to make life easier.
Responses is spreading, but what does support mean?
The matrix below is a snapshot of documented direct-provider compatibility, not a claim that every checked endpoint implements the same features. A gateway exposing Claude through Responses, for example, doesn’t mean Anthropic exposes Responses itself. Nor does accepting a Responses request imply support for stateful continuation or WebSockets.
The most telling part of this table is the first column. Chat Completions is everywhere, but in 2026 that is increasingly an indictment of the industry’s interoperability story rather than an achievement. It remains useful for basic text generation and conventional function calls. Once an application depends on hosted tools, reasoning-item lifecycles, semantic streaming or persistent execution, however, the universal format stops being universal. We have standardized the least interesting subset of what modern models can do and left the rest for customers and gateway vendors to reconcile.
Mistral and DeepSeek are good examples of why the distinction matters. Both document Responses HTTP implementations that require clients to replay history, while OpenAI and xAI also support continuation and WebSocket modes. That’s a legitimate range of implementations, but it needs to be visible to developers making architectural decisions rather than hidden behind a single green compatibility tick.
Responses compatibility is no longer confined to OpenAI. Mistral, DeepSeek, xAI, Moonshot, Z.ai, MiniMax and ByteDance have introduced implementations of varying scope, while Messages compatibility has also spread beyond Anthropic. That’s encouraging, although an HTTP endpoint accepting Responses-shaped JSON isn’t the same as supporting the whole protocol. Stateless execution, provider-managed continuation and persistent WebSocket transport are separate things, and support needs to be measured rather than inferred from the URL.
The WebSocket side is particularly interesting. Responses defines a persistent transport for successive turns and connection-local continuation, rather than treating every interaction as a fresh HTTP exchange. That’s useful for interactive agents, though it shouldn’t be confused with unrestricted full-duplex execution or voice. The published Open Responses WebSocket specification also places constraints on concurrency that matter when comparing vendor implementations.
The self-hosted crowd is already doing the work
There’s another group worth mentioning: the projects actually hosting open-weight models. Ollama, vLLM and llama.cpp all document support for Chat Completions, Anthropic Messages and Responses. SGLang supports Chat Completions and Messages on its mainline server, although I couldn’t verify a Responses endpoint in its published documentation. For a supposedly fragmented industry, that’s a remarkable amount of compatibility work being done by inference runtimes rather than the frontier labs.
These aren’t promises of complete protocol parity. Ollama explicitly excludes stateful Responses continuation and several Anthropic features. vLLM’s Responses interface is currently documented for text-generation models, and llama.cpp converts Responses requests into Chat Completions internally. SGLang’s Messages support also depends on the build: a specialized DeepSeek image was reported missing the route even though it existed on main. The endpoint names alone tell you surprisingly little about what a deployment will actually do.
There’s even a rather timely example of why that matters. An October llama.cpp issue describes its Responses stream reporting a truncated tool call as completed, without emitting the expected argument-completion event. The problem was reproduced, and a strict client could reject the turn because it couldn’t trust the tool-call lifecycle. That’s a real interoperability failure, not a hypothetical concern about how two schemas might differ. It doesn’t invalidate llama.cpp’s compatibility work, but it makes a strong case for conformance tests that exercise behavior, not merely whether an endpoint accepts a request.
The open-weight hosting projects have every incentive to make their runtimes accessible to applications written for different vendors. It’s encouraging that they’re doing so, but also slightly absurd that so much of the burden falls on them. A shared specification with meaningful conformance tests could turn this from an endless exercise in imitation into something developers can actually rely on.
A standard might finally emerge
There’s an obvious danger in proposing yet another standard, and Randall Munroe captured it rather well in xkcd #927. We already have competing formats, so naturally the solution is to introduce another one. Open Responses will only improve things if vendors actually converge on it, rather than adding one more compatibility endpoint to maintain.
On 22 October, Open Responses joined the Agentic AI Foundation under the Linux Foundation. Anthropic contributed MCP and Agent Skills to the same foundation, and both companies are participating in an ecosystem that already includes A2A. Open Responses has a published specification, governance provisions and a conformance-testing ambition, with AWS publicly backing the effort. This is more promising than another vendor publishing an endpoint and asking everyone else to copy it.
I haven’t found public evidence that Anthropic has committed to implementing Open Responses or maintaining its specification. That doesn’t mean Anthropic opposes it, and there’s no reason to discard the good ideas in Messages. Quite the opposite: I’d like Anthropic to engage and challenge the design where appropriate. A standard shaped by competing implementations is more useful than one vendor’s API wearing a neutral badge.
Where does that leave us?
I don’t expect every model to have identical capabilities, and standardization shouldn’t stop vendors experimenting. But customers shouldn’t have to choose between using those capabilities and being able to change providers. Chat Completions is now a poor answer to that problem, and translation between the modern APIs is a maintenance and correctness liability that customers shouldn’t have to shoulder indefinitely.
Responses is established and has room to evolve, particularly around persistent interaction and real-time execution. Open Responses gives the industry a chance to standardize on something more capable than Chat Completions, provided the labs are prepared to work on the parts where their APIs disagree. Anthropic’s Messages API has earned its place, and I would rather see its better ideas represented in a shared standard than discarded for the sake of consistency.
If the labs want to keep their proprietary formats for bleeding-edge features, I can live with that. New capabilities need room to evolve, and forcing every experiment through a standards committee would be a miserable way to build anything. But please commit to bringing the features that stick into Open Responses on a reasonable cadence.
Production agents don’t necessarily need the bleeding edge. They do need stable contracts, predictable behavior and the freedom to choose a model without rewriting the application around it.
So, dear Anthropic and Google, please stop being so precious about your respective formats. The industry adopted Anthropic’s MCP slop, warts and all, and perhaps it’s time to return the favor. Bring the good ideas from Messages and Gemini to Open Responses, argue about the details, and help make the common interface worth using. Labs, compete on cost, functionality and features, hell, even your little cybersecurity escapades if you must. But please don’t compete on the wire format.