← Agent Frameworks 🕐 19 min read

Agent Frameworks

Bedrock Agents Cost Anatomy — Multi-Step Workflow Billing (2026)

The Central Premise · March 2026

The AWS Bedrock pricing page lists per-token rates. Those rates are accurate and almost useless for estimating agent costs.

The AWS Bedrock pricing page lists per-token rates. Those rates are accurate and almost useless for estimating agent costs. The gap between the pricing page number and the actual bill comes from one structural fact: every step in an agent loop is a separate model invocation, and each invocation carries the full accumulated context of the session.

A 5-turn research agent with 3 tool calls per turn does not cost 5x a single direct call. It costs closer to 30–50x, because each of the ~18 model calls (preprocessing check, orchestration per turn, postprocessing, tool-result summarization) sees a context window that grows with every exchange. Understanding Bedrock Agents billing means understanding this compounding, not the per-token rate.

1. Bedrock Agents Billing Model: The Orchestration Step Tax

Bedrock Agents has no service-level surcharge. AWS does not add a per-invocation fee on top of model costs for the agent wrapper itself. You pay only for the underlying model calls the agent makes — but the agent makes far more of them than you expect.

The Four-Phase Execution Sequence

Each user turn (InvokeAgent call) executes up to four distinct phases, each of which can trigger a model call:

Phase	Default State	Model Call?	Notes
Pre-processing	Disabled	Optional	Classifies intent; decides if input is valid
Orchestration	Enabled	Always	Core ReAct loop; may repeat N times per turn
Knowledge Base Response Generation	Enabled	Per KB hit	Synthesizes retrieved chunks into answer
Post-processing	Disabled	Optional	Reformats or filters final response

With the defaults, a single user turn that requires two tool calls generates a minimum of three orchestration model calls: one to decide on the first tool, one to decide on the second after seeing the first result, and one to synthesize the final answer. Enable pre-processing and post-processing and you add two more.

Token Amplification Mechanics

Each orchestration model call receives as input:

The agent’s system prompt (the rendered $instruction$ placeholder, typically 300–800 tokens depending on configuration)
The tool schema definitions ( $tools$ placeholder — grows with number of action groups)
The complete session conversation history ( $agent_scratchpad$ )
The current user turn

The $agent_scratchpad$ grows with every tool call result. By turn 3 of a research agent, the scratchpad includes all prior tool invocations and their responses. A single orchestration call that triggers at turn 5 may have 8,000–15,000 input tokens before a word of the user’s question is added.

Realistic Token Count: Orchestration Prompt Baseline

The rendered orchestration prompt (without any conversation history) runs approximately:

Component	Approximate Tokens
Base guidelines (`<guidelines>` block)	250–350
Function schema per action group (per tool)	150–300
Session attribute block	50–100
XML structure tags, role markers	80–150
Baseline per orchestration call (no history)	~800–1,400

Add two prior tool results at 400 tokens each and you are at 1,600–2,200 tokens before the LLM has produced a single output token. This baseline is the hidden tax. Direct InvokeModel calls have no equivalent overhead.

2. Action Group Invocations: The Full Cost Stack

Action groups are the bridge from model decision to actual computation. When the orchestration LLM decides to call a tool, three cost layers activate independently.

Lambda Invocation Costs

Lambda charges apply to every action group call:

Request charge: $0.20 per 1 million invocations ($0.0000002 per call)
Duration charge: GB-seconds consumed during execution, at $0.0000166667 per GB-second
Provisioned Concurrency (if used to eliminate cold starts): charged at $0.000004646 per GB-second allocated

At low volume, Lambda invocation costs are negligible relative to token costs. At scale — 100,000 agent sessions per day with 4 tool calls each — Lambda charges reach approximately $8/day on invocations alone, plus duration.

API Gateway Costs (HTTP Action Groups)

If you define action groups as HTTP endpoints behind API Gateway rather than Lambda:

REST API: $3.50 per million API calls
HTTP API: $1.00 per million API calls
Data transfer: $0.09/GB out (first 10 TB/month)

HTTP action groups are less common than Lambda but relevant for connecting Bedrock Agents to existing microservice APIs. At 10 million tool calls per month through REST API Gateway, the gateway cost alone is $35.

The Real Cost: Model Tokens After Tool Execution

The model invocation that occurs after receiving a tool result is typically more expensive than the one that triggered the tool. The tool result is appended to the scratchpad and the model must now process everything — prior context plus the (often verbose) tool response — to decide next steps. Tool results that return large JSON payloads (e.g., database query results, API responses) directly inflate the input token count on the subsequent model call.

Mitigation: Truncate or summarize tool results before returning them to the agent. A tool that returns 2,000 tokens of raw JSON that the agent then processes costs 2,000 additional input tokens on every subsequent step in that session.

3. Multi-Turn Cost Accumulation: The Compounding Problem

The context window is stateful within a Bedrock Agents session. Each InvokeAgent call with the same sessionId appends to the growing conversation history, and that history is replayed as input tokens on every subsequent model call.

Token Growth Pattern: 5-Turn Research Agent

Setup: Agent using Claude Sonnet 4.6 ($3.00/M input, $15.00/M output). Each turn: 1 orchestration call to select tool, 1 tool call, 1 orchestration call to synthesize result. 3 tool calls per turn = 6 orchestration calls per turn.

Baseline prompt overhead: 1,000 input tokens per call before any history.

Turn	Cumulative History Tokens	Input per Call (avg)	Calls This Turn	Turn Input Total	Turn Output (est.)
1	0	1,200	6	7,200	1,800
2	2,400	3,600	6	21,600	1,800
3	4,800	6,000	6	36,000	1,800
4	7,200	8,400	6	50,400	1,800
5	9,600	10,800	6	64,800	1,800
Total			30	180,000	9,000

Cost calculation:

Input: 180,000 tokens × $3.00/M = $0.54
Output: 9,000 tokens × $15.00/M = $0.135
Session total: ~$0.68

Compare to a single direct model call with the same final answer:

Input: 1,500 tokens × $3.00/M = $0.0045
Output: 600 tokens × $15.00/M = $0.009
Direct call total: ~$0.013

The 5-turn agent loop costs approximately 52x the equivalent single-shot call. At 10,000 such sessions per month: $6,800/month vs. $130/month.

Session Duration as a Cost Lever

Bedrock Agents session expiry defaults to 10 minutes of inactivity. Sessions can be configured from 60 seconds to 3,600 seconds. Shorter sessions force context reset, which reduces per-call input tokens but breaks conversational continuity. The correct tradeoff depends on whether the agent’s task is genuinely multi-session (resumable research) or merely multi-turn within a single task (in which case sessions should expire quickly after completion).

4. Bedrock Agents Trace Cost: CloudWatch Overhead at Scale

Setting enableTrace: true in InvokeAgent requests causes Bedrock to emit detailed step-by-step reasoning traces as streaming events. These traces are valuable for debugging but create a secondary cost channel.

What Trace Emits

Each trace event captures the full model reasoning for a step: input tokens, output tokens, the raw <thinking> block if extended thinking is enabled, tool invocation parameters, tool responses, and latency metadata. For a 5-turn agent session with 30 model calls, trace output per session runs approximately 40–80 KB of JSON.

CloudWatch Logs Ingestion Cost

If you route trace data to CloudWatch Logs (the most common pattern):

Log ingestion: $0.50 per GB
Log storage: $0.03 per GB per month
Log Insights queries: $0.005 per GB scanned

At 100,000 sessions/day with 60 KB average trace per session:

Daily trace volume: 6 GB
Monthly ingestion: 180 GB × $0.50 = $90/month
Monthly storage (30-day retention): 180 GB × $0.03 = $5.40/month

This is manageable. The risk materializes when extended thinking is enabled (reasoning tokens are also traced, multiplying trace size 3–10x) or when trace is left on in production for high-volume deployments where sessions are measured in millions per month. At 1M sessions/day with extended thinking, trace ingestion alone can reach $3,000–$6,000/month.

Standard practice: Enable trace in dev/staging, disable in production, use sampling (1–5% of production traffic) routed to a separate log group for ongoing debugging.

AgentCore Observability Tier

AgentCore’s native observability (for agents deployed on AgentCore Runtime) uses the same CloudWatch pricing but adds structured span data through OpenTelemetry. Span ingestion runs at approximately $0.35/GB (standard CloudWatch metric ingestion). The production observability cost for a mid-scale deployment (10M sessions/month) is estimated at $3,500–$6,500/month in spans and event logs combined — a material line item that belongs in the cost model from day one.

5. Sub-Agent / Multi-Agent Collaboration Billing

Bedrock Agents multi-agent collaboration (Supervisor mode) allows a supervisor agent to spawn specialized sub-agents via the AgentCommunication__sendMessage tool. Each sub-agent is a full Bedrock Agent with its own model, action groups, and session state.

Billing Isolation

Each agent in the hierarchy is billed independently. The supervisor agent’s model calls and the sub-agent’s model calls are separate line items, each at the respective model’s per-token rate. There is no consolidated session-level pricing.

Double-Context Problem in Supervisor Mode

The supervisor must communicate task context to the sub-agent. Without Payload Referencing, the supervisor embeds the full task context in the sendMessage call body — those tokens are billed as output tokens on the supervisor’s side and input tokens on the sub-agent’s side. For a supervisor with 8,000 tokens of accumulated context delegating to a sub-agent, the delegation message itself costs:

Supervisor: 8,000 output tokens billed at supervisor model rate
Sub-agent: 8,000 input tokens billed at sub-agent model rate

Payload Referencing (S3-backed context passing) eliminates this by replacing inline context with a reference pointer. The context is stored in S3 and the sub-agent fetches it directly, breaking the double-billing. Enabling Payload Referencing is mandatory for any multi-agent deployment where supervisor context exceeds 1,000 tokens.

Cost Calculation: 3-Agent Hierarchy

Supervisor (Claude Sonnet 4.6) + 2 sub-agents (Claude Haiku 3.5 at $0.80/M input, $4.00/M output):

Supervisor session: 50,000 input tokens, 10,000 output tokens = $0.15 + $0.15 = $0.30
Sub-agent A: 20,000 input tokens, 5,000 output tokens = $0.016 + $0.02 = $0.036
Sub-agent B: 15,000 input tokens, 3,000 output tokens = $0.012 + $0.012 = $0.024
Total: ~$0.36 per session (versus ~$0.30 if all work done in single agent)

The premium for multi-agent architecture is modest when Payload Referencing is used. Without it, the supervisor context re-transmission can 2–3x the sub-agent input token count.

6. Memory Feature Costs: Short-Term and Long-Term

Bedrock AgentCore Memory (previously “agent session memory” in Classic Bedrock Agents) provides two distinct persistence tiers with separate billing.

Short-Term Memory

Short-term memory preserves context within and across sessions using an event store. Cost: $0.25 per 1,000 new CreateEvent API calls.

A session with 20 turns generating 2 events per turn (one for user input, one for agent response) creates 40 events. At $0.25/1,000 events, per-session cost is $0.01. At 1M sessions/month: $10,000/month — significant enough to track but not a primary cost driver.

Long-Term Memory

Long-term memory persists structured facts extracted from sessions indefinitely. Two billing dimensions:

Storage (choose extraction strategy):

Automatic extraction (built-in model inference included): $0.75 per 1,000 records/month
Self-managed extraction (model inference billed separately): $0.25 per 1,000 records/month

Retrieval: $0.50 per 1,000 RetrieveMemoryRecords calls

Memory Cost Scenario

Customer support agent with 10,000 active users, each accumulating 50 long-term memory records:

Storage (automatic extraction): 500,000 records × $0.75/1,000 = $375/month
Retrieval (2 retrievals per session, 5 sessions/user/month): 100,000 retrievals × $0.50/1,000 = $50/month
Memory total: ~$425/month

For the self-managed path, storage drops to $125/month, but you pay standard Bedrock model rates for the extraction inference — which typically adds $100–200/month at this scale, netting to similar total cost with more operational complexity.

Recommendation: Evaluate whether long-term memory is genuinely needed. Many use cases that appear to require persistent memory can be served by injecting a structured user profile string into the session prompt at start — a one-time input token cost rather than an ongoing storage/retrieval charge.

7. Prompt Template Overhead: Tokens the Pricing Page Ignores

Bedrock Agents renders its system prompt from four base templates using placeholder variables. The rendered prompt is what gets billed as input tokens. The overhead relative to a custom prompt depends on which features are enabled.

Placeholder Variable Token Costs

Placeholder	When Non-Empty	Approximate Token Cost
$instruction$	Always	50–500 (your agent instructions)
$tools$	When action groups defined	150–300 per tool
$agent_collaborators$	Multi-agent mode	200–400 per sub-agent
$knowledge_base_guideline$	When KB attached	100–200
$memory_guideline$ + $memory_content$	When memory enabled	200–600
$code_interpreter_guideline$	When Code Interpreter enabled	100–150
$prompt_session_attributes$	When session attrs set	Variable
Base template boilerplate	Always	400–600

Comparing Bedrock Agents vs. Custom Orchestration Prompt

A Bedrock Agents orchestration call with 3 action groups, a knowledge base, and memory enabled carries approximately 1,200–2,000 tokens of framework overhead before any conversation content. A custom ReAct loop using direct InvokeModel with a hand-crafted system prompt typically runs 300–600 tokens of framework overhead — 2–5x leaner.

Over 30 model calls per 5-turn session, the framework overhead difference is:

Bedrock Agents: 30 × 1,600 tokens avg overhead = 48,000 extra tokens
Custom loop: 30 × 450 tokens avg overhead = 13,500 extra tokens
Delta: 34,500 input tokens per session at Claude Sonnet 4.6 rates = $0.10 per session

At 100,000 sessions/month, the prompt overhead differential between Bedrock Agents and a lean custom loop is approximately $10,000/month — purely from framework boilerplate.

8. Action Group Cold Starts: Latency, Not Direct Cost

Lambda cold starts are latency events, not billing events, but they affect agent loop performance in ways that indirectly drive cost.

Cold Start Mechanics in Agent Loops

A cold start occurs when no pre-warmed Lambda execution environment is available. Lambda must provision a microVM, load the deployment package, initialize the runtime, and run initialization code before the handler executes. Typical cold start latency:

Node.js/Python (small package): 200–400 ms
Python with large ML dependencies: 2–8 seconds
Java/JVM runtimes: 1–4 seconds

In a 5-turn agent loop with 3 tool calls per turn, cold starts on all 15 Lambda invocations (worst case, burst scenario) add 3–6 seconds of user-visible latency per turn. More critically, because InvokeAgent is a synchronous call with a 60-second timeout for the agent reasoning loop, cold starts deep in a tool chain can push total session time past the timeout, requiring retry logic.

Provisioned Concurrency Tradeoff

Provisioned Concurrency eliminates cold starts by pre-initializing execution environments:

Cost: $0.000004646 per GB-second provisioned
For a 512 MB Lambda provisioned at 10 concurrent executions, 24/7: 10 × 0.5 GB × 3,600 s/hr × 720 hr/month = 12,960,000 GB-seconds = $60/month

This is worth the spend for user-facing agent workloads where the action group Lambda is hit on every agent turn. It is wasteful for back-office agent workflows where session volume is low and latency tolerance is high.

Cold Start Signal in Bedrock Agents Traces

When enableTrace: true, each tool invocation trace includes the Lambda execution time. A Lambda invocation taking >500 ms is typically a cold start; <50 ms is a warm invocation. Use this signal to identify which action groups need Provisioned Concurrency.

9. Code Interpreter: Execution-Based Pricing

Bedrock Agents Code Interpreter provides a sandboxed Python execution environment for each agent session. It enables agents to write and run code as a tool call, primarily for data analysis, calculations, and file manipulation.

Billing Model (AgentCore Runtime)

Code Interpreter uses AgentCore Runtime’s consumption-based model:

CPU: $0.0895 per vCPU-hour, charged only during active execution (not during I/O wait or model reasoning)
Memory: $0.00945 per GB-hour, charged on peak footprint for every second the sandbox exists

Cost Calculation: Data Analysis Agent

A financial analysis agent that runs 5 code executions per user session, each execution averaging 3 seconds on 1 vCPU with 2 GB peak memory:

CPU: (5 × 3 sec) / 3,600 sec/hr × 1 vCPU × $0.0895 = $0.000373 per session
Memory: (5 × 3 sec) / 3,600 sec/hr × 2 GB × $0.00945 = $0.0000788 per session
Code Interpreter total: ~$0.00045 per session

Token costs for the orchestration model calls around code execution dominate by 10–100x. At the above rates, Code Interpreter compute cost adds approximately 0.5–1% to session cost — a negligible line item. The cost concern with Code Interpreter is token costs from reading back large code outputs (DataFrames, computation results) that get appended to the scratchpad.

Code Interpreter Cold Start

Code Interpreter sandboxes have their own initialization latency, typically 500 ms–2 seconds for the first execution in a session. Subsequent executions within the same session reuse the sandbox. For agents making 10+ code executions in a session, only the first incurs this cold start.

10. Build vs. Buy: When Bedrock Agents’ Overhead Makes Custom Cheaper

Bedrock Agents delivers operational value: managed orchestration, built-in action group routing, knowledge base integration, memory, and guardrails, all without writing ReAct loop logic. The buy decision is correct in certain scenarios and wrong in others.

Decision Framework

Use Bedrock Agents when:

Team size is small and operational burden of a custom loop is high
The workload requires GuardRails, Knowledge Bases, or Memory features natively
Agent task complexity is moderate (3–8 tool calls per session, low volume)
Iteration speed matters more than per-session cost optimization

Build a custom loop when:

Session volume exceeds 100,000/month and per-session cost optimization is needed
Prompt engineering precision is critical (Bedrock Agents’ templates resist heavy customization without advanced-prompts)
Tool call patterns are predictable enough to replace full ReAct with deterministic routing
The agent’s action schema changes frequently (Bedrock requires re-deployment per schema change)
You need sub-10ms tool routing latency (Bedrock’s internal orchestration adds 150–500ms per step)

Cost Comparison: 100K Sessions/Month

Scenario: Research agent, 5 turns, 3 tool calls/turn, Claude Sonnet 4.6.

Component	Bedrock Agents	Custom Loop (LangGraph + direct InvokeModel)
Model tokens — input	$16,200	$10,800
Model tokens — output	$1,350	$1,350
Framework prompt overhead	$10,000	$1,350
Lambda invocations	$60	$60
Trace (CloudWatch)	$450	~$300 (custom logging)
Memory/session state	$425	$0–$200 (Redis/DynamoDB)
Operational engineering	Near-zero	$5,000–$15,000/month (eng time)
Monthly total (infra)	~$28,485	~$14,060 + eng overhead

The infrastructure cost advantage of custom loops (~$14K/month) typically breaks even against engineering overhead at 3–6 months. For large-volume workloads (>1M sessions/month), the custom loop infrastructure savings ($140K+/month) justify the investment within weeks.

The Hybrid Approach

Many production deployments use a hybrid: Bedrock Agents for the primary ReAct loop and managed features (GuardRails, Knowledge Bases) but override orchestration prompt templates using advanced-prompts to minimize token overhead. This recovers 30–50% of the framework prompt overhead while retaining managed infrastructure. The advanced-prompts feature allows replacing the default template with a stripped-down version that omits unused guidelines, reducing baseline overhead from ~1,600 to ~800 tokens per orchestration call.

11. CUR Patterns for Bedrock Agents

Cost and Usage Reports (CUR 2.0) are the canonical source for Bedrock billing reconciliation. Agents traffic is not separated from direct InvokeModel traffic in CUR by default — both appear as standard model inference line items.

CUR Line Item Structure for Agent Traffic

Each model call made by the agent generates separate CUR line items:

`line_item_usage_type` pattern	Meaning
`USE1-Claude4.6Sonnet-input-tokens`	Input tokens for orchestration call in us-east-1
`USE1-Claude4.6Sonnet-output-tokens`	Output tokens for orchestration call
`USE1-Claude4.6Sonnet-cache-read-input-token-count`	Cache hits (if prompt caching enabled)
`USE1-Claude4.6Sonnet-cache-write-input-token-count`	Cache writes (first-time cache population)

Agent calls appear under the same usage type as direct InvokeModel calls using the same model. CUR cannot distinguish whether tokens came from InvokeAgent or InvokeModel at the line-item level — both route through the same model inference endpoint.

Attributing Agent Costs in CUR

Three mechanisms enable per-agent cost attribution:

1. Application Inference Profiles — Create a named inference profile for each agent and route agent invocations through it. The profile name appears as a tag column (resourceTags/AgentName) in CUR. This is the primary recommendation for multi-agent cost attribution.

2. IAM Principal Tagging — Tag the IAM role used by the agent’s execution role. Tags from the IAM principal propagate to CUR line items in CUR 2.0 format. For a single-account, single-agent deployment, this works; for multi-agent deployments sharing an execution role, it breaks attribution.

3. Model Invocation Logging — Enable Bedrock model invocation logging (CloudWatch Logs destination). Every InvokeAgent and InvokeModel call is logged with requestId, token counts, and session metadata. Join CUR aggregates (model + usage-type grain) with invocation logs (request grain) to get per-agent, per-session cost breakdowns.

Tracing a Session Through CUR

CUR does not include requestId or sessionId. To reconstruct session cost:

Pull model invocation logs from CloudWatch for the session’s time window, filter by sessionId
Sum inputTokens and outputTokens across all log entries for that session
Apply the model’s per-token rate from the CUR line_item_unblended_rate for the matching model and usage type
Add Lambda invocation costs (appears in CUR under AWS Lambda service, us-east-1-Lambda-Duration usage type)

This join is the only reliable path to per-session cost. CUR alone cannot do it.

12. Cost Optimization Patterns

Pre-Processing Intent Routing

Before invoking the full agent, classify the user intent with a cheap model. Route simple factual queries that can be answered from a static knowledge base directly to an InvokeModel call with a pre-built prompt, bypassing the agent orchestration loop entirely. Claude Haiku 3.5 intent classification costs $0.0008 per 1K input tokens. A 200-token classification call costs $0.00016 — a rounding error against a $0.68 full agent session.

A rule-of-thumb routing model: if the intent classifier scores >0.95 confidence on a category that has a deterministic answer template, skip the agent. This pattern can reduce full-agent invocations by 20–40% for customer service or FAQ use cases.

Limiting Max Agent Iterations

Set maxLength in the agent configuration to cap the maximum number of orchestration steps. The default is 20 iterations. For most production agents, 6–8 iterations is sufficient. Capping at 8 prevents runaway agents that enter reasoning loops (common with ambiguous tool responses) from accumulating 20x the expected token cost.

Caching Action Group Results

Action group results are not cached natively by Bedrock Agents — every tool invocation executes the Lambda even if the same query was made in the same session. Implement a caching layer (ElastiCache/DynamoDB) inside the Lambda handler keyed on input parameters. For agent workflows where the same API is called multiple times with the same arguments (e.g., looking up the same user record across multiple reasoning steps), hit rates above 30% are common, with corresponding token savings on the subsequent model calls that would have re-read the cached data.

Prompt Caching for the System Prompt

Bedrock supports Anthropic’s prompt caching via explicit cache control markers. The agent system prompt (instructions, tool schema, guidelines) is identical across all turns in a session. Mark this prefix for caching:

Cache write: $3.75/M input tokens (one-time per session start, 5-minute TTL)
Cache read: $0.30/M input tokens (all subsequent turns)

For a session with 30 model calls and a 1,500-token system prompt:

Without caching: 30 × 1,500 × $3.00/M = $0.135 in system prompt input costs
With caching: 1 write ($0.0056) + 29 reads (29 × 1,500 × $0.30/M = $0.013) = $0.019 total
Savings: $0.116 per session, or 85% on the system prompt portion of input tokens

Prompt caching is the single highest-leverage cost optimization available for Bedrock Agents. It requires explicit implementation via advanced-prompts with cache control markers, which also requires switching from the default orchestration template to a custom one.

Disabling Unused Prompt Phases

Pre-processing and post-processing are disabled by default. Leaving them disabled is correct for most workloads. If pre-processing is enabled to validate input intent, benchmark whether it actually reduces downstream token waste (by catching invalid queries early) versus its cost. At Claude Haiku 3.5 rates, pre-processing is cheap; at Sonnet rates it adds meaningful cost per turn.

Knowledge Base Retrieval Tuning

Each Knowledge Base retrieval call costs $1.00 per 1,000 API calls and returns N chunks that are injected into the next model call’s context. Default chunk count is often 5. If most queries only need 2–3 chunks to answer accurately, reducing numberOfResults from 5 to 2 cuts KB token injection by 60%, reducing the subsequent model call’s input token count proportionally.

Summary: Cost Model for a 5-Turn Research Agent at Scale

Configuration: 100,000 sessions/month, Claude Sonnet 4.6, 5 turns, 3 tool calls/turn, Bedrock Agents with defaults.

Cost Component	Monthly Cost
Model input tokens (orchestration)	$16,200
Model output tokens	$1,350
Framework prompt overhead (vs custom)	+$10,000
Lambda invocations (4M calls)	$800
CloudWatch trace (production, 5% sample)	$23
Knowledge Base retrieval	$600
AgentCore Memory (short-term only)	$250
Total (Bedrock Agents, default config)	~$29,223/month
With prompt caching enabled	~$17,623/month
With pre-filtering (30% bypass rate)	~$13,100/month

The headline optimization path: enable prompt caching, implement intent pre-filtering, reduce numberOfResults on KB retrieval, cap max iterations at 8, disable trace in production. Combined, these four changes reduce cost by 55% relative to unoptimized defaults.