Skip to content

Pin declared Anthropic MPS targets by family, like Bedrock - #376

Open
masonc08 wants to merge 1 commit into
mainfrom
masonc08/pin-anthropic-mps-targets
Open

Pin declared Anthropic MPS targets by family, like Bedrock#376
masonc08 wants to merge 1 commit into
mainfrom
masonc08/pin-anthropic-mps-targets

Conversation

@masonc08

Copy link
Copy Markdown
Collaborator

Problem

ucode claude --provider <mps> sends whatever model string Claude Code's alias resolves to, and the gateway's direct-MPS path exact-matches that against the service's declared targets, then forwards it verbatim. For a Bedrock service ucode already pins ANTHROPIC_DEFAULT_*_MODEL to the service's target slugs — but for an API-key Anthropic service it pinned nothing and trusted Claude Code's canonical names to match the declared targets.

They often don't: a custom or dated target name, or an enterprise managed-settings pin like ANTHROPIC_DEFAULT_HAIKU_MODEL=system.ai.claude-haiku-4-5, makes the client send a name that isn't a declared target → gateway 403 … not in the allowed models list (and it wouldn't be a valid Anthropic model on egress either).

Fix

Extend resolve_provider_models to derive the {family: target} pin map for a non-relayed Anthropic service too — exactly as it already does for Bedrock. map_claude_family_models already handles canonical Anthropic ids (and yields nothing for non-Claude services), so the client now sends exactly the ids the MPS declares. Bedrock is unchanged; relayed Claude Max/Enterprise stays exempt (the gateway disables model selection server-side for that tier).

The managed (admin-manifest) path already pins Anthropic from authored slots, so this only closes the gap on the developer-configured path.

Caveat — managed-settings precedence

ucode writes ANTHROPIC_DEFAULT_*_MODEL into its --settings file; enterprise /etc/claude-code/managed-settings.json may outrank it. This fix reuses the exact mechanism Bedrock uses, so it takes effect wherever Bedrock MPS pinning already does. Decisive check: does a Bedrock MPS session pick up ucode's pinned slug on an Isaac-managed laptop today? If yes, this is sufficient everywhere; if no, both Bedrock and Anthropic need the separate managed-settings-scoping fix.

Testing

  • tests/test_agents_init.py: flipped test_anthropic_returns_no_modelstest_anthropic_pins_family_targets; added test_anthropic_with_no_claude_targets_pins_nothing.
  • 81 passed, ruff check clean. Bedrock and relayed behavior unchanged (existing tests green).

This pull request and its description were written by Isaac.

`ucode claude --provider <mps>` sends whatever model string Claude Code's alias
resolves to, and the gateway's direct-MPS path exact-matches that against the
service's declared targets (then forwards it verbatim). For a Bedrock service
ucode already pins ANTHROPIC_DEFAULT_*_MODEL to the service's target slugs, but
for an API-key Anthropic service it pinned nothing and trusted Claude Code's
canonical names to match — which they may not: a custom/dated target name, or an
enterprise managed-settings pin like `system.ai.claude-haiku-4-5`, yields a 403
"not in the allowed models list".

resolve_provider_models now derives the family->target map for a non-relayed
Anthropic service too (map_claude_family_models already handles canonical ids),
so the client sends exactly the ids the MPS declares. Bedrock is unchanged;
relayed Claude Max/Enterprise stays exempt (model selection is off server-side).

Co-authored-by: Isaac <no-reply@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant