← Agent Frameworks 🕐 12 min read

Agent Frameworks

Bedrock Flex Inference Tier — Cost Patterns and Optimization (2026)

1. What Flex Inference Is · March 2026

Amazon Bedrock launched Priority and Flex inference service tiers on **18 November 2025**, formalizing a four-tier on-demand inference architecture alongside the existing Standard and Reserved tiers.

Amazon Bedrock launched Priority and Flex inference service tiers on 18 November 2025, formalizing a four-tier on-demand inference architecture alongside the existing Standard and Reserved tiers.

Flex is a best-effort, lower-priority inference tier accessed via a single API parameter (service_tier: "flex") on the standard InvokeModel and Converse APIs. Unlike AWS Batch inference — which requires submitting a JSONL manifest to S3 and polling for results — Flex uses ordinary synchronous API calls. The trade-off: during periods of high aggregate demand, Flex requests are deprioritized behind Standard and Priority requests, accepting elevated queue depth and higher tail latency in exchange for a 50 percent reduction in per-token cost.

The four tiers, in priority order during contention:

Tier	Priority	Price vs. Standard	Typical use case
Reserved	Highest	Fixed capacity fee + token rate	Mission-critical 24/7 workloads
Priority	Second	+75% premium	Customer-facing, latency-sensitive apps
Standard (default)	Third	1× baseline	General-purpose on-demand inference
Flex	Lowest	−50% discount	Batch-like workloads via regular API

On-demand quota (RPM and TPM) is shared across Priority, Standard, and Flex tiers. Reserved capacity is a separate, non-shared allocation. Switching a request to Flex does not bypass account-level quota; it only affects scheduling priority when the underlying compute pool is under pressure.

2. Flex Pricing vs. On-Demand — By Model Family

The 50 percent discount applies uniformly to all models that support the Flex tier. Token rates below reflect Standard (baseline) pricing as of mid-2026. Flex rates are exactly half.

Claude (Anthropic via Bedrock)

Model	Standard Input ($/1M tok)	Standard Output ($/1M tok)	Flex Input	Flex Output
Claude Opus 4.6	$5.00	$25.00	$2.50	$12.50
Claude Sonnet 4.6	$3.00	$15.00	$1.50	$7.50
Claude Haiku 4.5	$1.00	$5.00	$0.50	$2.50

Amazon Nova

Model	Standard Input	Standard Output	Flex Input	Flex Output
Nova Pro	$0.80	$3.20	$0.40	$1.60
Nova Lite	$0.06	$0.24	$0.03	$0.12
Nova Micro	$0.035	$0.14	$0.018	$0.07

Meta Llama

Model	Standard Input	Standard Output	Flex Input	Flex Output
Llama 3.3 70B	$0.72	$0.72	$0.36	$0.36

Cross-region inference note. When Bedrock routes across regions (e.g., us.anthropic.claude-sonnet-4-6-v1:0), an approximate 10% surcharge applies on top of the regional rate. This surcharge stacks on top of the Flex rate — the net discount over cross-region Standard is closer to 45 percent. Verify the model ID prefix in your calls before projecting savings; cross-region prefix (us.*) is a common default for newer model versions.

Flex vs. Batch cost parity. Both Flex and Batch offer exactly 50% off Standard. The choice between them is an architecture decision, not a pricing one (see Section 8).

3. How Flex Requests Appear in CUR

CUR 2.0 field structure

Amazon Bedrock CUR line items follow this schema in AWS Data Exports (CUR 2.0) and Legacy CUR:

Column	Description
`line_item_product_code`	`AmazonBedrock`
`line_item_usage_type`	`{region}-{model-id}-{token-direction}[-{tier}]`
`line_item_operation`	`InvokeModelInference` or `InvokeModelStreamingInference`
`line_item_resource_id`	Application inference profile ARN if used; empty otherwise
`line_item_unblended_cost`	Actual charge for the line item
`pricing_unit`	`Token`

line_item_usage_type format with tier suffix

Standard tier requests omit the tier suffix. Flex adds a Flex suffix component. Representative patterns (us-east-1):

# Standard tier — no suffix
USE1-anthropic.claude-sonnet-4-6-v1:0-input-tokens
USE1-anthropic.claude-sonnet-4-6-v1:0-output-tokens

# Flex tier — Flex suffix
USE1-anthropic.claude-sonnet-4-6-v1:0-input-tokens-Flex
USE1-anthropic.claude-sonnet-4-6-v1:0-output-tokens-Flex

# Batch inference (for comparison) — Batch suffix
USE1-anthropic.claude-sonnet-4-6-v1:0-input-tokens-Batch
USE1-anthropic.claude-sonnet-4-6-v1:0-output-tokens-Batch

Important: AWS added granular line_item_operation values in January 2026. If your CUR was created before that date, you may see the generic Usage operation label instead of InvokeModelInference. Re-create the CUR export or use CUR 2.0 via Data Exports to get the granular field.

Operation field values by tier

Tier	`line_item_operation`
Standard synchronous	`InvokeModelInference`
Standard streaming	`InvokeModelStreamingInference`
Flex synchronous	`InvokeModelInference` (same as Standard — tier is in usage_type)
Batch	`InvokeModelBatchInference`

The tier is encoded in line_item_usage_type, not line_item_operation. To filter specifically for Flex charges, use the %-Flex LIKE pattern on usage type.

4. SLA and Latency Characteristics

AWS does not publish formal numeric SLAs for Flex-tier latency. The following characteristics are derived from AWS documentation and community benchmarking:

Latency behavior model. Flex requests are processed from a shared pool after Priority and Standard requests. Under low load, Flex latency is indistinguishable from Standard (typically 1–5 seconds for a 500-token response on Sonnet-class models). Under high aggregate demand, Flex requests accumulate in a logical queue and latency climbs — potentially to several minutes for large output requests.

Published behavior guarantees:

AWS does not guarantee a maximum queue wait time for Flex requests.
Requests are not dropped; they are queued until capacity becomes available.
The maximum completion timeout is 1 hour for Flex-tier requests, matching the extended timeout available to batch-style workloads on InvokeModel (vs. the default 30-second SDK timeout for Standard tier, which must be raised manually for Flex use).

Approximate latency envelope based on observed patterns:

Condition	p50	p95	p99
Low demand (off-peak)	~1–3s	~5–10s	~15–30s
Moderate demand	~3–8s	~20–60s	~2–5 min
High demand (peak hours)	~5–20s	~2–5 min	~10–20 min

These are rough approximations. There is no AWS-published SLA table. Teams operating Flex in production should instrument CloudWatch ModelInvocationLatency per serviceTier dimension and set their own p95 alerting thresholds before committing Flex to production pipelines.

Queue depth behavior. Flex requests consume on-demand quota (TPM/RPM). Once the account-level quota is exhausted, Flex requests receive ThrottlingException (HTTP 429) before Standard requests — effectively, Flex has lower claim on available quota during contention. AWS has documented approximate RPM/TPM ranges by tier:

Tier	Approximate RPM	Approximate TPM	Throttle risk
Priority	500–1,000+	150K–300K+	Low
Standard	100–500	50K–150K	Medium
Flex	10–100	5K–50K	High

These are defaults, not hard limits — service quota increases are available via support request.

5. Workloads Appropriate for Flex

The following workload characteristics make a task a good Flex candidate:

Latency tolerance. The task result is consumed minutes to hours after the request, not seconds. A human or synchronous downstream system is not waiting on the response.

Best-effort delivery acceptance. Occasional long tail latency (5–20 minutes for a single request during peak) does not break SLOs or cause cascading downstream failures.

Ideal Flex workload categories:

Category	Example
Model evaluation	Running evals on a new model version overnight
Dataset annotation	Labeling 10K records with a classification prompt
Content summarization	Nightly summarization of ingested documents
Async agentic pipelines	Multi-step agent workflows triggered by event queue
Embedding generation	Bulk embedding of a document corpus
Backtesting	Re-running historical prompts against a new model
Compliance scanning	Overnight policy-adherence checks on content
Report generation	Pre-rendering daily or weekly analytics digests
RAG index enrichment	Generating metadata or chunk summaries at index build time
Fine-tuning data prep	Generating synthetic training examples

Signal pattern for eligibility: The workload is triggered by an event queue (SQS, EventBridge, Step Functions), results are written to a data store for later retrieval, and no human-facing UI is blocked waiting on the response.

6. Workloads NOT Appropriate for Flex

Flex is unsuitable when any of the following apply:

Real-time user interaction. Chat interfaces, copilots, and interactive search must respond within 1–3 seconds. Flex p95 latency under moderate load exceeds this budget.

Synchronous agent tool calls. If an agent invokes a tool, waits for the result, and then calls the model again, each inference step is on the critical path for total agent response time. A 2-minute Flex delay in step 3 of a 10-step chain produces a 20-minute user-visible response.

Streaming responses. Flex can technically be used with InvokeModelWithResponseStream, but the first-token latency degradation during peak hours defeats the purpose of streaming.

SLA-bounded automations. Any automation with a contractual or regulatory response deadline (e.g., fraud alert within 30 seconds, order confirmation within 10 seconds) cannot absorb Flex queue variability.

Health/safety systems. Crisis detection, medical triage suggestions, real-time monitoring alerts — any system where delayed inference has human safety implications must use Standard or Priority.

Explicit NOT-Flex workload table:

Workload	Reason
Customer chat (Lex + Bedrock)	Sub-3s latency required
Real-time recommendation API	Synchronous request path
Streaming document generation (user watching)	First-token latency unacceptable
Step in agentic chain with human in loop	Critical path for UX
Fraud / anomaly detection (real-time)	SLA breach risk
Voice assistant backend	200–500ms target
Interactive code completion	Synchronous editor integration

7. LiteLLM Flex Tier Configuration

LiteLLM exposes the Bedrock service_tier parameter via the extra_body mechanism (OpenAI-compatible client) or the serviceTier parameter in direct LiteLLM calls.

Direct LiteLLM call

import litellm

response = litellm.completion(
    model="bedrock/anthropic.claude-sonnet-4-6-v1:0",
    messages=[{"role": "user", "content": "Summarize this document: ..."}],
    # Flex tier — 50% cost reduction, best-effort latency
    extra_body={"service_tier": "flex"},
    # Critical: raise timeout above the default 30s.
    # Flex p99 under load can exceed 10 minutes.
    timeout=900,  # 15 minutes — adjust to workload SLO
    request_timeout=900,
)

Async LiteLLM call (recommended for Flex workloads)

import asyncio
import litellm

async def invoke_flex(prompt: str) -> str:
    response = await litellm.acompletion(
        model="bedrock/anthropic.claude-sonnet-4-6-v1:0",
        messages=[{"role": "user", "content": prompt}],
        extra_body={"service_tier": "flex"},
        timeout=900,
    )
    return response.choices[0].message.content

# Concurrent Flex requests — fan out across a work queue
async def process_batch(prompts: list[str]) -> list[str]:
    tasks = [invoke_flex(p) for p in prompts]
    # asyncio.gather preserves order; use return_exceptions=True
    # to avoid one Flex timeout aborting the entire batch
    results = await asyncio.gather(*tasks, return_exceptions=True)
    return results

LiteLLM proxy config (for gateway deployments)

# config.yaml
model_list:
  - model_name: claude-sonnet-flex
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-4-6-v1:0
      aws_region_name: us-east-1
      extra_body:
        service_tier: "flex"
      timeout: 900
      request_timeout: 900

OpenAI-compatible client (via LiteLLM proxy)

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:4000",
    api_key="your-litellm-proxy-key",
)

response = client.chat.completions.create(
    model="claude-sonnet-flex",  # maps to Flex-configured model in proxy
    messages=[{"role": "user", "content": "..."}],
    extra_body={"service_tier": "flex"},
    timeout=900,
)

Timeout handling for Flex. The default AWS SDK read timeout is 30 seconds. Under peak demand, a Flex request may queue for several minutes before processing begins. The SDK timeout fires before the request completes, returning a ReadTimeoutError — the request is still in the queue on AWS’s side, so the caller has now been billed for a partial request (input tokens consumed) with no output. Always set timeout ≥ 300 seconds (5 minutes) for Flex. 900 seconds (15 minutes) is a safer default for large-output requests.

Retry strategy. The AWS SDK retries up to 5 times by default with exponential backoff. For Flex under saturation, this can mean 5 consecutive timeouts and 5× input token charges with no useful output. Disable automatic retries for Flex, or set max_retries=1 and handle retry logic explicitly in your worker code with circuit-breaker logic based on response latency telemetry.

8. Flex vs. Batch Inference — When to Use Each

Both tiers cost exactly 50% of Standard on a per-token basis. The architecture differences drive the choice.

Dimension	Flex	Batch Inference
API model	Synchronous `InvokeModel` / `Converse`	Async: submit JSONL to S3, poll for result
Request unit	Single prompt per API call	Up to 50,000 records per job in one JSONL file
Result delivery	Immediate in API response body	Written to S3 output prefix; poll `GetModelInvocationJob`
Maximum job size	No file size limit (quota-bounded by RPM/TPM)	256 MB JSONL per job
Completion time	Seconds to minutes	Up to 24 hours
Streaming support	Yes (`InvokeModelWithResponseStream`)	No
Mid-job cancellation	Per-request cancellation only	`StopModelInvocationJob` cancels entire job
Failure granularity	Per-request `ThrottlingException` or timeout	Per-record errors in S3 output; job-level error on fatal failure
Integration complexity	Minimal — same SDK call with one extra parameter	Requires S3 write, job submission, polling loop, S3 read
Best for	Event-driven async pipelines, <10K items/run	Bulk data processing, >10K items/run, overnight ETL jobs

Decision heuristic:

If workload is:
  - Triggered by event (SNS, SQS, EventBridge, webhook)
  - Items arrive continuously / irregularly
  - Per-item result needed within minutes (not hours)
  → Use Flex

  - Fixed-size dataset processed on a schedule (nightly, weekly)
  - Items can be batched into a single manifest
  - Results needed before next pipeline stage, not in real time
  - >5,000 records per run
  → Use Batch

Hybrid pattern. For continuous-ingest pipelines with periodic large bursts: use Flex for the continuous stream (SQS → Lambda → Bedrock Flex), and switch to Batch for the end-of-day roll-up job (Step Functions → S3 manifest → Bedrock Batch → S3 output → downstream ETL). This captures the simplicity of Flex for real-time event handling while using Batch’s higher throughput ceiling for bulk operations.

9. Cost Optimization — Flex for Off-Hours and Time-Shifting

The 50% discount compounds with other Bedrock cost reduction mechanisms:

Mechanism	Discount	Stackable with Flex?
Flex tier	−50% vs Standard	—
Prompt caching	Up to −90% on cached input tokens	Yes — Flex + cached input stacks
Cross-region routing (avoided)	+10% overhead if using cross-region	Flex removes overhead if you explicitly specify in-region model IDs
Model right-sizing	70–90% savings (e.g., Nova Micro vs Sonnet)	Yes

Time-shifting strategies

Off-peak scheduling. Flex is cheapest per-token at all times, but its latency is most predictable at off-peak hours (weekends, 2–8 AM local time for US regions). Schedule non-urgent workloads — nightly summaries, eval runs, annotation jobs — to start between midnight and 6 AM UTC to minimize queue saturation risk and improve p95 throughput.

SQS-based Flex worker pattern. Decouple producers from Bedrock calls using an SQS queue with a visibility timeout of 20 minutes (to cover Flex queue variability). Worker Lambda or ECS tasks poll SQS, call Bedrock with service_tier: "flex", and write results to DynamoDB or S3. If a Flex request times out, the SQS message becomes visible again and a new worker picks it up. This prevents timeout-induced token waste.

Producer → SQS (visibility=1200s) → Worker → Bedrock Flex → DynamoDB
                                         ↑ retry on timeout / ThrottlingException

EventBridge Scheduler for batching. Use EventBridge Scheduler to accumulate work items during the day, then trigger a Batch job (not Flex) at 2 AM for the accumulated corpus. Reserve Flex for items that arrive with a “needs result within 1 hour” SLA; route everything else to the overnight Batch job.

Prompt caching + Flex compounding example:

Claude Sonnet 4.6 Standard: $3.00 input / $15.00 output per 1M tokens
After Flex: $1.50 / $7.50
If 80% of input tokens are cached at 90% cache discount: effective input cost ≈ $0.42/1M
Effective total savings vs uncached Standard: ~86% on input, 50% on output

10. CUR Athena Queries — Identifying Flex Migration Candidates

These queries run against a CUR 2.0 table in Athena. Replace your_cur_database.your_cur_table with your actual CUR table identifier. The table is typically partitioned by year and month.

Query 1 — Identify current Standard-tier Bedrock spend eligible for Flex migration

-- Find Standard-tier Bedrock inference spend by model for the last 30 days
-- These are candidates for Flex migration if the caller is non-interactive

SELECT
    line_item_usage_type,
    line_item_operation,
    line_item_resource_id,
    SUM(line_item_unblended_cost)        AS total_cost_usd,
    SUM(line_item_usage_amount)          AS total_tokens,
    COUNT(*)                             AS line_item_count
FROM your_cur_database.your_cur_table
WHERE
    line_item_product_code = 'AmazonBedrock'
    -- Exclude already-Flex and Batch line items
    AND line_item_usage_type NOT LIKE '%-Flex'
    AND line_item_usage_type NOT LIKE '%-Batch'
    -- Exclude Priority tier
    AND line_item_usage_type NOT LIKE '%-Priority'
    -- Last 30 days (adjust year/month partition filter for performance)
    AND line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY 1, 2, 3
ORDER BY total_cost_usd DESC
LIMIT 50;

Query 2 — Estimate potential Flex savings by model

-- Project 50% savings if Standard spend is migrated to Flex

SELECT
    REGEXP_EXTRACT(line_item_usage_type, '^[A-Z0-9]+-(.+)-(?:input|output)-tokens$', 1) AS model_id,
    CASE
        WHEN line_item_usage_type LIKE '%-input-tokens' THEN 'input'
        WHEN line_item_usage_type LIKE '%-output-tokens' THEN 'output'
        ELSE 'other'
    END                                                        AS token_direction,
    SUM(line_item_unblended_cost)                              AS current_cost_usd,
    SUM(line_item_unblended_cost) * 0.50                       AS projected_flex_cost_usd,
    SUM(line_item_unblended_cost) * 0.50                       AS estimated_savings_usd
FROM your_cur_database.your_cur_table
WHERE
    line_item_product_code = 'AmazonBedrock'
    AND line_item_usage_type NOT LIKE '%-Flex'
    AND line_item_usage_type NOT LIKE '%-Batch'
    AND line_item_usage_type NOT LIKE '%-Priority'
    AND line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY 1, 2
ORDER BY current_cost_usd DESC;

Query 3 — Breakdown of current Flex adoption vs Standard

-- Show what fraction of Bedrock spend is already on Flex vs Standard vs Batch

SELECT
    CASE
        WHEN line_item_usage_type LIKE '%-Flex'     THEN 'Flex'
        WHEN line_item_usage_type LIKE '%-Batch'    THEN 'Batch'
        WHEN line_item_usage_type LIKE '%-Priority' THEN 'Priority'
        ELSE 'Standard'
    END                                    AS tier,
    SUM(line_item_unblended_cost)          AS total_cost_usd,
    ROUND(
        100.0 * SUM(line_item_unblended_cost)
        / SUM(SUM(line_item_unblended_cost)) OVER (),
        1
    )                                      AS pct_of_bedrock_spend
FROM your_cur_database.your_cur_table
WHERE
    line_item_product_code = 'AmazonBedrock'
    AND line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY 1
ORDER BY total_cost_usd DESC;

Query 4 — Identify callers running latency-insensitive patterns (Flex migration signal)

-- Callers that invoke Bedrock outside business hours (UTC 00:00-07:00)
-- are strong candidates for Flex: off-hours = likely batch/async, not interactive

SELECT
    line_item_resource_id,
    line_item_iam_principal,         -- available in CUR 2.0 after Apr 2026
    HOUR(line_item_usage_start_date) AS hour_utc,
    SUM(line_item_unblended_cost)    AS cost_usd,
    COUNT(*)                         AS invocation_count
FROM your_cur_database.your_cur_table
WHERE
    line_item_product_code = 'AmazonBedrock'
    AND line_item_usage_type NOT LIKE '%-Flex'
    AND line_item_usage_type NOT LIKE '%-Batch'
    AND HOUR(line_item_usage_start_date) BETWEEN 0 AND 7
    AND line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY 1, 2, 3
ORDER BY cost_usd DESC
LIMIT 100;

Note on line_item_iam_principal. This column was added to CUR 2.0 in April 2026 and requires Bedrock IAM principal cost attribution to be enabled. If the column is absent, join on line_item_resource_id (Application Inference Profile ARN) instead.

11. Flex Failure Modes and Cost Implications

Queue saturation and ThrottlingException (HTTP 429)

When account-level on-demand quota is exhausted — shared across Priority, Standard, and Flex — Flex requests are the first tier to receive ThrottlingException. A Flex request that has not yet started processing is rejected outright (no tokens consumed). However:

Tokens already counted at request submission. Input tokens for a Flex request may be metered at invocation initiation, not at completion, depending on model implementation. Under sustained saturation, a sequence of rejected-then-retried calls can accumulate input token charges without producing output.
Mitigation: Implement exponential backoff with jitter. Do not let the AWS SDK’s default 5-retry behavior run unchecked on Flex. Set max_retries=0 in the SDK and handle retries in your worker with a back-off ceiling of 60–120 seconds.

ModelTimeoutException and partial billing

If a Flex request times out server-side (extremely rare, but possible for very long outputs during saturation), ModelTimeoutException is returned. Input tokens have been processed; output tokens are not charged for the incomplete response. The economic risk is: a 100K-input-token prompt timed out generates ~$0.15 of input charges (Sonnet Flex) with no usable output.

Priority inversion under Reserved + Flex mixed workloads

If the same account runs Reserved-tier inference for one application and Flex for another, the Reserved capacity is isolated — it does not compete with on-demand quota. However, Priority and Standard requests from other services still reduce the on-demand pool available to Flex. In accounts with high Priority-tier usage, Flex effective throughput degrades before the published TPM quota is hit, because Priority consumers drain the pool first.

Detection query:

-- Spot hours where Flex cost drops sharply (throttle-induced request failures)
-- while Standard or Priority cost spikes

SELECT
    DATE_TRUNC('hour', line_item_usage_start_date)    AS hour_bucket,
    SUM(CASE WHEN line_item_usage_type LIKE '%-Flex' THEN line_item_unblended_cost ELSE 0 END)     AS flex_cost,
    SUM(CASE WHEN line_item_usage_type NOT LIKE '%-Flex'
             AND line_item_usage_type NOT LIKE '%-Batch'
             AND line_item_usage_type NOT LIKE '%-Priority'
             THEN line_item_unblended_cost ELSE 0 END)                                             AS standard_cost,
    SUM(CASE WHEN line_item_usage_type LIKE '%-Priority' THEN line_item_unblended_cost ELSE 0 END) AS priority_cost
FROM your_cur_database.your_cur_table
WHERE
    line_item_product_code = 'AmazonBedrock'
    AND line_item_usage_start_date >= DATE_ADD('day', -7, CURRENT_DATE)
GROUP BY 1
ORDER BY 1;

A pattern where flex_cost goes to zero while priority_cost spikes indicates Priority consumers are saturating the pool and throttling Flex callers.

Retry cost amplification

A Flex worker that catches ThrottlingException and retries immediately creates a positive-feedback loop: each retry adds to the queue depth, worsening the saturation that caused the throttle. The correct retry pattern for Flex:

import time
import random
import boto3
from botocore.config import Config

bedrock = boto3.client(
    "bedrock-runtime",
    config=Config(
        retries={"max_attempts": 1, "mode": "standard"},  # disable SDK auto-retry
        read_timeout=900,
    ),
)

def invoke_flex_with_backoff(payload: dict, max_attempts: int = 4) -> dict:
    for attempt in range(max_attempts):
        try:
            response = bedrock.invoke_model(
                **payload,
                additionalModelRequestFields={"service_tier": "flex"},
            )
            return response
        except bedrock.exceptions.ThrottlingException:
            if attempt == max_attempts - 1:
                raise
            # Exponential backoff: 10s, 20s, 40s + jitter
            sleep_sec = (10 * 2**attempt) + random.uniform(0, 5)
            time.sleep(sleep_sec)

Summary: Flex Decision Matrix

Signal	Recommendation
Interactive user is waiting	Standard or Priority
Agent on critical path to user response	Standard or Priority
Async pipeline, results needed in <1 hour	Flex
Scheduled nightly job, <5K records	Flex
Scheduled nightly job, >5K records	Batch
Continuous event-driven stream	Flex (SQS worker pattern)
High-volume bulk processing with S3 I/O	Batch
Cost-sensitive eval / annotation / labeling	Flex
Account with high Priority-tier contention	Flex + monitor for saturation
24/7 mission-critical, cannot tolerate latency	Reserved