[FEATURE]: Python client for the OpenCode 2.x server API · Issue #54300 · anomalyco/opencode · GitHub
Skip to content

[FEATURE]: Python client for the OpenCode 2.x server API #54300

Open

Description

@shrijayan

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

(Related but not the same: #2266 and #4031 asked for a Python SDK in general; both are closed. This request is specifically about OpenCode 2.x.)

Describe the enhancement you want to request

A maintained Python client for the OpenCode 2.x server API, generated from packages/sdk/openapi.json.

Today there is no Python client that speaks the 2.x API:

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:

  1. 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)?
  2. 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.

Activity

  1. opencode-agent commented on Oct 10, 2026

    @opencode-agent
    Contributor

    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.

  2. MilindKulkarni12 commented on Oct 13, 2026

    @MilindKulkarni12

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions