Catalogue › Microsoft Foundry › foundry-cost-management

Foundry cost management

Estimates, budgets and controls the running cost of a Microsoft Foundry solution - model consumption, reserved capacity, search, storage, compute and monitoring - with cost per outcome, tagging, budgets, alerts and named owners. Use when a Foundry build needs a cost estimate, when consumption spend is rising or unexplained, or when a team is choosing between pay-per-use and reserved capacity.

Department

Microsoft Foundry

Lifecycle

Mobilise, Deliver, Measure, Improve

Maturity

builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

ai-foundry, azure

Editions

starter, scale, enterprise

Reviewers

design-authority

Status

draft

Copilot Cowork

Microsoft Foundry plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

A Foundry solution is paid for every time it runs, and its cost moves with usage, prompt length, model choice and design decisions nobody priced. This skill brings financial operations discipline to custom AI: an estimate built from the solution's own behaviour, a cost per business outcome the owner can judge, tagging so all spend is attributable, budgets and alerts that reach someone who can act, and a routine of optimisation. Cost management goes wrong when the estimate is a guess at token counts made before the prompts exist, when shared resources make spend unattributable, and when the first anyone hears of an overspend is the monthly invoice.

When to use

• A Foundry solution has been approved and needs a running-cost estimate and budget before build continues.
• Consumption spend is rising, spiking or cannot be explained by usage.
• A team is choosing between pay-per-use deployments, reserved throughput and batch processing.
• A sponsor asks what a solution costs per case, per answer or per user, and whether it still pays back.
• Several Foundry solutions share resources and finance wants spend split by owner.

When not to use

• Deciding whether the solution is worth building at all - use ai-foundry:foundry-solution-assessment.
• Licensing, seat and capacity entitlement questions across Microsoft AI - use platform-governance:ai-licensing-and-capacity.
• Programme-level budget and people capacity - use programme-management:budget-and-capacity.
• Choosing deployment type, region and capacity for reasons other than cost - use ai-foundry:foundry-deployment-architecture.
• Building the return-on-investment model for the benefits case - use value-realisation:roi-model.

Questions to ask first

1. What is the unit of business outcome (a case resolved, a document processed, a question answered), and how many are expected per day at launch and at full use?
2. Which cost-bearing components does the design use: models, reserved capacity, search indexes, storage, compute for tools, monitoring and evaluation runs?
3. Who owns the budget, who receives alerts, and what may they do when a threshold is crossed?
4. Is demand steady, spiky or batch, and does any part of the work tolerate delay?
5. What cost per outcome would make the solution no longer worth running?

Required inputs

• The solution design on the foundry-solution-design template, with the model selection record and deployment choices.
• Measured token use per task from prototype or evaluation runs, not estimates from the specification.
• Volume forecasts from the business owner, with a low, expected and high case.
• The organisation's Azure tagging standard, cost allocation model and budget approval route.

Where measured token use is not yet available, mark the estimate [To confirm: measured during evaluation] and give a range rather than a figure. Never quote unit prices from memory; read them from the current Azure pricing source on the day and record the date.

Decision framework

Practitioner approach

Build the estimate from the design, not from a calculator. List every component that bills, then for each model call in the solution record its inputs, typical prompt and context size, output size and how many times it runs per business outcome. Agentic designs multiply calls: a single answer may involve planning, several tool calls and a final response, each carrying the conversation so far. Measure these on the prototype or evaluation runs and multiply by the volume range. Add search, storage, compute for hosted tools, monitoring data ingestion and the evaluation runs you will repeat after every change, which teams routinely forget.

Express the result as cost per outcome as well as cost per month. A monthly figure invites a yes or no; a cost per resolved case can be set against the value hypothesis and watched as usage grows. Agree with the business owner the ceiling above which the solution should be redesigned or paused, and record it.

Make spend attributable from the first deployment. Apply the organisation's tags for solution, owner, environment and cost centre to every resource, keep production and non-production apart, and where capacity is shared, agree the allocation key in writing before the first invoice. Unattributed AI spend is the commonest reason finance loses confidence in a programme.

Set budgets and alerts that reach a person with authority to act, and write down what they will do: throttle, switch to a smaller model, pause a workflow or accept the spend. Pair budget alerts with consumption-rate alerts in monitoring, because invoices and cost reports lag behind usage. Guard against runaway cost in the design itself with per-run budgets in agentic workflows, rate limits per caller and quotas per environment.

Review cost monthly with usage and quality side by side. Look first at prompt and context bloat, steps that use a larger model than they need, repeated identical calls that could be cached, and work that could move to batch. Change one thing at a time and rerun evaluation, because a cheaper configuration that quietly lowers quality is not a saving.

Reserved capacity is a financial commitment, not a performance setting. Recommend it only when measured, steady usage shows a saving at realistic utilisation, and when someone owns the commitment and its renewal. Capacity terms, prices and discounts are volatile; take them from the current source and route commercial questions to the Microsoft licensing guide, a licensing partner or procurement.

State what the estimate cannot determine: real user behaviour after launch, especially conversation length and retry patterns, which only production data reveals.

Outputs

• A cost model in the foundry-solution-design template: components, measured units per outcome, volume range, cost per outcome, monthly range, assumptions with dates and sources.
• A budget, alert and response plan naming the owner and action for each threshold.
• A tagging and allocation statement for every resource the solution uses.
• A monthly cost review record with the optimisations tried and their effect on quality.

Microsoft platform considerations

Foundry costs combine model consumption, which differs by model, provider and deployment type, with the Azure services around it. Partner and third-party models may be billed differently from models sold by Microsoft, and reserved, pay-per-use and batch options are not available for every model or region. All of this changes often, so take current facts from the source records and the Azure pricing pages, and use Azure cost management tooling for budgets, alerts and allocation. Licensing and commercial terms route to the Microsoft licensing guide or a licensing partner.

Adoption considerations

Not applicable to most cost work, because users do not see it directly. Where cost controls change what users experience, such as shorter answers or queued requests, tell them through the solution's release communications.

Knowledge considerations

Not applicable to cost directly, but grounding design drives context size; large, poorly targeted retrieval results are a common hidden cost, so share findings with ai-foundry:retrieval-design.

Security and privacy considerations

Cost and usage reports can reveal who used the solution and how much. Report at solution, team or role level only, and restrict access to any per-caller usage data used for throttling. Denial-of-wallet attacks, where an attacker drives up consumption, are a security concern; rate limits and authenticated access are the controls.

Responsible AI considerations

Not applicable in most cases, because cost decisions rarely affect people directly. Where a cost saving reduces safety filtering, human review or evaluation coverage, it becomes a responsible AI decision and goes to the responsible-ai department before it is made.

Evaluation requirements

Every cost optimisation that changes a model, prompt, context size or cache is evaluated against the existing threshold before release, using ai-foundry:model-evaluation. Record the quality result next to the saving.

Value measures

Track cost per outcome against the agreed ceiling and against the value per outcome in the benefits case, owned by the solution owner with finance. Track the share of spend that is tagged and attributable, aiming for all of it.

Scale notes

Starter

Keep one budget per solution with a forecast alert to the owner, use pay-per-use, and review cost monthly alongside usage. A simple spreadsheet cost model is enough if its assumptions are dated.

Scale

Standardise tags, budgets and cost-per-outcome reporting across Foundry solutions, and run a shared monthly review where solution owners compare patterns and reuse optimisations.

Enterprise

Run AI cost as part of the organisation's financial operations practice, with chargeback or showback by owner, governed decisions on reserved capacity across solutions, and anomaly detection on consumption.

Hand-offs

• To ai-foundry:foundry-deployment-architecture when cost points to a different deployment type or capacity model.
• To ai-foundry:model-selection when a smaller model might do a step.
• To platform-governance:ai-licensing-and-capacity for entitlement and commercial questions.
• To value-realisation:roi-model with cost per outcome for the benefits case.
• To ai-operations:ai-solution-monitoring for consumption-rate alerts.

Reviewer gates

From risk tier 2, design-authority checks that the cost model is complete, that resources are tagged to the standard and that reserved capacity commitments have an owner. Cost changes that alter safety or review controls also pass the responsible-ai gate.

Failure modes

• The estimate counts one model call per answer, but the agent makes several with growing context, and spend runs far above budget.
• Resources are shared and untagged, so nobody can say which solution caused a spike.
• Budget alerts go to a shared mailbox nobody reads, and the overspend is found on the invoice.
• Reserved capacity is bought on forecast volume that never arrives.
• A cheaper model is swapped in to save money without re-evaluation, and quality falls unnoticed.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Quote prices, discounts or capacity terms from memory.
• Approve a running cost without a named budget owner and an alert that reaches them.
• Make a cost optimisation that changes model behaviour without re-running evaluation.
• Report usage or cost by named individual.