/v1/chat/completions endpoint so clients that already speak the OpenAI protocol can call an OpenHands agent.
Use this when you want an existing chat UI, IDE integration, evaluation harness, voice platform, or another agent to treat OpenHands as an OpenAI-style backend while still getting the full agent runtime behind the request.
What to Configure
Most OpenAI-compatible clients ask for the same three fields:| Client Field | Value |
|---|---|
| Base URL | https://YOUR_AGENT_SERVER/v1 |
| API key | Your agent-server session API key |
| Model | openhands_<profile_name> |
gateway_demo appears as the OpenAI model openhands_gateway_demo.
The gateway accepts the same session key in either OpenHands or OpenAI-compatible 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: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 OpenAI Chat Completions protocol usually sends full message history on every request. The OpenHands 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.
Current Limitations
- Only non-streaming Chat Completions requests are supported. Requests with
stream: truereturn400until streaming support is added. - The response contains the final assistant text only. Internal OpenHands tool activity is not exposed as OpenAI tool calls.
- OpenAI request fields that are not needed by the gateway are ignored or rejected intentionally by the server implementation.
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.
