Custom routing config in openclaw.json is silently ignored

[jeegankones]

I defined custom routing tiers in openclaw.json under plugins.entries.clawrouter.config.routing, but the proxy always starts with the default routing config. No errors or warnings, it just silently uses defaults.

After digging into the source, I found the cause: register(api) gets called twice during OpenClaw's gateway startup. The first call happens in a pre-gateway phase before openclaw.json has been read, so api.pluginConfig is empty. The proxy starts with DEFAULT_ROUTING_CONFIG at this point. Then proc.__clawrouterProxyStarted gets set to true, which causes the second register() call (the one that actually has the user's config in api.pluginConfig) to bail out immediately.

You can see this in the gateway log: the timestamp-less [plugins] lines (pre-gateway phase) appear before [gateway] loading configuration…, and all subsequent timestamped calls log "Proxy already started by earlier register() call - skipping".

This means plugins.entries.clawrouter.config.routing effectively does nothing for anyone.

Repro: Define any custom tiers in openclaw.json, restart the gateway, check blockrun/logs/usage-*.jsonl. Routed models will match DEFAULT_ROUTING_CONFIG, not the user config.

Version: @blockrun/clawrouter@0.12.139, OpenClaw 2026.4.9

[1bcMax]

Fixed in v0.12.142.

Your diagnosis was exactly right — the first register() call had empty pluginConfig and was tripping the proxyAlreadyStarted guard before the second call (with the populated config) had a chance to run.

Fix: when pluginConfig is empty, defer proxy startup for 250ms. If a second register() arrives within that window with populated config, it cancels the deferred timer and takes over. If no second call ever comes (e.g. user with no plugin config), the timer fires and the proxy starts with defaults — no deadlock.

Upgrade with:

curl -fsSL https://blockrun.ai/ClawRouter-update | bash

After upgrading, your plugins.entries.clawrouter.config.routing (and walletKey, maxCostPerRun, etc.) will actually be honored. You can verify in the gateway log — the second register() call should now log Superseding earlier deferred proxy start — using current pluginConfig instead of Proxy already started by earlier register() call.

Thanks for the precise root-cause writeup.