openclaw - ✅(Solved) Fix active-memory: hardcoded default fallback model is expensive and assumes OpenAI [1 pull requests, 1 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#64884Fetched 2026-04-12 13:26:23
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
Participants
Timeline (top)
closed ×1cross-referenced ×1

Error Message

  1. Architecturally wrong: If no OpenAI connection is configured (common in BYOK setups), falling back to an OpenAI model makes no sense — it should log an error and fail, not silently substitute an unconfigured provider
  • Fail loudly with a clear error if no valid provider is configured, rather than silently routing to an unconfigured provider

Fix Action

Workaround

Set modelFallbackPolicy: "resolved-only" and ensure a valid free model is configured.

PR fix notes

PR #65047: fix(active-memory): remove built-in fallback model

Description (problem / solution / changelog)

Summary

  • remove the built-in hardcoded Active Memory fallback model from runtime resolution
  • add plugins.entries.active-memory.config.modelFallback as the explicit fallback path
  • keep modelFallbackPolicy only as a deprecated compatibility field with no runtime effect
  • update docs and extension tests to match the explicit-only fallback behavior

Why

Issue #64884 reports that Active Memory silently falls back to a hardcoded default model. That makes provider behavior surprising and can route traffic to an unintended provider/model.

This change makes fallback explicit:

config.model
-> current session model
-> agent primary model
-> config.modelFallback
-> stop

Verification

  • node scripts/run-vitest.mjs run --config test/vitest/vitest.extensions.config.ts extensions/active-memory/index.test.ts

Closes #64884

Changed files

  • docs/concepts/active-memory.md (modified, +9/-13)
  • extensions/active-memory/index.test.ts (modified, +5/-2)
  • extensions/active-memory/index.ts (modified, +27/-26)

Code Example

const DEFAULT_MODEL_REF = "github-copilot/gpt-5.4-mini";
RAW_BUFFERClick to expand / collapse

Bug Description

The active-memory extension has a hardcoded fallback model:

const DEFAULT_MODEL_REF = "github-copilot/gpt-5.4-mini";

When modelFallbackPolicy: "default-remote" is set AND the configured model fails (or modelFallbackPolicy is not set), active-memory silently falls back to this hardcoded model via OpenAI's API. This is problematic for several reasons:

  1. Expensive: GPT-5.4-mini is significantly more expensive than many capable alternatives that would be sufficient for memory recall tasks
  2. Assumes OpenAI: The fallback routes through OpenAI's API, ignoring the user's configured provider preferences
  3. No config override: There is no configuration option to set the fallback model — it's hardcoded in the extension source
  4. Silent failure with default-remote: Users may not realize their active-memory is making expensive OpenAI calls unless they monitor their API logs closely
  5. Architecturally wrong: If no OpenAI connection is configured (common in BYOK setups), falling back to an OpenAI model makes no sense — it should log an error and fail, not silently substitute an unconfigured provider

Expected Behavior

The fallback model should be:

  • Configurable via plugins.entries.active-memory.config.modelFallback (or similar)
  • Default to a free/cheap model suitable for memory recall (e.g. the same model used for embeddings, or a lightweight free model like nemotron)
  • Fail loudly with a clear error if no valid provider is configured, rather than silently routing to an unconfigured provider

Environment

  • OpenClaw: v2026.4.10
  • active-memory plugin

Workaround

Set modelFallbackPolicy: "resolved-only" and ensure a valid free model is configured.

extent analysis

TL;DR

Set modelFallbackPolicy to "resolved-only" and configure a valid free model to avoid silent fallbacks to the expensive hardcoded model.

Guidance

  • Configure modelFallbackPolicy to "resolved-only" to prevent silent fallbacks to the hardcoded model.
  • Set a valid free model in the configuration to use as a fallback, such as the same model used for embeddings or a lightweight free model like nemotron.
  • Verify that the configured model is being used by monitoring API logs or checking the active-memory plugin's behavior.
  • Consider setting up logging or monitoring to detect and alert on any unexpected fallbacks to unconfigured providers.

Example

No code snippet is provided as it is not explicitly mentioned in the issue, but an example configuration might look like:

{
  "plugins": {
    "entries": {
      "active-memory": {
        "config": {
          "modelFallbackPolicy": "resolved-only",
          "modelFallback": "nemotron"
        }
      }
    }
  }
}

Notes

This workaround assumes that the modelFallbackPolicy and modelFallback configuration options are available and functional in the active-memory plugin.

Recommendation

Apply the workaround by setting modelFallbackPolicy to "resolved-only" and configuring a valid free model, as this allows for more control over the fallback behavior and avoids silent fallbacks to the expensive hardcoded model.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING