gpt-5-codex is not accessible via the chat/completions endpoint

[rakotomandimby]

Hi all,

gpt-5-codex is now proposed in the list of models. It is in preview.

But this model is only usable with the "responses" API.
https://cookbook.openai.com/examples/gpt-5-codex_prompting_guide says "This model is only supported with the Responses API and does not support the verbosity parameter."

This is how the responses API is different https://platform.openai.com/docs/guides/migrate-to-responses

I have looked arround the documentation, they do not talk about multi-turn chat anymore in the "response" API.

I also have to adapt my plugin...

[rakotomandimby]

@deathbeam , I ask your validation for the following process:

• I will create a configuration parameter named api_specification: default to chat , possible other value responses
• If the parameter is set to chat, it will use the current API client
• I will write a client that will be able to use the Responses API
• If the parameter is set to responses, it will use the code I wrote

Later, if we are satisfied with the code using the Responses API, we can switch it to the default, if we want.

[deathbeam]

Its a bit harder than that. The client.lua should known only about 1 way to send and receive responses adn the adapter should do everything else. So it cannot be configuration, it is model specific as well (only gpt-5-codex support response api for example every other model will error instead, so switching completely is also pointless, it needs to be dynamic in adapter itself)

[rakotomandimby]

OK, so putting a "if gpt-5-codex" switch is good for you? I'm fine with that too.
Do we go that way?

[rakotomandimby]

@deathbeam , I cannot figure out what is the endpoint to use for the Reponses API.
I tried /responses and /v1/responses but it seemd they are not the ones to use...

[deathbeam]

its responses instead of chat/completions, and when getting models you get for each model if it supports responses api or not

[rakotomandimby]

I set log_level to debug in my configuration and after reloading, I ran :CopilotChatModels.
It logs the Github API call and the reponse.
This is the relevant parts of the logs:

    {
      "capabilities": {
        "family": "gpt-5-codex",
        "limits": {
          "max_context_window_tokens": 200000,
          "max_output_tokens": 64000,
          "max_prompt_tokens": 128000,
          "vision": {
            "max_prompt_image_size": 3145728,
            "max_prompt_images": 1,
            "supported_media_types": [
              "image/jpeg",
              "image/png",
              "image/webp",
              "image/gif"
            ]
          }
        },
        "object": "model_capabilities",
        "supports": {
          "parallel_tool_calls": true,
          "streaming": true,
          "structured_outputs": true,
          "tool_calls": true,
          "vision": true
        },
        "tokenizer": "o200k_base",
        "type": "chat"
      },
      "id": "gpt-5-codex",
      "model_picker_category": "powerful",
      "model_picker_enabled": true,
      "name": "GPT-5-Codex (Preview)",
      "object": "model",
      "policy": {
        "state": "enabled",
        "terms": "Enable access to the latest GPT-5-Codex model from OpenAI. [Learn more about how GitHub Copilot serves GPT-5-Codex](https://gh.io/copilot-openai)."
      },
      "preview": true,
      "supported_endpoints": [
        "/responses"
      ],
      "vendor": "OpenAI",
      "version": "gpt-5-codex"
    },

It is explicitely said that the supported_endpoint is /responses .
Note that this is the only model in the list that has that supported_endpoint property.

I continue the work and log me moves here

[rakotomandimby]

There is an attempt here: #1462

But it is clearly not the good way to do things. I just provide the modification here to be a starting point for the community, not to end with it.

The Responses API is capable of storing a precedent response and the user can ask the continuation of the conversation by providing the id of the precedent answer.

So, if we really want to use the Responses API correctly, we must handle storing the id.

Documentation: https://platform.openai.com/docs/api-reference/responses/get

I continue the work, do not hesitate to put your comments

[deathbeam]

both completion api and response api support that now based on openai docs btw. Also the chat continuation also means that your conversation data is stored on the servers, which means its insecure. I dont think skipping it is not using responses api correctly or incorrectly, they even say in their api docs if you care about them not storing data dont use the continuation. So its something thats completely optional. We can add opt-in support in future maybe but for now I dont think its needed at all for supporting the responses api (or beneficial even, you still have same context limit regarldess if you send full convo or just response with previous id)

[rakotomandimby]

@deathbeam , In clear, you prefer "simulating" the conversation in the input property value. Right?

In the POC code I provided, it is done like this:

# Context

# file://foo/bar/baz.ext:
{content_of_the_file}

# file://foo/bar/baz.ext:
{content_of_the_file}

# file://foo/bar/baz.ext:
{content_of_the_file}

# I asked: 
{content}

# The answer was: 
{content}

# I asked: 
{content}

# The answer was: 
{content}

# I asked: 
{content}

# The answer was: 
{content}

# I ask:
{prompt}

I think we should work on some semantic.
What are your preferences?

[deathbeam]

No, the response api support list just fine as input based on their documentation

[deathbeam]

So you can still simply use list of { "content"/ "type" } objects, same as before

[rakotomandimby]

@deathbeam ,
The support of Responses API is ready: If the model advertizes it supports the Responses API, then REsponses API will be used.