Problem
dexdo buyer --local-listen exposes the consumer endpoint after a buyer has purchased a lot. On the current main branch, the buyer API implements OpenAI Chat Completions, but does not expose a /v1/responses handler.
Current Codex custom providers use the OpenAI Responses wire API. Consequently, a user can buy a DexDo lot and receive a working local consumer endpoint, yet cannot connect that endpoint directly to current Codex without maintaining a separate protocol adapter.
This is not about a seller upstream, a provider subscription, or a seller-side API key. It is specifically the buyer-side local consumer endpoint after a successful deal.
User example
Alice buys two ticks of a coding model on DEX.DO. She starts the normal buyer consumer with --local-listen and wants to add that endpoint to Codex as a custom provider. Codex sends POST /v1/responses; the buyer endpoint currently accepts Chat Completions instead, so Alice needs a separate technical proxy rather than simply using the access she bought.
Requested behavior
Add OpenAI Responses API support to the buyer-side local server:
- expose
POST /v1/responses on the same --local-listen server;
- map supported Responses requests into the existing buyer request, entitlement, and budget-accounting path;
- return valid Responses-compatible JSON and streaming SSE for supported text requests;
- explicitly reject unsupported features rather than silently degrading them;
- retain the existing
/v1/chat/completions behavior and any other supported consumer protocols;
- document the supported Responses subset and add end-to-end coverage for non-streaming and streaming
/v1/responses.
Acceptance criteria
After purchasing a lot, a user can configure the local buyer endpoint as a current Codex custom provider and use it without a third-party protocol adapter. Existing Chat Completions clients remain compatible.
Why this matters
The simple user journey should be: buy a model -> receive/start the buyer endpoint -> use it in Codex. Requiring a separate proxy turns a product integration into a server-side engineering task and prevents non-technical buyers from using their purchased access in a standard coding workflow.
Problem
dexdo buyer --local-listenexposes the consumer endpoint after a buyer has purchased a lot. On the currentmainbranch, the buyer API implements OpenAI Chat Completions, but does not expose a/v1/responseshandler.Current Codex custom providers use the OpenAI Responses wire API. Consequently, a user can buy a DexDo lot and receive a working local consumer endpoint, yet cannot connect that endpoint directly to current Codex without maintaining a separate protocol adapter.
This is not about a seller upstream, a provider subscription, or a seller-side API key. It is specifically the buyer-side local consumer endpoint after a successful deal.
User example
Alice buys two ticks of a coding model on DEX.DO. She starts the normal buyer consumer with
--local-listenand wants to add that endpoint to Codex as a custom provider. Codex sendsPOST /v1/responses; the buyer endpoint currently accepts Chat Completions instead, so Alice needs a separate technical proxy rather than simply using the access she bought.Requested behavior
Add OpenAI Responses API support to the buyer-side local server:
POST /v1/responseson the same--local-listenserver;/v1/chat/completionsbehavior and any other supported consumer protocols;/v1/responses.Acceptance criteria
After purchasing a lot, a user can configure the local buyer endpoint as a current Codex custom provider and use it without a third-party protocol adapter. Existing Chat Completions clients remain compatible.
Why this matters
The simple user journey should be: buy a model -> receive/start the buyer endpoint -> use it in Codex. Requiring a separate proxy turns a product integration into a server-side engineering task and prevents non-technical buyers from using their purchased access in a standard coding workflow.