/v1 with two endpoints:
POST /v1/chat/completions— the OpenAI Chat Completions protocol.POST /v1/responses— the OpenAI Responses protocol.
How It Works
Both endpoints are protocol adapters over the same full OpenHands agent, not a thin wrapper around a raw LLM call. Each request:- Loads the OpenHands agent configured by the named profile.
- Starts (or, for Chat Completions, optionally reuses) an OpenHands conversation.
- Runs the agent’s complete internal tool loop to completion.
- Returns only the final assistant text as an OpenAI-shaped response.
What to Configure
Most OpenAI-compatible clients ask for the same three fields:
For example, a saved LLM profile named
gateway_demo appears as the OpenAI model openhands_gateway_demo.
Authentication maps OpenAI-style bearer tokens onto the agent-server’s existing session key mechanism. The gateway accepts the same session key in either form:
X-Session-API-Key: <key>Authorization: Bearer <key>
Prepare a Profile
OpenAI-compatible traffic is backed by an agent-server LLM profile. Create one with the native profile API first:Chat Completions (POST /v1/chat/completions)
Each request runs a full OpenHands agent to completion and returns the final assistant text in a standard Chat Completions shape.
Supported request fields:
model— required; must be anopenhands_<profile_name>exposed viaGET /v1/models.messages— a standard list. The lastusermessage becomes the agent’s task;systemanddevelopermessages are folded into the agent’s system context.stream—truereturns a server-sent events stream;false(default) returns a single response.
X-OpenHands-ServerConversation-ID header. Send that header on a follow-up request to continue the same server-side OpenHands conversation instead of starting a new one.
Client Recipes
- curl
- Python SDK
- JavaScript SDK
- Chat UIs
- Voice or Webhook
X-OpenHands-ServerConversation-ID. Save that header if you want a later request to continue the same agent conversation.Conversation State
The Chat Completions protocol usually sends full message history on every request, but the gateway does not reconstruct agent history from prior assistant messages. Instead:- Omit
X-OpenHands-ServerConversation-IDto start a new OpenHands conversation. - Read
X-OpenHands-ServerConversation-IDfrom the response. - Send that header on follow-up requests to continue the same OpenHands conversation.
messages. The server-side OpenHands conversation owns the previous agent state, tool activity, and workspace context.
Responses (POST /v1/responses)
The Responses endpoint targets the OpenAI Responses API — a better fit for agent-shaped traffic, with typed input/output items. It is stateless-first by design.
Mental Model
Every request starts a fresh OpenHands conversation and runs the full agent to completion. There is no server-side continuation handle: to carry context forward, clients replay prior input and output items into the next request’sinput.
X-OpenHands-ServerConversation-ID header, but unlike Chat Completions you cannot pass it back to continue that conversation — the Responses surface ignores it. Use the header only to correlate the response with the underlying OpenHands conversation through the native agent-server API.
Replaying Context
To maintain context across Responses calls, replay the previous assistant output items (and any system/developer context) into the next request’sinput:
How Input Is Interpreted
- Top-level
instructionsand anysystem/developerinput items become the agent’s system context. - The remaining input items become the agent’s user prompt. A single
useritem is sent as-is; multiple non-system items are wrapped in<message role="…">tags so their roles are preserved. modelmust be anopenhands_<profile_name>exposed viaGET /v1/models.
Not Supported Yet
The following OpenAI Responses features are intentionally rejected or ignored. Status codes and wording are exact.Current Limitations (Both Endpoints)
- The response contains the final assistant text only. Internal OpenHands tool activity is not exposed as OpenAI tool calls or Responses output items.
- OpenAI request fields the gateway does not need are either ignored or rejected intentionally by the server implementation. Declared tools and generation-tuning fields do not change agent behavior.
Ready-to-run example
This example is available on GitHub: examples/02_remote_agent_server/15_openai_compatible_gateway.py
examples/02_remote_agent_server/15_openai_compatible_gateway.py
The model name should follow the LiteLLM convention:
provider/model_name (e.g., anthropic/claude-sonnet-4-5-20250929, openai/gpt-4o).
The LLM_API_KEY should be the API key for your chosen provider.
