Problem
platform doctor's Bedrock check calls GetFoundationModel on the bare model id, stripped from the platform default. That answers "is this model in the catalog in this Region" — which is not the question that decides whether tasks work.
At invoke time the agent calls a cross-Region inference profile (<geo>.anthropic.…), and the IAM grant is scoped to explicit profile ARNs. So a stack can be granted profiles the account cannot invoke, and doctor still reports healthy.
Why it matters now
bedrockGeoRegion (#746) makes the geography a deploy-time choice, so there are more ways for the configured profile and the account's entitlements to disagree. Two failure modes doctor currently cannot see:
- the model has no profile published in the configured geography;
- the account's Bedrock access does not cover that geography's entitlements.
Both surface as AccessDenied at turn 0, with nothing in doctor pointing at the cause. Observed while verifying #747: doctor passed reporting anthropic.claude-sonnet-4-6 visible in us-east-1 while the deployment was configured for global.anthropic.claude-opus-5 — two different models and a geography it never looked at.
Suggested change
Probe what will actually be invoked:
- Resolve the configured geography (
bedrockGeoRegion, default us) — from stack outputs, or the same context resolution the CDK uses.
- Check the profile, not just the catalog:
GetInferenceProfile on <geo>.<modelId>, or a minimal InvokeModel if a real entitlement check is wanted.
- Report the profile id in the check label, so the output states what was verified.
Keep the catalog check as a second, narrower signal — it distinguishes "model does not exist here" from "profile exists but you cannot invoke it", and those need different fixes.
Scope
cli/src/platform-doctor.ts (checkBedrockModel), plus cli/test/platform-doctor.test.ts.
Not this issue
The geo-prefix strip in the same function was broken for global./us-gov./jp./au. and is fixed in #800 — that was a straight regression. This issue is the larger question of what the check probes, which is a behaviour change to doctor's output and deserves its own review.
Problem
platform doctor's Bedrock check callsGetFoundationModelon the bare model id, stripped from the platform default. That answers "is this model in the catalog in this Region" — which is not the question that decides whether tasks work.At invoke time the agent calls a cross-Region inference profile (
<geo>.anthropic.…), and the IAM grant is scoped to explicit profile ARNs. So a stack can be granted profiles the account cannot invoke, anddoctorstill reports healthy.Why it matters now
bedrockGeoRegion(#746) makes the geography a deploy-time choice, so there are more ways for the configured profile and the account's entitlements to disagree. Two failure modesdoctorcurrently cannot see:Both surface as
AccessDeniedat turn 0, with nothing indoctorpointing at the cause. Observed while verifying #747:doctorpassed reportinganthropic.claude-sonnet-4-6visible inus-east-1while the deployment was configured forglobal.anthropic.claude-opus-5— two different models and a geography it never looked at.Suggested change
Probe what will actually be invoked:
bedrockGeoRegion, defaultus) — from stack outputs, or the same context resolution the CDK uses.GetInferenceProfileon<geo>.<modelId>, or a minimalInvokeModelif a real entitlement check is wanted.Keep the catalog check as a second, narrower signal — it distinguishes "model does not exist here" from "profile exists but you cannot invoke it", and those need different fixes.
Scope
cli/src/platform-doctor.ts(checkBedrockModel), pluscli/test/platform-doctor.test.ts.Not this issue
The geo-prefix strip in the same function was broken for
global./us-gov./jp./au.and is fixed in #800 — that was a straight regression. This issue is the larger question of what the check probes, which is a behaviour change todoctor's output and deserves its own review.