Feature Request: Support OpenAI Responses API (/v1/responses) in llama.cpp server

[AF-2000]

Prerequisites

• I am running the latest code. Mention the version if possible as well.
• I carefully followed the README.md.
• I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
• I reviewed the Discussions, and have a new and useful enhancement to share.

Feature Description

Description:
The llama.cpp OpenAI-compatible server currently supports endpoints like /v1/chat/completions, but does not support the newer OpenAI Responses API (/v1/responses).

Many OpenAI client SDKs and tools are moving toward the unified Responses API, which supports structured outputs, tool calls, and multimodal responses in a single endpoint. Lack of /v1/responses support makes it harder to use llama.cpp as a drop-in replacement for OpenAI backends without an additional proxy or translation layer.

Requested feature:
Add native support for the /v1/responses endpoint in llama-server, aligned as closely as possible with OpenAI’s Responses API request/response format.

Benefits:

Improved compatibility with modern OpenAI SDKs

Easier migration from OpenAI APIs to llama.cpp

Reduced need for custom proxy or request rewriting layers

Thanks for the great work on llama.cpp!

Motivation

I want to use ClaudeCode with llama-server offline, but it currently don't support necessary endpoints.

Possible Implementation

No response

[wqerrewetw]

#14702

#18486

[njbrake]

Hi! Instead of Responses, could we make this support the OpenResponses protocol?

https://www.openresponses.org/

It's the OpenAI sponsored open source protocol, already adopted by Huggingface as well.

[mekarpeles]

Bump :)

[riskywindow]

I'd like to work on this, specifically building on #18486 to bring the /v1/responses endpoint toward OpenResponses compliance, as @njbrake suggested.
My plan is to start by running the OpenResponses acceptance tests against the current server to baseline what passes/fails, then tackle the biggest gaps which are non-streaming mode, structured output support via text.format, and full streaming event lifecycle (content_part.added/done, sequence_number, correct output_item.done ordering).
Happy to share a detailed implementation plan once I've profiled the compliance gaps.

[jooooooooood]

Bump

[alimohan12m12-ai]

I don't understand what did you say

…

On Thu, Mar 19, 2026, 3:03 PM Lorenzo Rondán ***@***.***> wrote: *LorenRd* left a comment (ggml-org/llama.cpp#19138) <#19138 (comment)> Bump! — Reply to this email directly, view it on GitHub <#19138 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7VQ6JAEKNKHDIRXSEMFISL4RQD47AVCNFSM6AAAAACTBNS3OGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAOJQG43TMMBXGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bartlettroscoe]

NOTE: It would seem with Hugging Face supporting the Open Reponses standard:

• https://huggingface.co/blog/open-responses

and with GGML joining Hugging Face:

• ggml.ai joins Hugging Face to ensure the long-term progress of Local AI #19759

that one would expect llama.cpp to adopt the Open Responses standard?

I guess that the PR:

• server: add OpenAI Responses API compliance #19720

is not ready to be merged because it does not yet pass all of the Open Responses compliance tests?