The Responses API is more than another text endpoint
An AI coding agent does not simply send a prompt and wait for prose. One model step may contain typed input, reasoning metadata, a function call, a custom patch operation, or several parallel tool proposals. The client may consume the answer as buffered JSON or reconstruct it from a sequence of server-sent events.
That makes the OpenAI Responses API a protocol contract, not a cosmetic variation of chat completions. A gateway that flattens the request into messages and rebuilds an approximate response can lose exactly the details an agent harness uses to continue safely.
Punk therefore exposes POST /v1/responses as a native runtime path. Supported Responses traffic remains Responses traffic through normalization, routing, provider execution, policy, tracing, and final serialization.
What the Punk Responses runtime preserves
The runtime accepts buffered requests and SSE streaming. It preserves the output-item structure used for assistant messages, reasoning summaries, function calls, custom tool calls, and tool outputs. It also carries usage and terminal status so an incomplete or failed response is not misrepresented as a successful reusable result.
Streaming requires stricter bookkeeping than buffered output. Punk checks that item identifiers and output indexes remain consistent, that text and tool-argument deltas reconstruct the completed item, and that terminal events agree with the accumulated stream. A malformed stream should become an explicit protocol error rather than a plausible-looking partial tool call.
Those checks are especially important for coding tools. A missing character in explanatory prose is annoying. A missing character in a JSON argument or patch operation can change what the agent attempts to execute.
Punk’s current public contract supports buffered HTTP and server-sent events. It does not advertise Responses WebSockets. Keeping the capability catalog narrower than the upstream universe prevents a client from selecting a transport Punk has not actually qualified.
Governance applies to typed output, not only prose
Traditional gateway controls often inspect the visible assistant text and stop there. Tool-using agents need a wider boundary.
Punk evaluates the normalized request under tenant, application, agent, and subject identity. Policy and data-loss-prevention checks can account for visible output and proposed tool arguments before those items leave the gateway. Trace storage applies redaction rules so operational evidence does not become an uncontrolled copy of sensitive payloads.
The route explanation records which provider or optimized path served the step, which alternatives were rejected, and whether policy, compatibility, or fallback affected the decision. Token and cost evidence stays connected to that same run.
This does not transfer execution authority to Punk. A function or custom tool call returned by the model is still a proposal. The calling harness decides whether to approve it, applies its local sandbox, executes the tool, and sends the result on a later Responses turn.
That separation is the foundation of the Codex integration: Punk governs the model path while Codex continues to own repository and workstation execution.
Capability-aware routing avoids silent protocol loss
Not every provider implements every Responses feature. A request may ask for custom tools, parallel calls, reasoning summaries, structured text, or input types that a candidate route cannot reproduce faithfully.
Punk checks the requested capability set against the provider path before serving it. An unsupported feature is not quietly stripped to make the request fit. The runtime can reject the incompatible path or use an eligible fallback while retaining the reason in route evidence.
The same principle applies to optimization. An exact response or deterministic artifact is useful only if Punk can serialize the result back into valid Responses output without inventing missing state. Cached and artifact routes must preserve the caller’s wire contract and pass the same output and policy checks as a live result.
This is where protocol fidelity and economics meet. Reuse should remove unnecessary model work, not remove information the agent needs.
Native Responses support improves operational evidence
A protocol-aware trace can answer questions that a generic proxy log cannot:
- Which typed input and tool contracts shaped the step?
- Was the response streamed natively or reconstructed from a qualified route?
- Which proposed calls were returned to the harness?
- Did the stream finish, fail, or remain incomplete?
- Which provider capabilities made another route ineligible?
- How much model work and cost did the completed step consume?
These details give platform teams a usable failure boundary. They can distinguish a provider stream fault from a policy block, a malformed tool proposal, a client-side execution failure, or an unsupported transport.
They also improve learning safety. Punk does not need to infer success from the presence of some text. It can require a valid terminal state and complete output evidence before a run becomes an example for replay or future optimization.
A practical Responses API adoption check
Start with one non-destructive request that returns text, then one declared function tool, and finally an SSE version of the same tool step. Confirm that the buffered and streamed outputs describe the same completed item and that the run detail contains the expected route, policy, tool, usage, and cost evidence.
Next, test one intentionally unsupported capability. The result should fail clearly or select a documented eligible path; it should never pretend the unsupported control was honored.
Finally, cancel a stream and confirm the upstream work stops promptly and the run is not treated as a completed reusable success. That test says more about production readiness than another happy-path completion.
The OpenAI migration guide explains why newer agent workflows use the Responses model. Punk’s role is to keep that richer protocol intact while adding the controls required to operate it across a team.
Questions readers ask
Does Punk translate Responses requests into chat completions?
No. Supported Responses traffic stays on Punk’s native Responses path so typed output items, custom tools, reasoning summaries, stream events, and terminal states are not flattened into a different protocol.
Does Punk execute function calls returned by the Responses API?
No. Punk can govern and trace a proposed call, but the client or agent harness retains responsibility for local approval, sandboxing, execution, and returning the tool result on a later request.
Does Punk support Responses WebSockets?
Not currently. Punk supports buffered HTTP and server-sent event streaming for the Responses endpoint. The runtime does not advertise WebSocket support.