fix(harness-pi): resolve compound provider/id model ids under their scoped provider - #18334

This PR is fully authored by Opus 5 and Sonnet 5 using Claude Code harness.

Here's a message from Opus regarding this change

Root cause. createPiModelResolver matched catalog entries with flat equality only (packages/harness-pi/src/pi-model-resolver.ts:42-43 before this change): m.id === effectiveId || m.name === effectiveId. That never inspects the separate provider field, so a compound id only ever matched a provider that happens to store the whole compound string as its own flat id, which is what the routing proxies do.

The id is not dropped, it resolves to the wrong provider. ModelRegistry.getAll() returns the full static catalog for every builtin provider with no credential filtering (model-registry.js:18-20 into model-runtime.js:192-194; the auth-filtered list is the separate getAvailable(), which this resolver never calls). vercel-ai-gateway registers its whole model table unconditionally, and that table contains an entry whose flat id is literally "xai/grok-4.3". So for a user with only xai credentials: useGateway is false, the gateway-preference clause short-circuits, and the unrestricted models.find(matches) returns the gateway entry, which builtinProviders() registers ahead of xai. Pi then dispatches through a provider the user never configured and fails with "No API key found for vercel-ai-gateway".

The fix is one new tier, and its position is the whole subtlety. Resolution order is now:

1. when gateway credentials are present, the vercel-ai-gateway flat match (pre-existing)
2. the new provider-scoped match: split on the first /, then m.provider === prefix && (m.id === bareId || m.name === bareId)
3. the unrestricted flat match (pre-existing)

The scoped tier deliberately sits after the gateway preference. Gateway and OpenRouter entries legitimately carry another provider's id verbatim as their own flat id (vercel-ai-gateway has an entry whose id is literally "xai/grok-4.3", alongside the native xai entry with bare id: "grok-4.3"), and when the user has gateway credentials, routing through the gateway is what they asked for. I originally placed the scoped tier first, which regressed exactly that case; the automated review on an earlier commit caught it, and the added tests now pin both directions.

Why ordered tiers rather than one predicate. Folding the scoped check into the existing matches predicate would make a single find() return whichever entry sits earlier in the catalog array, so a proxy entry could beat the real one by array position. Separate tiers make the outcome deterministic. Two tests assert this in both catalog orderings.

Why not delegate to Pi's own resolveCliModel. It is a public export from @earendil-works/pi-coding-agent and does the same slash-split, but adopting it would also replace the harness-specific vercel-ai-gateway preference tier, and it returns a richer result shape (warning/error/thinkingLevel) that the adapter does not consume. This keeps the change inside the existing tier structure.

Scope. Matching logic only. #18155 makes an unresolved model id throw instead of being silently dropped; that is a different failure mode from this one (here the id resolves, just to the wrong provider), and it is left to that PR. #18147 and #18153 share the symptom but have a different root cause again (customEnv registering credentials without corresponding catalog entries).

No reproduction example was added under examples/: the bug is pure catalog-matching logic covered by the unit tests, and reproducing it end to end would require live xai plus gateway credentials just to surface the symptom.

Background

I have pi authenticated with xai on my machine. Passing xai/grok-4.3 to HarnessAgent apparently routed to vercel-ai-gateway, meanwhile xai/grok-4.3 is a valid pi's modelId (<provider-id>/<provider-model-id>). For example pi --model "xai/grok-4.3" -p "hello" is a valid expected syntax for grok-4.3 from xai provider.

Summary

Compound <provider>/<model-id> ids were only matched literally, against a provider's flat id. That happens to work for routing proxies like vercel-ai-gateway, which store the compound string as their own id, but never for a native provider like xai, whose entry is provider: "xai" + id: "grok-4.3". So xai/grok-4.3 silently landed on the gateway entry instead. Added provider-scoped matching so these resolve to the provider the id actually names.

End-to-End Verification

Added unit tests in packages/harness-pi/src/pi-model-resolver.test.ts for compound provider/id and provider/name resolution, the gateway and scoped tiers against each other in both catalog orderings, and fallthrough to flat matching.

• pnpm test:node (packages/harness-pi): 126 tests passed.
• pnpm type-check:full (root): passed.
• oxfmt and oxlint: clean on both changed files.

Checklist

• All commits are signed (PRs with unsigned commits cannot be merged)
• Tests have been added / updated (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)
• A patch changeset for relevant packages has been added (for bug fixes / features - run pnpm changeset in the project root)
• I have reviewed this pull request (self-review)

Related Issues

Related to #18155, #18147, #18153 (see the collapsed summary above for how each relates).