GCP To AWS

Estimate Phase: AI Workload Cost Analysis

Loaded by estimate.md when aws-design-ai.json exists.

Execute ALL steps in order. Do not skip or optimize.

Pricing Mode

The parent estimate.md selects the pricing mode before loading this file.

Price lookup order:

1. references/vendored/ai/bedrock-pricing-cache.md (primary for Bedrock) — Look up Bedrock model and service pricing by table. Set pricing_source: "cached".

2. shared/pricing-cache.md (primary for source providers) — Look up Gemini and OpenAI source-provider comparison pricing by table. Set pricing_source: "cached".

3. Unavailable — If a model is NOT in the applicable cache, set pricing_source: "unavailable" and warn the user. An _unverified_ cache cell is blocking — do not use it as if it were a confirmed price.

For typical migrations (Claude, Llama, Nova, Mistral, DeepSeek, Gemma, OpenAI gpt-oss, Gemini source pricing), all prices are in the two caches. Zero MCP calls needed.

Model lifecycle: When building the model comparison table, check references/vendored/ai/ai-model-lifecycle.md and apply the 90-day exclusion rule:

• Excluded (≤90 days to EOL): omit entirely from model_comparison, recommended_model, and backup_model.

• Legacy (>90 days to EOL): include in model_comparison with (Legacy — EOL YYYY-MM-DD) annotation. Do not select as recommended_model unless no Active alternative exists.

• Active: no restrictions.

• Restricted (restricted (…) in the references/vendored/ai/bedrock-pricing-cache.md Status column — Covered Models such as Claude Fable 5 / 5.1, gated previews such as Claude Mythos): never recommended_model or backup_model. Include in model_comparison only when the user explicitly asked for a frontier model, annotated with the data-retention opt-in it requires.

Prerequisites

Read from $MIGRATION_DIR/:

• ai-workload-profile.json — current_costs.monthly_ai_spend, current_costs.services_detected, models[], metadata.profile_source, summary.inferred_from_iac

• openai-usage-profile.json (if present) — summary.monthly_cost_usd, usage_by_model[] (real per-model input/output token counts from the OpenAI Admin API). Check metadata.capture_warnings first: a failed usage endpoint means that category's volume is UNKNOWN, not zero — say so in the output and do not price the affected capability from this profile.

• openrouter-usage-profile.json (if present) — summary.monthly_cost_usd, usage_by_model[] (real per-model usage from the OpenRouter Activity API). Field names differ from the OpenAI profile: OpenRouter's rows use prompt_tokens/completion_tokens, NOT input_tokens/output_tokens — normalize to input_tokens/output_tokens when combining with an OpenAI profile's rows (prompt_tokens → input_tokens, completion_tokens → output_tokens). reasoning_tokens is already included IN completion_tokens (both OpenRouter's and OpenAI's usage accounting report it as a breakdown component of completion/output tokens, not a separate pool — a 125-completion/25-reasoning row means 125 output tokens total, 25 of them reasoning) — do NOT add reasoning_tokens on top of completion_tokens when computing output_tokens; that double-counts the reasoning portion. Check metadata.capture_warnings first, same rule as the OpenAI profile.

• anthropic-usage-profile.json (if present) — summary.monthly_cost_usd, usage_by_model[] (real per-model input/output/cache token counts from the Anthropic Admin API). Cache fields ARE additional volume, the opposite of OpenRouter's reasoning_tokens case: input_tokens in this profile is read from the Admin API's uncached_input_tokens field — it does NOT include cache_read_tokens or cache_creation_tokens. Anthropic's own accounting contract is total prompt tokens = uncached_input_tokens + cache_read_input_tokens + cache_creation_input_tokens — these are three mutually exclusive pools, not one field with sub-components nested inside it. When computing total token volume for pricing or capacity purposes, SUM all four fields: input_tokens + cache_read_tokens + cache_creation_tokens + output_tokens. Omitting the two cache fields silently drops most of the volume for a prompt-cached workload, since cache reads are typically the majority of a cached workload's input tokens. Check metadata.capture_warnings first, same rule as the other two profiles. Check metadata.cost_status before touching summary.monthly_cost_usd: cost_status: "cost_unavailable" means summary.monthly_cost_usd is null — the usage/token side is fine (feed it into Part 2 normally) but the dollar side must NOT be read as 0 or any other number; see the cost_status exception in Parts 1 and 2 below.

• preferences.json — ai_constraints.ai_token_volume.value, ai_constraints.ai_capabilities_required.value

• aws-design-ai.json — metadata.ai_source, ai_architecture.honest_assessment, ai_architecture.tiered_strategy, ai_architecture.bedrock_models[] (with source_provider_price, bedrock_price, honest_assessment), ai_architecture.capability_mapping

Traditional-AI workloads (not yet costed by this phase): design_blocks[] entries with target_aws_service set (capability document_extraction, image_analysis, or speech_transcription — Textract, Rekognition, Transcribe) are per-page/per-image/per-minute priced, not token priced, and this phase's cost model does not cover them yet. Skip these blocks in Parts 1–2 below; list them in the output under a services_not_estimated[] array ({workload_id, target_aws_service, reason: "not_token_priced"}) so the user knows they're excluded rather than assumed free.

Observed capacity

When a usage profile carries the fields below, use them. When a field is absent, the profile is a 30-day sum only — say that, and do not divide the month by the number of minutes and call the result a peak.

• On-demand quota uses peak.peak_input_tokens_per_minute and peak.peak_output_tokens_per_minute on rows whose batch is not true and whose service_tier is not batch. Batch and other tiers stay visible and are not added into that peak. day_to_average_ratio is the burst hint. Design persists quota_risk from this peak before Generate reads aws-design-ai.json, using the observed-peak rule in references/vendored/ai/bedrock-quotas.md. A low monthly volume tier does not stay quota_risk: "low" when that weighted on-demand peak is above the bar in that rule. Profiles with no usable peak keep the monthly table.

• A capture_warnings entry that names only usage-completions-hourly.json, usage-completions-minute.json, usage-messages-hourly.json, usage-messages-minute.json, or analytics-hourly.json means the peak is uncertain. Price the daily volume and cost. Do not treat that warning as a failed daily usage endpoint. A warning that names a daily usage or cost file still makes that capability's volume UNKNOWN.

• OpenAI cache fields are already inside input_tokens. Do not add input_cached_tokens or input_cache_write_tokens on top. Text, image, and audio splits describe modality. They are not extra volume.

• Anthropic cache fields stay additional volume, as in the prerequisites. cache_creation_5m_tokens and cache_creation_1h_tokens are the split of cache_creation_tokens. Price them separately when both are present, and do not add them on top of the sum. context_window 200k-1M is long-context pricing. inference_geo is where the provider ran the call, not the AWS region the customer requires. web_search_requests means the workload uses server-side web search.

• OpenRouter p95_latency_ms and p95_throughput_tokens_per_sec are observed speed, not a latency SLO. byok_fees_usd is the router fee, not inference. cached_tokens is a subset of prompt tokens. web_search_cost_usd and guardrail_invoked_count are feature flags. Do not split a mixed model's tokens with byok_request_count.

Part 1: Establish Current AI Costs

Determine current AI spending from the best available source:

1. current_costs.monthly_ai_spend (preferred whenever present) — from ai-workload-profile.json. This figure is already provider-aware: Discover merges billing-CSV (GCP/Vertex), OpenAI usage API, OpenRouter usage API, and Anthropic usage API spend there, summing across providers with source: "mixed" and a per-provider breakdown[]. Do NOT bypass it by reading a usage profile's summary.monthly_cost_usd directly — that drops the other providers of a mixed workload. When breakdown[] exists, carry the per-provider split into the comparison output. Partial-window check: if source is openai_usage_api, openrouter_usage_api, anthropic_usage_api, or mixed (with a breakdown[] entry whose source is one of those) AND the corresponding usage profile's metadata.partial_window is true (openai-usage-profile.json for the OpenAI portion, openrouter-usage-profile.json for the OpenRouter portion, anthropic-usage-profile.json for the Anthropic portion), that portion is not a monthly baseline — apply source 2's exception to it (reference figure only, labeled with active_days; for mixed, keep the other providers' portions from breakdown[] and cover the partial portion via sources 3–4).

2. Usage profile dollars (fallback) — Use summary.monthly_cost_usd from openai-usage-profile.json, openrouter-usage-profile.json, and/or anthropic-usage-profile.json ONLY when no current_costs exists (a standalone usage capture with no AI workload profile). If MULTIPLE profiles exist, SUM them — they measure different providers (OpenAI-direct vs OpenRouter vs Anthropic), so taking one drops the others' spend; present the per-provider split the same way a mixed current_costs.breakdown[] would. Partial-window exception applied PER PROFILE: if a profile's metadata.partial_window is true, that profile's window is too short to be a monthly baseline — do NOT rank its figure above sources 3–4; present its partial actuals as a reference figure only, labeled with active_days, and cover that provider's portion via sources 3–4 (keep the other profile(s)' full-window figure if not partial), applying this per profile (OpenAI, OpenRouter, or Anthropic). Second, parallel exception — cost_status (Anthropic profile only, currently the only profile that writes this field): if metadata.cost_status is "cost_unavailable", summary.monthly_cost_usd is null for that profile — exclude it from this SUM entirely (do not add null, and do not substitute 0); cover that provider's dollar portion via sources 3–4 instead, while its token volume still flows into Part 2 normally (see Part 2's cost_status note). This is a distinct failure mode from partial_window: partial_window means "window too short to be monthly," cost_unavailable means "usage is known, cost specifically is not" — a profile can be partial_window: false and still cost_status: "cost_unavailable".

3. Estimated from token volume — Use ai_constraints.ai_token_volume.value from preferences.json with source-provider pricing from pricing-cache.md (under "Source Provider Pricing"), matched to summary.ai_source: "gemini" → the Gemini table, "anthropic" → the "Anthropic (Standard Tier, 1P API)" table (Claude Haiku 4.5 / Sonnet 4.5 / Sonnet 5), "openai" → the OpenAI table. For "both" or "other", use whichever table(s) match the actual source model(s) in ai-workload-profile.json → models[]; if no table matches, this level does not apply — fall through to level 4. Apply 60/40 input/output ratio if actual ratio unknown. Do not pick that table from summary.ai_source for an OpenRouter workload. OpenRouter is a transport: discover-openrouter-api.md Step 4 leaves summary.ai_source as the SDK/provider family the code scan set, so an OpenRouter app can still say "openai" or "anthropic". Treat the workload as OpenRouter when aws-design-ai.json → code_migration.openrouter_path is set, or ai-workload-profile.json has a base_url containing openrouter.ai. pricing-cache.md has no source-side listed-price row for OpenRouter — level 3 does not apply to that OpenRouter portion (no usage profile and no current_costs, or a profile whose dollars were excluded above); fall through to level 4 for it. A direct, non-OpenRouter provider in the same run still uses its own table. Do not add new fallback pricing as a side effect of this gap.

4. None available — Note in output and present model comparison at multiple volume tiers so user can find their range.

Regardless of which dollar source wins, usage_by_model[] from EVERY usage profile that exists (openai-usage-profile.json, openrouter-usage-profile.json, and/or anthropic-usage-profile.json) remains the Part 2 token-volume source — not just whichever profile happened to be readable first. When more than one exists, combine their per-model rows (normalizing OpenRouter's prompt_tokens/completion_tokens to input_tokens/output_tokens, and INCLUDING Anthropic's cache_read_tokens/cache_creation_tokens in the sum — these are additional volume the Admin API reports separately from input_tokens, per the Prerequisites note) into one volume figure, the same SUM discipline as their dollar figures above — a token-volume comparison that reads only a subset of profiles while the dollar comparison above already summed all of them understates the workload by exactly the fraction the omitted profile(s) carry (subject to the same partial_window exception there, applied per profile).

Live CLI usage. When gcp-publisher-metrics-profile.json exists, its tokens are Gemini and Vertex publisher usage, including serverless Gemini that has no endpoint. Add its input_tokens and output_tokens to the Part 2 volume. The profile has no dollar field. A GCP billing CSV stays the dollar source. Do not add a second bill derived from these tokens. request_type shared is not provisioned quota. observed_p95_first_token_ms is the worst hour's p95, not the 30-day percentile and not a latency SLO. peak.peak_source "hour" means the maximum hour anywhere in the window, divided by 60, not the busiest hour of the busiest day. Say that when you use it as a quota starting point. Design already applied the observed-peak rule in bedrock-quotas.md. Do not recompute quota_risk from the monthly tier alone. Empty monitoring is not proof the project has no AI. Do not divide the month by the number of minutes and call the result a peak.

IaC-only profile: If metadata.profile_source is iac_vertex or summary.inferred_from_iac is true and billing/token data is missing, state explicitly that current GCP AI spend is unverified and widen uncertainty bands (use the same multi-tier comparison approach as in case 3).

Part 2: Build Model Comparison Table

Calculate the monthly Bedrock cost for every viable model at the user's token volume.

Token volume mapping (from ai_token_volume in preferences.json):

If design or discover phase has more specific token estimates, use those instead. In particular, when openai-usage-profile.json, openrouter-usage-profile.json, and/or anthropic-usage-profile.json exists with metadata.partial_window false, use its (their combined, if all are full-window) usage_by_model[] actual monthly token totals (and actual ratio) instead of the tier table — a real observed month beats a tier midpoint. Combine all profiles' rows the same way Part 1 combines their dollars: sum matching models by input_tokens/output_tokens, after normalizing OpenRouter's prompt_tokens/completion_tokens and INCLUDING Anthropic's cache_read_tokens/cache_creation_tokens in the sum (per the Prerequisites note — these are additional volume, not a sub-accounting of input_tokens) — a workload with 1M/0.1M tokens direct plus 9M/0.9M tokens via OpenRouter is a 10M/1M-token workload, not a 1M/0.1M one. Exception: if a profile's metadata.partial_window is true, a few days of tokens from THAT profile is NOT a monthly volume — projecting it as one understates the Bedrock estimate. Do NOT fall back to the ai_token_volume tier table for the partial profile's portion — that tier (when set by Clarify's auto-resolve, clarify-ai.md § Q18) was derived by summing ONLY the full-window profile(s), so it already represents a DIFFERENT provider's observed volume, not this partial one; substituting it infers a volume for the partial provider that was never actually observed for that provider. Instead: keep the other, full-window profile's actual totals for its own portion, and treat the partial profile's portion as unresolved — show its partial actuals as a reference figure labeled with active_days, plus explicit low/medium/high scenario rows (using the tier table's absolute volumes, each labeled "(scenario for the partial provider's portion, not derived from the other provider's volume)") so the comparison's sensitivity to that provider's true monthly volume is visible, rather than presenting one blended number as if it were fully data-derived. cost_status exception (independent of the partial_window exception above — a profile can trip one, both, or neither): metadata.cost_status: "cost_unavailable" does NOT disqualify a profile's token volume — token counts came from usage_report/messages, which succeeded; only cost_report failed. Include that profile's usage_by_model[] token totals in this volume sum as normal. The disqualification is dollar-only (Part 1 above): a cost_unavailable profile contributes volume here but no dollar figure there.

Cost formula: Monthly = (input_tokens / 1M × input_rate) + (output_tokens / 1M × output_rate)

Long-context pricing: If ai_critical_feature = "ultra_long_context", use the published rate for the exact model, source region, and inference profile. Opus 5.5 has no long-context surcharge: it uses the same per-token rates throughout its 1M context window (Global $4/$20, commercial Geo/Mantle $4.40/$22, GovCloud $4.80/$24 per 1M input/output tokens). Do not apply a generic 2x multiplier or assume that 50% of input falls in a premium tier. For other models, apply a long-context tier only when its threshold and rates are verified in the pricing cache or an authoritative source; if the required tier is unverified, report pricing as unavailable instead of guessing.

OpenAI/GPT source-side long-context parity: When comparing a GPT-5.x/GPT-6 source cost against its Bedrock target, both sides MUST use the same context tier. If usage_by_model[] or ai-workload-profile.json carries no per-request token-size data (so it is unknown whether any requests exceed 272K input), do NOT assume the short-context rate for the source side while the Bedrock side may be priced long-context (or vice versa) — flag the comparison pricing_tier: "approximate — request-size distribution unknown" and present both a short-context and a long-context scenario row rather than a single blended number. When request-size data IS available (e.g., ai_workload_profile.json → workloads[].typical_request_tokens or measured usage profile per-request stats), apply the GPT breakpoint at 272,000 input tokens on BOTH sides consistently: a request above the threshold reprices input, cache, and output 2x/2x/1.5x on the OpenAI source row the same way it does on the Bedrock row (see pricing-cache.md's GPT-6 breakpoint note). Measured source spend (Part 1's current_costs/usage-profile dollar figures) always takes precedence over this list-rate comparison when it exists.

Worked example: 100 requests of GPT-6 Sol at 300,000 input / 10,000 output tokens each (30M input / 1M output total) is ABOVE the 272,000-token breakpoint on every request. Source cost at the flat ≤272K rate ($2.00/$10.00) is $70 — wrong, because it ignores the breakpoint. Source cost at the correct long-context rate ($4.00 input / $15.00 output, per pricing-cache.md's GPT-6 family — long context table, Global column) is $135. Bedrock Global CRIS long-context is $135 (parity); Bedrock In-Region/Geo-CRIS long-context ($4.40 input / $16.50 output) is $148.50 — a ~10% premium, not the 112% a flat-rate comparison would produce.

Astra context and inference option: use its dedicated table in shared/pricing-cache.md: short-context at up to 272K input tokens, long-context above that boundary, with separate In-Region/Geo and Global input/output rates. Do not use a short-context row for a long-context workload or apply a Claude-specific surcharge to Astra.

Comparison table columns: Model, Bedrock Monthly, vs Source Provider ($ and %), vs Current GCP, Quality, Capabilities Match (checked against ai_capabilities_required).

Include source provider pricing from aws-design-ai.json → bedrock_models[].source_provider_price.

If Bedrock is more expensive for the recommended model, flag prominently.

If embeddings are needed, add a separate line (additive to primary model cost).

Part 3: Recommended Model Cost Breakdown

Using the model selected in the design phase, show:

• Input tokens × rate, output tokens × rate, embeddings × rate (if applicable)

• Total monthly cost

• Comparison to current GCP spend (monthly and annual difference)

• Backup model cost for comparison

Part 4: Human One-Time Migration Costs (Out of Scope)

Do not present human labor, contractors, professional services, or engineering effort as one-time migration costs or budget line items (no dollar figures, no "budget for people work" lists, no "one-time migration cost" categories for implementation).

Populate migration_cost_considerations.categories as an empty array []. Use migration_cost_considerations.note to state that human and professional-services one-time migration costs are intentionally excluded from this advisor.

Technical integration complexity (for internal JSON and risk context only — not framed as money):

From ai-workload-profile.json, record non-monetary factors in migration_cost_considerations.complexity_factors[] as short strings, for example:

• integration.pattern = "framework" → lower integration touch surface

• integration.pattern = "direct_sdk" → moderate SDK and API pattern changes

• integration.pattern = "rest_api" → higher endpoint, auth, and parsing changes

• summary.total_models_detected > 3 → multi-model coordination

• quota_risk = "high" (from aws-design-ai.json) → Bedrock quota increase required before migration; allow 1–5 business days (see vendored/ai/bedrock-quotas.md)

Do not repeat these as "costs" in the user-facing summary.

Part 5: ROI Analysis

Present the monthly and annual cost difference between current GCP AI spend and projected Bedrock cost:

• If the model is unchanged (model_change: false): compute the difference from the verified source rate and the selected model's context tier and inference option. Do not impose a fixed premium. A verified $60 source versus $60 Astra Global comparison is 0%; an applicable $60 source versus $66 In-Region/Geo comparison is 10%. If the source rate is unverified, mark the source comparison unavailable and do not infer a percentage from another tier. For Astra inputs above 272K, select its long-context input/output rates for that inference option before calculating totals.

• If Bedrock is cheaper: present monthly and annual savings clearly

• If Bedrock is more expensive: state clearly, justify with non-cost benefits or note "not justified if cost is the only priority"

When both monthly totals are established for the same workload volume, calculate:

monthly_difference = bedrock_monthly - source_monthly
percentage_difference = monthly_difference / source_monthly * 100 if source_monthly > 0 else None

A zero source total has no defined percentage comparison; show the dollar difference instead.

Reference aws-design-ai.json → honest_assessment. If "recommend_stay", present prominently along with honest_assessment_reason.

Non-cost benefits to present: usage counting toward existing AWS commitments, IAM/VPC/PrivateLink/KMS/CloudTrail governance, in-region processing for data residency, prompt caching (Claude, and GPT-5.6 at 90% off cached input with cached tokens exempt from the input-TPM quota), model flexibility (100+ models), AWS ecosystem (Guardrails, Knowledge Bases, AgentCore), and — for a same-model move — reduced model-change risk, while endpoint/API compatibility still requires evaluation.

Pricing source caveat (all providers): a references/vendored/ai/bedrock-pricing-cache.md cell marked _unverified_ is blocking for any quoted Bedrock figure, whatever the provider — resolve it from the Bedrock pricing page or the model card before the row enters model_comparison or the ROI table; never substitute a guess or a same-tier sibling's rate. An _unverified_ Bedrock cache cell is not evidence the model is unavailable or free — it means the rate was not confirmed when the cache was last updated. See shared/openai-on-bedrock.md.

Unverified gate (all providers, not just OpenAI): any cell marked _unverified_ in references/vendored/ai/bedrock-pricing-cache.md — including Anthropic batch cells for models not yet on the batch-supported models table (Sonnet 5, Opus 4.8 as of 2026-09-02) — is blocking for any quoted figure that depends on it. Do not apply a batch discount to an _unverified_ batch cell; price on-demand and note batch as a possible future saving, or resolve the rate from the Bedrock pricing page first.

Note: Human/professional-services one-time migration costs are intentionally out of scope for this advisor and excluded from ROI calculations.

Part 6: Cost Optimization Opportunities

Present applicable optimizations with estimated savings. Every entry requires a type (stricter than the infra side, where type is optional — see references/shared/ri-sp-eligibility.md § Consumers) so a Provisioned Throughput row can never silently inherit RI/SP-style commitment language by copy-paste. commitment and target_services are also required on every entry, for parity with the infra-side render columns consumed by generate-artifacts-report.md Appendix B (see that file's key-map table for how the differently-named savings fields on each side map to the same rendered column).

Do not attach the infra-side Activate-credits caveat to any row in this table. That caveat (references/shared/ri-sp-eligibility.md § Required caveats item 2) exists because RIs/Savings Plans have an upfront cost credits can't cover. None of these seven AI-side levers have an upfront cost — six carry commitment: "none" (not "free": Batch API is 50% of on-demand cost, not zero, and prompt-cache-write tokens can be billed at a higher rate than uncached input for some models — "no RI/SP upfront cost" is the accurate framing, not "free"), and Provisioned Throughput is billed hourly with no upfront fee. Applying that sentence here would be incorrect, not just redundant.

Sequencing note — not all seven are available on day one. Prompt caching (if prompts qualify), Batch API (if latency is flexible), model downsizing, input token reduction, and multi-model tiered routing (a design-time choice) are usable immediately after migration. Provisioned Throughput requires a sustained-traffic baseline (>100M tokens/month, predictable) and Intelligent Prompt Routing benefits from 2+ weeks of production traffic to validate routing quality before either is worth adopting. Do not present all seven as equally available at migration time — a pre-revenue team reading "up to 90%" and "Provisioned Throughput" side by side, with no sequencing signal, could read both as things to buy in week one.

target_services is ["Bedrock"] for all seven entries — every AI-side optimization applies to Bedrock inference specifically, unlike the infra side where target services genuinely differ per optimization.

potential_savings_monthly will frequently be null pre-migration — populate potential_savings_percent too, on every entry, so the merged report table is never blank. Unlike the infra side, where savings_monthly falling back to savings_percent is Appendix B's job, the AI-side schema previously had no percent field at all — add one (see Output schema below), sourced from this table's Savings column. Do not ship potential_savings_monthly: null with no percent fallback; that produces exactly the blank Monthly Savings cell this schema change exists to prevent.

Prompt caching vs. Intelligent Prompt Routing vs. Multi-model tiered routing — these are three distinct mechanisms, do not merge or confuse them:

• Prompt caching reduces cost on repeated input tokens within the same model, via Bedrock's cache-read pricing. AWS's own published figure is "up to 90% on cached input tokens" (verified via docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html and the GA announcement) — this is a ceiling figure driven by cache hit rate and how much of the prompt is cacheable, not a typical realistic number. Applies beyond Claude — Nova Micro/Lite/Pro and other models also support it (do not title this row "(Claude)"; GPT-5.6 caching is referenced separately in Part 5 of this file). Do not use the previous ~30% estimate found elsewhere in this codebase; that figure was never sourced from AWS and has been corrected.

• Intelligent Prompt Routing is Bedrock's own automatic per-request router between two models in the same family — default routers cover Anthropic and Meta Llama families only; additional models require a configurable router. This will not help a design whose only Bedrock models are Gemini-on-Bedrock or OpenAI-on-Bedrock — confirm the design's model family has a router available before surfacing this row. AWS's own published figure is "up to 30%" (verified via aws.amazon.com/bedrock/intelligent-prompt-routing/) — this figure is AWS-sourced, but the "2+ weeks production traffic" wait before adopting it is this plugin's own caution, not an AWS requirement (AWS's documentation states no minimum traffic period); label it as a plugin estimate the same way the 60-87% multi-model routing figure below is labeled, not as an AWS constraint. This is a separate row from Multi-model tiered routing below — do not collapse the two into one entry.

• Multi-model tiered routing is this plugin's own design-time optimization: manually splitting traffic across model tiers by workload type (e.g. simple queries to a cheap model, complex queries to a premium model), driven by tiered_strategy in the design artifact. This is not an AWS product feature with a published percentage — the 60-87% figure is this plugin's own estimate for that specific design pattern, distinct from Bedrock's automatic Intelligent Prompt Routing.

For each applicable optimization, calculate before/after monthly cost and show an optimized_projection (best-case monthly with all optimizations).

Post-migration optimization (do not surface during migration): Model distillation — training a smaller, faster student model from a larger teacher model — can reduce inference costs up to ~75% for high-volume, stable workloads. Requires production traffic, labeled examples, and a teacher/student eval loop. Mention in the estimate summary as: "Once you have 2–4 weeks of Bedrock production traffic, consider model distillation to further reduce costs. See docs.aws.amazon.com/bedrock/latest/userguide/model-distillation.html." Do not recommend distillation before the startup has migrated and validated their workload. Model distillation is a genuinely different mechanism from model downsizing/tiering above — downsizing picks a cheaper existing model up front, distillation trains a new, custom smaller model post-migration from observed production traffic. Both are legitimate, non-overlapping levers.

Emit template — one example per type:

{
  "opportunity": "Prompt caching",
  "type": "prompt_caching",
  "target_services": ["Bedrock"],
  "potential_savings_monthly": null,
  "potential_savings_percent": "up to 90% on cached input tokens",
  "commitment": "none",
  "implementation_effort": "low",
  "available": "day_1",
  "description": "Repeated system prompts or long shared context qualify for cache-read pricing. AWS's published figure is up to 90% cost reduction on cached input tokens — actual savings depend on cache hit rate and how much of the prompt is cacheable. Applies to Claude, Nova Micro/Lite/Pro, and other supported models, not Claude only."
}

{
  "opportunity": "Intelligent Prompt Routing",
  "type": "intelligent_prompt_routing",
  "target_services": ["Bedrock"],
  "potential_savings_monthly": null,
  "potential_savings_percent": "up to 30%",
  "commitment": "none",
  "implementation_effort": "low",
  "available": "after_2_weeks_production_traffic",
  "description": "Bedrock's automatic per-request router between two models in the same family (default: Anthropic or Meta Llama; additional models via configurable routers). AWS's published figure is up to 30% cost reduction without compromising accuracy. Does not apply to a design whose only Bedrock models are Gemini-on-Bedrock or OpenAI-on-Bedrock -- confirm a router is available for the design's model family before emitting this entry."
}

{
  "opportunity": "Provisioned Throughput",
  "type": "provisioned_throughput",
  "target_services": ["Bedrock"],
  "potential_savings_monthly": null,
  "potential_savings_percent": "varies",
  "commitment": "no-commit, 1-month, or 6-month",
  "implementation_effort": "medium",
  "available": "after_sustained_traffic_baseline",
  "description": "For sustained, predictable high-volume traffic (>100M tokens/month). Distinct from Reserved Instances/Savings Plans — no 1-year or 3-year term exists for this product. Billed hourly, no upfront fee."
}

The remaining four types (model_tiering, batch_api, input_token_reduction, multi_model_routing) follow the same shape with "commitment": "none" and "available": "day_1" — always populate potential_savings_percent from Part 6's table above, even when potential_savings_monthly is null.

Part 7: Migration Recommendation (REQUIRED)

Produce a clear migrate/stay/optimize verdict for the AI workload migration. This is the AI-only equivalent of estimate-infra.md Part 7.

Decision logic:

Output fields (add to estimation-ai.json top-level):

"recommendation": {
  "path": "migrate_optimized | migrate_phased | stay",
  "path_label": "Migrate to Bedrock | Migrate selectively | Stay on current provider",
  "migrate_if": "Brief condition under which migration makes sense (1 sentence)",
  "stay_if": "Brief condition under which staying makes sense (1 sentence)",
  "confidence": "high | medium | low",
  "rationale": "2-3 sentence justification citing cost delta and non-cost factors"
}

Rules:

• MUST emit recommendation — never omit. If data is insufficient, set confidence: "low" and state why in rationale.

• If honest_assessment from aws-design-ai.json says recommend_stay, recommendation.path MUST be stay regardless of cost numbers.

• Same-model cost is the computed Part 5 result, not a fixed premium. The final recommendation.rationale must use the selected inference option/context tier and verified source baseline. Report parity, savings or an increase as actually calculated. When the source comparison is unavailable, say so, set confidence appropriately and do not invent a percentage. Apply the decision table to those actual costs and the user's non-cost drivers; the honest_assessment: recommend_stay override still takes precedence.

• For multi-workload runs: if some workloads favor migration and others don't, use migrate_phased and list which workloads to migrate vs. keep in rationale.

Output

Write estimation-ai.json to $MIGRATION_DIR/.

Schema — top-level fields:

All cost values are numbers, not strings. Output must be valid JSON.

Validation Checklist

• [ ] recommendation field is present with non-empty path, path_label, migrate_if, stay_if, and rationale

• [ ] recommendation.path is one of: migrate_optimized, migrate_phased, stay

• [ ] If Design honest_assessment = recommend_stay, then recommendation.path = stay

• [ ] model_comparison includes ALL viable Bedrock models, not just recommended

• [ ] Legacy models in model_comparison are annotated with EOL dates (per vendored/ai/ai-model-lifecycle.md)

• [ ] recommended_model is an Active model (not Legacy) unless no Active alternative exists

• [ ] Neither recommended_model nor backup_model carries a restricted (…) Status in references/vendored/ai/bedrock-pricing-cache.md

• [ ] Every model has capabilities_match checked against ai_capabilities_required

• [ ] recommended_model.rationale references user's priority, preference, and volume

• [ ] roi_analysis is honest — if migration increases cost, says so

• [ ] optimization_opportunities only includes strategies relevant to user's workload

• [ ] Every optimization_opportunities[] entry has type, commitment, target_services, potential_savings_percent, and available — none are omitted, and potential_savings_percent is populated even when potential_savings_monthly is null

• [ ] The provisioned_throughput entry's commitment is "no-commit, 1-month, or 6-month" (or equivalent exact wording from references/shared/ri-sp-eligibility.md) — never "1-year" or "3-year"

• [ ] No optimization_opportunities[] entry carries the infra-side Activate-credits caveat sentence — none of these seven levers have an upfront cost for that caveat to apply to

• [ ] The intelligent_prompt_routing entry is omitted (or the design is confirmed to have a router available) when the design's Bedrock models are Gemini-on-Bedrock or OpenAI-on-Bedrock only

• [ ] No compute, database, storage, or networking costs (those belong in estimate-infra.md)

• [ ] migration_cost_considerations.categories is [] — no human one-time migration costs presented

Completion Handoff Gate (Fail Closed)

Before returning control to estimate.md, require:

• estimation-ai.json exists and passes the Validation Checklist above.

If this gate fails: STOP and output: "estimate-ai did not produce a valid estimation-ai.json; do not complete Phase 4."

Present Summary

After writing estimation-ai.json, present under 25 lines:

1. Pricing source and accuracy: State whether prices came from cache or live API, and the accuracy range (±15-25% for AI models from cache, ±5-10% from live API). Example: "AI model estimates based on cached pricing (2026-03-07), accuracy ±15-25%."

2. Current GCP AI spend vs estimated monthly Bedrock cost (recommended model)

3. Model comparison table: model name, estimated monthly cost, vs source provider %, capabilities match

4. Recommended model with estimated monthly cost breakdown

5. If migration increases cost: flag honestly with non-cost justification

6. Top 2-3 optimization opportunities with potential estimated monthly savings (use potential_savings_percent when potential_savings_monthly is null — never present a blank savings figure). If Provisioned Throughput is among the top entries shown, state its commitment terms explicitly: "no-commit, 1-month, or 6-month" — never imply a 1-year or 3-year term. If Intelligent Prompt Routing or Provisioned Throughput is shown, note they require a production-traffic baseline first (2+ weeks, or a sustained >100M tokens/month baseline respectively) — do not present them as available immediately alongside day-1 levers like prompt caching or Batch API. Do not attach the "Activate credits don't cover upfront RI/SP costs" caveat here — none of these AI-side optimizations have an upfront cost.

7. Optimized projection

Cost labeling rule: All dollar figures presented to the user MUST be labeled as "estimated monthly costs" or prefixed with "Est." — never present raw dollar amounts as if they are exact.

Generate Phase Integration

The Generate phase uses estimation-ai.json:

1. recommended_model — Which Bedrock model to provision and test

2. migration_cost_considerations — complexity_factors[] only for integration risk context; never present human one-time migration costs to the user (categories stays [])

3. optimization_opportunities — Which optimizations to implement and when

4. cost_comparison — Cost monitoring targets and alerts in production

5. model_comparison — Fallback options if recommended model doesn't meet quality bar

Scope Boundary

This phase covers financial analysis ONLY for AI workloads.

FORBIDDEN — Do NOT include compute, database, storage, networking cost calculations, infrastructure provisioning, code migration examples, or detailed migration timelines.