OmniRoute API Returns HTTP 403 When Accessing Model Connections

[charleech]

I'm using a clean OmniRoute Docker installation with the image diegosouzapw/omniroute:3.8.51-web.

I created an OmniRoute API through the console and configured my client as follows:

export OMNIROUTE_API_KEY="sk-some-key"
export OMNIROUTE_URL="http://localhost:20128"

export ANTHROPIC_BASE_URL=$OMNIROUTE_URL
export ANTHROPIC_API_KEY=$OMNIROUTE_API_KEY
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY="1"

Additionally, I only configured the free providers, following the setup instructions provided by the OmniRoute Console when I logged in for the first time. I did not configure any paid providers or additional connections.

Using Claude CLI version 2.1.289, I selected the model auto/claude-opus and sent a simple "Hello" message. However, the system returned the following error:

Please run /login · API Error: 403 oc/muse-spark-1.3: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/big-pickle: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/muse-spark-1.2: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/muse-spark-1.2-contributor-free: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/muse-spark-1.3-contributor-free: auth — [opencode] 1 connection(s) exist but are excluded by this…

{"level":40,"time":"2026-10-05T03:26:52.270Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"opencode | 1 connection(s) hidden by the API key's allowed_connections/quota scope"}
{"level":30,"time":"2026-10-05T03:26:52.271Z","service":"omniroute","module":"sse","tag":"COMBO","msg":"Trying model 10/10: oc/nemotron-3-ultra-free"}
{"level":30,"time":"2026-10-05T03:26:52.273Z","service":"omniroute","module":"sse","tag":"ROUTING","msg":"oc/nemotron-3-ultra-free → opencode/nemotron-3-ultra-free"}
{"level":40,"time":"2026-10-05T03:26:52.276Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"opencode | 1 connection(s) hidden by the API key's allowed_connections/quota scope"}
{"level":40,"time":"2026-10-05T03:26:52.276Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"[opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope"}
{"level":40,"time":"2026-10-05T03:26:52.289Z","service":"omniroute","module":"sse","tag":"COMBO","status":403,"errorBody":"[opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope","msg":"Model oc/nemotron-3-ultra-free failed, trying next"}
{"level":40,"time":"2026-10-05T03:26:52.289Z","service":"omniroute","module":"sse","tag":"COMBO","msg":"All models failed | oc/muse-spark-1.3: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/big-pickle: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/muse-spark-1.2-contributor-free: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/muse-spark-1.2: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403); oc/muse-spark-1.3-contributor-free: auth — [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope — add them to the key in the dashboard, or use a key without that scope (HTTP 403)... (+5 more)"}
{"level":30,"time":"2026-10-05T03:26:52.343Z","service":"omniroute","module":"sse","tag":"COMBO","msg":"combo trace combo-1c59a843-5787-4f28-b563-96df41fcad4a terminal={\"status\":403,\"errorClass\":null} decisions=10"}

Could you please advise if I am doing anything incorrectly or if there is any additional configuration I need to apply?

Thank you very much for your help and support in advance.

[TanbirRamim]

The 403 means the key you exported is scoped to a set of connections that doesn't include the ones you added. In src/sse/services/auth.ts the provider's connections are filtered by the key's allowed_connections before anything else:

if (allowedConnections && allowedConnections.length > 0) {
  allConnections = allConnections.filter((conn) => allowedConnections.includes(conn.id));
}
const blockedByKeyPolicyCount = connectionsBeforeKeyPolicy - allConnections.length;

When that leaves nothing, src/sse/handlers/chatHelpers.ts returns exactly your message (N connection(s) exist but are excluded by this API key's connection allowlist / quota scope) with a 403. The comment next to it describes your situation: a key created with an allowlist before the connections existed, so /test and the model sync still work (they address a connection by id) while chat is refused.

Fix it in the dashboard: open API Manager, edit sk-some-key, and under "Allowed Connections" tick the opencode and other free-provider connections (or clear the allowlist entirely so the key can use everything). Or just create a fresh key without a connection restriction and put that in ANTHROPIC_API_KEY. No restart needed.

[diegosouzapw]

@charleech The answer above from @TanbirRamim is right, and I checked it against the code: the 403 is the key's connection allowlist. When a key has allowedConnections set, only those connections are used, and the connections that exist but aren't on the list produce exactly the message you got, N connection(s) exist but are excluded by this API key's connection allowlist / quota scope.

What I can't tell you is why a fresh install's key had an allowlist at all. The dashboard's key creation lets you choose connections, but I didn't find where a default list would be filled in for you. If you didn't pick any, tell me how you created the key (the onboarding wizard, API Manager, or the CLI) and what Allowed Connections shows for it in API Manager. That would show whether a default was applied. The fix is the one given above: edit the key and clear the allowlist (or tick the opencode connections), or use a key with no connection restriction.

A second point from your log: OpenCode Free's 403 … only be used from within OpenCode can also appear on a key with no restriction, if the request doesn't look like an OpenCode client. That one is a separate cause, covered in #14139.

[charleech]

Hi @TanbirRamim and @diegosouzapw

Thank you for your advice and for pointing me to the configuration.

I created the OmniRoute API key via the console by following these steps:

OMNIPROXY > API Keys > Create API Key

In the Create API Key screen, Management Access is set to Disabled, and Self-Service Visibility is enabled for all three options: Own Cost and Token Usage, Shared Account Quota, and Allow local usage command. Then I clicked the Create API Key button.

Then I clicked Edit Permissions at the end of the row of the created API key.

• The Allow All button is highlighted in red, with the message "This key can access all available models."
• I scrolled down to Allowed Connections, where All Connections is highlighted in red.

At this point, I understood that all free providers are allowed by default, but the server still gave me the 403 error as reported previously.

However, I followed your guidance by changing Allowed Connections from All Connections to Only Selected Connections and selected all five free providers: AI Horde, Cloudflare AI Playground, DuckDuckGo AI Chat, OpenCode Free, and Unclose AI.

After saving the changes, I used Claude CLI to connect to OmniRoute with auto/claude-opus again. The 403 error was gone, but the 503 error was introduced instead:

[503] Service temporarily unavailable: all targets were skipped by pre-dispatch filters

Previously, with a clean OmniRoute Docker installation using the diegosouzapw/omniroute:3.8.50-web image, before the OpenCode issue, I was able to successfully use Claude CLI to connect to OmniRoute with free providers, but not with the clean diegosouzapw/omniroute:3.8.51-web installation.

Could you please advise if I am doing anything incorrectly or if there is any additional configuration I need to apply?

Thank you very much for your help and support in advance.

[diegosouzapw]

@charleech Thanks for the detail, it contradicts something I told you, so first a correction. I said the 403 comes from the key's connection allowlist, and I confirmed that against the code. But that message can only be produced when the key's allowedConnections list is not empty (src/sse/services/auth.ts, where it counts connections removed by that list). A key showing All Connections shouldn't hit it. So either the key held a list that the screen displayed as "All", or something else narrowed it (the key's quota scope is the other source the same message names). I don't know which, and I won't claim one.

The new 503, all targets were skipped by pre-dispatch filters, is a different message: every target in auto/claude-opus was dropped before a request was sent. Typical reasons are a connection in cooldown, a quota window, an open circuit breaker, or a model not in the provider's catalog. Two things could be feeding it:

• The earlier 403s may have put those connections into a cooldown, which would also explain why it didn't clear right away.
• Several of the five free providers have prerequisites, as listed in None of the "No Auth" providers work #15232: Cloudflare Playground needs Chromium (the -web image has it), DuckDuckGo can reject an IP, and OpenCode Free only accepts requests that look like the OpenCode client. With only those five available, a Claude-flavored auto pool can end up with nothing eligible.

I can't tell from here whether 3.8.51 behaves differently from your 3.8.50-web install for the same setup, so I won't call it a regression yet. Three things would settle it:

1. The app.log lines for one failing request after the edit: the COMBO … skipped line and any AUTH lines near it.
2. GET /api/v1/auto-combo/claude-opus/candidates called with that key, which lists the pool and which targets are reachable.
3. Whether the 3.8.50-web install used the same key, or a different one.

[diegosouzapw]

@charleech A follow-up on my own theory, so you don't spend time on it. I suspected that OpenCode Free's refusal pause could produce the misleading "excluded by this API key's connection allowlist" 403 on an unrestricted key: a combo pins keyless targets to the internal noauth connection, and a pause would leave the real opencode connection hidden by that pin. I tested it: with a real opencode connection present, the ["noauth"] pin, and the pause armed, the code answers 429 "The shared no-auth connection is in a refusal pause", not the allowlist 403. So that is not what produced your 403, and I still don't know what did. A key shown as "All Connections" shouldn't be able to reach that message, as I said before.

The data that would settle it is the same as before: the app.log lines for one failing request (the AUTH … hidden by the API key's allowed_connections/quota scope line and its neighbors), and the output of GET /api/v1/auto-combo/claude-opus/candidates called with that key. If you still have the key, also the exact value shown under Allowed Connections right after creation, before you edited it.

[charleech]

@diegosouzapw

Thank you very much for your advice, and especially for the time you have spent investigating this issue. I really appreciate it.

I would like to provide the following steps to reproduce the issue.

First Round

1. I started with a clean OmniRoute Docker installation using the diegosouzapw/omniroute:3.8.51-web image.

2. I visited http://localhost:20128 for the first-time setup and used the setup wizard to select only the five free providers:

   • AI Horde
   • Cloudflare AI Playground
   • DuckDuckGo AI Chat
   • OpenCode Free
   • Unclose AI

3. I created an OmniRoute API key with the following settings:

   • Management Access: Disabled

   • Self-Service Visibility: Enabled for all three options:

     • Own Cost and Token Usage
     • Shared Account Quota
     • Allow local usage command

4. I used Claude CLI with the model auto/claude-opus and sent a simple Hello message.

5. The server returned an HTTP 403 error.

6. For this step, please refer to the attachment step-01.zip, especially 01-08-app-403.log, which contains the OmniRoute app.log output.

Second Round

1. I modified the API key to Only Selected Connections and selected only OpenCode Free.
2. I started a new Claude CLI session using the model auto/claude-opus and sent a simple Hello message.
3. The server returned an HTTP 503 error.
4. For this step, please refer to the attachment step-02.zip, especially 01-08-app-503.log, which contains the OmniRoute app.log output.

Please note that the log in step-02.zip is accumulated from the previous step as well.

Additional Information

For the curl test against:

GET /api/v1/auto-combo/claude-opus/candidates

please refer to the attachment step-03.zip.

I hope this information is helpful for reproducing and investigating the issue.

If you have any questions, need additional information, or would like me to test anything else on my side using a fresh and clean installation, please do not hesitate to let me know.

Again, thank you very much for your attention to this issue, and especially for the time and effort you have spent investigating it. I really appreciate it.

step-01.zip
step-02.zip
step-03.zip

[diegosouzapw]

@charleech Thank you, this is exactly the data I needed, and it changes the picture. What your logs show, which I'm confident about because it's in the text:

• The server never received your API key. Every request in both logs says No API key provided (local mode). So editing the key (Allowed Connections, Only Selected Connections) couldn't have affected these requests, and the 403's wording ("this API key's connection allowlist") blames a key that wasn't on the request. That wording is a defect on our side.
• Your pool is entirely keyless. The /candidates output has 10 candidates, all opencode with connectionId: "noauth".
• There is also one real opencode connection on that install. The log says forcedId=noauth and 1 connection(s) hidden: the keyless pin filters that real row out, the pool comes up empty, and the keyless fallback then returns nothing without logging why.
• The 503 comes after the 403s. From the second request on, all 10 targets are skipped before dispatch (no credentials available). That fits the failed attempts having disabled the keyless connection, but I haven't verified it.

What I still don't know is why the allowlist that reached the credential check wasn't empty. I tried to reproduce it in a test (a keyless pin, a real opencode row, an allowlist of null, empty, or ["noauth"]), and each of those resolves normally, so something else in your setup produces it. I've opened #15889 for the misleading message and the missing log lines, without claiming a cause.

Two questions that would help narrow it down:

1. Was ANTHROPIC_API_KEY really set in the shell where Claude CLI ran? The server says no key arrived. (Your first message listed OMNIROUTE_API_KEY and ANTHROPIC_API_KEY; if the second was empty or unset in that terminal, that would explain "local mode".)
2. On the OpenCode Free provider page, how many accounts does it show? The log says one real connection exists. If you're willing to test on this throwaway install: delete that connection (keep the provider itself enabled), restart, and repeat the request. I haven't verified that this helps, so please treat it as an experiment and not a fix.

[charleech]

@diegosouzapw

I would like to provide the testing steps as follows.

1. I captured my shell environment variables, Claude CLI version, and usage, including the failure. Please refer to the attachment step-01.zip, especially 01-07-app.log, which contains the OmniRoute app.log output.

2. I removed the connection from OpenCode on the Provider screen and tested with Claude CLI. Please refer to the attachment step-02.zip, especially 02-04-app.log, which contains the OmniRoute app.log output.

3. I then went back to basics by using curl:

curl $OMNIROUTE_URL/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OMNIROUTE_API_KEY" \
  -d '{
    "model": "auto/claude-opus",
    "messages": [
      {
        "role": "user",
        "content": "Explain how OmniRoute works."
      }
    ]
  }'

The failure still occurred. Please refer to the attachment step-03.zip, especially 03-02-app.log, which contains the OmniRoute app.log output.

4. I then tested with curl, using the HTTP header X-API-KEY, as mentioned in Get your Claude API key:

The client SDK reads ANTHROPIC_API_KEY automatically. Direct HTTP requests send the key in the x-api-key header.

curl $OMNIROUTE_URL/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: $ANTHROPIC_API_KEY" \
  -d '{
    "model": "auto/claude-opus",
    "messages": [
      {
        "role": "user",
        "content": "Explain how OmniRoute works."
      }
    ]
  }'

The failure still occurred. Please refer to the attachment step-04.zip, especially 04-03-app.log, which contains the OmniRoute app.log output.

Please note that the log file accumulates output from all steps.

I hope this information is helpful in reproducing and investigating the issue.

If you have any questions, need additional information, or would like me to test anything else on my side using a fresh and clean installation, please do not hesitate to let me know.

Again, thank you very much for your attention to this issue, and especially for the time and effort you have spent investigating it. I really appreciate it.
step-01.zip
step-02.zip
step-03.zip
step-04.zip

[diegosouzapw]

@charleech Thank you for the four runs. I read the .log files (the screenshots I did not open), and they change what I told you last time, so here is the corrected picture. Everything below is in your logs unless I say otherwise.

1. This time there is no 403 anywhere. All 29 requests across the four steps end in terminal={"status":503}, and none of them reached OpenCode.

2. Your API key is not the cause. In step 3 (the Authorization: Bearer curl) the log says API key provided, and that request still ended in 503. The other requests say No API key provided (local mode). For the curl in step 4, that one is expected: on /v1/chat/completions, X-API-KEY is only honored when the request looks like an Anthropic client (an anthropic-version header or a Claude user agent), so use Authorization: Bearer there. For the Claude CLI requests I can't tell why the key didn't arrive, because your environment capture is in a screenshot. Either way, it didn't change the outcome.

3. While the real connection existed (step 1), 9 of the 10 targets were rejected with model is not in the live catalog. Right before that, ModelSync logged OpenCode Account 1: ✓ 1 models. I reproduced this in a test: with a real OpenCode connection whose sync returned a single model, oc/muse-spark-1.2, oc/deepseek-v4-flash-free and the others are rejected, while the free tier would serve them. That one is a real defect on our side, and I have a one-line candidate fix (stop treating a partial OpenCode sync as the complete list). It passes that test and 160 neighbouring catalog tests, and it is open as draft PR #16042, not merged.

4. After you deleted the connection (steps 2–4), all 10 targets were rejected with no credentials available or model excluded. This part I can't explain. In a test with no OpenCode connection at all and the same keyless pin, the credentials come back normally, so something in your install blocks the keyless path and the log doesn't say what. Two things would narrow it down:

• In the dashboard, does anything list OpenCode as blocked or disabled (for example under Settings, in a blocked-providers list, or a "disable anonymous fallback" switch)?
• After deleting the connection, what does GET /api/v1/auto-combo/claude-opus/candidates return now?

I'm not going to guess further without those. #15889 already tracks the missing log lines for this exact situation.

[charleech]

@diegosouzapw

Thank you for your advice. I have no idea what I'm doing wrong, so I went back to the basics and followed the steps below.

Round 1

OmniRoute

1. Start a fresh and clean OmniRoute Docker container.

docker run -d \
  --name omniroute \
  --restart unless-stopped \
  -p 20128:20128 \
  --network ai-tier \
  --env APP_LOG_LEVEL=debug \
  diegosouzapw/omniroute:3.8.51-web

2. Access the console and complete the setup wizard, selecting only OpenCode Free.

3. Create an API key using all the default settings.

Client

1. Start a fresh, separate Docker container to simulate the client.

docker run -it --rm \
    --name omiroute-client \
    --network ai-tier \
    --entrypoint /bin/bash \
    node:26

2. Install Claude CLI inside the client container.

curl -fsSL https://claude.ai/install.sh | bash

3. Set up the environment variables.

export OMNIROUTE_API_KEY="sk-...."
export OMNIROUTE_URL="http://omniroute:20128"
export ANTHROPIC_BASE_URL=$OMNIROUTE_URL
export ANTHROPIC_API_KEY=$OMNIROUTE_API_KEY
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY="1"

4. Execute Claude CLI and select the auto/cluade-opus model, send simple hello.

5. The server returns a 403 failure.

6. Please refer to 01-01-app.log.

7. Execute curl to call the api/v1/auto-combo/claude-opus/candidates endpoint.

curl -X GET \
    -H "Authorization: Bearer $OMNIROUTE_API_KEY" \
    http://omniroute:20128/api/v1/auto-combo/claude-opus/candidates \
    | jq .

8. Please refer to 01-02-curl.txt for the result.

Round 2

OmniRoute

1. Access the console and update the API key's Allowed Connections setting from All Connections to Only Selected Connections, then select OpenCode Free.

Client

1. Execute Claude CLI and select the auto/cluade-opus model, send simple hello.

2. The server returns a 503 failure.

3. Please refer to 02-01-app.log.

4. Execute curl to call the api/v1/auto-combo/claude-opus/candidates endpoint.

curl -X GET \
    -H "Authorization: Bearer $OMNIROUTE_API_KEY" \
    http://omniroute:20128/api/v1/auto-combo/claude-opus/candidates \
    | jq .

5. Please refer to 02-02-curl.txt for the result.

Round 3

OmniRoute

1. Access the console and update OpenCode Free Provider by removing the connection.

Client

1. Execute Claude CLI and select the auto/cluade-opus model, send simple hello.

2. The server returns a 503 failure.

3. Please refer to 03-01-app.log.

4. Execute curl to call the api/v1/auto-combo/claude-opus/candidates endpoint.

curl -X GET \
    -H "Authorization: Bearer $OMNIROUTE_API_KEY" \
    http://omniroute:20128/api/v1/auto-combo/claude-opus/candidates \
    | jq .

5. Please refer to 03-02-curl.txt for the result.

Please note that the log file accumulates output from all steps.

I hope this information is helpful in reproducing and investigating the issue.

If you have any questions, need additional information, or would like me to test anything else on my side using a fresh and clean installation, please do not hesitate to let me know.

log.zip

[diegosouzapw]

@charleech Thank you, the debug-level logs help a lot. I read the six .log/.txt files and ran several tests against them. What I can say from the logs:

1. The 403 comes from the combo's own pin, not from your key. The debug line on the first request is opencode | active=0, excluded=0, forcedId=noauth, blocked_forced=1, blocked_allowed=0. blocked_allowed=0 means the key's allowlist hid nothing. blocked_forced=1 means one OpenCode-family connection exists and was filtered out because the auto-combo pinned the target to the keyless noauth connection. Then the code reports it as "excluded by this API key's connection allowlist", which is the wrong attribution. That wording is a bug on our side (#15889).

2. In round 3 that connection was still there. After you removed the OpenCode Free connection, the debug line is still blocked_forced=1 (40 times in 03-01-app.log), and /candidates is byte-identical to round 1. So something in the OpenCode family still has one connection row. That would also explain why removing it changed nothing.

3. What I can't explain yet: with the keyless pin, the credential check should hand back the keyless connection. I tried it with the connection types I could think of (an OpenCode API-key account, an OpenCode Zen account, an OpenCode Go account) and with an empty, missing and ["noauth"] allowlist, and in every case it does. So I still can't reproduce the 403 or the 503 here, and I don't want to guess a cause.

Two things would settle it:

• A screenshot of the Providers page showing every OpenCode-related card (OpenCode Free, OpenCode Zen, OpenCode Go) with its accounts, if any. I want to know what that one row is.
• Whether Settings lists any blocked providers (and whether OpenCode is on that list).

There's also a separate real defect I found from your earlier logs: a one-model sync from the OpenCode account made the other free models get rejected as "not in the live catalog". That fix is in draft PR #16042.

[charleech]

@diegosouzapw

Please find attached the screenshots for Rounds 1, 2, and 3, respectively.

If you have any questions, need additional information, or would like me to perform any further tests on my side using a fresh, clean installation, please do not hesitate to let me know.

step-01.zip
step-02.zip
step-03.zip

[diegosouzapw]

@charleech Thank you for the screenshots. They show something I couldn't see in the logs, so here is what I read in them (nothing else):

• OpenCode Zen and OpenCode Go both show "0 connections", so they aren't the extra row.
• OpenCode Free shows "Accounts (0)" in the keyless box, but under Connections there is 1 connection, named "OpenCode Free", status unknown. That is the row the debug counter (blocked_forced=1) is counting: the auto-combo pins the target to the keyless connection, and this row is filtered out by that pin.
• In round 3 you select that row and click delete. Your logs from that round still say blocked_forced=1, so after the delete, a connection row was still there (or came back).

Could you check these two things on the throwaway install?

1. After deleting the row, reload the OpenCode Free page. Does "1 connection" come back, and with what name and status?
2. In the Blocked Providers screenshot I can't tell which providers are selected, since the chips all look alike in the capture. Is "OpenCode Free" one of the highlighted ones? (If you hide the whole list and show only the selected ones, that would be clear.)

I still can't reproduce the 403 myself, so this narrows where to look rather than naming a cause.

[charleech]

@diegosouzapw Thank you for your response and advice.

The step-03.zip contains additional captures taken after deleting the OpenCode Free connection, along with a screenshot of the Blocked Providers settings. The screenshot confirms that none of the three providers—OpenCode Free, OpenCode Zen, and OpenCode Go—is blocked.

Additionally, I performed a fourth test case using the following steps:

1. Started a fresh, clean OmniRoute Docker container.

2. During the initial setup wizard, created only the password and skipped all other configuration steps, especially the Free Provider setup. This means no connections were configured in OmniRoute at this point.

3. Created an API key.

4. Used the API key from step 3 to send a curl request to the /api/v1/auto-combo/claude-opus/candidates endpoint.

Surprisingly, the request succeeded and returned a list of candidates. I would have expected it to fail because no connections had been configured.

I'm not sure whether this is a useful test scenario, but I thought the result might provide another clue for investigating the issue. Please refer to step-04.zip for the screen captures and curl output.

If you have any questions, need additional information, or would like me to run any further tests using a fresh, clean installation, please don't hesitate to let me know.

step-03.zip
step-04.zip

[charleech]

I performed a fifth test case using the following steps:

1. Started a fresh, clean OmniRoute Docker container.

2. Skipped the initial setup wizard entirely. This means no connections should have been configured in OmniRoute at this point.

3. Created an API key.

4. Used the API key from step 3 to send a curl request to the /api/v1/auto-combo/claude-opus/candidates endpoint.

Surprisingly, the request succeeded and returned a list of candidates. I would have expected it to fail because no connections had been configured, just as in the fourth test case.

One possibility is that there may be an issue with how OmniRoute initializes its data during the first run. However, I cannot confirm this yet.

For reference, I am using the following Docker image:

docker image ls -a --format table | grep omniroute
diegosouzapw/omniroute                           3.8.51-web      3af8a15d2086   2 weeks ago    2.36GB

I hope this additional information helps narrow down the cause of the issue.

If you have any questions, need additional information, or would like me to run any further tests using a fresh, clean installation, please don't hesitate to let me know.

step-05.zip

[diegosouzapw]

@charleech Thank you for the fifth test. What it tells me:

• On an install where you skipped the wizard, /candidates returns the same 10 keyless oc/* candidates. That's expected: the keyless OpenCode models are part of the auto pool even with zero connections, so it doesn't show a bug by itself.
• I found where the extra row from the wizard comes from. The "free providers" step of the setup wizard creates a connection for OpenCode Free with the type no-auth, name "OpenCode Free" and status "unknown". That matches your Providers-page screenshot. Without the wizard, that row doesn't exist.

I then tried the exact same row (type no-auth, status unknown, active) together with the combo's keyless pin, with a missing, an empty and a ["noauth"] allowlist, and the credential check still returns the keyless connection. So I still can't reproduce your 403.

One question would tell us whether that wizard row is what matters: on the install where you skipped the wizard, does the actual Claude CLI request (the auto/claude-opus "Hello") succeed, or does it also fail? If it succeeds there and fails after the wizard step, the wizard row is the trigger and I'll go after it. If it fails there too, the cause is somewhere else.

[charleech]

@diegosouzapw Thank you for your response and guidance.

In the fifth test, I skipped the setup wizard and sent "Hello" to auto/claude-opus via Claude CLI, but it failed with:

[503] Service temporarily unavailable: all targets were skipped by pre-dispatch filters

Please refer to the screenshots and logs in the attached step-05.zip.

I hope this helps narrow down the issue. I'm happy to run further tests on a fresh installation if needed.

step-05.zip

[diegosouzapw]

@charleech Thank you, this fifth test is the most useful one so far, and it also corrects what I asked you: the wizard row is not the trigger.

What the new log shows: on a clean install with no connections at all (all connections (incl inactive): 0, blocked_forced=0, blocked_allowed=0), the keyless OpenCode lookup returns nothing (No credentials for opencode), so every target is skipped and you get 503 all targets were skipped by pre-dispatch filters.

That is not what I get when I run the same lookup in tests on the v3.8.51 code and on the development line: with zero connections and the same keyless pin, I get the keyless connection back every time. So something in your environment makes it return nothing, and the log doesn't say what. Three quick checks, in this order, would narrow it a lot:

1. Direct request, no auto-combo. Send one request with the model set to oc/big-pickle (using your API key, to /v1/chat/completions). If that works, the problem is only in how the auto-combo reaches the keyless connection; if it fails the same way, the keyless path itself is blocked on your install.
2. The plain image. Run the same fresh test with diegosouzapw/omniroute:3.8.51 (without -web) and tell us if the result is the same.
3. Settings. On the fresh install, does Settings → Security → Blocked Providers have OpenCode Free selected, or does Providers → OpenCode Free show a switch for the keyless fallback turned off? In the earlier screenshot the chips all looked the same, so I couldn't tell.

I'm not guessing a cause yet. The missing log line for exactly this case is #15889.

[charleech]

Thank you for your response and guidance.

I am currently using diegosouzapw/omniroute:3.8.51 to run all the test cases described below.

Case 1: Skipping the Onboarding Wizard

1. Skip the entire onboarding wizard.
2. Create an API key and use it with Claude CLI, specifying the model auto/cluade-opus.
3. The server returns [503] Service temporarily unavailable: all targets were skipped by pre-dispatch filters.
4. Please refer to the attached step-01.zip for details.

Case 2: Using OpenCode's Free Tier

1. Continue from Case 1.

2. Use Claude CLI with the same API key created in Case 1, specifying the model oc/big-pickle.

3. The server returns the following error:

   [403]: OpenCode's free tier can only be used from within OpenCode.

4. Please refer to the attached step-02.zip for details.

Screenshots and Configuration

1. Please refer to the attached step-03.zip.
2. Under Settings → Security → Blocked Providers, the screenshots confirm that none of the three providers—OpenCode Free, OpenCode Zen, or OpenCode Go—is blocked.
3. The keyless fallback switches are enabled for OpenCode Zen and OpenCode Go. For OpenCode Free, the corresponding switch is labeled No authentication required, and it is also enabled.

Case 4: Testing with a Fresh Installation and the Onboarding Wizard

1. Start a fresh OmniRoute Docker container with a clean configuration.

2. This time, complete the onboarding wizard and enable only OpenCode Free.

3. Create an API key and use it with Claude CLI, specifying the model auto/cluade-opus.

4. The server returns the following error:

   403 [opencode] 1 connection(s) exist but are excluded by this API key's connection allowlist / quota scope

5. Reconfigure the API key to use Only selected connections, and select only the OpenCode connection created by the onboarding wizard.

6. Use Claude CLI with the same API key and model auto/cluade-opus again.

7. The server returns the following error:

   [503] Service temporarily unavailable: all targets were skipped by pre-dispatch filters

8. Please refer to the attached step-04.zip for details.

Summary

Based on my testing, both diegosouzapw/omniroute:3.8.51-web and diegosouzapw/omniroute:3.8.51 produce the same results when tested with a clean Docker installation.

I hope this additional information helps narrow down the root cause of the issue.

If you have any questions, need further information, or would like me to run additional tests using a fresh installation, please don't hesitate to let me know.

Thank you again for your time and assistance.

step-01.zip
step-02.zip
step-03.zip
step-04.zip

[diegosouzapw]

@charleech Thank you for the four cases. They make the picture a lot sharper. What I take from them (logs and text only; I did not open the screenshots of the settings pages):

• Case 2 is a different, expected thing. Sending oc/big-pickle directly gets as far as the upstream: the log says Using opencode account and then OpenCode itself answers 403: OpenCode's free tier can only be used from within OpenCode. So the keyless connection is found on a direct request, and that 403 comes from OpenCode's server, which only accepts requests shaped like its own client's. Claude CLI's requests aren't, so that's not an OmniRoute error and not something your settings can change.
• The auto-combo path is where it breaks. The same lookup, used by auto/claude-opus to decide whether a target is usable, returns nothing (No credentials for opencode, 0 connections, blocked_forced=0), so all 10 targets are skipped and you get the 503.
• With the wizard (case 4) the message is the misleading one: forcedId=noauth, blocked_forced=1, blocked_allowed=0: the one wizard row is filtered out by the combo's keyless pin and then it's reported as your key's allowlist. That wording is a bug of ours (fix(auth): a 403 blames 'this API key's allowlist' when no key was sent and the pool was emptied by a combo noauth pin — and the synthetic no-auth fallback declines silently #15889).

What I can't explain: I ran the combo's own lookup path (including the quota-preflight wrapper and a session key) with zero connections on the v3.8.51 tag and on the development line, and I always get the keyless connection back. So I still can't reproduce the empty result. Since everything else is identical, could you tell us how the container is started: the full docker run / compose (with secrets removed) and every OMNIROUTE_*, NOAUTH*/provider-related environment variable set in it? Something there is the next suspect.

For the 503 specifically, #16042 (merged into the 3.8.52 line) fixed a different problem (a partial OpenCode account sync hiding the free models), so don't expect it to change this one.

[charleech]

@diegosouzapw Thank you for your response and guidance.

As I mentioned in this discussion thread (#15540), I tested this using a fresh OmniRoute Docker container with a clean configuration. The setup is straightforward, with no special configuration, as described below.

OmniRoute

1. Start a fresh OmniRoute Docker container

docker run -d \
  --name omniroute \
  --restart unless-stopped \
  -p 20128:20128 \
  --network ai-tier \
  --env APP_LOG_LEVEL=debug \
  diegosouzapw/omniroute:3.8.51-web

2. Complete the initial setup

Access the OmniRoute console and complete the setup wizard, selecting only OpenCode Free as the provider.

3. Create an API key

Create an API key using all default settings.

Client

1. Start a separate, fresh Docker container to simulate the client environment

docker run -it --rm \
  --name omniroute-client \
  --network ai-tier \
  --entrypoint /bin/bash \
  node:26

2. Install Claude CLI inside the client container

curl -fsSL https://claude.ai/install.sh | bash

3. Set the required environment variables

export OMNIROUTE_API_KEY="sk-..."
export OMNIROUTE_URL="http://omniroute:20128"
export ANTHROPIC_BASE_URL="$OMNIROUTE_URL"
export ANTHROPIC_API_KEY="$OMNIROUTE_API_KEY"
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY="1"

4. Run Claude CLI

Launch Claude CLI and select auto/claude-opus as the model.

Cleanup

After completing the test, I stop the OmniRoute container and clean up unused Docker resources.

docker stop omniroute
docker container prune
docker volume prune

I hope this additional information helps narrow down the root cause of the issue.

If you have any questions, need further information, or would like me to run additional tests using a fresh installation, please don't hesitate to let me know.

Thank you again for your time and assistance.

[diegosouzapw]

@charleech Thank you for all the testing, it was a lot of work. An update that changes the picture: v3.8.52 was published on 2026-10-19 (npm latest and the Docker 3.8.52/latest tags), and in it the keyless OpenCode Free provider was removed (PR #16310, listed in docs/reference/REMOVED_PROVIDERS.md: a preventive removal by the project owner, honoring a public request from the OpenCode operator). Authenticated OpenCode Zen and OpenCode Go stay, and a legacy connection that carried an API key is moved to Zen by a migration.

What this means for this thread, as I read the code and that doc: on 3.8.52 the auto/* pool no longer contains the keyless oc/* models, so the empty-pool and 403 paths we were chasing for that provider no longer exist there. I never reproduced your 503, so I can't tell you that the removal "fixes" it, only that it removes that route from the pool. If you upgrade and auto/claude-opus still answers 503, please tell us the new log lines (with APP_LOG_LEVEL=debug), since then it would be a different cause.

[charleech]

@diegosouzapw

Thank you for your response and guidance.

I have updated the image to diegosouzapw/omniroute:3.8.52-web and retested using auto/claude-opus. The 403 error no longer occurs; however, the provider returned the following error:

devin-cli-agentic [500]: DEVIN_AGENTIC_HOME must be an absolute path inside the bridge sandbox

In my opinion, version 3.8.52-web appears to have fixed the original issue that caused the 403 error.

Please note that I have also attached app.log and the curl command to query candidate results for your reference.

Thank you again for your time and assistance.

step-01.zip