new v0.13.2 is outscheduled runs live inside Flows, the orchestrator parks proposed batches for your approval, interval triggers take days and an active window, and release notes open once after an update. release notes ↗

┌─ [ 01 ]  ·  a desktop app for people who live in coding CLIs

Five coding agents. One honest window.

Overcli wraps claude, codex, gemini, copilot, and ollama in a single desktop app — conversations, diffs, git worktrees, and usage stats in the same place. Stop juggling terminals. Start reading the work.

over·CLI  — a GUI that sits over your CLIs. Yes, that's the name.

  • macOS
  • windows
  • linux
  • Electron · React · TypeScript

add a rate limiter to /api/login

Claude CLI opus 5 [1m]
⑂ fork ▾ ⊘ Bypass (dangerous) ⚡ Effort ▾ ↥ rebound
Writing…
Message… (type / for commands)
9 turns · ctx 34% · 341k/1.0M · claude-opus-5[1m] · 63329119

A live peek. The three lanes are actually streaming.

[ 02 ]  ·  inside the window

Built by engineers obsessed with their dev environment.

Every surface below exists because somebody got annoyed that it didn't. No feature-ballast, no PM checkboxes — just the pieces you miss the moment you pop back into a raw terminal.

01

Multi-backend chat

Claude, Codex, Gemini, Copilot, and Ollama — five stream parsers, one consistent UI. Markdown. Syntax highlight. Streaming tokens. Cloud or local, same window.

02

No new subscriptions

Overcli sits on top of the CLIs you already use, with the auth they already have. Your Claude Pro, your ChatGPT plan, your gcloud creds, your GitHub Copilot seat — whatever claude, codex, gemini, and copilot are signed into is what overcli runs through. Local ollama for the rest. No API keys to manage. No new bills.

03

Workspaces — projects of projects

Group related repos into a single workspace and every agent inherits the map: it knows the projects belong together and navigates between them naturally. Ask for a change that spans api-gateway and billing-svc and the agent edits both, runs both test suites, and shows one review. The feature that makes polyrepo feel like monorepo.

04

Silent agents

Long-running background agents that live next to your work. A doc-writer that keeps /docs in sync as the code changes. A PR-reviewer that quietly comments on every pull request the moment it opens. No Slack pings. No dashboards. Just work getting done.

05

Rebound reviews

After every turn, fire a second agent — on a different backend if you like — to review what just landed. Thinking blocks visible, round counter included. Collaboration mode loops rounds until the reviewer stops finding things to fix.

Note: Copilot can't be a reviewer yet — its CLI doesn't read prompts from stdin. When it's your primary, overcli routes the review to claude/codex/gemini and shows a "Routed via X" chip so it's not surprising.

06

Tool cards, not wall-of-text

File edits render as diffs. Bash lives in a terminal block. Reads, writes, todos each get their own card — so you can actually see what the agent did.

07

Permission & approval, first-class

Claude permission prompts and Codex approval cards (exec + apply_patch) are proper UI elements — not modals interrupting the flow.

08

History from disk

Loads prior transcripts straight out of ~/.claude/projects, ~/.codex/sessions, and ~/.gemini/tmp. Nothing gets re-invented; we just read the files you already have.

09

File editor, right there

Syntax highlighting, line-range highlighting, HTML & Markdown preview tabs for previewable files. No context-switch to VS Code to check the agent's work.

10

Extensions browser

One searchable pane for everything the CLIs can do — slash commands, sub-agents, skills, plugins, MCP servers — unified across Claude, Codex, Gemini, and Ollama. Rescan on demand; no YAML to edit.

11

Keyboard first

⌘P file finder. ⌘\ toggles the sidebar. ⌘, opens settings. ⌘K jumps conversations. It is not a website; it is a tool.

12

Agent worktrees

Create, update, rebase, merge, push, or remove a git worktree from inside the conversation. Agents work in isolation; you merge when you like what you read.

13

Changes bar

A live +/− rollup sits above the composer, counting everything the agent has touched this turn. Click to expand the diff, click a file to jump to it. The commit badge is one click away.

14

Local model dashboard

A proper UI for your Ollama install: browse the catalog, filter by maker or country, pull and delete with one click, watch server logs live, and see a readout of the GPU you're actually running on.

15

Usage dashboard

Rolling 5h / 24h / 7d stats, broken down by backend, model, and project. Know what you're burning before the invoice tells you.

16

Smart downgrades

As you approach a rate limit or cost ceiling, Overcli can step you down automatically — opussonnet, cloud → local ollama — so the next turn still ships. Configurable per project. Off by default.

17

Health badges

Per-backend status pills: ready, unauthenticated, missing, error. The app tells you which CLI is broken before you try to use it.

18

Colosseum

Fire one prompt at every backend at once. Watch the answers land side by side, compare the diffs, keep the winner, discard the rest. The fastest way to tell which agent actually understood the task. see it below ↓

19

Flows

Reusable, open-source workflow templates. Chain steps across backends — research on a cloud model, build on a local one — with typed inputs and outputs handed between them, and a human checkpoint anywhere you want one. 35 ship in the box; define your own in a few lines of YAML. see them below ↓

20

Orchestrator

Point one producer turn at your backlog — it investigates over MCP (Jira, GitHub, Sentry, Zendesk…) and carves out small, self-contained asks. Map each to a flow and launch the whole batch in parallel, each in its own git worktree, a PR per finish. A paused checkpoint frees its slot so the rest keep moving. see it below ↓

21

Scheduled runs

A schedule is a trigger on work you already defined, so it lives inside Flows rather than as a fourth place to launch from. Fire a flow on a cadence, or point a schedule at the orchestrator and have it park what it finds — every item lands proposed and nothing launches until you approve it. Intervals take days and an active window, so "every hour, weekdays, 8–5" is one trigger and not twenty-four.

A missed schedule coalesces or skips rather than stampeding on wake, and "Run now" is a test drive — it never re-anchors the cadence.

22

Flow watch

When a flow finishes, it doesn't have to stop caring. Put a run in watch and it keeps an eye on the thing it touched — the PR, the Jira ticket, the Slack thread — answering follow-up questions with the full context of what it just did. A cheap detect pass polls every tick; the real model only wakes when someone actually asks something.

It tends, it never re-does. If a comment asks for real work — a code change, a re-run — the watcher flags you instead of touching the repo, and pings you on the desktop.

23

Install MCP once, everywhere

Add a Model Context Protocol server in one place and Overcli writes it into every CLI's config in the exact format each one wants — ~/.claude.json, ~/.codex/config.toml, ~/.gemini/settings.json — dropping a .bak first. Pick from a curated catalog with one-click install, or copy a server you already have on one backend across to all the others. No hand-edited TOML, no format-juggling.

[ 03 ]  ·  flows model

Define. Verify. Approve. Ship. Learn.

Flows are reusable, open-source workflow templates built into Overcli. Available to everyone through the same public repo and desktop app: define a pipeline once, run it consistently across projects, and keep the full audit trail. And the work doesn't end at the diff — a finished run can stay on watch, fielding follow-up questions on the PR or ticket with the context it built and flagging you the moment something needs real work.

your request researchclaude · opus 5 designclaude · opus 5 buildollama · qwen2.5-coder diff

Participants

ThinkerClaude · opus 52 steps
LocalOllama · qwen2.5-coder1 step

Steps

1. researchreads: your request

Role: research / gather context

Produces: research.md

2. designreads: research.md

Role: design / implementation plan

Produces: plan.md

3. buildreads: plan.md

Role: implement / run checks / emit diff

Produces: final.diff

↓  the same flow, running

Research + design + build DONE
1.2k thinking 842k fast +96−12 5 files
1 research 2 design 3 build

Add a token-bucket rate limiter to /api/login — 100 req/min per IP, return 429 with Retry-After.

steps in this thread ✓ research ✓ design ✓ build

what each participant produced

  • research.mdfrom research6,204 chars“Where /login is handled + the existing middleware chain”
  • plan.mdfrom design8,710 chars“Plan: token-bucket limiter in the auth middleware”
  • final.difffrom build+96 / −12 · 5 files“Limiter, config, and tests”
▸ flow step Step: build · implementer

↪ Picking up this thread — switched to ollama/qwen2.5-coder for the build step. Reads plan.md, emits final.diff.

inputs plan.md

+ src/auth/rateLimiter.ts
+ const bucket = buckets.get(ip) ?? refill(ip);
+ if (bucket.tokens < 1) {
+   res.setHeader('Retry-After', bucket.resetIn);
+   return res.status(429).end();
+ }
- // TODO: throttle /login
✓ type-check clean · 18 tests pass

↓  same run, still open — steps shipped, now watching for follow-up

Research + design + build WATCHING
detect every 5m 1 answered 0 escalations
1 research 2 design 3 build watching

The flow doesn't close when the diff lands. The same run stays open in a watch phase — every step above already complete, every artifact still in context — now fielding follow-up on the work it just shipped. A cheap detect pass polls; the full model only wakes when someone actually asks something. It never touches the repo.

▸ watch tick detect → answer · claude · haiku

↪ New comment from @dana on the PR: “does the limiter count failed logins too?” — answered inline, grounded in plan.md: yes, every request to /login draws a token before auth runs, so failures count.

reads PR thread · plan.md · final.diff

▸ watch tick escalate · flagged for you

@sam asked to bump the limit to 200/min. That's real work, not a question — so the watcher left it alone and pinged you on the desktop instead of editing the code.

mix providers · mix models · cloud thinking, local speed · tends the work after the diff

[ 04 ]  ·  orchestrator

Point it at a backlog. It carves out the work. Flows run in parallel.

The Orchestrator turns a pile of tickets into a batch of running flows. A producer turn investigates your MCP sources — Jira, GitHub, Linear, Zendesk, Sentry, ProductBoard — and pulls out small, self-contained asks. Map each one to a flow, hit launch, and Overcli runs them side by side, each in its own git worktree, opening a PR as it finishes. When a flow pauses for a human checkpoint it frees its slot, so the rest of the batch keeps moving.

1

Ask

A producer turn investigates with your MCP tools — read-only, never editing — and proposes candidates.

“Find small, safe bugs in my open issues.”

github·searchjira·listsentry·issues

→ 6 candidates

2

Map

Each ask maps to one flow + a base branch. Take the producer's suggestion or override per row.

  • Null deref in /logindebug-logs
  • Stale Retry-After headerdebug-logs
  • Typo in onboarding docdocs-from-code
  • Flaky checkout testflaky-test-hunter
  • + 2 moremapped
3

Run

Launch. Flows run in parallel, each in an isolated worktree — up to N at a time, your call (1–8).

run at most 2 at a time

☑ open a PR when each finishes

↓  one batch, mid-run

payments-platform
Batch · 6 asks
1 done 2 running 1 paused 2 queued max 2
  • done Typo in onboarding doc docs-from-code PR #418 · +4 −1
  • running… Null deref in /login debug-logs step 3/4 · build
  • running… Stale Retry-After header debug-logs step 2/4 · diagnose
  • paused Flaky checkout test flaky-test-hunter checkpoint — freed its slot · continue →
  • queued Deprecated API in billing analyze-stack-trace waiting for a slot
  • queued Missing index on orders migration-plan waiting for a slot

↪ The paused checkpoint doesn't stall the batch — it freed its slot, so the next queued ask pumps in behind it. Continue it from the Flows tab whenever you're ready.

[ 04b ]  ·  on a cadence

Run it every morning. Park what needs a human.

A schedule is a trigger on work you already defined, so it lives inside Flows rather than becoming a fourth place to launch from. Point one at a flow and it runs. Point one at the orchestrator and it investigates your sources — then parks what it found. The producer decides how many items exist, so dispatching that unattended is the one thing a schedule must not do.

  • Morning triage propose a batch weekdays · 08:00 5 proposed
    • SR-12 Null deref in /login analyze-stack-trace
    • SR-12 Flaky checkout test flaky-test-hunter
    • SR-12 Deprecated API in billing migration-plan
    • + 2 more
    Review & pick Launch all Discard
  • Nightly dep audit run a flow every day · 02:00 running · SR-31
  • Docs drift check run a flow every 1h · weekdays 08–17 in 41m

Every occurrence is numbered [SR-n] — a scheduled prompt is fixed by definition, so the twelfth morning run would otherwise be titled exactly like the first. A schedule missed while the app was closed coalesces into one catch-up run or skips; it never stampedes on wake. Run now is a test drive: it produces a real run but leaves the cadence exactly where it found it.

backlog in · self-contained asks out · parallel, isolated worktrees · a PR per finish · on your cadence, parked for approval

[ 05 ]  ·  rebound reviews

Ship a turn. Bounce it back. Let a second agent tear it apart.

A rebound isn't a pipeline — it happens in the conversation. After a turn lands, a reviewer agent reads the actual diff and writes back, round after round. You watch it concede, push back, and re-check in collaboration mode until it stops finding things. The reviewer can stay in the same family — a heavier thinker checking a faster model's work — or be completely independent, like Claude reviewing what Codex just shipped. A second pair of eyes that doesn't share the first one's blind spots.

opus 5 copy · copy raw

Added the rate limiter and a test. stop() now kills the collab client instead of a best-effort interrupt(), and the notification / request / close handlers check codexCollab.get(id) === session before acting. Type-check clean, all 332 tests pass.

✓ 257.2s · in 62 · out 45,680 · cache 6,012,782

codex · collab · round 4

codex · gpt-5

Looks fine overall. Killing and removing the persistent collab session on stop() closes the cross-round race I flagged last time.

Only nit: the comment slightly overstates the close change — it guards map eviction, then still inspects session.active. Fine in practice, but the wording is loose.

opus 5 copy · copy raw

Conceded — the wording was loose. No code change needed; just a more accurate restatement of what the close handler actually guards.

✓ 5.8s · in 68 · out 45,877 · cache 6,194,396

codex · collab · round 5

codex · gpt-5 ✓ clean

Looks fine. The clarification matches the code — no issue, just tighter wording. Nothing left to flag.

One rebound, many shapes — pick a preset, or open Custom… for the dials.

  • OffNo secondary review.
  • Half-finished work checkSame model hunts stubs, TODOs, and missed branches. Cheap. Code-change turns only.
  • Security reviewA smarter model reads the diff for vulnerabilities. Code-change turns only.
  • Cheap-and-paranoidA cheap primary writes; a smart reviewer checks every turn.
  • Skeptical user"Did it actually do what I asked?" Catches scope creep, every turn.
  • Design reviewA smart model weighs architecture, abstractions, and approach.
  • Independent second opinionA different CLI entirely, for fully independent reasoning.
  • Custom…Set reviewer CLI, model, persona, and mode by hand.
reviewer cli
claude (same as primary) · codex · gemini · ollama
mode
review — flag → fix → verify, no loops  ·  collab — ping-pong until the budget's spent
reviewer model
cli default · cheap (sonnet) · smart (opus)
persona
none · half-finished · security · critic · skeptical user · design

same conversation · round after round · until it's clean

[ 06 ]  ·  colosseum mode

One prompt. Five agents. One diff to rule them.

Fire the same task at every backend in parallel — cloud or local. Watch the answers land at their own pace. Compare the diffs side by side. Pick the best. Keep it. Discard the rest.

I

claude

opus 5

0.0s

          
touched 3 files +18 −4
II

codex

gpt-5

0.0s

          
touched 2 files +22 −3
III

gemini

2.5-pro

0.0s

          
touched 2 files +14 −1
IV

copilot github

gpt-5

0.0s

          
touched 2 files +17 −2
V

ollama local

llama3-8b

0.0s

          
touched 1 file +11 −2

same prompt · five answers · one diff

[ 07 ]  ·  why overcli exists

Move fast without losing the thread.

Most coding-agent tooling optimizes for the demo. Overcli optimizes for the afternoon of the fourth day — when you've shipped three features with it, hit a weird edge, and need to understand what happened without breaking stride. The whole point is to keep you moving: a clean local environment where nothing is hidden, so you never stop to untangle what the agent did.

Diffs you can read, tool cards you can audit, permission flows you can follow, history that came from a file on disk. No invented abstractions. No hidden state. If something is on screen, there's a line of code you can find that put it there. That's the bar.

Written & maintained by Lionel Farr and Owen Farr. Open-source — contributors, issues, and PRs welcome.

┌─ [ 08 ]  ·  before you install it at work

Questions your security team will ask.

Short answers, and the source is right there if you'd rather read it than take our word for it.

What does it cost?

Nothing. Overcli is free and open source under Apache 2.0 — no licence to buy, no per-seat pricing, no paid tier holding features back. It drives the agent subscriptions you already pay for, so there is no new invoice from us and none from anyone else either.

Which agents does it actually drive?

claude, codex, gemini, copilot, and ollama. Overcli drives the CLIs you already have installed and signed in — it is a window over them, not a reimplementation of them.

Do we need to provision API keys?

No. Overcli uses the auth those CLIs already hold — a Claude Pro plan, a ChatGPT plan, gcloud credentials, a GitHub Copilot seat, or a local ollama. No API keys to issue, no new billing relationship, no per-seat pricing.

Where does our code go?

Wherever the CLI you picked was already sending it. Overcli adds no server, no proxy, and no account of its own — it runs the same binaries on the same machine with the same credentials. Pick ollama and nothing leaves the box at all.

Is there any telemetry?

None. No analytics, no crash reporting, no phone-home on launch. Conversation history is files on disk you can open in any editor, and you can verify all of that in the source.

What is an agent worktree?

Each agent works in an isolated git worktree instead of your checkout, so you can rebase, merge, or throw the whole attempt away from inside the conversation. Your working tree is never the experiment.

Can we audit or build it ourselves?

Yes — Apache 2.0, and the repo builds with npm install && npm run dist. macOS releases are Developer-ID signed and notarized; Windows isn't code-signed yet, so SmartScreen may still warn.

[ 09 ]  ·  grab a build

Signed, notarized, and real.

Overcli is in beta, but the macOS builds are now Developer-ID signed and notarized by Apple — they open on a double-click, no right-click ceremony. Windows isn't code-signed yet, so SmartScreen may still flag it. Either way the source is right there; build it yourself.

macOS arm64 + x64 .dmg  ·  .zip ~ 120 MB [download]
Windows x64 + arm64 NSIS installer ~ 110 MB [download]
🐧 Linux x64 + arm64 .AppImage  ·  .deb ~ 130 MB [download]