Glider — multiple CLIs, one prompt

The handoff

One flag at the end of a message, and the work moves.

fix the failing test in internal/foo /claude summarize the last ten commits /cursor-agent refactor this module /agy or open it in its own window /claude:interactive and tell Glider where your project is C:\dev\myapp /workspace

You never leave your terminal

No second window, and no repeating the task. Glider runs the other CLI and puts its final answer into the session you are already in.

Permissions stay switched on

When the other CLI stops for a permission, Glider returns the question with a token. Reply 4472bef1 /cursor-agent:allow and the run continues with exactly that one grant.

The task arrives informed

The other CLI receives your task, your working directory, and the relevant part of this session. It does not start cold and guess.

Glider cannot read that directory out of your CLI, so it asks each session once. Answer with the path, then the flag — and . is a valid path, so . /workspace typed inside the project is the short form. Every later handoff in that session runs there. Set a default on the dashboard and the question arrives with that path ready to accept — it still asks, because a second CLI opened in a different project must never inherit the first project's directory without being told.

Three CLIs today, and the list is data

Claude Code (/claude), Cursor Agent (/cursor-agent) and Antigravity (/agy) are supported now, and each one works in both directions — any of them can send a task, and any of them can receive one.

Which CLIs exist is a YAML file plus a small adapter, never a branch on a name inside the core. A fourth is a new entry, not a rewrite. What adding one takes.

Redirect

The handoff works because Glider is already in the traffic.

A message with no flag is none of Glider's business, and goes on to that CLI's own backend untouched, with that CLI's own credentials. Only a flagged message is claimed. Glider then runs the named CLI itself and hands back what it produced.

Route plate · one turn /claude

you

GLIDER reads the flag

claude
cursor-agent
agy
Not a CLI
ollama · qwen2.5-coder
your own key

↳ no flag · passes through, untouched

answer · permission question

Square = you Hexagon = Glider Triangle = CLI Circle = local model Diamond = BYOK Solid = this turn Hairline = idle route Dashed = pass-through

Start here

Gateway

Point the CLI at Glider with one environment variable or one base-URL setting. Explicit, easy to reason about, and it works with every CLI.

http://127.0.0.1:8080/v1

Works with every CLI · Gateway reference

When a CLI won't cooperate

Transparent

Some CLIs ignore proxy settings entirely. Glider redirects their outbound HTTPS at the operating system level instead, and it catches a session that is already running.

Needs Administrator on Windows or root on Linux, and it matches by process name across the whole machine. Read this first.

The memory

The second CLI knows what the first one already did.

A delegate is a cold process. It never saw your session, and it cannot see the delegate you sent before it. Left alone, the second one asks a question you already answered, or undoes the change the first one made.

So Glider keeps one record for each project. Every turn goes in — including the ordinary ones with no flag, because those are what the instruction refers to. Each delegate is handed the part that matches its own task, and what it did goes back in.

Memory plate · one session 3 turns · 2 CLIs

Square = a turn Hexagon = Glider Bar = the record Triangle = delegate CLI Solid = into the record Dashed = outcome back

The record lives in ~/.glider, never in your repository — it is Glider's bookkeeping, and it would show up in git status forever if it sat in your project. How the record is built

One more thing

Since it is already in the path

Glider can send the cheap turns to a model on your own machine instead of out to the cloud. A rename, an explanation, a format pass — none of them need a frontier model.

/local forces this turn onto your machine
/cloud forces it straight back out
auto a rule ladder decides, and you can rewrite it

Off until you turn it on. The routing rules · Pure local mode

Install

Build it, run it, done

Transparent redirection is already on in the default config, so every supported CLI is caught exactly as it is. You change nothing in any of them, and a session that is already open gets caught too.

bash

# 1 — build go build -o glider.exe ./cmd/glider # 2 — run from the repo root, as Administrator .\glider.exe # claude · cursor-agent · agy are now redirected # dashboard http://127.0.0.1:8081

Administrator is what OS-level redirection costs on Windows, and root is the cost on Linux. Without it, point a CLI at the gateway instead and everything else works the same.

The walkthrough

An empty machine to a working handoff: every command and every template — /claude:interactive, /agy:headless, the permission tokens, the workspace flag — with the result you should see at each step.

Multiple CLIs.
One prompt.

Permissions stay on

Nothing to reconfigure

One flag at the end of a message, and the work moves.

You never leave your terminal

Permissions stay switched on

The task arrives informed

Three CLIs today, and the list is data

The handoff works because Glider is already in the traffic.

Gateway

Transparent

The second CLI knows what the first one already did.

Since it is already in the path

Build it, run it, done

Fund the work

Multiple CLIs.One prompt.

Permissions stay on

Nothing to reconfigure

One flag at the end of a message, and the work moves.

You never leave your terminal

Permissions stay switched on

The task arrives informed

Three CLIs today, and the list is data

The handoff works because Glider is already in the traffic.

Gateway

Transparent

The second CLI knows what the first one already did.

Since it is already in the path

Build it, run it, done

Fund the work

Multiple CLIs.
One prompt.