(Filed here because microsoft/amplifier-app-cli has issues disabled — this is an app-cli runtime bug.)
Setting routing.matrix in settings.yaml makes app-cli inject a hooks-routing entry into the mount plan with no source: field, appended after Bundle.prepare() has run (amplifier_app_cli/runtime/config.py, the "Routing matrix config injection" block). The module is in neither ~/.amplifier/registry.json nor the CLI environment, so it never downloads and the hook silently never mounts.
No foundation bundle mounts it either — grep -rn routing over bundles/anchors returns nothing, and amplifier run uses anchors by default.
Result: amplifier routing show prints a perfect role→model table while every delegation runs on the root session's model.
Why it hides well: a critique delegation often resolves to the same model the root session already uses — the obvious spot-check passes by coincidence. It only becomes visible when delegating to an agent whose frontmatter model_role maps to a different model than the root session (e.g. anchors:builder → coding), and the delegation comes back on the root model anyway. Confirmed via the session events.jsonl (llm:request model per delegation), not the model's self-report.
Ask: either resolve a real source: for the injected hook entry (the routing-matrix bundle pins one — git+https://github.com/microsoft/amplifier-module-hooks-routing@main), or fail loudly at boot when a mount-plan entry has no resolvable source — anything but silently disabling the feature the settings key just enabled.
Workaround: a minimal user app bundle (~/.amplifier/bundles/routing-hook.md) that mounts hooks-routing with a pinned source:, registered via bundle.app in settings — restores routing for amplifier run delegations.
🤖 Generated with Claude Code
(Filed here because
microsoft/amplifier-app-clihas issues disabled — this is an app-cli runtime bug.)Setting
routing.matrixinsettings.yamlmakes app-cli inject ahooks-routingentry into the mount plan with nosource:field, appended afterBundle.prepare()has run (amplifier_app_cli/runtime/config.py, the "Routing matrix config injection" block). The module is in neither~/.amplifier/registry.jsonnor the CLI environment, so it never downloads and the hook silently never mounts.No foundation bundle mounts it either —
grep -rn routingoverbundles/anchorsreturns nothing, andamplifier runusesanchorsby default.Result:
amplifier routing showprints a perfect role→model table while every delegation runs on the root session's model.Why it hides well: a
critiquedelegation often resolves to the same model the root session already uses — the obvious spot-check passes by coincidence. It only becomes visible when delegating to an agent whose frontmattermodel_rolemaps to a different model than the root session (e.g.anchors:builder→coding), and the delegation comes back on the root model anyway. Confirmed via the sessionevents.jsonl(llm:requestmodel per delegation), not the model's self-report.Ask: either resolve a real
source:for the injected hook entry (the routing-matrix bundle pins one —git+https://github.com/microsoft/amplifier-module-hooks-routing@main), or fail loudly at boot when a mount-plan entry has no resolvable source — anything but silently disabling the feature the settings key just enabled.Workaround: a minimal user app bundle (
~/.amplifier/bundles/routing-hook.md) that mountshooks-routingwith a pinnedsource:, registered viabundle.appin settings — restores routing foramplifier rundelegations.🤖 Generated with Claude Code