new v0.18.0 is outClaude in Chrome, per conversation — opt in on the turn that actually needs a browser, and the live MCP servers behind it now show up in the Capabilities sheet. GPT-6 Astra joins the codex line at the frontier tier — opt-in, so gpt-5.6-sol stays the auto-pick. Also shipping: outbound webhooks so notifications reach you away from the desktop, a day view for the Workers tab with a way to skip triage, and faster starts. release notes ↗

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

Five coding agents. One honest window. Some of them work nights.

Overcli wraps claude, codex, gemini, copilot, and ollama in one desktop app — conversations, diffs, worktrees, usage. Then it keeps going without you: flows, scheduled batches, and standing workers you hire, fund, and review. Stop juggling terminals. Start reading the work.

And it runs the cheap steps on cheap models — every flow step names its own — so the bill is not five frontier subscriptions.

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 ]  ·  how much runs without you

Six rungs. You pick how far up you go.

Everything below this line is the same axis seen from different heights: how much of the work you hand over, and how little it asks of you on the way. Nothing here is a mode you have to adopt — the rung you stop at is a decision about trust, and you make it per project, per flow, per worker. Most people live on the first two for a month before they climb.

  1. 01

    A turn

    You ask, you watch it work, you approve the tool calls you want to approve. Nothing happens that you didn't type.

    the whole app
  2. 02

    A rebound review

    The turn ends and a second agent — a different backend, if you like — reviews what just landed without being asked twice.

    rebound ↓
  3. 03

    A flow

    You defined the pipeline. It runs the steps across backends, hands artifacts between them, and stops at the checkpoints you put in.

    flows ↓
  4. 04

    An orchestrated batch

    You point it at a backlog. It investigates, carves out the small self-contained asks, and runs them in parallel worktrees — a PR per finish.

    orchestrator ↓
  5. 05

    A schedule

    The same batch, on a clock, while you're asleep — parked for your approval by default, and never launching more than the cap you set.

    workers ↓
  6. 06

    A worker

    The last thing you were still doing was deciding what the work should be. A worker decides that too — on probation until you say otherwise, out of a pot you approve once.

    workers ↓

The rungs share machinery on purpose. A worker's shift launches a flow; a schedule fires the orchestrator; a flow step can be reviewed by a rebound. There is one engine here wearing five hats, which is why climbing a rung costs you nothing you already learned.

[ 03 ]  ·  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
screenshot codex reviewing an opus turn
A rebound review in a conversation: a block headed CODEX REVIEW lists the checks it considered, then findings rated high, medium and low against the worker subsystem, ending in a verdict. Below it the original model replies, noting that one finding contests a factual claim it made and that it will go and check.
A different backend auditing the turn that just landed — checks considered, findings rated, a verdict. Then the original model answers: most of this is architectural opinion on existing code rather than feedback on my turn, but one finding contests a factual claim I made, so let me check it. That exchange is the feature; neither model gets the last word by default.

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

[ 04 ]  ·  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

[ 05 ]  ·  standing workers

Hire it once. It wakes on its own clock. You review the work.

A schedule fires work you already defined. A worker decides what the work should be — which is the exact point where "it runs on a cron" stops being a good enough answer. So the guarantees come first. Every worker is hired on probation and launches nothing until you approve it; promotion is an explicit act you take. The whole crew spends from a single monthly pot you set once, paid down the roster in order, and a worker below the waterline skips its shift and journals why rather than quietly overspending. Then the clock. Describe the job in prose — attach the spec or the screenshot if you have one — and whichever backend you're signed into drafts the contract and the flow it launches. From there it wakes on its own, reads its journal, proposes what it thinks is worth doing, and files what it produces, keeping a desk, a calendar, a filing cabinet, and a journal you can read.

1

Hire

Write the job the way you'd write it for a person. A drafting turn returns the contract, its tagline, and the flow it will run.

“Sweep our Jira every hour. Propose the small, safe ones. Never touch billing.”

spec.pdfscreenshot.pngbrand.md

→ contract + flow drafted

2

Shift

On its clock it reads the journal, sweeps its sources, and plans — streaming into the desk as it goes.

  • Null deref in /loginpropose
  • Stale Retry-After headerpropose
  • Globex ticketruled out
  • Flaky checkout testpropose
3

Review

A probationary worker parks everything. Read the shift, launch what you like, leave a note on what you don't.

trust probation all parked

☑ a note goes into the journal, not the contract

screenshot a worker’s contract
A worker's Settings tab: the job description it was hired for, its contract — cadence, project, proposals per shift, worktree, approval-required external actions — the probation / trusted / autonomous trust ladder, and the panel that saves the whole job as YAML.
The real thing: a worker's contract. The job it was hired for, the caps it works under, the trust rung it is on — and the panel that writes the whole job out as a .worker.yaml. Moving up a rung is your call; moving down is not.

↓  the roster, mid-morning

5 hired · 1 on probation
Roster
1 working 1 waiting on you 2 filed pot $60 / mo
  • working… Prometheus — the overcli innovator shift 41 planning · Read
  • waiting Chief of Staff — keeps the backlog honest shift 12 3 proposed · review →
  • filed Vantage — the 7am dashboard shift 30 brief.html · 07:02
  • filed Bricklayer — tidies the changelog shift 8 nothing to do · 5 folded
  • idle Slack fielder — answers what it can below the line skipped · out of pot

↪ A worker shows its newest shift, plus any earlier one still holding candidates you haven't reviewed — an empty sweep at 3pm must not hide the one at noon that proposed three things. The rest say how many rows were folded away. Selecting a worker opens what it made in the preview beside its desk, so a daily brief is a click and not a hunt through a folder named after today's date.

screenshot the same desk, on an errand
A worker's desk mid-errand: it explains why three of four open issues should stay open, proposes the one that is genuinely small, and below it a launched flow run — gather-issues, diagnose, write-triage — with the status bar reading one planned, one launched.
The same worker on an errand, deciding that three of four issues should stay open and saying why — then launching a flow for the one that was actually small. 1 planned · 1 launched.

[ 05b ]  ·  the pot

One monthly budget. Paid down the roster.

Every worker used to carry its own cap and nothing carried the sum, so the number that actually mattered — what the whole crew can spend this month — existed nowhere and had never been approved. There is now a single pot, and it is paid down the roster in order: a worker may spend only what is left after everyone above it is funded to its own cap. Dragging a name up the list is a funding decision you can watch land, an unspent cap is held for its worker rather than handed to the hungry one below, and pausing a worker releases its reserve to everyone under it. Lowering the pot squeezes the bottom of the list first, never the top.

pot $60.00 / month · $38.10 spent · $21.90 claimed

  1. 1Prometheus$18.70 / $24
  2. 2Chief of Staff$11.20 / $18
  3. 3Vantage$8.20 / $12
  4. 4Bricklayer$2.00 / $8 · pot ran out
  5. waterline
  6. 5Slack fielderskips & journals why

The arrows stay, revealed on hover or focus — a drag-only list can't be reordered without a mouse. An upgrading install starts with a pot equal to the caps it already had, so day one behaves exactly as it did before and the pot only begins to bite when you lower it. A dry pool notifies once for the whole roster, not once per starved worker.

A worker is a file you can hand to another team. Its Settings tab carries the job as YAML — readable on screen before you send it, saveable as a .worker.yaml, with the flows it launches embedded whole rather than merely named. What deliberately doesn't travel is everything that is a record of what happened here: the id, the hire date, the shift history, the project path, and above all the trust level. An imported worker always lands on probation, because trust is earned against the person who will review the work — and a file that could arrive pre-trusted would be a way to hand somebody a worker that launches runs unattended on day one.

a job description in · a contract and a flow out · its own clock · probation until you say otherwise · one pot, paid down the roster

[ 05c ]  ·  the orchestrator

Point it at a backlog. It carves out the work.

A producer turn investigates your MCP sources — Jira, GitHub, Linear, Zendesk, Sentry, ProductBoard — and pulls out small, self-contained asks. Map each to a flow, hit launch, and Overcli runs them side by side, each in its own git worktree, opening a PR as it finishes. A flow that pauses for a checkpoint 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

screenshot one ask, fanned out
The Orchestrator tab in three numbered stages: a producer turn investigating the project's test coverage and reporting what it found and what it deliberately dropped; eight candidate asks, each sized small or medium and mapped to a flow; and a flow-runs panel. A footer sets the parallel cap to two and offers to open a PR when each finishes.
The producer's turn is the whole feature, and it is worth reading: it reports what it found, then a paragraph headed “What I deliberately dropped.” — the two big stateful panes it refuses to touch, because standing up a render harness "is a design decision, which is your call, not an autonomous run". Eight asks came out, each sized and mapped to a flow, and nothing launches until you press the button — two at a time, a PR per finish.

↓  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.

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

[ next ]  ·  services coming soon

Run the whole stack. Point it at any branch.

A Services pane that starts, stops, and watches every service a workspace runs, each bound to the checkout or worktree it should run from. When a flow finishes on a branch, the stack can follow it there. It's built and merged, and ships in the next release.

Services payments-platform all running problems Start group

REST services ⎇ feat/cost-ceiling 3 of 3 running

  • api-gatewayspring boot:8080ready · http /actuator/health
  • billing-svcspring boot:8081ready · 14 s
  • ledger-coregradle:8082waiting for log "Started LedgerApplication"

Processors 1 module, 3 ways

  • payment-processormaven:9001ready
  • refundscopy · --mode=refunds:9002ready
  • retriescopy · --mode=retries:9003stopped

Front ends 1 problem

  • webvite:5173ready
  • notificationsnode:8090port held by another stack

:8090 is held by notifications in checkout-flow, running from worktree feat/webhooks. Starting here would take it from a run you may not be watching.

Run alongside on :8091 Stop the other one Cancel
ledger-core ⌕ placeholder 2 error 5 warn Raw

INFO09:14:02.118maino.s.b.StartupInfoLoggerStarting LedgerApplication using Java 21

INFO09:14:03.402mainc.z.h.HikariDataSourceHikariPool-1 - Start completed.

WARN09:14:03.977maino.s.c.PropertySourceCould not resolve placeholder 'ledger.db.ip', using default

INFO09:14:05.260maino.s.b.w.e.tomcatTomcat started on port 8082 (http)

Select lines to ask your AI about them

A flow finished on feat/cost-ceiling

Move this workspace's services to that branch? Each one moves to its own repo's worktree.

  • 4 services move and restart
  • web skipped: pinned to main
  • infra skipped: no such branch in that repo
  • local config linked in: application-local.properties, .env.local
Move 4 services Not now
Import the setup you already have
Tiltfiles, compose files, Procfiles, and IntelliJ or VS Code run configurations come in as they are. Shared options are factored out, and credentials move into your keychain instead of ten copies of one password.
Works out how a checkout boots
With nothing to import, it reads the build files, per module in multi-module Gradle and Maven builds, and shows why it decided each thing so you can check it before trusting it.
One owner per port
Several flows can run on different worktrees at once. When two stacks want the same port, you get a choice to run alongside or stop the other one, not a silent takeover.
A stack that follows the branch
Move a whole stack to a branch or worktree in one step. Gitignored local config from the main checkout is linked in, so a service doesn't fail on a missing placeholder. It's offered when a flow lands, never done automatically.
Output that reads like the terminal
Colours come through, JVM lines split into level, time, thread, and logger columns, and you can search, filter by level, or switch to Raw. Services start in dependency order, and each one is ready when its HTTP, port, log, or command check passes.

[ 06 ]  ·  what it costs to run

Every step names its own model. Most of them don't need the expensive one.

A flow step that greps a repo, drafts a changelog or files a ticket does not need a frontier model to do it. Point the premium judgement at a premium model and the bulk at a cheaper — or local — one, and the clock gets cheap enough to leave running. This is not a dial you tune afterwards; it is how a flow is written in the first place.

The cheapest agent is still the one on your own machine: ollama is a peer of the other four backends, not a lesser fifth, and every place the app picks a model is a place you can pick a local one. That matters most at the top of the ladder, where a worker on an hourly clock is the one thing here spending money while nobody is watching.

the flows we ship  ·  model mix

86 of 130 steps

run on something other than the expensive model.

cheaper & local 86 premium 44

the mix
sonnet 62  ·  opus 44  ·  gpt-5.6-terra 17  ·  fable 7
downgrades
near a rate or cost ceiling: opus sonnet, cloud local ollama, rather than stopping
the ceiling
one monthly pot for the whole crew, paid down the roster in order

[ 07 ]  ·  what's in the box

Built by engineers obsessed with their dev environment.

Every surface here 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. They fall into four groups: the window you read the work in, the machinery underneath it, the growing pile of work that runs itself, and what is left when there is no repo at all.

the window

What you look at while the agent works — the surfaces that made a terminal a bad place to explore.

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.

Reasoning effort is set per backend, because the word means something different to each of them — and turning it up lands on the turn you are watching, not the one after it. Claude's /design canvas and its Artifact tool work here too, with permission cards that summarise what actually leaves the machine rather than showing you truncated raw JSON.

02

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.

03

Permission & approval, first-class

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

04

File editor, right there

Syntax highlighting, line-range highlighting, HTML & Markdown preview tabs for previewable files, and a one-click download out of the preview pane beside the file's own path. No context-switch to VS Code to check the agent's work.

An .html report previews the way it does in a browser — the CDN React + Tailwind page our dashboard flows ask agents to write actually paints, and a link in it opens in your browser. The frame can still neither phone home nor read a file it wasn't shown.

05

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.

06

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.

07

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.

08

Keyboard first

⌘P file finder. ⌘\ toggles the sidebar. ⌘, opens settings. ⌘1⌘9 jumps between open files. It is not a website; it is a tool.

09

⌘K finds anything

One input over the whole app — chats, agents, runs, flows, workers, projects, workspaces, archived threads and app actions. ↵ goes where the subtitle says it goes — a worker row arrives at that worker's desk, ⌘↵ opens its contract. A quick switcher that only indexed conversations meant everything else could be found only by knowing which tab it lived behind, which is the opposite of the point.

Ranking is a pure module with its own tests, because "an exact project name should beat a chat that merely mentions the word" degrades silently — a test catches it, a screenshot doesn't.

10

A sidebar you navigate by what you were doing

The old list rendered where things live; people navigate by what they were doing. Stream is one newest-first list of chats, agents and runs together, with the owner printed once above a run of consecutive rows rather than on every one, so going flat doesn't cost you the sense of which repo you're in. Places keeps the tree for when the question really is where something lives — two layouts rather than a toggle, because they answer different questions.

"Active" is now Working on, and momentum — turns per hour, decayed — earns a row its slot, so a thread you've been forty turns deep in all morning outranks a message you fired off and forgot. Anything untouched for two days rolls up under a dashed count line in place: not hidden, which makes people hunt, and not archived, which needs a decision and an undo. Search still reaches inside it.

the machinery

What sits under the window: the CLIs, the credentials, the worktrees, and the numbers that say what it cost.

11

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.

12

Health badges

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

13

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.

14

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.

15

Local model dashboard

A proper UI for your Ollama install: browse a hand-checked catalog of 46 tags, 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.

It also tells you when the copy of Ollama you have is one you shouldn't still be running — read off the binary even with the server stopped, and escalated to a security finding once you're several minors behind — and when the API is answering on a non-loopback address, where anyone on your network can pull and delete your models. Nothing upgrades itself: you get the command, in a Terminal you can watch.

16

Usage dashboard

Rolling 5h / 24h / 7d stats, broken down by backend, model, and project. Quotas are read from the CLIs themselves rather than estimated, so the number you're looking at is the one the provider is counting. Know what you're burning before the invoice tells you.

17

Where the turn went

A Timing tab splits every turn into model time and tool time — and the tool share is split again by tool name, with a legend giving each tool's busy time, call count, slowest single call, and errors. Forty seconds in tools is a very different afternoon depending on whether it was one Bash build or thirty Read calls.

Tools are ranked slowest-to-fastest on a red → amber → green ramp, so the expensive one is findable without reading a number, and nothing lands near the blue the model's share is drawn in. Parallel calls overlap, so widths are wall clock and the legend is what each tool actually spent.

18

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.

19

Four speeds, one ladder

Full, Swift, Turbo and Warp, on every hosted backend. Swift keeps answers concise and consolidates independent tool work. Turbo enables each backend's speed-first behaviour while keeping the model you picked. Warp also drops to that backend's fast tier — Sonnet for Claude, Luna for Codex, Flash-Lite for Gemini, Haiku for Copilot. Colour-coded icons make the ladder readable without opening a menu.

Leaving Warp restores the model and effort you were on rather than stranding you on the fast tier. Ollama stays manually controlled, because a local model's speed is your hardware's business and not a setting.

work that runs itself

Everything that keeps going once you stop typing — ordered by how much you hand over, and how little it asks of you.

20

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.

21

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.

22

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. see it above ↑

23

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.

24

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 ↓

The library groups by provenance — starred, yours, this project, installed — and its search reaches the registry as well as your disk. When nothing matches anywhere, the search text becomes the brief for an AI draft that opens in the editor rather than running unseen.

25

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 above ↑

The tab has two shapes. Composing keeps the numbered panes; once nothing is being composed the ledger takes the full stage, and every count in its bar is a filter — a number you can't act on is a run row given up for decoration.

26

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 — by default 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.

Three trigger kinds: an interval, a cron expression for the cadences no preset covers, or onFlowComplete — "when the nightly scrape succeeds, launch triage" — which reacts to runs it did not launch, bounded at a depth of five.

For a producer you have learned to trust, a schedule can launch its own proposals — but the cap is required, not optional. The first N go in producer order, which is best-first, and everything past it stays parked with a note saying why. A missed schedule coalesces or skips rather than stampeding on wake, and "Run now" is a test drive — it never re-anchors the cadence.

27

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.

28

Headless, and deployable alpha

The same flow YAML runs from an overcli command line with no window — one shot in CI, or on a box you own — and a flow or a worker's whole cadence deploys to GitHub Actions or Jenkins as a generated pipeline. There is no second runtime: the app and the CLI drive the same runner and the same engine, so a flow that worked at your desk works on the runner.

In alpha: runnable today, but the interface can still move. Everything else on this page is shipped.

29

A risk scan before it runs

A flow is a set of instructions that later runs with real tool access, and the only checks used to be an integrity hash and a structural validation — nothing read the instructions. Every step's prompt override and tool list is now scanned for credential-file references and for network egress declared as a local effect, on the registry path and on every hand-authored save.

Nothing is blocked: a heuristic that refused a legitimate install would be worse than the warning it replaces. A high-severity finding pauses the run instead, under its own reason. Separately, bash, websearch and webfetch stopped counting as local — an unattended worker with no grant for outside actions cannot run them, and a step's declared tool list reaches the CLI as a real allowlist rather than a label.

30

Standing workers

Hire a persona that wakes on its own clock, decides what is worth doing, and files what it produces. Describe the job in prose — with a spec or a screenshot attached if you have one — and whichever backend you're signed into drafts the contract and the flow it launches. Every worker keeps a desk, a calendar, a filing cabinet, and a journal, and starts on probation: nothing runs until you approve the batch. see it above ↑

A shift streams into the desk as it is worked, and any turn opens in a reader with a find box — a sweep across seventy tickets is a document, not a chat bubble. Leave it a note and the worker reads it before planning the next shift, because the record of what it did is not a thing you edit.

The tab opens on a work queue banded Running now, Needs you, Finished today — status is not a column you sort by, it is what a row is, and a single time-ordered table buries the two rows with a decision waiting on them under eight that need nothing from anyone.

31

One pot, paid down the roster

Eight workers at $10 a month is an $80 exposure nobody ever approved. The crew now draws from a single monthly pot, paid down the roster in order: a worker may spend only what is left after everyone above it is funded. Drag a name up and that is a funding decision you can watch land. Pausing one releases its reserve to everyone below it.

A worker's unspent cap is held for it, so the one that runs your morning can't be starved by the one that tidies changelogs. Shifts below the waterline skip quietly and journal why, and a dry pool notifies once for the whole roster.

without a repo

The same app for people who have documents rather than code — added in 0.16, and the reason "is this for me?" now has a second answer.

32

Everyday projects

Describe what you want and Overcli scaffolds a folder under ~/Documents/Overcli Projects/, prepares an undo history, and opens a conversation pointed at it. No path decision, no file dialog, and git is never mentioned. A folder you already have joins the same way — the explorer's dead end is now a Turn on history button.

33

Documents, not a file tree

Everyday projects open into a card grid with real file-type icons, human names, and edited 2 days ago — one folder at a time, with a breadcrumb. Code projects keep the explorer tree, because a nested column of monospace paths is right for a repo and wrong for a folder of Word documents. Drag files in from Finder; the project's own .git never appears.

.doc, .docx, .xls, .xlsx, .ppt and .pptx preview with no Office installed. Three converters are raced rather than queued — LibreOffice, Quick Look, Office COM — so a hung LibreOffice no longer costs thirty seconds. The result renders sandboxed with no scripts and no outbound channel, because a document someone emailed you is untrusted input.

34

Auto-save, and every version back

Documents save themselves a few seconds after you stop typing, because nobody outside software thinks about saving. A version is captured whenever something finishes, and Earlier versions lists them in plain language with a Restore button.

Restoring moves forward rather than rewinding — the current state is committed first and the restored one on top — so putting the folder back is itself undoable. Ask for a change in one line at the foot of any document and you get a before/after diff with Keep changes, Undo it or Try again; highlight a passage first and only that passage is sent.

[ 08 ]  ·  day to day

Most days, it's just this.

Everything above is what Overcli can do when you hand it the keys. This is what it is the rest of the time: a conversation with a diff attached, and a number at the end of the month telling you what that came to. Both are real screens, not renders.

screenshot a conversation, with the work attached

A conversation in the Chat tab: the model answers a question about the project with headings, a table of the three-process layout, and inline file references; the header carries fork, plan, effort, turbo and rebound controls; a changes bar above the composer reads one file changed, plus 395.
The header is the whole control surface — fork, plan, effort, turbo, and which backend will rebound-review the turn. The bar above the composer counts what has been touched so far, and the status line at the bottom is the context window, the model, and the session id. Nothing is hidden behind a menu you have to go looking for.

screenshot and what it came to

The Usage tab: all-time sessions, turns, tokens and lines changed; a Limits Right Now row showing Claude on a subscription, Codex on Plus and Gemini estimated, each with its window and reset time; and a model mix bar splitting spend across frontier, thinking, standard and fast tiers.
Quotas come from the CLIs themselves where they report them — note the subscription, plus and estimated labels, and the line saying which is which. The model mix underneath is where the money actually went, by tier rather than by name.

[ 09 ]  ·  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.

┌─ [ 10 ]  ·  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?

The app is free. Overcli is open source under Apache 2.0 — no licence to buy, no per-seat pricing, no paid tier holding features back, and no invoice from us. What you do pay for is model usage on the agent subscriptions you already have, which is why every flow step names its own model and why the crew draws from a pot you set.

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. If you have none of them yet, the start screen walks you through it and keeps watching — install a CLI in a terminal and the app unblocks itself without a restart.

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 in the app. 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.

Can it run in CI, without the desktop app?

Yes — but it is alpha as of 0.17, so treat it as something to trial rather than to depend on this quarter. The same flow YAML runs headlessly from an overcli command line — one shot in CI or on a machine you own — and a flow or a worker cadence can be deployed to GitHub Actions or Jenkins as a generated pipeline. There is no second runtime to certify: the app and the CLI drive the same runner and the same engine, so what you reviewed at a desk is what executes on the runner. It still authenticates the same way, through the CLIs and credentials you already provision.

What stops a flow or a worker doing something we didn't sanction?

Three things. A risk scan reads each step's prompt override and tool list before you install, save or run it, looking for credential-file references and for network egress declared as local — a high-severity finding pauses the run. A step's declared tool list is enforced as a real allowlist rather than trusted as a label, so a step that declares nothing no longer keeps everything. And bash, websearch and webfetch require the same approval as pushing or sending, so an unattended worker without a grant for outside actions stops rather than proceeding.

Do we need a git repository to use it?

No — not since 0.16. Everyday projects are folders of documents rather than code: Overcli scaffolds one, keeps an undo history for it, and never mentions git in the process. The history underneath is an ordinary repo, so nothing is locked in and any other tool can read it, but nobody is asked to learn it. A folder you already have can be brought in with one button, and any project can be switched between everyday and code without moving a single file.

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 a standing worker spend money or push code without us?

Not without you saying so. Every worker is hired on probation — it may propose, it may not launch, and promoting it is an explicit act you take. The whole crew draws from a single monthly pot you set once; a worker below the waterline skips its shift and journals why rather than quietly overspending. A worker imported from a .worker.yaml always lands back on probation regardless of what the file says, and a shared worker can never ask to run in your working copy.

Can an agent-written report in the preview reach the network?

No. A rendered document preview may run the CDN script it was built from and nothing else — no fetch, no XHR, no sendBeacon — and inlined images, fonts, and stylesheets stop at an allowlist of previewable types, including through a stylesheet's own imports. A dashboard that calls a live API shows no data instead of fetching it, which is the trade for a preview that can't exfiltrate what it can see.

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.

[ 11 ]  ·  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]