Open Velocity, an agent-first IDE built around a model gateway

The pitch is a gateway, not an editor

Open Velocity is presented as an open-source, universal AI gateway for agentic development, and the project calls itself an ambitious open-source project to build a web-native, agent-first integrated development environment. The project description gives its own comparison, calling it the open-source equivalent of Google's Antigravity, Claude Code and Cursor.

The architectural diagram in the README shows what it is actually made of, and the picture is more gateway than editor.

graph TD
    UI[Web UI / Editor] --> GW[Gateway & Orchestrator]
    GW --> WM[Workspace Manager]
    GW --> AG[AI Model Gateway]
    WM --> Docker[Isolated Containers]
    AG --> LLMs[Gemini, Claude, GPT-4, Llama]

A browser editor and a gateway sit on top of a workspace manager that runs isolated Docker containers, and a model gateway that talks to several providers. The claim that no code or environment information is sent to third parties without your consent follows from that shape, because the containers do the work and the gateway is the only thing that talks outwards.

The stated reasons for building it are a list of four, and they are worth quoting in spirit because they set the scope. True model freedom, so the platform is not tied to a single AI provider. Democratising AI, so that state-of-the-art agentic development is accessible to everyone. Transparency and extensibility, described as an open core the community can shape, extend and trust. And self-hosting and privacy, giving full control over your code, your data and your AI connections.

The audience is a developer who wants to run agents against their own infrastructure, with the model provider as a swappable choice rather than a commitment.

The licence situation needs checking before you rely on it. The repository is recorded with a GPL-2.0 licence, while the badge in the README points at an MIT licence, and the top-level tree contains a LICENSE file. The README also carries a disclaimer stating that Open Velocity is an independent, community-driven project and is not an official product of Google LLC, Alphabet Inc. or any of its affiliates, and that it is not endorsed, sponsored or supported by Google, with a note that the names velocity, Gemini and Google are trademarks of their respective owners. So there is a licensing and naming question to settle before this goes anywhere near a commercial setting, and the licence file is where to settle it.

The SQLite core that runs the agents

The part of the project that is described as implemented is the OpenCentravity v0.2.0 backend core, and the README is quite specific about what is in it. The underlying core engine in `newcore/` is said to support enterprise-grade, concurrent multi-agent coordination.

The list of capabilities is long and concrete, which is a good sign for a project whose README is otherwise aspirational.

The persistence layer is a 14-table SQLite database under `src/db/`, with Write-Ahead Logging and sequential schema migrations numbered 0001 to 0014. On top of that there is a connection safety mechanism, a module-level promise that blocks concurrent read and write queries from running on a partially migrated database, which the documentation says eliminates race condition locks.

The multi-agent machinery is the interesting part. The database tracks parent-child relationships between agents, which allows workflows to branch into what the documentation calls hierarchical swarms. A shared communication whiteboard at `src/orchestrator/messagebus.ts` lets sub-agents broadcast status and coordinate. A distributed lock manager at `src/orchestrator/locks.ts` provides file-level mutexes that prevent overlapping writes and edit collisions by parallel agents on the same files.

There is also a snapshotting engine at `src/memory/snapshot.ts` that saves agent memory states periodically so agents can restore state and self-heal from failures, and a cost recorder that monitors and persists input and output token counts and the real-time API cost per LLM call, which is what makes a swarm-level cost ceiling possible through the `MAX_COST_USD` rule.

The last piece is the CLI, described as a consolidated command suite: `swarms`, `swarms inspect`, `swarms cancel`, `cost`, `db:status`, `db:backup` and `db:backups`.

So the design is a job queue with a relational store, a message bus for inter-agent chatter, file locks for the actual workspace, memory snapshots for crash recovery, and a token ledger for cost control. That is a coherent architecture for the problem, and each piece addresses a specific failure mode of parallel agents editing the same repository.

Running it, and where the compose file and the README disagree

The getting started instructions list three prerequisites: Docker and Docker Compose, Node.js version 20 or later, and Python version 3.11 or later. Then three steps, of which the third is the one that matters.

    git clone https://github.com/ishandutta2007/open-velocity.git
    cd open-velocity

Note the repository name in that URL is `open-velocity` while the repository itself is called `Velocity`, and the tree contains a `README.md.bak` and a `README.zh-CN.md` alongside the main README, so the project has been through some renaming.

Step two copies the environment template.

    cp .env.example .env

And step three starts the stack.

    docker-compose up --build

The README then says to access the platform at `http://localhost:3000`. The compose file in the repository says something different. The service is called `velocity`, it is built from `newcore/Dockerfile`, and it publishes the port as `"3777:3777"`, with a healthcheck that queries `http://localhost:3777/health`. There is no port 3000 anywhere in the compose file.

The compose file also reads its environment from `newcore/.env` through the `env_file` key, while the README tells you to create `.env` in the repository root. The file has a second service, `velocity-dev`, built from `newcore/Dockerfile.dev`, behind the `dev` profile, with the source directory mounted for hot reload. Three named volumes carry the state: `workspaces`, `artifacts` and `data`.

Those two mismatches are the kind of thing that costs an afternoon, and they are the reason the project is worth writing about carefully rather than praising. The documentation describes an intent, the compose file describes an implementation, and they have drifted apart.

Neither is a reason to walk away, and both are reasons to read the compose file before you run anything rather than after.

What the feature list promises and what the tree contains

The core features section is labelled as the vision, which is an unusual and honest heading, and the list describes fusing the best features of Cursor, Windsurf, Trae and Velocity into a single experience, incorporating the capabilities of Google CodeMender and Google Jules for code generation, and a universal LLM gateway connecting to GPT-4, Claude 3.5, Gemini 1.5 Pro, Llama 3, Deepseek and more.

The agent-first features are the ones that are specific. Agents delegate high-level tasks and plan, write and verify code. Multi-agent collaboration spawns multiple agents to work in parallel on different parts of a project. Verifiable artifacts have agents generate tangible artefacts, described as task lists, screenshots and test results, so you can check the work rather than trust it. And interactive feedback lets you give agents input while they work.

What the tree contains is worth a separate look, because it shows where the effort went. There is a `newcore/` directory holding the backend core, a `mitmserver/` directory, an `assets/` directory, a `docs/` folder alongside a `ROADMAP.md`, a `DESIGN.md` and a `SECURITY.md`, and three banner-related files at the top level, `banner_escaped.txt`, `banner_escaped_json.txt` and `banner_raw.txt`, along with an `escape_art.js` script that appears to be responsible for them. The README does not describe what the `mitmserver/` directory contains, so that is worth checking directly in the source if the traffic path through the gateway matters to you.

The roadmap is four phases. Phase 1 is the core platform and universal gateway, phase 2 is single-agent workflow and tooling, phase 3 is advanced agentic features covering multi-agent work, and phase 4 is community and extensibility. The README points to ROADMAP.md for the full details.

Read together with the phase list, the feature list is a statement of direction rather than a shipping manifest, and the OpenCentravity section is the part that is claimed to exist. The distinction is in the README itself, and a reader who notices it will make better decisions about what to expect.

Where this is the wrong tool

Two honest reasons not to use it, and one that is not about the project at all.

The first is the contradiction between the vision and the implementation. The core features section is headed as the vision, the roadmap is four phases long, and the backend core is the part claimed to be done. If you need a polished editor with an agent panel and a stable file tree today, this is not that, and no amount of good intent in the README changes it.

The second is the environment. Docker and Docker Compose, Node.js 20 or later and Python 3.11 or later, all for a single developer machine, with the model gateway making outbound calls to whichever provider you configure. That is a heavier footprint than a native agentic editor, and the CI cost of running the container stack on every change is a real consideration for a team.

The third is a legal one that has nothing to do with the code. The project positions itself as an alternative to proprietary platforms and names them in its own description, and it carries a disclaimer stating that it is not an official product of Google, Alphabet or any affiliate, and that the referenced names are trademarks. Building a tool that names competing products in its own marketing is a choice with consequences, and a commercial user of the code inherits the questions that come with the branding.

On the licence, the repository metadata says GPL-2.0 and the README badge says MIT, and the two cannot both be what you rely on. The LICENSE file at the root settles it, and until you have read it, treat the terms as unknown.

What the project offers that a proprietary tool does not is control. The gateway means the provider is a configuration detail, the containers mean the agent's file access is bounded, the file locks mean two agents do not corrupt the same file, and the cost recorder means you can set a ceiling on what a swarm spends. Those are real, and they are the reason to watch the project rather than dismiss it.

Editorial conclusion

Open Velocity suits a developer who wants to self-host an agentic coding environment, needs to point several agents at different model providers, and is prepared to work on the project rather than just install it. It does not suit someone who wants a finished editor today, because the roadmap in the README is phased and the core is described as the implemented part of a larger vision. Verify first that the port and environment variable paths the compose file defines match what the README tells you to expect, since the two disagree, and read the licence files yourself, because the repository metadata and the README badge name different licences.

Frequently asked questions

Official sources

1. ishandutta2007/Velocity on GitHub
2. Issues
3. License: GPL-2.0
4. README