fix(github): Implement dynamic fallback for Codex models requiring /responses endpoint

[I3eka]

Summary

This PR resolves the 400 Bad Request error encountered when using newer GitHub Copilot Codex models (e.g., gpt-5.1-codex, gpt-5.2-codex). The issue is addressed by implementing a dynamic, reactive fallback mechanism within the GithubExecutor that automatically switches to the correct API endpoint.

Root Cause Analysis

Certain GitHub Copilot models have deprecated the standard /chat/completions endpoint and now exclusively require requests to be sent to the /responses endpoint, which also uses a different payload structure (input array instead of messages). The previous implementation was hardcoded to /chat/completions, causing API rejections for these models.

Implementation Details

A resilient, self-correcting strategy has been implemented:

1. Initial Attempt: The executor first makes a standard request to /chat/completions.
2. Error Detection: If a 400 Bad Request is received with the specific error message "not accessible via the /chat/completions endpoint", the fallback logic is triggered.
3. Caching for Performance: The model's ID is immediately added to an in-memory Set (this.knownCodexModels). All subsequent requests for this model will bypass the initial failed attempt and go directly to the correct /responses endpoint, eliminating future latency.
4. On-the-Fly Translation: The request is automatically retried on the /responses endpoint. This involves two real-time translations:
   • Request Body: The OpenAI messages array is converted into the input array format.
   • Response Stream: The SSE event stream from /responses is converted back into the standard OpenAI Chat Completion chunk format, ensuring client compatibility and correct token usage tracking.

Considered Alternative: Proactive Service Discovery

An alternative, proactive "Service Discovery" approach was also investigated. This would involve making a GET https://api.githubcopilot.com/models request at startup or periodically to build a map of which models support which endpoints, based on the supported_endpoints field present in the response.

Pros of Service Discovery:

• Eliminates the latency of the initial failed request for new models.

Cons / Reasons for Choosing the Fallback Approach:

• API Stability Risk: The /models endpoint and its schema are part of an internal, undocumented API. Relying on its structure is fragile, as it could change without warning and break the integration for all GitHub models.
• Reliability: The reactive fallback relies on a more stable "contract"—the API's explicit error response. This makes the proxy more resilient to future changes and new models that may not yet appear in the /models list.

Suggestion for the Future:
While the current reactive approach is safer, a hybrid model could be considered. We could implement Service Discovery as a "best-effort" optimization and still keep the reactive fallback as a safety net. This would provide the performance of Service Discovery with the resilience of the current implementation. I am happy to discuss or implement this if you think it's a worthwhile addition.

For now, this PR prioritizes robustness and future-proofing.

Related Issue

Fixes #102

[Copilot]

Pull request overview

Implements a reactive fallback in the GitHub provider executor to handle newer GitHub Copilot Codex models that reject /chat/completions and require the /responses endpoint (Fixes #102).

Changes:

• Adds dynamic detection of the specific 400 error and retries the request against /responses.
• Caches models known to require /responses to avoid repeating the initial failing request.
• Translates OpenAI Chat Completions request/response streaming to/from the OpenAI Responses API format.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

TransformStream creates a new TextEncoder() for every parsed SSE line (new TextEncoder().encode(...) inside the loop). This adds avoidable overhead in high-token streams. Instantiate a single TextEncoder once (outside the loop / outside the transform callback) and reuse it for all enqueues.

[Copilot]

executeWithResponsesEndpoint assumes the upstream /responses call returns an SSE stream and immediately pipes response.body through an SSE transformer, but headers/body are still built from the caller-provided stream flag. If stream is false, buildHeaders() sends Accept: application/json, which can cause /responses to return JSON and make the streaming parser/pipeThrough path fail. Either force streaming when using /responses (set Accept to text/event-stream and ensure the request body has stream: true), or add a non-streaming code path that parses JSON and converts it to the expected OpenAI chat completion response format.

[Copilot]

In the SSE transformer flush(), a trailing data: [DONE] line can be dropped if it arrives without a terminating newline: parseSSELine(buffer.trim()) returns {done:true}, but the code only forwards buffered data when !parsed.done. This can leave clients waiting indefinitely for [DONE]. Handle the parsed.done case in flush() (enqueue data: [DONE]\n\n), or flush any remaining buffered line through the same parsed.done branch used in transform().

Suggested change

	if (buffer.trim()) {
	const parsed = parseSSELine(buffer.trim());
	if (parsed && !parsed.done) {
	const converted = openaiResponsesToOpenAIResponse(parsed, state);
	if (converted) {
	controller.enqueue(new TextEncoder().encode(formatSSE(converted, "openai")));
	}
	}
	}
	const trimmed = buffer.trim();
	if (!trimmed) {
	return;
	}
	const parsed = parseSSELine(trimmed);
	if (!parsed) {
	return;
	}
	if (parsed.done) {
	controller.enqueue(new TextEncoder().encode("data: [DONE]\n\n"));
	return;
	}
	const converted = openaiResponsesToOpenAIResponse(parsed, state);
	if (converted) {
	controller.enqueue(new TextEncoder().encode(formatSSE(converted, "openai")));
	}

[Copilot]

The fallback trigger checks errorBody.includes("not accessible via the /chat/completions endpoint") on the raw response text. Since GitHub returns structured JSON errors, it would be more robust to JSON.parse and inspect error.message (and guard parse failures). This avoids false positives and makes the fallback resilient to formatting changes (whitespace, wrapping, localization).

[I3eka]

Hi @decolua,

First off, thanks for this awesome project!

I've just submitted PR #127 which fixes the 400 Bad Request error for newer GitHub Codex models. The fix uses a resilient, reactive fallback mechanism: it tries the standard endpoint, and if it gets the specific "endpoint not accessible" error, it retries on /responses and caches that model's preference to avoid future latency.

While working on this, I explored a more proactive architectural approach that I wanted to share for your consideration, even though I opted for the safer method in the PR itself.

Alternative Idea: Proactive Service Discovery

I confirmed that the GET https://api.githubcopilot.com/models endpoint returns a full list of available models, and most importantly, each model object contains a supported_endpoints array.

For example, for gpt-5.2-codex:

{
    "id": "gpt-5.2-codex",
    ...
    "supported_endpoints": [
        "/responses"
    ],
    "vendor": "OpenAI"
}

And for a standard model like claude-opus-4.6:

{
    "id": "claude-opus-4.6",
    ...
    "supported_endpoints": [
        "/v1/messages",
        "/chat/completions"
    ],
    "vendor": "Anthropic"
}

We could implement a "Service Discovery" mechanism that fetches this data on startup (or periodically) and builds an in-memory map (model -> endpoint).

Pros of this approach:

• Eliminates the "cold start" latency of the initial failed request for new Codex models, as we would proactively know the correct endpoint.

Why I didn't implement it in the PR:

• API Stability Risk: My main concern is that api.githubcopilot.com is an internal, undocumented API. Relying on its schema (like the supported_endpoints field) feels fragile. Any unannounced change from GitHub could break the entire integration, whereas relying on an explicit error message feels like a more stable contract.

Suggestion for the Future:
The current PR prioritizes resilience. However, a hybrid approach could potentially offer the best of both worlds:

1. Try to use the "Service Discovery" map for optimal performance.
2. If a request fails with the known 400 error (e.g., for a model not yet in the cache), fall back to the reactive mechanism and update the map.

Request for Review

Could you please review the current implementation?

I'd also love to hear your thoughts on the architectural direction:

• Should we stick with this reactive fallback for maximum resilience?
• Or would you prefer a proactive Service Discovery (or a hybrid) to completely eliminate the "cold start" latency on the very first request?

I am happy to adjust the code based on your preference.

Thanks for the great project!