Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Embedded runs send full model path to API instead of resolved model ID [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#48876•Fetched 2026-04-08 00:51:33
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
1
Author
sakol1986sakol1986
Participants
astroclawastroclawsakol1986sakol1986
Timeline (top)
cross-referenced ×3labeled ×2commented ×1

When switching models via /model command (embedded run), OpenClaw sends the full model path (e.g. provider/model-name) to the API instead of the resolved model ID. This breaks OpenAI-compatible proxies that don't accept provider prefixes.

Error Message

Embedded runs (/model in Telegram): sends polza/gpt-4o-mini -> API returns BAD_REQUEST error. Direct API calls (session_status with model override): sends gpt-4o-mini -> works correctly.

Root Cause

When switching models via /model command (embedded run), OpenClaw sends the full model path (e.g. provider/model-name) to the API instead of the resolved model ID. This breaks OpenAI-compatible proxies that don't accept provider prefixes.

Fix Action

Fixed

PR fix notes

PR #49541: fix: normalize same-provider embedded model refs

Description (problem / solution / changelog)

Summary

  • Problem: embedded runs could pass provider/model through to OpenAI-compatible proxies instead of the resolved model ID when the selected ref repeated the same provider prefix.
  • Why it matters: proxies such as polza.ai reject polza/gpt-4o-mini and expect gpt-4o-mini, so /model-selected embedded runs fail even though the configured model is valid.
  • What changed: retry embedded model resolution with the same-provider prefix stripped before provider fallback matching, and use the normalized ID for the fallback model payload.
  • What did NOT change (scope boundary): exact model resolution still runs first, and provider-qualified refs for other providers (for example OpenRouter dynamic models) are left intact.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #48876
  • Related #

User-visible / Behavior Changes

Embedded runs now normalize same-provider-qualified model refs like polza/gpt-4o-mini to gpt-4o-mini before provider fallback, so OpenAI-compatible proxy backends receive the configured model ID instead of the menu/display ref.

Security Impact (required)

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

Repro + Verification

Environment

  • OS: Windows 11
  • Runtime/container: Node 24.14.0 for targeted harness validation
  • Model/provider: polza/gpt-4o-mini and openrouter/healer-alpha
  • Integration/channel (if any): embedded runner model resolution
  • Relevant config (redacted): custom OpenAI-compatible provider with configured model gpt-4o-mini, provider headers, and model-specific overrides

Steps

  1. Configure a custom OpenAI-compatible provider with model gpt-4o-mini.
  2. Select polza/gpt-4o-mini in an embedded run.
  3. Resolve the embedded model configuration.

Expected

  • The resolved model sent to the proxy uses gpt-4o-mini.
  • Provider-level and model-level overrides still apply.

Actual

  • Before this change, embedded fallback resolution kept polza/gpt-4o-mini, and model-specific overrides keyed by gpt-4o-mini were skipped.

Evidence

Attach at least one:

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

Before fix (targeted harness): id = "polza/gpt-4o-mini", reasoning = false, headers only included the provider-level header.

After fix (same harness): id = "gpt-4o-mini", reasoning = true, headers include both provider-level and model-level overrides. The same harness also confirms openrouter/healer-alpha stays unchanged.

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: reproduced the failing fallback path in a targeted local harness built from the current source, then reran the same harness after the fix and confirmed the normalized ID plus restored model-specific overrides.
  • Edge cases checked: exact-match resolution still wins; OpenRouter-style provider-qualified refs continue to pass through unchanged.
  • What you did not verify: pnpm exec vitest for this file hangs in my current Windows environment, so I could not get the repo test runner to complete locally for this case.

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/No): Yes
  • Config/env changes? (Yes/No): No
  • Migration needed? (Yes/No): No
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this commit to restore the previous embedded fallback behavior.
  • Files/config to restore: src/agents/pi-embedded-runner/model.ts, src/agents/pi-embedded-runner/model.test.ts
  • Known bad symptoms reviewers should watch for: embedded runs stripping prefixes for provider-qualified refs that should remain untouched.

Risks and Mitigations

  • Risk: over-normalizing a provider-qualified ref that should stay qualified.
    • Mitigation: exact resolution still runs first, and the fallback strip only applies when the prefix matches the already selected provider.

Changed files

  • src/agents/pi-embedded-runner/model.test.ts (modified, +37/-0)
  • src/agents/pi-embedded-runner/model.ts (modified, +32/-4)

PR #49566: fix: normalize same-provider embedded model refs

Description (problem / solution / changelog)

Summary

  • Problem: embedded runs could pass provider/model through to OpenAI-compatible proxies instead of the resolved model ID when the selected ref repeated the same provider prefix.
  • Why it matters: proxies such as polza.ai reject polza/gpt-4o-mini and expect gpt-4o-mini, so /model-selected embedded runs fail even though the configured model is valid.
  • What changed: retry embedded model resolution with the same-provider prefix stripped before provider fallback matching, and use the normalized ID for the fallback model payload.
  • What did NOT change (scope boundary): exact model resolution still runs first, and provider-qualified refs for other providers (for example OpenRouter dynamic models) are left intact.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • UI / DX
  • API / contracts
  • CI/CD / infra

Linked Issue/PR

  • Closes #48876
  • Related #

User-visible / Behavior Changes

Embedded runs now normalize same-provider-qualified model refs like polza/gpt-4o-mini to gpt-4o-mini before provider fallback, so OpenAI-compatible proxy backends receive the configured model ID instead of the menu/display ref.

Security Impact (required)

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

Repro + Verification

Environment

  • OS: Windows 11
  • Runtime/container: Node 24.14.0 for targeted harness validation
  • Model/provider: polza/gpt-4o-mini and openrouter/healer-alpha
  • Integration/channel (if any): embedded runner model resolution
  • Relevant config (redacted): custom OpenAI-compatible provider with configured model gpt-4o-mini, provider headers, and model-specific overrides

Steps

  1. Configure a custom OpenAI-compatible provider with model gpt-4o-mini.
  2. Select polza/gpt-4o-mini in an embedded run.
  3. Resolve the embedded model configuration.

Expected

  • The resolved model sent to the proxy uses gpt-4o-mini.
  • Provider-level and model-level overrides still apply.

Actual

  • Before this change, embedded fallback resolution kept polza/gpt-4o-mini, and model-specific overrides keyed by gpt-4o-mini were skipped.

Evidence

Attach at least one:

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

Before fix (targeted harness): id = "polza/gpt-4o-mini", reasoning = false, headers only included the provider-level header.

After fix (same harness): id = "gpt-4o-mini", reasoning = true, headers include both provider-level and model-level overrides. The same harness also confirms openrouter/healer-alpha stays unchanged.

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: reproduced the failing fallback path in a targeted local harness built from the current source, then reran the same harness after the fix and confirmed the normalized ID plus restored model-specific overrides.
  • Edge cases checked: exact-match resolution still wins; OpenRouter-style provider-qualified refs continue to pass through unchanged.
  • What you did not verify: pnpm exec vitest for this file hangs in my current Windows environment, so I could not get the repo test runner to complete locally for this case.

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/No): Yes
  • Config/env changes? (Yes/No): No
  • Migration needed? (Yes/No): No
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this commit to restore the previous embedded fallback behavior.
  • Files/config to restore: src/agents/pi-embedded-runner/model.ts, src/agents/pi-embedded-runner/model.test.ts
  • Known bad symptoms reviewers should watch for: embedded runs stripping prefixes for provider-qualified refs that should remain untouched.

Risks and Mitigations

  • Risk: over-normalizing a provider-qualified ref that should stay qualified.
    • Mitigation: exact resolution still runs first, and the fallback strip only applies when the prefix matches the already selected provider.

Changed files

  • src/agents/pi-embedded-runner/model.test.ts (modified, +320/-0)
  • src/agents/pi-embedded-runner/model.ts (modified, +136/-22)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +8/-7)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

When switching models via /model command (embedded run), OpenClaw sends the full model path (e.g. provider/model-name) to the API instead of the resolved model ID. This breaks OpenAI-compatible proxies that don't accept provider prefixes.

Steps to reproduce

  1. Add a custom OpenAI-compatible provider (e.g. polza.ai) with model ID like gpt-4o-mini
  2. Model becomes available as polza/gpt-4o-mini in /model
  3. Switch to the model via /model polza/gpt-4o-mini
  4. Send a message
  5. OpenClaw sends model: polza/gpt-4o-mini to the API instead of model: gpt-4o-mini

Expected behavior

OpenClaw should resolve the model ID and send only gpt-4o-mini to the API, same as it does for direct session API calls (which work correctly).

Actual behavior

Embedded runs (/model in Telegram): sends polza/gpt-4o-mini -> API returns BAD_REQUEST error. Direct API calls (session_status with model override): sends gpt-4o-mini -> works correctly.

OpenClaw version

2026.2.25

Operating system

macOS 15.4 (arm64)

Install method

No response

Model

polza/gpt-4o-mini

Provider / routing chain

openclaw -> polza.ai (OpenAI-compatible proxy)

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Polza.ai API only accepts short model IDs (gpt-4o-mini) but not full paths (polza/gpt-4o-mini or openai/gpt-4o-mini). This is a common pattern for OpenAI-compatible proxies. The issue is that embedded runs do not resolve the model ID before sending to the API, while direct session API calls do resolve it correctly.

extent analysis

Fix Plan

To resolve the issue, we need to modify the OpenClaw code to extract the model ID from the full model path before sending it to the API.

Here are the steps:

  • Identify the function responsible for sending the model to the API in embedded runs.
  • Modify this function to split the full model path by '/' and extract the last part, which is the model ID.
  • Use this extracted model ID instead of the full model path when sending the request to the API.

Example code snippet in Python:

def send_model_to_api(model_path):
    # Split the model path by '/' and extract the last part (model ID)
    model_id = model_path.split('/')[-1]
    
    # Send the model ID to the API
    api_request = {'model': model_id}
    # ... rest of the API request code ...

# Example usage:
model_path = 'polza/gpt-4o-mini'
send_model_to_api(model_path)  # Sends {'model': 'gpt-4o-mini'} to the API

Verification

To verify that the fix worked, you can:

  • Switch to a custom model using the /model command in Telegram.
  • Send a message and check the API request sent by OpenClaw.
  • Verify that the API request contains the resolved model ID (e.g., gpt-4o-mini) instead of the full model path (e.g., polza/gpt-4o-mini).

Extra Tips

  • Make sure to test the fix with different custom models and providers to ensure it works correctly in all scenarios.
  • Consider adding logging or debugging statements to verify that the model ID is being extracted and sent to the API correctly.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

OpenClaw should resolve the model ID and send only gpt-4o-mini to the API, same as it does for direct session API calls (which work correctly).

#api#ssr#installation#tensor shape#request error#serialization error#model compatibility#GPU setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Embedded runs send full model path to API instead of resolved model ID [2 pull requests, 1 comments, 2 participants]