What Glider does
Glider does these three tasks:
-
It sends a task to a different CLI. Type
refactor this module /agyin Claude Code, and Antigravity does the task. You can do this from any supported CLI, to any other one. You stay in one terminal. If the other CLI asks for a permission, Glider shows the question in your own session. → Delegation -
It sends work to a local model. Simple tasks such as a rename, an
explanation or a format operation can go to Ollama. This keeps your cloud tokens for
the difficult work, which stays on the cloud backend. To select the route yourself,
use
/localor/cloud. → Routing - It shows you what occurs. The local dashboard shows each intercepted request. It also shows the route decision and the cause of that decision. → HTTP API
How Glider gets between the CLI and the backend
There are two methods. You can change the method later:
| Mode | What you must do | When to use it |
|---|---|---|
| Gateway | Point the CLI at Glider. Use an environment variable or a base URL setting. | Use this mode first. It is simple and easy to understand. |
| Transparent | Nothing. Glider intercepts the traffic in the operating system. | Use this mode for a CLI that ignores the proxy settings, or for a session that is open. |
Transparent mode needs no help from the CLI. It operates on a CLI session that is already open, because it redirects the packets. The CLI does not change its own settings. This mode needs Administrator permission on Windows, or root permission on Linux. It applies to the full machine and selects the traffic by process name. Read MITM & interception before you turn it on.
How to start
Use pure local mode. You do not need a cloud key:
ollama serve .\glider.exe --config configs\glider.local.yaml # Dashboard: http://127.0.0.1:8081 # Gateway: http://127.0.0.1:8080/v1
Then point your CLI at the gateway. Or turn on transparent mode, and you do not have to do that step. Pure local gives the full procedure.
The CLIs that Glider supports
Glider supports three CLIs today. Each one operates in two directions. It can send a task to a different CLI, and it can do a task that a different CLI sends to it.
| CLI | As the CLI you use | As a delegate |
|---|---|---|
Claude Code (claude) | Yes | Yes |
Cursor Agent (cursor-agent) | Yes | Yes |
Antigravity (agy) | Yes | Yes |
The number is three today, but it is not a limit in the design. Glider keeps the list of
CLIs as data. It is configs/vendor_candidates.yaml, and it is not a condition
on a vendor name in the shared Go code. To add a fourth CLI, you write one YAML entry and
one adapter. You do not change the shared code.
How to add a fourth vendor gives the full list of files.