openclaw - 💡(How to fix) Fix Feature: expose OpenRouter provider preference/pinning in model config [1 participants]

Summary

OpenRouter supports a provider field in the request body to control which backend handles the request (e.g. force Anthropic direct, or prefer Bedrock). OpenClaw does not expose this as a configurable model param, making it impossible to pin OR requests to a stable backend for prompt cache reuse.

Problem

When OR routes consecutive requests to different backends (e.g. Bedrock node A → Bedrock node B, or Bedrock → Anthropic direct), each request gets a cold cache. Prompt cache hit rate drops to near zero even with cacheRetention: "short" set.

Observed: OR Sonnet and Opus sessions cycling between Amazon Bedrock instances — cache stays at 23,535 tokens (system prompt only) instead of 100K+. When OR happens to stick to one backend for 2-3 consecutive requests, cache builds to 100%.

OpenRouter API

OR supports provider preferences natively:

{
  "provider": {
    "order": ["Anthropic"],
    "allow_fallbacks": false
  }
}

This pins the request to Anthropic direct (not Bedrock/Google), enabling proper prompt cache reuse.

Requested config

agents:
  defaults:
    models:
      "openrouter/anthropic/claude-opus-4-6":
        params:
          cacheRetention: "short"
          providerPreference:
            order: ["Anthropic"]
            allowFallbacks: false

Or alternatively, a simpler preferDirect: true shorthand that maps to {"order": ["Anthropic"], "allow_fallbacks": false} for Anthropic model refs.

Impact

Without this, cacheRetention on OR is effectively useless for large contexts (100K+) because OR load-balances across backends that don't share cache. Every turn costs full input price instead of cache-read price.

With Anthropic direct pinning: cache builds in 1-3 turns and stays warm, reducing per-turn cost by ~10× at 170K context.

Environment

• OpenClaw 4.5 (3e72c03)
• Model: openrouter/anthropic/claude-opus-4-6 and openrouter/anthropic/claude-sonnet-4-6
• Context size: 107K–173K tokens
• cacheRetention: "short" configured but ineffective due to backend switching

Related

Follows from #62974 (cache-aware sticky fallback). Even with sticky fallback, if OR itself load-balances across backends, cache will still bounce.