# opendev-to/opendev: a Rust coding agent that binds each workflow to its own model

> OpenDev splits a coding task into typed workflows, each attached to a separate LLM, and fans out sub-agents that run in parallel inside one session. The Rust runtime and per-slot model routing are the interesting parts; the measured startup numbers come from the project's own comparison table.

**opendev-to/opendev** — Open-Source Coding Agent in the terminal

- Repository: https://github.com/opendev-to/opendev
- Stars: 851 · Forks: 89
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/opendev-to-opendev

## Five workflow slots, each bound to a model you pick

The central design decision in OpenDev is that a single monolithic model does not do everything. The project describes itself as a compound AI system built from a structured ensemble of agents and workflows, where each agent runs typed workflows that independently bind to an LLM. Five slots are named: Normal, which handles execution, Thinking, which handles reasoning, Compact, which does context summarization, Self-Critique, which verifies output, and VLM, which covers vision. Each slot binds to any model you configure, and the README gives a concrete arrangement: Claude Opus on execution, GPT-o3 on reasoning, and a lightweight Qwen model on compaction. The point of splitting this way is stated as fine-grained trade-offs in cost, latency and capability per workflow rather than one global choice. That is a real design opinion, and it is also the main thing to evaluate, because the benefit depends entirely on whether you have several models configured and are willing to reason about which one should handle which phase.

## Agent fleets fan out inside a single session

Work is organised into concurrent sessions composed of specialized sub-agents, and the fleet mechanism is what makes those sessions useful on a large codebase. The README describes spawning a fleet to survey an entire codebase, refactor across 20 crates, or run a dozen tool calls at once, with each sub-agent carrying its own LLM binding, its own context window and its own tool access. The diagram in the project description shows a survey request branching to agents pointed at crate/agents, crate/http, crate/tui, crate/tools and crate/config, with the aggregated results returning to the prompt. The mechanism is built on a Rust runtime with fully async I/O, and each agent runs its own async task. The subagents are not restricted to the same model, so a fleet can mix a cheap model for mechanical crates with a stronger one for the parts that need judgement. The practical cost is that you now have a concurrency problem to reason about: several agents may touch overlapping files in the same workspace, and the documentation does not describe a conflict resolution or locking policy.

## The Cargo workspace spreads the agent across 22 crates

The repository is a Cargo workspace rather than a single crate, and the member list is the clearest statement of the architecture. The workspace contains crates named opendev-models, opendev-config, opendev-http, opendev-context, opendev-history, opendev-tools-core, opendev-tools-impl, opendev-tools-lsp, opendev-tools-symbol, opendev-agents, opendev-web, opendev-repl, opendev-cli, opendev-mcp, opendev-channels, opendev-tui, opendev-runtime, opendev-hooks, opendev-plugins and opendev-sandbox. Read together, they trace a request path: tools in several flavours, an LSP and a symbol layer, context and history management, an agents crate, a runtime, a REPL and a TUI, plus separate crates for hooks, plugins, MCP and a sandbox. The dependency list confirms the stack, with tokio for async, reqwest and axum for HTTP, ratatui and crossterm for the terminal interface, and axum configured with a ws feature for websockets, which is what the Web UI path would sit on. The rust-version field is set to 1.94 and the edition is 2024, so a recent toolchain is a hard requirement.

## Installing opendev-cli through cargo, Homebrew or a shell script

The documented install paths are straightforward, and the crate published for this is opendev-cli. On any platform, cargo installs it:

```bash
cargo install opendev-cli
```

On macOS the project marks Homebrew as the recommended route, and also offers a shell installer:

```bash
brew install opendev-to/tap/opendev
```

```bash
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/opendev-to/opendev/releases/latest/download/opendev-cli-installer.sh | sh
```

Linux gets the same shell installer, with direct binary downloads listed for x86_64 and for aarch64, which the README labels as ARM64 and Raspberry Pi. Windows uses a PowerShell installer:

```powershell
powershell -ExecutionPolicy ByPass -c "irm https://github.com/opendev-to/opendev/releases/latest/download/opendev-cli-installer.ps1 | iex"
```

The install produces a single binary, and the release artefacts are named opendev-cli-aarch64-apple-darwin.tar.xz and opendev-cli-x86_64-unknown-linux-gnu.tar.xz among others. One caveat worth knowing before you run the shell installer: it pipes a remote script directly into a shell, so review it first if that is not your habit.

## The startup comparison is the project's own table

OpenDev makes a performance claim and then supplies the table behind it, which is unusual and worth reading carefully. The README reports a startup of 4.3 ms, peak memory of 9.4 MB and an install size of 18 MB, and puts OpenDev 0.1.4 against Codex 0.116.0, Claude Code 2.1.87 and OpenCode 1.2.27, giving multipliers of 128x faster startup and 30x less memory than the slowest row. The measurement conditions are given: macOS ARM64, startup timed with hyperfine using --shell=none --warmup 10 --runs 100, and memory taken as the median of 20 runs under /usr/bin/time -l. Two things follow. The claim is not a third-party benchmark, it is a table the project produced about itself and its competitors. And the row being measured is version 0.1.4, while the newest release listed for the repository is v0.1.9, so the numbers may not describe the binary you install. Startup time is also the least interesting metric for an agent that spends its time waiting on model responses.

## TUI for the terminal, Web UI for watching from elsewhere

Two interfaces ship in the same project. There is a full terminal UI for what the README calls power users, and a Web UI for visual monitoring, and the Web UI supports remote sessions, so the stated use case is starting a task from a phone and letting OpenDev work while you sleep. The repository contains a web-ui directory and a crates/opendev-web member, and the workspace enables a websocket feature on axum, which is consistent with a browser talking to a running session. The opendev-channels crate sits alongside it, suggesting another way to reach a session, though the project description does not spell out what channels are for. The reactive claim is that OpenDev can plan, execute and iterate autonomously, so a refactoring can be kicked off and reviewed later as a pull request. That is the mode that pairs well with parallel agents, and also the mode where you most want a way to watch and to intervene.

## MIT licence, tagged releases, and a last push on 2026-08-08

The repository is not archived and the last push was on 2026-08-08, so the code is still moving, but the release cadence is irregular rather than monthly. The listed releases are v0.1.7 on 2026-03-31, v0.1.8 on 2026-04-01 and v0.1.9 on 2026-07-10, which shows two releases one day apart and then a gap of more than three months before the latest. The license is MIT, one of the most permissive options available, and the workspace package metadata repeats version 0.1.9, edition 2024 and rust-version 1.94. Upgrade cost is therefore about pinning, not about migrating a licence or a config format. The repository also carries CHANGELOG.md, ROADMAP.md, RELEASE_FLOW.md and DEVELOPMENT.md, so the release process is documented even though the product documentation is not. That gap is the honest limitation: the project states plainly that the website and documentation are coming soon, so you will be learning the configuration surface from the crates and the source.

## Conclusion

Adopt opendev-to/opendev if you want per-workflow control over which model handles execution, reasoning and compaction, and you are comfortable wiring your own provider bindings. Do not adopt it expecting a documented, stable configuration surface, because the project states that the website and documentation are still coming soon, and the version in its own comparison table is 0.1.4 while the newest release is v0.1.9. Before you commit, check the crates that matter to your setup, which include opendev-config, opendev-mcp and opendev-sandbox, and confirm the model bindings each of the five workflow slots expects.

## FAQ

### What is opendev-to/opendev?

It is a terminal-native, open-source coding agent written in Rust that spawns parallel sub-agents, each bound to a language model the user configures. Work is organised into concurrent sessions of specialized sub-agents running typed workflows.

### How do I install opendev-to/opendev on macOS?

The README marks Homebrew as the recommended route with brew install opendev-to/tap/opendev, and also offers a shell installer and direct binary downloads from GitHub Releases. On any platform, cargo install opendev-cli is also listed.

### Can opendev-to/opendev use different models for different tasks?

Yes. Five workflow slots, named Normal, Thinking, Compact, Self-Critique and VLM, each bind independently to any model you configure. The README gives an example where Claude Opus handles execution, GPT-o3 handles reasoning and a lightweight Qwen model handles compaction.

### Does opendev-to/opendev have a web interface?

The project ships a TUI and a Web UI, and the Web UI supports remote sessions. The workspace contains a web-ui directory and a crates/opendev-web member, and the axum dependency is enabled with a ws feature for websockets.

## Sources

- [Issues](https://github.com/opendev-to/opendev/issues)
- [License: MIT](https://github.com/opendev-to/opendev/blob/main/LICENSE)
- [opendev-to/opendev on GitHub](https://github.com/opendev-to/opendev)
- [README](https://github.com/opendev-to/opendev/blob/main/README.md)
- [Releases](https://github.com/opendev-to/opendev/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opendev-to-opendev