Claudish configuration for Clawrouter

[RevolNoom]

I want to use claudish with clawrouter. This is my ~/.claudish/config.json

{
"version": "1.0.0",
"defaultProfile": "default",
"profiles": {
"default": {
"name": "default",
"description": "Default profile - shows model selector when no model specified",
"models": {},
"createdAt": "2026-06-02T14:06:10.564Z",
"updatedAt": "2026-06-02T14:06:10.564Z"
}
},
"defaultProvider": "clawrouter",
"autoApproveConfirmedAt": "2026-06-02T14:06:14.898Z",
"customEndpoints": {
"clawrouter": {
"kind": "simple",
"format": "openai",
"url": "http://127.0.0.1:8402/v1",
"apiKey": "none"
}
},
"stats": {
"enabled": false,
"lastMonthlyPrompt": "2026-06-02T14:06:14.903Z",
"promptedVersion": "7.2.0"
}
}

And then I ran:

claudish --model clawrouter@free

Any request I send keep getting "Retrying".

claudish version 7.2.0

System Details Report

---

Report details

• Date generated: 2026-06-02 21:46:52

Hardware Information:

• Hardware Model: Dell Inc. Inspiron 3580
• Memory: 24.0 GiB
• Processor: Intel® Core™ i7-8565U × 8
• Graphics: Intel® UHD Graphics 620 (WHL GT2)
• Graphics 1: HAINAN
• Disk Capacity: 2.1 TB

Software Information:

• Firmware Version: 1.30.0
• OS Name: Ubuntu 24.04.4 LTS
• OS Build: (null)
• OS Type: 64-bit
• GNOME Version: 46
• Windowing System: Wayland
• Kernel Version: Linux 6.17.0-23-generic

[claudish-bot]

@RevolNoom Your config validates fine — clawrouter registers as a simple OpenAI endpoint, so claudish POSTs to http://127.0.0.1:8402/v1/chat/completions with model free. "Retrying" means that upstream call is failing and claudish is swallowing the real error.

Get the actual cause:

• claudish --probe clawrouter@free confirms the wiring (transport, adapter, final URL)
• claudish --model clawrouter@free --debug "hi" writes the upstream HTTP status/body to logs/

Two common culprits: clawrouter may not accept free as a model id, or it rejects Authorization: Bearer none (see buildSimpleHandler in src/providers/custom-endpoints-loader.ts — the apiKey is always sent as a bearer token). What does the debug log show for the upstream response?

[RevolNoom]

Running
claudish --probe clawrouter@free
shows:
┌─ clawrouter@free ────────────────── clawrouter · 0/1 live ─┐
│ │
│ # │ Provider │ Model Spec │ Status │
├────┼────────────┼────────────────────────────┼─────────────┤
│ 1 │ clawrouter │ clawrouter@clawrouter@free │ ⊗ auth 401 │
│ └ Missing Authentication header │
│ │
│ Key — │
└────────────────────────────────────────────────────────────┘

Running
claudish --model clawrouter@free --debug "hi"
Shows:
[claudish] Error [OpenRouter]: HTTP 401. Check API key / OAuth credentials.

Do you have any idea of an example authentication header?

[claudish-bot]

@RevolNoom For a "kind": "simple" endpoint claudish hardcodes the auth as Authorization: Bearer <apiKey> (see buildSimpleHandler in packages/cli/src/providers/custom-endpoints-loader.ts:164 — authScheme: "bearer"). So with "apiKey": "none" it literally sends Authorization: Bearer none, and clawrouter is rejecting that with the 401. Put clawrouter's real key there — ideally via env expansion: "apiKey": "${CLAWROUTER_KEY}".

If clawrouter wants a non-Authorization header (or no auth at all), switch to "kind": "complex", which lets you set authScheme and arbitrary headers.

Separately, your probe line shows the model spec doubled as clawrouter@clawrouter@free — worth confirming the upstream model id ends up as free and not clawrouter@free once auth is sorted; if it's still doubled, share the --debug request body and I'll dig in.

[RevolNoom]

Clawrouter doesn't require authentication. How do I set my claudish config?

This is my clawrouter config in customEndpoints. It yields [claudish] Error [OpenRouter]: HTTP 401. Check API key / OAuth credentials.

"clawrouter": {
"kind": "complex",
"displayName": "clawrouter",
"transport": "openai",
"baseUrl": "http://127.0.0.1:8402",
"apiPath": "/v1",
"authScheme": "x-api-key",
"apiKey": "none",
"headers": {},
"streamFormat": "openai-sse"
}

[claudish-bot]

@RevolNoom Two things are working against you here.

1. The openai transport ignores authScheme. Look at getHeaders() in packages/cli/src/providers/transport/openai.ts:42-48 — it only ever emits Authorization: Bearer <apiKey>, and only when apiKey is non-empty. So "authScheme": "x-api-key" does nothing, and "apiKey": "none" literally sends Authorization: Bearer none. To send no auth header at all, set "apiKey": "" (empty string).

2. Your apiPath is wrong. claudish POSTs to baseUrl + apiPath, so "apiPath": "/v1" hits http://127.0.0.1:8402/v1 instead of the chat endpoint. Use the full path:

"clawrouter": {
  "kind": "complex",
  "displayName": "clawrouter",
  "transport": "openai",
  "baseUrl": "http://127.0.0.1:8402",
  "apiPath": "/v1/chat/completions",
  "apiKey": "",
  "headers": {},
  "streamFormat": "openai-sse"
}

If it still 401s with an empty key, clawrouter is likely forwarding the request upstream (your error said [OpenRouter]) and that upstream wants a key — in which case put it in headers (e.g. "headers": {"x-api-key": "..."}) since the openai transport can't set custom auth schemes. Share the --debug request headers/body if it persists.

[RevolNoom]

Following your recommendation, using "apiKey": "" will cause this error:
[claudish] customEndpoints['clawrouter'] failed validation: Too small: expected string to have >=1 characters

[claudish-bot]

@RevolNoom You're right, and that's my mistake — the schema rejects an empty key. Both custom-endpoint schemas declare apiKey: z.string().min(1) (packages/cli/src/config-schema.ts:37 and :50), so "" can never validate.

The catch: the openai transport only emits Authorization: Bearer <apiKey> when apiKey is non-empty (transport/openai.ts:44), but the schema forbids empty — so there's currently no way to send zero auth headers through this transport. That's a real gap, not a config you're getting wrong.

Workaround: keep a dummy key ("apiKey": "none") and fix the path to "apiPath": "/v1/chat/completions". Since clawrouter doesn't require auth, it should ignore the stray Bearer none header. If you still get a 401 tagged [OpenRouter], that means clawrouter is forwarding upstream to OpenRouter and that endpoint wants the key — share the --debug request headers and I'll confirm where the 401 originates.

I'll also flag the empty-key limitation to @jackrudenko since allowing no-auth custom endpoints looks like a legitimate fix.

[RevolNoom]

Claudish Session Log - 2026-06-03T14:32:19.961Z
Mode: structural (content redacted)

[2026-06-03T14:32:19.974Z] [Proxy] Registered 1 custom endpoint(s) from config
[2026-06-03T14:32:19.980Z] [Proxy] Server started on port 5086
[2026-06-03T14:32:20.835Z] [OpenRouter] Response status: 401
[2026-06-03T14:32:20.835Z] [OpenRouter] Error: {"error":{"message":"Missing Authentication header","code":401}}
[2026-06-03T14:32:20.836Z] Error [OpenRouter]: HTTP 401. Check API key / OAuth credentials

[claudish-bot]

@RevolNoom That log is the giveaway: the [OpenRouter] tag means claudish handled this request with its real OpenRouter provider, not your clawrouter custom endpoint. That label comes from this.provider.displayName (packages/cli/src/handlers/composed-handler.ts:452 and :564) — a clawrouter endpoint would log [Clawrouter]. So this request never hit 127.0.0.1:8402; it went to api.openrouter.ai, which 401s without a key. (That's also inconsistent with your earlier --probe, which did reach clawrouter.)

Confirm where it actually went — grep the full (non-redacted) debug log for the endpoint URL:

grep "Calling API" logs/claudish_*.log

That line (composed-handler.ts:384) prints the literal URL claudish POSTed to. If it shows openrouter.ai instead of 127.0.0.1:8402, the clawrouter@free spec isn't being routed to your custom endpoint at request time even though it registered ("Registered 1 custom endpoint").

@jackrudenko worth a look — between this (custom endpoint registers but a clawrouter@free request resolves to the OpenRouter provider) and the no-empty-key schema limitation I flagged earlier, this is looking like a real routing bug rather than a config mistake.

[RevolNoom]

logs/claudish_2026-06-03_14-32-19.log:[2026-06-03T14:32:20.379Z] [OpenRouter] Calling API: https://openrouter.ai/api/v1/chat/completions
logs/claudish_2026-06-03_14-32-19.log:[2026-06-03T14:32:21.429Z] [OpenRouter] Calling API: https://openrouter.ai/api/v1/chat/completions

[claudish-bot]

@RevolNoom That's the confirmation — both requests went to https://openrouter.ai/api/v1/chat/completions, not your 127.0.0.1:8402 endpoint. So clawrouter registers fine, but clawrouter@free is resolving to the built-in OpenRouter provider at request time instead of your custom endpoint. That's a real routing bug, not a config mistake (the doubled clawrouter@clawrouter@free in your earlier --probe is the same root cause showing up).

Worth trying as a stopgap: drop the explicit prefix and lean on your defaultProvider. Run a bare name — claudish --model free — since "defaultProvider": "clawrouter" should append clawrouter to the bare-name routing chain, and your dummy "apiKey": "none" keeps it credentialed. If a bare name routes to 127.0.0.1:8402 while the clawrouter@ prefix doesn't, that pins the bug to the explicit provider@model path.

@jackrudenko this is now confirmed: a registered custom endpoint (clawrouter) is reached by --probe but a live clawrouter@free request resolves to the OpenRouter provider and hits api.openrouter.ai. Combined with the no-empty-key schema gap, this needs a look at the runtime provider resolution for provider@model specs.

[RevolNoom]

I read the docs at https://github.com/MadAppGang/claudish/blob/main/CLAUDE.md, and running:

claudish --model http://localhost:8402/free

Actually works.

[claudish-bot]

@RevolNoom That's a great data point. The URL form (http://localhost:8402/free) works because it bypasses provider-name resolution entirely — claudish treats the URL as a direct local endpoint and POSTs straight to it, so it never goes through the broken provider@model lookup that was sending clawrouter@free to api.openrouter.ai.

So use that as your working config for now — it hits your clawrouter instance directly. (You may need /v1/chat/completions in the path depending on how clawrouter routes; if /free 404s, try http://localhost:8402/v1/chat/completions/free style or check clawrouter's expected path.)

This also cleanly confirms the bug: the custom-endpoint registers and is reachable, but the clawrouter@ prefix resolves to the built-in OpenRouter provider while the raw URL doesn't. @jackrudenko this is now pinned to the named custom-endpoint resolution path for provider@model specs — the URL escape hatch works as the workaround.