vitalops/openvibe: a modular Auto-GPT framework for Python teams
Modular Auto-GPT Framework
At a glance
- What is it?
- openvibe is a Python coding agent with a FastAPI server, SQLite sessions and swappable LLM and database backends. The repository has not been pushed since 2026-07-03, so treat it as a readable codebase rather than a maintained product.
- Who is it for?
- Adopt openvibe if you want a small, readable Python agent you can fork and extend, and you are comfortable with a repository whose last push was 2026-07-03. Do not adopt it if you need a supported product, a published licence file, or a Windows installer.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 75 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What openvibe is and who it is aimed at
openvibe describes itself as a Python implementation of opencode, an open-source AI coding agent. The README frames it that way in one line, and the rest of the repository follows the same shape: a CLI, an HTTP server, a session store and a set of built-in tools that let a language model read, write and execute things in a project directory.
The project is aimed at Python developers who want to inspect or modify the agent loop rather than consume a finished product. The package metadata sets requires-python to >=3.11 and lists pydantic, litellm, fastapi, mcp and textual among its dependencies. That is a stack a backend engineer can read in an afternoon. It is not aimed at people who want a desktop application, a graphical installer, or a managed service. The README's usage block is entirely terminal commands: serve, run, models, session list, session show.
The name collides with unrelated projects. Searching for openvibe returns EEG software, a Windows application and mobile apps, none of which are this repository. If you arrive from a search engine, check that you are on vitalops/openvibe before running anything.
The execution loop behind openvibe run
The README points to src/openvibe/ and names the modules that matter. session/processor.py holds the core agent execution loop. llm.py wraps a litellm backend behind an LLMBackend protocol. db.py wraps SQLite behind a Database protocol. server.py exposes FastAPI with SSE. The tool/ directory contains bash, read, write, edit, glob, grep, web_fetch and todo. mcp/client.py handles Model Context Protocol server integration.
That layout tells you where the seams are. Because both the database and the model backend sit behind protocols, swapping SQLite for another store or litellm for a direct provider client is a matter of implementing an interface rather than editing the loop. The processor is the piece you would read first if you wanted to change how tool calls are sequenced.
Permissions are declared in configuration rather than hardcoded. The example config pairs a tool name with an action, so bash and write can both be set to ask. That is a per-tool gate, not a sandbox. Nothing in the README claims process isolation, and the bash tool exists precisely to run commands on the host. Treat the permission list as a confirmation prompt, not a security boundary.
Installing openvibe and running a first prompt
The README gives one install command. It is an editable install with the dev extra, which pulls pytest, ruff, mypy and pytest-asyncio alongside the runtime dependencies. Run it from the repository root.
pip install -e ".[dev]"After that, the package exposes two console scripts, openvibe and vibe, both pointing at openvibe.main:app. The README uses the first form throughout.
Configuration lives in openvibe.json at the project root. The README gives this example, which selects an Anthropic model, sets the default agent to build, and marks bash and write as ask.
{
"model": { "provider_id": "anthropic", "model_id": "claude-sonnet-4-5" },
"default_agent": "build",
"permission": [
{ "tool": "bash", "action": "ask" },
{ "tool": "write", "action": "ask" }
]
}The API key is read from the environment. The README shows the Anthropic variable.
export ANTHROPIC_API_KEY=sk-...With the key set, a one-shot task is a single command. The README's example is a test-fixing prompt.
openvibe run "fix the failing tests"To drive the agent over HTTP instead, start the server. The default port is 4096, and server.py serves both HTTP and SSE.
openvibe serveSessions are persisted and can be inspected afterwards. The README lists both commands without describing their output format.
openvibe session list
openvibe session show <session-id>If you are unsure which models your configuration can reach, openvibe models lists them. The README does not document what that command prints when a provider is unreachable.
Where openvibe stops being the right tool
The permission model is the first limit. Setting a tool to ask produces a prompt; it does not confine the agent. The bash tool runs on the host, and the README lists no container, VM or filesystem jail. If you need to run an agent against untrusted code, this project does not provide that boundary and does not claim to.
Licensing is the second. pyproject.toml declares license = {text = "MIT"}, but the repository's top-level entries are .github/, .gitignore, CORE.md, README.md, mcp.md, openvibe/, pyproject.toml and tests/. There is no LICENSE file listed. A metadata field is not the same as a licence text in the tree, and anyone distributing this package should resolve that before shipping.
Maintenance is the third. The last push to main was on 2026-07-03. Releases run v0.0.15 in May 2023, v0.1.0 in July 2023 and v0.1.1 in March 2024, while pyproject.toml still carries version 0.1.0. The README does not document a deprecation policy, a support window or a rollback procedure. If you need a dependency that receives security patches on a schedule, this is the wrong choice.
Finally, the README is thin on failure modes. There is no troubleshooting section, no description of what happens when a tool call fails mid-session, and no statement about how partial writes are handled. You would be reading session/processor.py to answer those questions yourself.
openvibe compared with other coding agents
The nearest reference point is opencode, which the README names as the project openvibe reimplements in Python. The difference is language and packaging: openvibe is a pip-installable Python package with a Typer CLI and a FastAPI server, which means you can import its modules and embed the agent loop in another Python service. That is harder to do with a compiled or Node-based agent.
Aider is the other obvious comparison, and the split is architectural. Aider centres on editing files in a git repository through a chat interface. openvibe centres on a tool loop with an explicit permission list, an MCP client for external tool servers, and a long-running HTTP server that streams over SSE. If your integration point is an HTTP endpoint that other services call, openvibe's server.py is the relevant piece. If your integration point is a developer sitting in a terminal editing code, the difference matters less.
Against a hosted coding agent, the trade is control for operational burden. openvibe runs where you run it, stores sessions in SQLite you own, and sends prompts to whichever provider litellm supports. In exchange you supply the API key, the process supervision and the upgrades.
Upgrade cost and licence implications
Upgrades are source installs. The README's install command is pip install -e ".[dev]", which tracks the working tree rather than a pinned release, so the version you run is whatever commit you checked out. pyproject.toml pins minimum versions with lower bounds only: litellm>=1.52.0, fastapi>=0.115.0, pydantic>=2.9.0, mcp>=1.1.0. There are no upper bounds, so a fresh install can pull newer major versions of any of these. For a reproducible environment you would need to add your own lock file, which the repository does not include.
The mypy configuration runs in strict mode with the pydantic plugin, and ruff is configured with a select list of E, F, I, N, W and UP. That suggests type checking and linting are expected to pass, which lowers the cost of patching the code yourself. It does not tell you anything about test coverage; the tests/ directory exists and pytest is configured with an integration marker for live network tests, but the README does not report coverage.
On licensing, pyproject.toml declares MIT. The repository listing shows no LICENSE file at the top level, so the declaration is the only evidence available here. MIT is permissive and places few obligations on downstream use, but a metadata string is not a licence grant, and this article is not legal advice. If you plan to redistribute openvibe, confirm the licence text with the maintainers first.
Editorial conclusion
Adopt openvibe if you want a small, readable Python agent you can fork and extend, and you are comfortable with a repository whose last push was 2026-07-03. Do not adopt it if you need a supported product, a published licence file, or a Windows installer. Before committing, verify that the MIT declaration in pyproject.toml is backed by a LICENSE file, and confirm that the Database and LLMBackend protocols cover the storage and provider you intend to use.
Frequently asked questions
What is openvibe?
openvibe is a Python implementation of opencode, described in its README as an open-source AI coding agent. It ships a CLI, a FastAPI server with SSE, a SQLite session store and built-in tools for bash, file reading and writing, glob, grep, web fetch and todos.
Is openvibe open source?
pyproject.toml declares license = {text = "MIT"}, and the source lives in the openvibe/ package with tests/ alongside it. The top-level repository listing shows no LICENSE file, so the MIT declaration is the only licence evidence in the tree.
Is openvibe safe to run?
The README documents a permission list where tools such as bash and write can be set to ask, but it describes no sandbox, container or filesystem jail. The bash tool runs commands on the host, so the permission entries act as prompts rather than isolation.
What is a good openvibe alternative?
opencode is the project openvibe reimplements, so it is the closest alternative. Aider takes a different approach, centring on chat-driven edits to a git repository rather than a tool loop with an HTTP server and an MCP client.
How do I install openvibe?
The README gives pip install -e ".[dev]" from the repository root, which requires Python 3.11 or later. It then exposes the openvibe and vibe console scripts, and configuration goes in openvibe.json at the project root.
Community notes