A shared API shape creates an attractive inference: if an application can send the same request to more than one implementation, the workload has become portable.
There is real architectural progress inside that claim. A common response interface can remove provider-specific translation, preserve application logic, and create a stable target for testing. Open Responses makes those benefits concrete through an open, versioned contract based on the interaction shape introduced by OpenAI’s Responses API.[1][2]
But reusable orchestration code is not evidence that a governed workload is interchangeable. The contract can standardize request shape, response items, tool exchange, and selected continuation behavior. It does not make models equivalent, guarantee that required state survives, determine where tools execute, confer authority, or establish enterprise assurance.
Open Responses therefore does something more useful than promise universal portability: it turns portability from a broad vendor claim into a set of testable obligations.
OpenAI Created a Response-Oriented Primitive
OpenAI’s Responses API organizes the application-to-model boundary around typed input and output items, lifecycle events, tools, and continuation through response identifiers or explicit history.[1] An application can submit work, observe semantic events, receive tool requests, return results, and continue the interaction through documented mechanisms.
Open Responses takes that originating shape and defines a portable core that other implementations can target.[2][3] The layers remain distinct: OpenAI’s Responses API is the platform primitive; Open Responses is the shared specification; and a named provider endpoint is an implementation of some declared portion of that contract. None alone proves that an enterprise workload can move safely between implementations.
The gain is substantial: applications can design against a common interaction vocabulary instead of rebuilding the entire boundary for every implementation.
Open Responses Turns the Shape Into a Contract
The specification observed for this Dispatch was version 2026-04-24.[2][4] It defines shared item and event shapes, tool exchange, selected continuation behavior, optional WebSocket transport, and a standalone compaction endpoint.[2][3][5]
For HTTP streaming, Server-Sent Events terminate with response.completed, response.failed, or response.incomplete. A trailing [DONE] marker is optional.[2] Client logic must interpret the terminal response outcome rather than treating transport closure or [DONE] as proof of success.
The optional WebSocket contract is equally bounded. Client turns begin with response.create; responses are processed sequentially with one response in flight. With store=false, continuation may depend on connection-local state. A reconnect can fail when its predecessor is unavailable, including through previous_response_not_found, and the documented connection lifetime is limited to 60 minutes.[2]
Compaction is also explicit. POST /v1/responses/compact returns a compacted input window for a later request.[2][3] That is a typed handoff—not a universal continuation identifier, disclosure of an implementation’s internal compression, or guarantee of identical retained meaning.
These rules create a stable interoperability boundary. Adapter teams gain a target to implement; application teams gain a target to depend on; assurance teams gain a target to test. The value is visibility into differences, not an assumption of sameness.
Contract Compatibility Is Precise—and Bounded
At the October 25, 2026 checkpoint, Open Responses published 17 acceptance tests: 10 browser-runnable and seven CLI-only.[5][6] They covered core response phases, streaming, tools, images, multi-turn interaction, compaction, WebSocket sequencing and continuation, reconnect recovery, missing or evicted predecessors, and a new chain from compacted input.
That is useful acceptance coverage. It is not certification.
A passing result can show that a named implementation exhibited covered protocol behavior under tested conditions. It cannot establish equivalent model quality, refusal behavior, tool selection, semantic state, operational reliability, enterprise controls, or recovery under every failure. Nor does the published suite establish conformance for an implementation that was not tested.
The defensible record is specific:
This provider, endpoint, model, version, feature set, and extension set satisfied these contract behaviors under these test conditions.
Anything broader outruns the evidence.
This is the first portability obligation: establish that the implementation satisfies the exact contract behaviors the workload uses. It is necessary evidence, but it remains only one part of an interchangeability decision.
State Must Survive in the Form the Workload Requires
State is where an apparently compatible exchange can stop being an interchangeable workload.
An application may carry explicit history. A live connection may retain connection-local state. A provider may persist a response for later reference. A compacted input window may carry a transformed representation of earlier context. These mechanisms have different recovery properties.
A workflow that can reconstruct required context from explicit input differs from one that depends on provider-retained predecessors. A short interaction differs from an agent expected to resume after a connection expires. A compacted window sufficient for one task may omit or transform information that matters to another.
The enterprise question is:
Which state does this workload require to resume safely, and what evidence shows that state remains available and sufficiently faithful after a move or failure?
That requires tests for persistence mode, predecessor availability, reconnect paths, missing-state behavior, input reconstruction, and compaction outcomes. WebSocket compatibility is not durable resumability. A transferable compacted input shape is not proof of identical retained meaning.
A state record should therefore identify the selected store mode, the availability and lifetime of predecessors, the context the application can reconstruct, the reconnect strategy, any compaction dependency, and the expected response when recovery fails. Safe continuation depends on those conditions being explicit.
Tool-Call Portability Does Not Settle Execution
A common tool definition, call, and result shape can preserve application logic. It does not determine where the tool runs.
One implementation may host a tool. Another may return the call to enterprise code. A third may execute through a customer-controlled environment. The choice changes acting identity, credentials, network boundary, downstream permissions, side effects, recovery responsibility, and evidence ownership.
The tool call expresses requested work. It does not grant authority.
For consequential action, the enterprise must still establish which principal acts, which resource receives the request, which authorization applies, where the effect is enforced, and how the actual outcome is reconciled. The contract can carry a call across the interaction boundary; it cannot make a downstream system permit the action or turn provider capability into enterprise permission.
An execution record should identify the tool host, acting identity, enterprise authorization, downstream permission, side-effect evidence, and reconciliation owner. Those facts determine whether structurally similar tool calls remain acceptable when execution moves.
Assurance Must Match the Interchangeability Claim
Acceptance results are evidence. They are not the enterprise conclusion.
For a narrow claim—such as whether an endpoint returns streamed text with required event shapes—a focused protocol test may be sufficient. For a claim that a governed workflow can route between implementations without changing its accepted risk, recovery, or control posture, the evidence obligation is larger.
The record should pin the specification and repository ref; identify provider, endpoint, model, implementation version, features, and extensions; retain test inputs and results; cover required failure paths; state recovery assumptions; identify exceptions and compensating controls; name the review owner; and define what drift triggers retesting.
Evidence existence is not evidence sufficiency. A green protocol suite cannot decide, by itself, that a workload is acceptable for migration, fallback, dynamic routing, or production release.
The evidence must match the claim: contract evidence supports interface behavior; state evidence supports continuity and recovery; execution evidence supports identity, authority, and side effects; assurance evidence supports the enterprise conclusion about the exact governed workload.
Portability Becomes an Operating Discipline
Implementation documentation shows why scope matters. AWS distinguishes Responses availability by Bedrock endpoint and model.[7][8] Ollama documents a stateless surface that excludes provider-retained continuation fields.[9] vLLM scopes its documented endpoints to text-generation models and adds implementation-specific extensions.[10] Hugging Face labels its routed Responses API beta, while OpenRouter documents a Responses endpoint with a beta SDK surface.[11][12]
These examples are not rankings or conformance results. They show why “supports Responses” is too coarse to govern a workload.
The practical artifact is a four-obligation decision record:
- Contract: Which specification, endpoint, model, features, extensions, and acceptance results apply?
- State: Which storage mode, predecessor behavior, explicit history, reconnect strategy, compaction method, and recovery failures matter?
- Execution: Where do tools run, which identity acts, what authorization and downstream permission apply, and who reconciles the effect?
- Assurance: What interchangeability claim is being made, what evidence supports it, which exceptions remain, who owns the decision, and what triggers retesting?
These are independent checks, not four new control planes or a lifecycle. Together, they support workload-specific decisions about migration, fallback, routing, and provider change. They do not certify an implementation or make the decision automatically.
Luminity architectural interpretation. Enterprise decision method—not part of the Open Responses specification.
What the Contract Does Not Carry
Open Responses does not make models behaviorally equivalent, transfer opaque reasoning or provider-internal state, or guarantee semantically lossless compaction and durable cross-provider recovery.
It does not determine tool location, grant authority, or supply enterprise identity, retention, residency, Audit Trails, control coverage, evidence sufficiency, or assurance. An endpoint does not become conformant merely because it is advertised as Responses-compatible.
Those limits do not weaken the standard. They define the boundary that makes it useful.
A shared interface makes providers easier to integrate and compare; enterprise architecture must still establish whether they are interchangeable for a particular governed workflow.
Open Responses standardizes the contract, not the workload. The contract creates a stable place to test, compare, retain evidence, and detect drift.
Treat contract compatibility as a real architectural gain. Treat workload interchangeability as an evidence-backed enterprise conclusion.
