openvibe: a Python implementation of the opencode coding agent

What openvibe is for, and who it is aimed at

The README opens with one line: openvibe is a "Python implementation of opencode, an open-source AI coding agent." That framing sets the scope. This is not a new agent design. It is a port, and the people it serves are developers who want opencode's shape (a local server, a CLI, sessions, tools, MCP integration) in a Python codebase they can edit directly.

That audience is narrower than "anyone who wants an AI coding assistant." If you are comfortable with Python packaging, protocols and reading src/openvibe/ to understand behaviour, openvibe is aimed at you. If you want a finished desktop product with a GUI, the README does not describe one. It describes a serve command, a run command and a session subcommand, all driven from the terminal.

The topics attached to the repository are chatgpt, gpt, gpt4 and llms, which reflects the model-agnostic ambition but says nothing about which providers are actually exercised. The configuration example uses Anthropic, and the dependency list includes litellm, so the provider surface is broader than the topics suggest. The topics are the weakest signal on the page; the README and pyproject.toml are the useful ones.

The module layout: SQLite, litellm and a processor loop

The architecture section is short but concrete. It points at src/openvibe/ and names six modules. db.py is a "SQLite abstraction (swappable via Database protocol)". llm.py is an "LLM abstraction (litellm backend, swappable via LLMBackend protocol)". server.py is a "FastAPI HTTP + SSE server". session/processor.py is the "core agent execution loop". tool/ holds the built-in tools: bash, read, write, edit, glob, grep, web_fetch, todo. mcp/client.py handles MCP server integration.

Two design choices stand out. The first is protocol-based swapping. Because the database and the LLM backend sit behind protocols, a fork can replace SQLite or litellm without touching the agent loop. That is the kind of seam that matters when you are porting a project and expect to diverge from upstream. The second is the split between HTTP and SSE. The server exposes an HTTP API and streams events over Server-Sent Events, which is what makes a terminal client and a web client share one execution path.

The tool list is worth reading as a capability statement. bash, read, write, edit, glob and grep cover local repository work. web_fetch pulls remote content. todo is an internal planning tool rather than an external action. The permission model in the config example targets bash and write specifically, which suggests those two are treated as the dangerous ones. The README does not enumerate which other tools can be gated the same way.

Installing openvibe and running a first prompt

The README gives one install command, and it is an editable install with the dev extra:

pip install -e ".[dev]"

This installs the project from a checkout, not from a package index. The README does not document a plain pip install openvibe, and the pyproject.toml declares the name openvibe at version 0.1.0. Treat the checkout as the supported path. The requires-python field is >=3.11, so an older interpreter will fail before anything else runs.

The dev extra pulls pytest, pytest-asyncio, ruff and mypy. You do not need those to run the agent, but the README's single command includes them.

Two console scripts are declared in pyproject.toml: openvibe and vibe, both pointing at openvibe.main:app. The README uses openvibe throughout. Start the server with:

openvibe serve

The README states the default port is 4096. For a one-shot task without a running server:

openvibe run "fix the failing tests"

Configuration lives in openvibe.json at the project root. The README's example sets a model, a default agent and a permission list:

{
  "model": { "provider_id": "anthropic", "model_id": "claude-sonnet-4-5" },
  "default_agent": "build",
  "permission": [
    { "tool": "bash", "action": "ask" },
    { "tool": "write", "action": "ask" }
  ]
}

The credential goes in the environment, not the JSON:

export ANTHROPIC_API_KEY=sk-...

To see what the configured provider actually exposes, the README lists a models command:

openvibe models

Sessions are inspectable after the fact. openvibe session list shows stored sessions and openvibe session show <session-id> prints one. Because db.py is SQLite-backed, those sessions live in a local database file rather than a remote service. The README does not name the file path.

Where openvibe is the wrong tool

The README documents no rollback. If an agent run edits files through the write or edit tools, there is no described mechanism for undoing that run as a unit. The permission list can force an ask before bash and write, which limits blast radius, but a prompt is not a checkpoint. Anyone expecting transactional edits should look elsewhere or build the checkpointing themselves on top of the session store.

The second gap is release cadence. The repository lists three releases: v0.0.15 on 2023-05-12, v0.1.0 on 2023-07-16 and v0.1.1 on 2024-03-10. Meanwhile pyproject.toml declares version 0.1.0, which does not match the newest tag. The last push to the default branch was on 2026-07-03, so work has continued, but the published version numbers have not tracked it. If your adoption process depends on tagged, versioned artifacts, that mismatch is a real problem.

The third gap is the licence. pyproject.toml carries license = {text = "MIT"}, while the repository metadata supplied for this project lists the licence as unknown. Those two statements disagree, and the README says nothing about licensing at all. Until you confirm which is authoritative, you cannot reason about redistribution.

Finally, the install path assumes you are willing to run from a checkout. If your environment forbids editable installs or requires pinned artifacts from an index, openvibe does not fit without extra packaging work.

How openvibe differs from running opencode itself

The obvious alternative is opencode, the project openvibe reimplements. The README links to opencode.ai and describes openvibe as a Python implementation of it. The difference is the implementation language and the ecosystem around it, not the agent concept.

That distinction has practical consequences. A Python codebase lets you reuse Python tooling: pydantic for configuration and validation, mypy in strict mode, ruff for linting, pytest with asyncio_mode set to auto. If your team already lives in that stack, extending openvibe means writing Python against the Database and LLMBackend protocols rather than working in another language's plugin model. The pyproject.toml shows exactly which libraries you inherit: fastapi, uvicorn, pydantic, litellm, mcp, httpx, aiofiles, typer, rich, sse-starlette, mistune, textual, ddgs, selenium, webdriver-manager and beautifulsoup4.

That dependency list is also the cost. selenium and webdriver-manager are heavyweight, and they imply browser automation for some part of the fetch path. beautifulsoup4 and ddgs suggest scraping and search. If you only want shell, file and grep tools, you are still installing a browser stack. A leaner agent that ships only the local tools would avoid that, at the price of not having web_fetch.

The other axis is MCP. openvibe includes mcp/client.py, and the repository has a top-level mcp.md alongside CORE.md. If your extension strategy is MCP servers, that integration is part of the port. If your strategy is in-process plugins, the protocol seams in db.py and llm.py are the more relevant surface.

Maintenance, versioning and what the licence declaration implies

The last push to the default branch was on 2026-07-03. The repository is not archived. Those are the two facts available, and they support one claim: someone pushed code recently. They do not establish a support commitment, a deprecation policy or a compatibility guarantee.

The version evidence points the other way. The newest release is v0.1.1 from 2024-03-10, while pyproject.toml still reads version = "0.1.0". A project whose manifest lags its tags by a minor version is not maintaining a clean release pipeline. Plan for installing from a commit rather than from a release artifact.

On licensing, pyproject.toml declares MIT. The repository metadata does not confirm it. This is not a legal opinion and I am not giving one. The practical point is that two sources in the same repository disagree, and you should resolve that before you build anything you intend to distribute. Check the repository for a LICENSE file and check whether the MIT declaration in pyproject.toml is the authoritative one.

Upgrade cost is bounded by the dependency set. litellm, fastapi, pydantic and mcp all move quickly, and mypy strict mode means type errors surface as build failures rather than runtime surprises. The dev extra pins minimum versions only, with no upper bounds, so a fresh install can pull newer majors than the code was written against.

Editorial conclusion

Adopt openvibe if you want an opencode-style agent loop you can read and modify in Python, with SQLite and litellm behind swappable protocols. Do not adopt it if you need a published package, a stable release cadence or documented support guarantees: the README's install path is an editable checkout and the repository's own version string is 0.1.0. Before committing, verify that pip install -e ".[dev]" resolves on Python 3.11 or newer, that openvibe serve binds port 4096 in your environment, and what licence the repository actually carries, since pyproject.toml declares MIT while the repository metadata does not.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. vitalops/openvibe on GitHub