fix(models): resolve openrouter compat aliases by vincentkoc · Pull Request #68579 · openclaw/openclaw

vincentkoc · 2026-04-18T13:34:24Z

Summary

Problem: openrouter:free and openrouter:auto fall through the providerless model path, so openrouter:free gets mis-resolved under the default provider and openrouter:auto is not treated as the canonical OpenRouter auto model.
Why it matters: users see nonsense like anthropic/openrouter:free and then hit unknown-model failures even though the issue is only the compatibility alias resolver.
What changed: parseModelRef now normalizes openrouter:auto to the canonical openrouter/auto ref, and configured-model resolution now maps openrouter:free to the first configured concrete openrouter/...:free model from allowlist/config instead of shoving it under the default provider.
What did NOT change (scope boundary): this PR does not hardcode a specific vendor free model, and it does not touch OpenRouter baseUrl repair or reasoning_details parsing.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Bug]: OpenRouter compatibility aliases: openrouter:free resolves to anthropic/openrouter:free; openrouter:auto should also be handled explicitly #57066
Related [Bug]: native OpenRouter model openrouter/openrouter/free returns incomplete turn payloads=0 #68185
Related fix(models): resolve openrouter:free and openrouter:auto compatibility aliases #57456
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: providerless model parsing only split on /, so OpenRouter compatibility aliases using : never got their own path and were treated like bare model names under the default provider.
Missing detection / guardrail: there was no regression coverage for OpenRouter compatibility aliases in either generic parsing or configured-model resolution.
Contributing context (if known): a previous attempt hardcoded openrouter:free to one vendor model, but that is the wrong architectural shape because the right free target depends on user config.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/agents/model-selection.test.ts
Scenario the test should lock in: openrouter:auto resolves canonically, and openrouter:free resolves to a configured concrete free OpenRouter model instead of the default provider.
Why this is the smallest reliable guardrail: the bug is entirely in model parsing and configured-model resolution.
Existing test that already covers this (if any): none for these aliases before this PR.
If no new test is added, why not: N/A

User-visible / Behavior Changes

openrouter:auto now resolves to openrouter/auto.
openrouter:free now resolves to the first configured concrete openrouter/...:free model when one exists.
OpenClaw no longer rewrites those aliases under the default provider.

Diagram (if applicable)

Before:
openrouter:free -> providerless fallback -> anthropic/openrouter:free -> unknown model

After:
openrouter:free -> configured OpenRouter free model lookup -> openrouter/<vendor>/<model>:free

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (No)
New/changed network calls? (No)
Command/tool execution surface changed? (No)
Data access scope changed? (No)
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: macOS
Runtime/container: local dev worktree
Model/provider: OpenRouter model selection
Integration/channel (if any): N/A
Relevant config (redacted): agent default model set to openrouter:auto or openrouter:free

Steps

Configure an agent default model as openrouter:auto or openrouter:free.
Include at least one concrete openrouter/...:free model in the allowlist or models.providers.openrouter.models for the free case.
Resolve the configured model ref.

Expected

openrouter:auto resolves to openrouter/auto.
openrouter:free resolves to a concrete configured OpenRouter free model.

Actual

The aliases were treated as bare providerless strings and could fall back to the default provider.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios: ran pnpm test:serial src/agents/model-selection.test.ts and confirmed the new parse case plus both configured resolution paths.
Edge cases checked: openrouter:auto; openrouter:free via allowlist config; openrouter:free via models.providers.openrouter.models when allowlist is absent.
What you did not verify: live OpenRouter execution against a real account.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: openrouter:free could resolve to an unexpected free model when multiple concrete free models are configured.
- Mitigation: the behavior is deterministic and intentionally follows first configured model order; it avoids hardcoded vendor bias and keeps the alias tied to the user’s own config.

greptile-apps · 2026-04-18T13:43:33Z

Greptile Summary

This PR fixes the mis-resolution of openrouter:auto and openrouter:free compatibility aliases. parseModelRef now intercepts openrouter:auto before the slash-split logic and returns the canonical openrouter/auto ref; configured model resolution adds resolveConfiguredOpenRouterCompatAlias to also handle openrouter:free by scanning the configured allowlist and provider models for a concrete :free model. Tests are added for both paths and the CHANGELOG is updated.

Confidence Score: 5/5

Safe to merge — core fix is correct and well-tested; all remaining findings are style/cleanup suggestions.

The fix correctly handles both aliases: openrouter:auto is resolved globally via parseModelRef, and openrouter:free is resolved in configured-model paths. Three new test cases pin the regression. No P0/P1 issues found.

CHANGELOG.md (wrong version block + mid-section insertion); src/agents/model-selection.ts (minor indirection and known gap in interactive model-switch path for openrouter:free).

Comments Outside Diff (1)

src/agents/model-selection.ts, line 783-834 (link)

openrouter:free still mis-resolves through the interactive model-switch path

resolveAllowedModelRef (used for runtime model switching) calls resolveModelRefFromString → parseModelRef. Because parseModelRef only special-cases openrouter:auto, a user who types openrouter:free in the model picker will still get {provider: <defaultProvider>, model: "openrouter:free"} — the same wrong behavior the PR fixes for configured defaults.

openrouter:auto is fully fixed in all paths because parseModelRef handles it globally; openrouter:free remains a configured-default-only fix. Worth tracking as a follow-up if users are expected to use the alias interactively.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/agents/model-selection.ts
Line: 783-834

Comment:
**`openrouter:free` still mis-resolves through the interactive model-switch path**

`resolveAllowedModelRef` (used for runtime model switching) calls `resolveModelRefFromString` → `parseModelRef`. Because `parseModelRef` only special-cases `openrouter:auto`, a user who types `openrouter:free` in the model picker will still get `{provider: <defaultProvider>, model: "openrouter:free"}` — the same wrong behavior the PR fixes for configured defaults.

`openrouter:auto` is fully fixed in all paths because `parseModelRef` handles it globally; `openrouter:free` remains a configured-default-only fix. Worth tracking as a follow-up if users are expected to use the alias interactively.

How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: CHANGELOG.md
Line: 121

Comment:
**CHANGELOG placement: wrong section and mid-block insertion**

The new entry lands inside the `## 2026.4.15` block (a past release, cut April 15) rather than in the `## Unreleased` section at the top, and it was inserted at line 121 — in the middle of that section's `### Fixes` list — rather than appended at the end. Per `CLAUDE.md`: *"in the active version block, append new entries to the **end** of the target section; do not insert new entries at the top of a section."*

Move the line to `## Unreleased → ### Fixes` and append it after the last existing entry in that block.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/agents/model-selection.ts
Line: 293-313

Comment:
**Redundant `parseModelRef` round-trip for `openrouter:auto`**

When `normalized === "openrouter:auto"`, this function calls `parseModelRef("openrouter:auto", ...)` which immediately re-hits the `OPENROUTER_AUTO_COMPAT_ALIAS` guard in `model-selection-normalize.ts` and calls `normalizeModelRef("openrouter", "auto", opts)` anyway. The double dispatch is harmless but adds a subtle indirection that makes the intent harder to read.

```suggestion
  if (normalized === "openrouter:auto") {
    return normalizeModelRef("openrouter", "auto", {
      allowPluginNormalization: params.allowPluginNormalization,
    });
  }
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/agents/model-selection.ts
Line: 783-834

Comment:
**`openrouter:free` still mis-resolves through the interactive model-switch path**

`resolveAllowedModelRef` (used for runtime model switching) calls `resolveModelRefFromString` → `parseModelRef`. Because `parseModelRef` only special-cases `openrouter:auto`, a user who types `openrouter:free` in the model picker will still get `{provider: <defaultProvider>, model: "openrouter:free"}` — the same wrong behavior the PR fixes for configured defaults.

`openrouter:auto` is fully fixed in all paths because `parseModelRef` handles it globally; `openrouter:free` remains a configured-default-only fix. Worth tracking as a follow-up if users are expected to use the alias interactively.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(models): resolve openrouter compat a..." | Re-trigger Greptile}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b3750120ec

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bd6a90a972

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b06e8d3e64

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-18T15:25:27Z

+  const openrouterCompatRef = resolveConfiguredOpenRouterCompatAlias({
+    cfg: params.cfg,
+    raw: trimmed,
+    defaultProvider: params.defaultProvider,
+  });


Preserve alias precedence for OpenRouter compat aliases

resolveAllowedModelRef now short-circuits through resolveConfiguredOpenRouterCompatAlias before alias lookup, so a user-defined alias named openrouter:free/openrouter:auto is ignored and resolves to the first configured compat target instead. This is a regression from prior behavior and also diverges from model-selection-resolve.ts, where resolveModelRefFromString still checks aliasIndex first; in practice the same config can resolve to different models depending on which resolver path is used.

Useful? React with 👍 / 👎.

* fix(models): resolve openrouter compat aliases * fix(models): cover openrouter free interactive alias * fix(models): mirror openrouter compat aliases in runtime resolver * fix(models): align openrouter free allowlist aliases

vincentkoc self-assigned this Apr 18, 2026

openclaw-barnacle Bot added agents Agent runtime and tooling size: S maintainer Maintainer-authored PR labels Apr 18, 2026

vincentkoc marked this pull request as ready for review April 18, 2026 13:38

greptile-apps Bot reviewed Apr 18, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

Comment thread src/agents/model-selection.ts

openclaw-barnacle Bot added size: M and removed size: S labels Apr 18, 2026

chatgpt-codex-connector Bot reviewed Apr 18, 2026

View reviewed changes

Comment thread src/agents/model-selection.ts

chatgpt-codex-connector Bot reviewed Apr 18, 2026

View reviewed changes

Comment thread src/agents/model-selection.ts

openclaw-barnacle Bot added size: L and removed size: M labels Apr 18, 2026

vincentkoc force-pushed the fix/openrouter-alias-cleanup branch from 3c65036 to adc0915 Compare April 18, 2026 15:12

vincentkoc added 4 commits April 18, 2026 08:18

fix(models): resolve openrouter compat aliases

d1b64a1

fix(models): cover openrouter free interactive alias

7d1ca26

fix(models): mirror openrouter compat aliases in runtime resolver

ec5b204

fix(models): align openrouter free allowlist aliases

b06e8d3

vincentkoc force-pushed the fix/openrouter-alias-cleanup branch from adc0915 to b06e8d3 Compare April 18, 2026 15:19

vincentkoc merged commit d13869a into main Apr 18, 2026
49 checks passed

vincentkoc deleted the fix/openrouter-alias-cleanup branch April 18, 2026 15:24

chatgpt-codex-connector Bot reviewed Apr 18, 2026

View reviewed changes

github-actions Bot mentioned this pull request Apr 18, 2026

📡 Upstream Digest — 2026-04-18 16:29 UTC curtismercier/openclaw-mods#608

Open

This was referenced Apr 18, 2026

[Bug]: OpenRouter provider not routing requests to models #67989

Closed

[Bug]: Openrouter wont work anymore after last update #68118

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(models): resolve openrouter compat aliases#68579

fix(models): resolve openrouter compat aliases#68579
vincentkoc merged 4 commits into
mainfrom
fix/openrouter-alias-cleanup

vincentkoc commented Apr 18, 2026

Uh oh!

greptile-apps Bot commented Apr 18, 2026 •

edited

Loading

Comments Outside Diff (1)

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Apr 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

vincentkoc commented Apr 18, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

greptile-apps Bot commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Comments Outside Diff (1)

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Apr 18, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

greptile-apps Bot commented Apr 18, 2026 •

edited

Loading