Sizing & cost planner
Start with the isolated architecture. Adjust your workload and resources to see their monthly cost.
Estimate only. Workload and build schedules are hypothetical. Nothing is deployed. Assumptions & price sources
Largest monthly costs
Adjust workload
These inputs describe demand, not what the deployment guarantees. Resource choices use the isolated standalone reference, with regional differences and billing hypotheses described below. Network isolation stays enabled. Changing demand does not automatically resize resources.
Peak planning rate assumes sustained concurrency at the entered mean turn duration. Calls and queries are distributed over that duration. This is a demand hypothesis, not a burst limit or measured performance. Index and vector footprints are entered separately from corpus bytes. Resource capacity is never resized automatically.
Presets change demand and its assessment, not allocated infrastructure. They are not validated Low / Medium / High capacity profiles.
Adjust architecture
Open a capability, then a resource to change it or read its sizing guidance. Options not deployed by default start at 0. Where supported, set an included resource's quantity to 0 to exclude its new allocation and linked costs. Keep replicas and partitions at valid values for an included service.
Check sizing
How to size this architecture
Establish the workload
Start with peak concurrent turns, turn duration, model/tool calls, input/output tokens, corpus and vector-index size, update rate and ingestion deadlines. Users alone do not determine capacity. Measure ingestion alongside interactive traffic, not only in isolation.
Models and quota
The reference deploys gpt-5-nano and text-embedding-3-large, each with sku.capacity=100. This allocates model-specific quota, not 100 users or a prepaid token budget. Check actual TPM/RPM, retries and regional availability. More application replicas do not increase model quota. Model limits ↗
Search capacity
Application Search and Foundry backing Search are separate services, each initially S1 with one replica and one partition. Partitions address index/vector footprint and growth. Replicas address retrieval/indexing load and availability. One replica is not a high-availability design. Validate limits for the service's region and creation date. Private native ingestion also needs approved, ready shared private links, not just more Search capacity.
Search SKU and counts are infrastructure literals, not root environment scaling flags. Persist changes in reviewed Bicep/Terraform source. Portal-only changes can be reset by provisioning. aiSearchResourceId reuses Foundry's backing service, not Application Search.
Host the components separately
The hosted orchestrator starts at 2 CPU / 4 GiB. Its child hosted-agent/azure.yaml declares literal sizes: changing provisioning environment variables alone does not resize it. Review the child definition and deployment metadata, then deploy a compatible agent version.
The frontend starts at 0.5 CPU / 1 GiB and one minimum/maximum replica. Optional application ingestion starts at 1 CPU / 3 GiB. They share the D4 Container Apps profile, whose node bounds start at 0 to 1. Minimum app replicas can retain a billable node. Raising app replicas does not raise the node ceiling or resize the Foundry host.
Data and operations
Budget Foundry backing Cosmos separately from optional application Cosmos. Verify actual throughput offers, data/index size, retention and backup policy. Build memory and parallel jobs size the build pool, not chat traffic. Registry storage persists when that pool is scaled to zero. Set logging retention/sampling from investigation and compliance needs, without capturing message content merely to size the system.
Validate the bottleneck
Use representative nonproduction tests with response-time, error-rate, ingestion-delay and concurrency targets. Include real tools, document sizes, authentication and document allow/deny behavior. Traces distinguish model throttling, Search limits, tool waits and host CPU/memory pressure. Compare before and after a capacity change.
Apply reviewed settings
Keep platform inputs in the root main.parameters.json. infra/main.parameters.json and Terraform inputs are generated. Verify the composed deployment, component versions and actual metrics rather than treating placeholders as measured capacity. Preserve Bicep/Terraform parity and use the infrastructure or full-stack runbook for execution.
Review constraints & evidence
Add availability requirements, quotas & measured evidence
Zero means not supplied, not zero capacity. Benchmarks apply only to the matching configuration and are cleared when it changes. They are operator-reported, not independently validated by this page.
Save, compare & export
Estimate scope
Compare the included resources, usage and price sources as well as the total. A scenario difference is not a guaranteed saving or an exact invoice.
Cost breakdown & changed inputs
Deployment handoff
Review guidance only, not generated deployment-ready IaC. Infrastructure changes must preserve Bicep/Terraform parity.
Edit sourced price assumptions
Edit USD price assumptions with a source/date, not confidential quote details. These are your planning inputs, not negotiated prices discovered by this tool. Token rates apply to the selected model and region; hosted/build amounts replace the whole row. Build amounts cover pool allocation, not active build time. Changing region/model clears these entries so you can reconfirm their scope.
Links and exports contain planning inputs and estimate notes. Do not enter credentials, confidential information or private identifiers. Saving on this device is explicit. Reload keeps a shared scenario URL, not unsaved edits.
Assumptions & price sources
Build a comparable estimate
Record the owner, date, region/currency, platform/component versions, selected and reused resources, expected monthly usage and contingency. Budget initial ingestion/reindexing separately from steady-state traffic. Resource counts, allocated hours, token usage, tool calls, transfer and retained storage are independent inputs. Changing topology, models, corpus or traffic can invalidate the estimate.
Public rates and sourced estimates
The catalog combines Azure Retail Prices API records with automatically captured official pricing-page rows, not a live quote. The gpt-5-nano Global token rates and dedicated ACR S1 allocation rate come from exact published HTML rows, recorded with source and capture date separately from API meters. Resource details identify each source and billing unit. Operator-entered amounts are labelled separately.
Automated daily refresh publishes only a validated catalog. If collection, exact-row parsing or validation fails, the last validated catalog remains in use. Check the displayed snapshot date and any stale-data warning before relying on an estimate.
730 hours is an editable monthly convention, not a deployment default. Daily meters use hours ÷ 24. Dedicated ACR pool allocation is billed even without active builds. Hosted allocation hours are a separate billing hypothesis, not a concurrency guarantee.
Budget for your selected scope
The inventory includes Foundry backing dependencies, application services, management networking and optional integrations. Structural configuration and shared compute must not be billed twice. Quantity zero means an option is not allocated in this scenario, not that it is free when enabled.
Review each row's included billing units and assumptions. Contract-priced options use your editable, sourced USD amounts. Additional model/tool use, ingestion, retrieval features, storage operations, retention, transfer and separately licensed services can change the bill.
Public rates do not incorporate your agreement, negotiated discounts, credits, taxes or currency conversion. Confirm availability, offer terms and the full selected scope with Azure Pricing Calculator or your account team. A difference from the reference is meaningful only with comparable scope and assumptions.
Reference billing hypotheses & regional differences
The initial build schedule is 1 deployment/day for 30 days, with an editable 40 allocated minutes per deployment including startup, build and shutdown: 20 hours/month. At the captured S1 rate of $0.0001/vCPU-second and 2 vCPU, that is $14.40/month. Scale the pool to zero outside those windows in the actual operating process. Neither the planner nor this assumption implements that automation. Leaving it allocated for 730 hours costs $525.60 at the same rate. Use the pool's monthly-hours mode for continuous allocation or an already measured schedule.
The initial model workload is 132 million input tokens and 22 million output tokens per month. Captured gpt-5-nano Global rates are $0.05 and $0.40 per million respectively, producing $15.40. Billable reasoning tokens belong in output tokens. Review each resource's live calculation for refreshed rates and your selected quantities.
The fresh Foundry backing Cosmos DB account uses provisioned throughput. Its budget example assumes five manual 1,000-RU/s offers (5,000 RU/s total), 10 GB of transactional data plus indexes, a separate 10 GB of Continuous30Days backup and one non-zone-redundant region. This is a $296.50/month hypothesis at the captured rates, not a declaration of deployed offers. The Foundry runtime owns the actual offers.
The backup selector is also a billing hypothesis: pinned Bicep AVM inherits Continuous30Days, while Terraform omits the backup policy and receives the API's periodic default. Selecting a backup hypothesis here does not change either provider or establish deployed parity.
Standalone firewall selection
East US 2 starts with the shipped Basic Firewall choice. Include allocation, processed data, its separate management public IP and subnet, diagnostics and transfer. Choose security features before price. Standard DNS proxy is not a Basic capability. For Sweden Central, no VNet Basic rate was found in the Retail API or official Basic pricing row, so Standard is the regional reference. A secured-vHub price is not substituted. Deploying that reference needs a reviewed IaC change.
Keep the scope explicit
Hosted compute, frontend compute, two Search services, backing data services and private management networking are separate costs. Count shared Container Apps nodes and workspace-based Application Insights ingestion only once. An omitted new resource can require a compatible existing service or a different feature selection, not a free replacement. DNS zones, disks, registry images and other retained allocations do not necessarily disappear with their consumers.
Control spend without weakening the design
Measure idle allocations, retries, logs and retained resources. Tune model choice, capacity, replicas and retention against quality, latency, availability and compliance. Budgets and alerts notify, they do not stop services or cap spend. Keep private networking, authentication and document-level authorization intact. Shared infrastructure needs approved ownership, routes and permissions. Review backup, dependencies and access before deleting existing resources. A quantity of 0 here never deletes them.
This planner models network-isolated standalone deployments. The reference uses hosted-no-panel, native Foundry IQ ingestion, no separate Agent Application Cosmos DB and no Agent App Ingestion worker. Foundry backing services are separate resources. Review deployment choices, deployment settings and the deployment runbook before applying a scenario. The shared cost guide has additional dated pricing examples, not current Agent defaults.