feature gpt-5-codex responses api #119
Conversation
|
@ericc-ch help review it? |
caozhiyuan
force-pushed
the
feature/gpt-5-codex
branch
from
f47f657 to
a57c238
Compare
|
@caozhiyuan I tested your feature. Using codex and copilot's API wrap. I often get these errors: ■ stream disconnected before completion: Transport error: error decoding response body |
|
@eurotrip11 command line add --verbose to log stream event, check which event is causing the issue . The currently provided openai responses API interface has almost no complex logic, it's just simple forwarding. My premium requests for this month have run out, so I can only test next month. In codex cli, I only tested simple prompts and tool calls, and there were no issues during my testing. |
I also saw this, alongside 429s and "we're currently experiencing high demand." Sometimes the stream disconnects, other times it doesn't. I think it's a problem on Github's side. See: #118 |
|
@vtomnet @eurotrip11 This seems to be a codex cli error openai/codex#3835 ; responses API return is actually normal. I'm using gpt-5-codex in claude code without any abnormalities. |
…se output message type
…nd state management
…ure in translation tests
|
@vtomnet @eurotrip11 I have added the ping event, which currently resolves the codex disconnection issue: Transport error: error decoding response body. I've tested it and it's working fine now. |
|
when use in claude code, please permissions deny WebSearch Tool , Otherwise, it will meaninglessly consume Premium requests . https://github.com/ericc-ch/copilot-api/pull/115/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R315 |
Now, It works for me. Thank you! |
I have not thoroughly investigated myself, but perhaps when is calling agentic websearch it is not being correctly classified as tool call around logic with respect to "X-Initiator" header (from my understanding this is partially what dictates whether premium request is used or not #68) - I may have also missed if this is already accounted for in PR changes, but just potentially something to look into if can otherwise be circumvented that way |
|
@dylbarne The claude code websearch tool will initiate a separate search request with only a llm built-in websearch tool. Currently, the translation code has not been adapted for the llm built-in websearch tool, and the github copilot API does not support the llm built-in websearch tool. |
|
Hey @caozhiyuan I really genuinely appreciate that you opened a lot of PRs to contribute to this project I will try to get through all of them, try to understand it and review them |
merge master
|
@ericc-ch The response API stream event parsing has added specific type constraints and requires certain testing. |
This pull request introduces a new
/responsesAPI endpoint and integrates it into the server, enabling support for a new Copilot "Responses API" with streaming and non-streaming capabilities. The changes include routing, handler logic, payload translation, and new utility functions to support the endpoint. The request handler for/v1/messagesis refactored to conditionally use the new Responses API for supported models, and comprehensive type definitions are added for the new API. Additionally, tests are introduced for the streaming translation logic.New Responses API Integration
/responsesendpoint with routing (responsesRoutes) and a corresponding handler (handleResponses). The handler validates model support, processes requests, and forwards both streaming and non-streaming responses. [1] [2]/responsesendpoint into the main server routing, including under both/responsesand/v1/responsespaths. [1] [2]Conditional API Selection and Translation
/v1/messageshandler to conditionally use the Responses API for supported models, including translation between Anthropic and Responses payloads/results, and streaming event translation. [1] [2] [3]Type Definitions and Utilities
create-responses.ts, and introduced utility functions for request option parsing and vision/initiator detection. [1] [2]Testing