Let explicit selectors route unverifiable ARNs to BedrockInvokeModel

[samuelboland]

Problem

invoke_model? consults anthropic_model? before the selector, so an application-inference-profile ARN with no provider_name metadata can never route to InvokeModel — even when an Array or Proc selector opts in explicitly. The refusal warning's own advice ("Use an Array or Proc selector with bedrock_use_invoke_model to opt in explicitly") is impossible to follow.

This breaks agents_app in staging/production: chats there use application-inference-profile ARNs as model ids (cost-allocation tagging), and every chat is created with assume_model_exists: true, which builds Model::Info.default — no registry metadata ever reaches the request-time model object. Result: with the BEDROCK_INVOKE_MODEL flag on, every request silently fell back to Converse, where with_thinking(effort:) renders as a bare reasoning_effort field that Anthropic rejects with a 400 ("reasoning_effort: Extra inputs are not permitted") — on every model.

Fix

Split vendor verification into two tiers:

• Provably non-Anthropic ids (known vendor prefixes — amazon., meta., etc., bare or cross-region like us.amazon.) are never routed, under any selector. The InvokeModel payload is Anthropic Messages format and would be rejected.
• Unverifiable ids (ARNs whose Model::Info carries no provider_name) route when the selector opts in explicitly (Array listing the id, or Proc returning truthy). An operator naming the exact id is the verification.
• Only the blanket true selector still requires positive verification via anthropic_model?, since it expresses "all Anthropic models", not "this specific model".

Verified against the exact production scenario: Model::Info.default(<staging profile ARN>, 'bedrock') with a Proc selector now routes to BedrockInvokeModel; us.amazon.nova-pro-v1:0 under the same Proc still routes to Converse. Full suite: 1628 examples, 0 failures.

🤖 Generated with Claude Code

[staging-supernova-dx-appf-io]

🤖 Supernova Code Review — View trace

[staging-supernova-dx-appf-io]

The fix is logically correct and well-motivated. The two-tier vendor verification — hard-blocking known non-Anthropic prefixes at the top of invoke_model? while letting Array/Proc selectors bypass anthropic_model? for unverifiable ARNs — cleanly solves the problem described. Test coverage is thorough, including the key negative cases (non-Anthropic ids stay on Converse even under a permissive Proc selector).

Two minor observations inlined; neither is a blocker.

---

🔁 Re-run this review

[staging-supernova-dx-appf-io]

nit: the optional geo-prefix segment [a-z0-9-]+ in NON_ANTHROPIC_PATTERN is unboundedly wide — it would treat any single-dot-prefixed string (e.g. a hypothetical "foo.amazon.x") as a cross-region non-Anthropic id. The existing cross-region geo codes are all short (us, eu, apac, global, jp, au, us-gov), so a tighter bound like [a-z]{2,6}(?:-[a-z]+)? would make the intent clearer and prevent surprise matches on longer prefixes. Low severity since real Bedrock model IDs don't look like that today.

[staging-supernova-dx-appf-io]

The before { allow(RubyLLM.logger).to receive(:warn) } stub is shared across all four examples in this context, but the three cases that bypass anthropic_model? (Array, Proc-true, Proc-false) never actually trigger the warning path. Consider adding a negative assertion to the first two cases (expect(RubyLLM.logger).not_to have_received(:warn)) to confirm the warning is silenced by bypassing anthropic_model? rather than by coincidence. The test for the true selector case at line 256–260 already does this correctly.