Ollama

Pure local mode

In this mode Glider uses no cloud API key. It sends each request that it fulfils to a model on your machine. The profile is configs/glider.local.yaml.

Read this first. "Pure local" describes what Glider fulfils. It does not put your machine offline. Two paths still reach the network, and each one is under your control. The section below names them.

Start

ollama serve
ollama pull qwen2.5-coder:14b
ollama pull llama3:8b-instruct
.\glider.exe --config configs\glider.local.yaml

Then point your CLI at the gateway:

# Claude Code
set ANTHROPIC_BASE_URL=http://127.0.0.1:8080

# any CLI with a base-URL setting
http://127.0.0.1:8080/v1

This profile does not turn transparent interception on. The default profile does, and this one does not. Therefore a CLI does not reach Glider by itself here. You must point it at the gateway, or add mitm.transparent: true yourself. Refer to what this profile intercepts.

The models that the profile gives

Model	VRAM	Context	Labels	In memory
`qwen2.5-coder:14b`	9000 MB	32768	code, refactor, debug	Always. `keep_warm: true`.
`llama3:8b-instruct`	5000 MB	8192	general, docs, explain	On demand.

The strategy for the VRAM keeps headroom_mb: 512 free, and it holds a maximum of 3 models. The coder model stays in memory. Therefore the first request after a pause is not slow.

Three aliases let a CLI ask for a cloud model and receive a local one:

The CLI asks for	The model that answers
`gpt-4o`	`qwen2.5-coder:14b`
`claude-3.5-sonnet`	`qwen2.5-coder:14b`
`gpt-4o-mini`	`llama3:8b-instruct`

To use a different model, pull it with Ollama, add it to models, and change routing.default_local_model. The configuration reference gives each field.

What the profile changes

Setting	Value	Why
`routing.default`	`local`	The rule at priority 0 sends the work to the local model, and not to the cloud.
`routing.allow_cloud_fallback`	`false`	After a local model fails, Glider does not try a cloud model.
`routing.task_classifier.tools_force_cloud`	`false`	A request with tools can stay local. In the default profile that request goes to the cloud. Your model must support tools.
`cloud.providers`	`[]`	No cloud backend exists. Therefore no rule can reach one.
`cloud.budget_cap_usd`	`0`	A second stop on the same path.
`mitm.origin_on_local_error`	`false`	You see the error of Ollama. Glider does not send the request to the origin of the CLI, which would spend a subscription with no message.
`mitm.require_local_healthy`	`true`	Glider selects the local model only after a health check succeeds.
`mitm.agent_rpc_canned_on_error`	`false`	No fixed test reply. A failure stays visible.

What this profile intercepts

mitm.hosts in this profile lists the hosts of Cursor only. It does not list api.anthropic.com. With passthrough_default: true, each host that is not in the list goes to its origin with no decryption.

How your CLI reaches Glider	Does it operate here?
The gateway, with a base URL that you set	Yes. This is the method for this profile.
MITM with CONNECT, for Cursor	Yes.
Transparent, with no help from the CLI	No. Add `mitm.transparent: true` to turn it on, and start Glider as Administrator or root.

The two paths that still reach the network

Glider fulfils no request from the cloud in this mode. These two mechanisms are different, and each one is a choice that you can change.

1. A delegate CLI uses its own backend

<task> /claude starts the real Claude Code as a subprocess. That process talks to the backend of its vendor, with its own credentials. Glider fulfils nothing there, and this profile does not change it. To keep a delegate local also, you must intercept the traffic of that subprocess: turn transparent mode on, and add the hosts of that vendor to mitm.hosts.

2. The summary of a compaction

This profile gives no context.summary block. Therefore the default order applies: [origin, cloud, local]. Glider skips cloud, because no provider exists. But origin comes first, and it runs an installed CLI, which spends that subscription. To keep compaction on your machine, name the source:

context:
  summary:
    chain: [local]

Refer to Context · compaction for what the summary does, and for when it runs.

How to confirm that a request stayed local

Where	What you see
The Overview page of the dashboard	A row for each request, with the rule that claimed it and the cause.
`GET /api/metrics`	The counts, and the percentage that went local against cloud.
The Rules Engine page	A test that shows which rule a message obeys, before you send it.
`POST /api/router/explain`	The same test, as an endpoint.

You can also force one turn, at any position in the message: /local or /fast. Refer to Routing.

What you accept

Item	The effect
Quality on a difficult task	A 14b model is not a frontier model. Keep the cloud for the difficult work, or use the default profile and `/cloud` for one turn.
The context window	32768 tokens for the coder model, against the much larger window of a cloud model.
Tools	The classifier permits them, and your model must truly support them. A model with no support for tools gives text where a tool call must be.
Speed	It is the speed of your GPU. `keep_warm` removes the load time, and it does not remove the time to generate.

When something is wrong

What you see	The cause
Each request goes to the origin	Your CLI does not reach Glider. This profile does not turn transparent mode on, therefore set the base URL.
An error from Ollama, and no answer	This is correct here. `origin_on_local_error: false` shows the failure. Start `ollama serve`, and pull the model.
Glider does not select the local model	`require_local_healthy: true`, and the health check fails. Test `http://127.0.0.1:11434`.
The answer stops in the middle of a sentence	Increase `thresholds.default_max_tokens`. Ollama receives it as `num_predict`.
A tool call arrives as plain text	The model does not support tools. Use a model that does, or set `tools_force_cloud: true` and give a cloud provider.

Next: the configuration reference gives each setting, Routing gives the rules, and MITM gives the interception.