Repository navigation
fix(mod): dispatch native Claude workers on advertised model IDs - #115
Merged
Merged
Conversation
PBJ-2
requested changes
Oct 30, 2026
PBJ-2
left a comment
Owner
There was a problem hiding this comment.
Thanks — resolving the worker aliases through CLAUDE_WORKERS so the advertised version is the one that runs is the right fix, and it merges cleanly on current main (typecheck, test/mod 174/174, engine tests 341/341 here). The Windows job failure is the pre-existing one that #98 fixed; the failing test names are identical to main's at 1bd2580.
One change before merging:
- Don't put
@levelon a nativeclaude-*id.register.tsx(marker branch, ~L2256) now sendsclaude-sonnet-5-5@highformodel: 'sonnet'+[[ripple: sonnet@high]], andnative-models.test.tsx:74-84pins that. The router only splits@effortoff routed models; aclaude-*id is passed through byte for byte (routing.tsPASS), so the suffix would reach Anthropic as part of the model name. With[1m]in front it also defeats the CLI's trailing-[1m]strip (claude-sonnet-5-5[1m]@high). Native workers already get their effort through the spawn'seffortfield (register.tsx~L1912) — please carry the level there (or drop it) and update the test.
Smaller, optional:
if (e.resume) return next(e)(~L2193) also skips the disabled-provider and nested-worker denials. Skipping only the content rewrite on resume would keep the fail-closed policy from the 2026-10-25 decision in ARCHITECTURE.- Since the ids are now pinned, a retired model makes that worker fail hard instead of sliding to the CLI default. A line in ARCHITECTURE saying
CLAUDE_WORKERSmust be updated on a model change would help.
The router passes a claude-* id through byte for byte, so claude-sonnet-5-5@high would reach Anthropic as the model name and hide a trailing [1m] from the CLI's strip. The marker is still consumed; the level is dropped. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PBJ-2
approved these changes
Oct 30, 2026
PBJ-2
left a comment
Owner
There was a problem hiding this comment.
Pushed the one requested change onto this branch (d174d7b): a direct native marker's model now goes out as the bare concrete id, with no @level. Also merged current main. Engine tests 341/341 and test/mod 174/174 pass. Merging — thanks!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolve native Claude worker family aliases to the concrete model IDs already declared in
CLAUDE_WORKERSbefore dispatching a subagent.The catalogue advertises concrete Claude versions, but
spawnModel()previously returned aliases such assonnet. Claude Code resolved those aliases independently, so the dispatched version was not guaranteed to match the advertised worker. This is a product-level consistency fix, not a user-specific settings change.Scope
No global
settings.jsonedits, no router-wide replacement of explicitly selected older models, and no changes to the Auto mode security classifier.Validation
node --test test/mod/*.test.ts: 169 passed, 0 failed.npm run typecheck: passed.npm run check:mod: passed.git diff --check: passed.claude plugin test packages/mod: 329 passed, 9 failed, 338 total. All 37 newly added engine dispatch cases passed.The full engine suite is not green with the installed Claude Code 2.1.309 engine. I also ran it against an untouched worktree at the same upstream base: 292 passed, the same 9 tests failed, 301 total. Eight failures concern the existing
ui.viewAPI/tests; one concerns the existing Workflow spawn-rewrite test, which this engine disallows. The final branch introduces no additional failing test names. These compatibility failures were left unchanged rather than weakening the tests or altering unrelated behavior.The engine regressions intercept the actual
agent.spawndispatch boundary with external effects stubbed. No live inference, user configuration, or running router was changed by this PR.Windows CI baseline
The Windows job is still failing, but this is also true of the unchanged upstream base:
7e0c4ac, Windows job: 20 failed tests.1bd2580, Windows job: the same 20 failed test names, in the same order; no additional or missing failures.These failures are in existing CLI ownership/launcher/tray and remote filesystem tests, not the native Claude model-dispatch tests. Windows portability fixes are separately proposed in PBJ-2/clauderipple#98. They have not been folded into this focused PR, and Windows CI is not claimed to pass.