Claude Platform on AWS gets new capabilities fast — typically same-day with the first-party Claude API, including beta features enabled through the standard anthropic-beta header. That velocity is a gift and a hazard: the platform will never force you to wait, so you have to be the one who decides when a change reaches users. Feature flags — runtime switches evaluated per request, managed outside your code — are how mature teams do that. This article covers what to flag, how workspaces make rollouts safer, and what to measure before going to 100%.
What deserves a flag
Flag anything that changes model behavior or cost, not just "features" in the product sense: a model upgrade (say, moving a workload from claude-sonnet-5 to claude-opus-4-8), a new system prompt version, enabling a server-side tool like web search or code execution, turning on a beta capability via anthropic-beta, or changing max_tokens and thinking settings. Each of these can shift quality, latency, and spend at once. A flag definition should carry the whole request "recipe" — model ID, prompt version, tool list, headers — so a variant is one coherent, named configuration rather than five independent toggles that can combine in untested ways.
from anthropic import AnthropicAWS
client = AnthropicAWS()
VARIANTS = {"control": {"model": "claude-sonnet-5", "prompt_v": "v14"},
"candidate": {"model": "claude-opus-4-8", "prompt_v": "v15"}}
def answer(user_id: str, question: str):
name = flags.variant("assistant-upgrade", user_id) # your flag service
v = VARIANTS[name]
resp = client.messages.create(model=v["model"], max_tokens=1024,
system=load_prompt(v["prompt_v"]),
messages=[{"role": "user", "content": question}])
log.info("claude_call", variant=name, model=v["model"],
in_tok=resp.usage.input_tokens, out_tok=resp.usage.output_tokens)
return respOne caching note for percentage rollouts: prompt caches key on the model and prompt prefix, so each variant warms its own cache. A 1% slice of traffic may never amortize its cache writes — expect slightly worse cache economics during the ramp and don't read that as a regression.
Workspaces as the hard backstop
Flags are application-layer and can be misconfigured; workspaces give you an infrastructure-layer backstop. Point early-stage variants at a separate workspace (workspace IDs are per-client configuration), and you get three things flags alone can't provide. Blast-radius control: quota and usage roll up per workspace, so a runaway candidate variant exhausts its own limits, not production's. Cost attribution: the experiment's spend is cleanly separated in per-workspace cost rollups — no tagging discipline required. Hard access control: IAM policies bind to workspace ARNs, so only the services meant to run the experiment can even reach the experimental workspace; and if a capability should stay off entirely for some principals, IAM deny statements (for example, denying CreateBatchInference and CreateFile on a workspace ARN, per Anthropic's documented lockdown pattern) enforce it below the application layer. Note that beta variants of a route need no separate IAM action, so IAM cannot gate "beta vs. GA" — that distinction is the flag system's job.
Measure before you widen
A staged rollout is only as good as its readout. On Claude Platform on AWS the programmatic Usage and Cost Admin APIs are not available, so plan to rely on your own telemetry: log the variant name, model, token counts from the usage object, latency, and error codes on every call (the Claude Console's usage and cost pages give per-workspace rollups as a cross-check). Compare variants on four axes before widening: quality (task success rate, human-review or evaluation-suite scores), latency (p50/p95 per variant), cost per request (token counts multiplied by list prices — remember output tokens usually dominate), and failure modes (429s, refusals, truncations). Ramp on a schedule with explicit gates — 1%, 5%, 25%, 100% — and make the rollback action literally one flag change.
Where to go next
Prompt versioning — the other half of the recipe — is covered in System Prompt Management Across Workspaces. For the telemetry to power your readouts, see Observability for Claude Platform on AWS Workloads, and for the workspace mechanics, workspace isolation.