You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Python client for the OpenCode 2.x server API #54300
The Python SDK merged in Feat/python sdk #2779 is no longer in packages/sdk (only js/ and openapi.json remain).
2.x ships on npm under @opencode/*, so JS/TS users have @opencode/client, but Python users have to hand-write HTTP calls.
Why it matters: we run OpenCode as a headless agent engine (opencode serve) from a Python backend: custom agents in opencode.json, MCP tools, one session per unit of work, structured JSON output. Moving that service from 1.18.x to 2.0.26 meant writing our own httpx client against the 2.0.26 server's /openapi.json.
What a Python client needed to cover for that use case:
list agents and MCP server status (agents load asynchronously after boot, so callers wait until theirs are listed)
create a session with an agent and its model (the model must be set at creation; otherwise the root session ran on another model)
send a prompt with text and file parts (images as data: URLs)
wait until the session is idle (in 2.0.26 this is /api/experimental/session/{id}/wait, still marked experimental)
read the transcript, paged
interrupt a session
read cost and token usage
Basic auth with a per-boot server password
Things that surprised us in 2.x and would be worth documenting next to a Python client:
A provider key in the environment takes precedence over the apiKey in opencode.json.
When the server runs inside a project checkout, it loads that checkout's AGENTS.md and skills into every agent's system prompt. Headless/embedded use needs a way to opt out (we run the server from an isolated directory with a private HOME).
Ask:
Is a Python client for 2.x planned, and if so, generated by which tool (Feature request: Python SDK #2266 mentioned moving off Stainless to open-source per-language generators)?
If a community PR would be welcome, we are happy to contribute ours (a small typed httpx client with tests against a fake server) as a starting point, or to help wire up a generator such as openapi-python-client against packages/sdk/openapi.json.
Thanks for the detailed request, and for offering to contribute!
To restate it: you're asking for a maintained Python client for the OpenCode 2.x server API, ideally generated from the OpenAPI spec. It would cover the headless opencode serve flow: agents and MCP status, creating a session with an agent and model, prompting with text and file parts, waiting for idle, paged transcripts, interrupting, cost and usage, and Basic auth. You also flagged two things worth documenting: provider env keys take precedence over the config apiKey, and there's no way to opt out of loading the project's AGENTS.md and skills when embedding the server.
Maintainers will consider it, including which generator to use and whether a community PR fits. I can't promise anything yet. Related earlier work, all closed and about pre-2.x versions:
It may help to hold off on a full PR until a maintainer says which direction they prefer. If you do share your client, a link to a repo would make it easy to look at.
Hi @shrijayan and maintainers — I'm a Python/backend and AI engineer with 5+ years of experience, currently building production agentic applications at Knotch. My work includes multi-tenant RAG, MCP/tool integrations, and evaluation and reliability testing.
I'd like to help with a focused API compatibility test suite rather than duplicate the client you've offered: Basic auth, creating a session with an explicit agent/model, admitting a prompt, waiting for idle, paging transcripts, and interrupting execution. I'd start with auth and session creation against a local V2 server, with no paid model calls.
Current dev has the spec at packages/protocol/openapi.json and serves /openapi.json; packages/sdk is now an embedded TypeScript host. I also saw the earlier Hey API plans in #4031. Is that effort intended to cover V2, and would these tests be useful alongside your client or the chosen generator? I'm happy to align with the approved direction.
Activity
opencode-agent commentedon Oct 10, 2026
Thanks for the detailed request, and for offering to contribute!
To restate it: you're asking for a maintained Python client for the OpenCode 2.x server API, ideally generated from the OpenAPI spec. It would cover the headless
opencode serveflow: agents and MCP status, creating a session with an agent and model, prompting with text and file parts, waiting for idle, paged transcripts, interrupting, cost and usage, and Basic auth. You also flagged two things worth documenting: provider env keys take precedence over the configapiKey, and there's no way to opt out of loading the project'sAGENTS.mdand skills when embedding the server.Maintainers will consider it, including which generator to use and whether a community PR fits. I can't promise anything yet. Related earlier work, all closed and about pre-2.x versions:
It may help to hold off on a full PR until a maintainer says which direction they prefer. If you do share your client, a link to a repo would make it easy to look at.
MilindKulkarni12 commentedon Oct 13, 2026
Hi @shrijayan and maintainers — I'm a Python/backend and AI engineer with 5+ years of experience, currently building production agentic applications at Knotch. My work includes multi-tenant RAG, MCP/tool integrations, and evaluation and reliability testing.
I'd like to help with a focused API compatibility test suite rather than duplicate the client you've offered: Basic auth, creating a session with an explicit agent/model, admitting a prompt, waiting for idle, paging transcripts, and interrupting execution. I'd start with auth and session creation against a local V2 server, with no paid model calls.
Current
devhas the spec atpackages/protocol/openapi.jsonand serves/openapi.json;packages/sdkis now an embedded TypeScript host. I also saw the earlier Hey API plans in #4031. Is that effort intended to cover V2, and would these tests be useful alongside your client or the chosen generator? I'm happy to align with the approved direction.