How to make Headroom proxy work with Cline + OpenRouter in VS Code (Windows)

[serjko]

Hi! Trying to get Headroom proxy working as a compression layer between Cline (VS Code extension) and OpenRouter, using GLM-5.2 as my model. Running on Windows.

Questions:

1. What is the correct Cline provider type and base URL format to route through Headroom's proxy to OpenRouter?
2. Should the API key field in Cline be the dummy key or the real OpenRouter key?
3. What model name format should I use — e.g. zhipuai/glm-5.2, openrouter/zhipuai/glm-5.2, or something else?

My setup:

• VS Code with Cline extension
• OpenRouter as API provider (model: zhipuai/glm-5.2)
• Headroom installed via pip in a venv
• Running proxy with: headroom proxy --port 8787 --backend openrouter

What happens when I start the proxy:
The proxy starts and prints this helpful guidance for OpenRouter users:

IMPORTANT for OpenRouter users:
  1. Set credentials: OPENROUTER_API_KEY
  2. Set a dummy Anthropic key: ANTHROPIC_API_KEY="sk-ant-dummy"
  3. Set base URL: ANTHROPIC_BASE_URL=http://127.0.0.1:8787
  4. Use model names: anthropic/claude-3.5-sonnet, openai/gpt-4o, etc.

I set OPENROUTER_API_KEY and ANTHROPIC_API_KEY as environment variables in the same PowerShell session before starting the proxy. But I'm not clear on how to apply step 3 and 4 to Cline specifically, since ANTHROPIC_BASE_URL is an environment variable that Claude Code reads natively — Cline uses a settings UI instead.

What I've tried in Cline settings:

Attempt 1 — OpenAI Compatible provider:

• Base URL: http://127.0.0.1:8787/v1
• API Key: sk-ant-dummy
• Model: openai/gpt-4o
• Result: 401 Incorrect API key provided

Attempt 2 — Anthropic provider:

• Base URL: http://127.0.0.1:8787
• API Key: sk-ant-dummy
• Result: 401 invalid x-api-key — and Cline's Anthropic provider doesn't allow a custom model name, so GLM-5.2 isn't usable this way

Any guidance appreciated — the proxy guidance message is helpful but written with Claude Code in mind and it's not clear how to translate it to Cline's settings UI. Thanks!

[richardchen874-sys]

I think the confusion here comes from mixing two different compatibility paths: OpenAI-compatible settings in Cline vs the Anthropic-style proxy guidance printed by Headroom.

Since Headroom’s OpenRouter guidance mentions ANTHROPIC_BASE_URL and a dummy Anthropic key, that looks mainly written for clients that speak the Anthropic API shape, such as Claude Code. Cline’s OpenAI Compatible provider will send OpenAI-style /v1/chat/completions requests, so it may not match the endpoint shape Headroom expects in that mode.

A few things I would check:

• whether Headroom exposes an OpenAI-compatible /v1/chat/completions endpoint or only an Anthropic-compatible endpoint
• whether --backend openrouter expects Anthropic-style input and translates to OpenRouter
• whether Cline’s Anthropic provider supports custom base URL + custom model name together
• whether the proxy logs show the incoming path: /v1/chat/completions vs /v1/messages
• whether the real OpenRouter key should stay only in OPENROUTER_API_KEY, while Cline uses a dummy key to talk to the local proxy
• whether the model name should be passed as zhipuai/glm-5.2 exactly as OpenRouter expects, or wrapped by the proxy

For Cline specifically, the cleanest setup would usually be:

Cline → local proxy → OpenRouter → GLM-5.2

But the proxy has to expose the same API shape that Cline is using.

So if Cline is configured as OpenAI Compatible, the local proxy probably needs to accept OpenAI-compatible requests at something like:

http://127.0.0.1:8787/v1/chat/completions

If Headroom only accepts Anthropic-style requests, then Cline’s OpenAI Compatible provider will likely keep failing even if the key and model name are correct.

The most useful next debugging step would be to inspect one proxy log line and confirm the incoming request path, auth header, and model name that Cline is actually sending.

[highoncomputers]

The issue is that Cline's OpenAI Compatible provider and Headroom's OpenRouter backend need the right wiring. Here is the working configuration for Cline + OpenRouter via Headroom on Windows:

Cline Provider Settings (OpenAI Compatible):

• Base URL: http://127.0.0.1:8787/v1
• API Key: your real OPENROUTER_API_KEY (not the dummy key)
• Model: zhipuai/glm-5.2 (use the exact OpenRouter model slug)

Why the dummy key doesn't work: The ANTHROPIC_API_KEY=sk-ant-dummy env var is only relevant when Headroom routes requests in Anthropic wire format (for Claude Code which sends x-api-key). Cline's OpenAI Compatible provider sends requests in OpenAI wire format (/v1/chat/completions) with Authorization: Bearer <key>. Headroom forwards those to OpenRouter using your OPENROUTER_API_KEY. So you must put your real OpenRouter key in Cline's API key field.

For GLM-5.2 specifically: Use zhipuai/glm-5.2 as the model name in Cline. That's the OpenRouter model slug. Do not prefix it with openrouter/.

If you want to use Claude models via OpenRouter: Set the model to anthropic/claude-sonnet-4-6-20250515 (or whatever the current OpenRouter slug is).

Verification steps:

1. Start proxy: headroom proxy --port 8787 --backend openrouter
2. Ensure OPENROUTER_API_KEY is set in the same terminal session
3. In Cline, use OpenAI Compatible provider with:
   • Base URL: http://127.0.0.1:8787/v1
   • API Key: your OpenRouter key
   • Model: zhipuai/glm-5.2
4. Send a test message

The proxy's guidance message is written assuming Claude Code (which reads ANTHROPIC_BASE_URL from env vars). For Cline you translate it to the settings UI fields as shown above.

[richardchen874-sys]

Good clarification — this matches the key distinction between the OpenAI-compatible wire format and the Anthropic-style guidance printed by Headroom.

The real OpenRouter key in Cline also makes sense here, since Cline is sending Authorization: Bearer ... to the local proxy rather than using the Claude Code-style x-api-key flow.

One thing I’d still verify after this works is whether Headroom logs the model slug, upstream provider, request path, and failure/retry behavior cleanly. For local proxy setups, the config can be “working” but still be hard to debug later when switching models or providers.

Have you seen this setup behave consistently with other OpenRouter models in Cline, or only with zhipuai/glm-5.2 so far?

[serjko]

Good suggestion here. Alas, no luck so far. It looks like Headroom's OpenRouter backend expects Anthropic APIs in CLI mode. No combination of setting for Cline OpenAI Compatible model worked for me. I ended up switching to 9Router and it was a breeze to plug it into my Cline + OpenRouter setup. Bonus: It supports KLM and Headroom out of the box.