For computer users and music lovers of a certain ages, Winamp is an iconic piece of software. Now this piece of music software history is making another comeback, this time as a music streaming subscription service powered by Deezer. But before you dash off to see how it compares to Spotify and Apple Music, you should be aware that there is a bit of a wait to endure. The new Winamp Player is not expected to launch until the first half of next year. Announcing the new deal, Deezer says: “Scheduled for release in H1, 2027, the new Winamp Player… [Continue Reading]

Highlights this week include:

• Microsoft Tops $90B Quarterly Revenue as Azure Hits $100B Annual Milestone by Sean Parker - Microsoft's $90 billion quarterly revenue reflects robust Azure growth and expanding AI market penetration across enterprises.
• Public Preview: Azure Enclave by The Azure Updates Team - Azure Enclave’s public preview supports high-security tenants, offering automated setup and centralized governance for isolating critical applications in Azure Government regions.
• Introducing Physical-World Intelligence: How GeoAI Is Helping Expand Enterprise AI by Nora Zhang - Physical-World Intelligence integrates real-world data including weather, satellite imagery, and infrastructure maps with enterprise information via AI to improve operational decision-making, such as forecasting storm effects on utilities.
• AI-Enabled Map Production Using Microsoft's MARS Model by Nelson Tam - The new Map Autoregressive (MARS) model from Microsoft automatically converts satellite images into structured GIS-ready vector maps, streamlining and accelerating automated feature extraction for enterprise mapping needs.
• Bring Your Own Orchestrator to Azure Container Apps Jobs by Hetvi Patel - Bring Your Own Orchestrator to Azure Container Apps Jobs lets teams use familiar workflow engines like Airflow, Temporal, or Dapr with Azure Container Apps Job execution layers, maintaining control plane familiarity while leveraging ACA Jobs for task processing.

Finally, I was renewed as a Microsoft MVP for the 11th year. This time around for the dual categories of Azure and .NET. These two interests come together in the Rx .NET framework, which was designed ~20 years ago for a cloud native future. We've just released v7.0 and my colleague and fellow MVP Ian Griffiths has just published a ~25 minute talk - Rx.NET v7.0 Released - and it could save you 95MB! - Rx.NET 7.0 reduces application deployment size by up to 95 MB through separated UI framework support in dedicated NuGet packages for .NET 8+, fixes breaking changes, and maintains binary compatibility.

Is [LibraryImport] always faster than [DllImport]? Not necessarily. I benchmarked both across native Windows API calls, string marshalling, handles, out parameters, and allocation-heavy scenarios. The results may surprise you.

Open letters about AI development

I wrote this summary of the past few weeks of open letters as a section of my sponsors-only newsletter but I've decided to share it here as well.

Open Weights and American AI Leadership was shepherded by Microsoft, dated July 24th, and signed by 235 AI-adjacent companies including NVIDIA, Amazon, Y Combinator, The Linux Foundation and (a later signer) OpenAI.

It's clearly an argument designed to counter any instincts by the current US government to ban or limit open weight models over "safety" concerns - a reasonable consideration given what happened to Claude Fable 5!

Relying solely on closed models is not inherently safe: they can be breached, misused, or fail in ways that outsiders cannot detect. And concentrating advanced AI capabilities behind a small number of closed models compounds that risk. It results in a small number of single points of failure, weakens competition, and leaves critical technology in the hands of a few providers. Open weight models, on the other hand, allow a broad community of researchers and developers to examine their behavior, identify vulnerabilities, develop safeguards, and improve them over time.

The one surprising note in the letter is that it comes out in support of distillation, where models train on output from other models:

In shaping this ecosystem, policymakers should be careful not to conflate legitimate model-development techniques with misappropriation. Distillation, or the practice of using one model’s outputs to help train or improve another, is a widely used technique for model improvement, evaluation, and validation. It reflects a long tradition of learning from, building upon, and improving existing technologies, a tradition that has helped drive innovation since the rise of the open-source software movement.

Notably absent from the signatures: Anthropic, who published their own response Our position on open-weights models three days later. CEO Dario Amodei doubled down on the risk of authoritarian governments building "AI models that are more powerful than those built by the US", and models being "misused to carry out cyberattacks or biological attacks", and called for "a crack down on industrial-scale distillation operations", while also stating that "Anthropic has never advocated for a ban on open-weights models".

Then on July 28th Pacing the Frontier was published, featuring signatures from "1,324 employees of frontier AI companies" - with names like Jakub Pachocki (Chief Scientist, OpenAI), Ilya Sutskever (Safe Superintelligence Inc, previously OpenAI), Dario Amodei (Anthropic), Jack Clark (Anthropic) and more. Their core message:

We request that the U.S. government support an international effort to develop the technical and governance tools needed to deliberately pace the frontier of automated AI development.

Their concern is intense competitive pressure combined with accelerated AI progress caused by automated AI research - and given that Anthropic produce 80% of their code with Claude Code, OpenAI had Sol reduce their end-to-end serving costs by 20%, and Kimi K3 designed a chip to serve a nano model built on its own architecture, you can see why people are taking that risk more seriously right now.

Tags: anthropic, generative-ai, openai, ai, llms, ai-ethics

What I cover when a customer asks "we want to build AI applications on Azure, where do we start?"

TL;DR: Azure AI Foundry is the unified platform for building AI apps on Azure. Start with Standard PAYGO, use Priority Processing selectively when latency matters but traffic is bursty, and move predictable baseline traffic to PTU when utilization exceeds 60-70%. Use ptucalc.com to model your costs before committing.

This guide is for engineering teams moving from prototype to production on Azure AI Foundry. If you're still evaluating whether Foundry is the right platform, start at ai.azure.com.

---

The starting point

A few weeks ago, I had a conversation with a customer's engineering team that was ready to build their first AI-powered application on Azure. They had experimented with ChatGPT, prototyped with the OpenAI API directly, and now needed to understand: how do we go from playground to production at enterprise scale?

That conversation became a workshop, then a deck, and now this guide. The questions they asked are the same ones I hear from every team making this jump.

What is Azure AI Foundry?

Azure AI Foundry is the unified platform for building, deploying, and operating AI applications on Azure. Think of it as the control plane for everything AI in your Azure environment:

• Model Catalog: 1,900+ models (OpenAI, Meta Llama, Mistral, Cohere, Phi, others)
• Prompt Engineering: playground, prompt flow, evaluation tools
• Deployment Options: Standard and Priority pay-per-token processing, Provisioned Throughput (PTU), Global/Data Zone routing
• Safety and Governance: content filters, red teaming tools, model monitoring
• Agent Framework: multi-step AI agents with tool-calling, code interpreter, file search

Foundry is not just another Azure service. It is the layer that ties models, data, compute, and governance together into one development surface.

The decisions you will face

Every team building on Foundry hits the same questions in roughly the same order.

1. Model selection

The model landscape in mid-2026:

My recommendation for agentic workloads: GPT-5.x for the orchestrator (best tool-calling accuracy), GPT-5-mini for sub-tasks (classification, extraction, formatting), and Phi-4 or fine-tuned models for domain-specific components.

2. Model lifecycle

Every model in Foundry follows a lifecycle: Preview, GA, Legacy, Deprecated, Retired.

What matters in practice:

• GA lasts roughly 18 months. Sounds like a lot, but it goes fast when you have a system in production.
• Legacy means a replacement is available. Start planning migration.
• Deprecated gives you about 90 days to migrate. After that, the API returns 410 Gone and your system stops.

The critical detail: if you use Provisioned Throughput (PTU), model migration is NOT automatic. You must do it manually: plan a maintenance window, test the new model with existing prompts, validate quality, and swap. Standard/Global Standard deployments auto-upgrade, but you don't control when.

My recommendation: create a model governance process. Monitor Azure Updates, maintain automated quality tests per model, and start migration planning at least 60 days before retirement.

3. Deployment type: Standard, Priority, or PTU

Most teams overthink this. The rule is simple:

Start with PAYGO (Pay-As-You-Go) when:

• You're in development/testing
• Traffic is unpredictable or bursty
• You're still figuring out which models you'll use long-term

Add Priority Processing when:

• The workload is user-facing and sensitive to latency
• Traffic is bursty or concentrated in business hours
• You want model-specific latency targets without reserving PTU capacity

Move to PTU (Provisioned Throughput Units) when:

• Sustained utilization exceeds 60-70% of equivalent PTU capacity
• You need guaranteed latency (no noisy-neighbor throttling)
• You're running production workloads with predictable patterns

4. Where Priority Processing fits

Priority Processing is the middle ground between Standard PAYGO and PTU. It keeps pay-per-token billing and requires no reservation, but eligible requests are handled by a priority service tier with a defined, model-specific latency target. You can enable it for an entire Global Standard or US Data Zone Standard deployment, or select it per request with service_tier: "priority".

The benefit is simple: more consistent low latency for interactive agents, copilots, and other time-sensitive paths without paying for dedicated capacity during idle periods. A useful pattern is to reserve Priority Processing for requests users are actively waiting on, while background summarization, extraction, and evaluation stay on Standard. For predictable steady-state traffic, PTU is still the stronger economic and capacity choice.

Priority is not reserved capacity. Azure can process a request on the Standard tier during peak demand, for long-context requests on certain models, or when traffic increases by more than 50% tokens per minute in under 15 minutes. When that happens, the response reports service_tier: "default" and the request is billed at the Standard rate. Monitor ServiceTierRequest and ServiceTierResponse in Azure Monitor so you can see requested versus actual processing instead of assuming every request stayed on Priority.

Rule of thumb: Standard for flexible general traffic, Priority for latency-sensitive bursts, and PTU for predictable baseline throughput. Many production systems will use all three.

5. How PTU actually works

PTU is a token-bucket model. Each PTU reserves a fixed throughput in tokens per minute. The rate varies by model:

• GPT-5-mini: ~3,500 TPM per PTU
• GPT-5: varies by variant
• GPT-4.1: 3,000 TPM per PTU (deprecating)

So 100 PTUs of GPT-5-mini give you roughly 350,000 tokens/minute guaranteed. Go past that and the API returns 429. No queue, no wait. Hard cutoff.

6. The cost math (this is where it gets interesting)

The break-even: if sustained utilization is above 60-70% of your PTU capacity, monthly reservation already beats PAYGO.

⚠️ These are reference prices as of July 2026. EA/MCA negotiated rates may differ. Always validate against your specific agreement.

I built ptucalc.com to help with exactly this calculation. It is open source. Plug in your usage patterns and it tells you the optimal tier and PTU count.

7. Spillover architecture

The pattern I recommend for production:

Configure your deployment with PTU as primary and PAYGO as spillover. You get:

• Guaranteed latency for your baseline traffic (PTU)
• No dropped requests during spikes (PAYGO absorbs overflow)
• Cost optimization (PTU for steady-state, PAYGO only for peaks)

You configure this at the deployment level in Foundry. No application code changes.

Part 2: production hardening

Everything above gets you running. The sections below get you running safely, at scale, with governance.

APIM as your AI Gateway

For any production AI workload, I recommend putting Azure API Management (APIM) between your applications and the models. APIM acts as a centralized AI Gateway with six capabilities that Foundry alone does not provide:

• Load balancing: round-robin or weighted distribution across multiple PTU/PAYGO backends. Enables DR and capacity distribution across regions.
• Rate limiting by token: unlike traditional rate limiting by request count, APIM counts actual tokens consumed. A request that uses 10,000 tokens weighs differently than one using 100. Much fairer for consumption control.
• Circuit breaker: when a PTU backend returns 429, APIM automatically fails over to the next backend (another PTU or PAYGO). No client-side retry needed.
• Semantic caching: caches responses by semantic similarity of the prompt. If someone asked something similar in the last N minutes, it returns from cache. Reduces cost and latency for recurring questions.
• Token tracking: consumption metrics per app, per team, per user. Emits to Azure Monitor. Essential for chargeback when multiple teams share the same models.
• Content safety: gateway-level policies that block malicious inputs before they reach the model. Defense in depth on top of Foundry's content filters.

The pattern: your applications and agents call APIM, not the model directly. APIM routes, controls, monitors, and protects.

Reference architecture for agentic workloads

For teams building multi-agent systems, this is the reference architecture I recommend:

1. Orchestration layer: a primary agent (typically using the best tool-calling model available, today GPT-5.x) that coordinates sub-agents, maintains conversation state, and decides the next action.
2. Specialized agents layer: each agent optimized for a specific task using the right model. A data extraction agent on Phi-4, a compliance agent on GPT-4.1, a UX agent on GPT-5. Different models for different tasks, optimizing both cost and quality.
3. Gateway layer (APIM): sits between agents and models. Each agent has different rate limits, routes to different models, and the circuit breaker protects against throttling. This is where you centralize governance.
4. Models layer (Foundry): multiple deployments with PTU for base load and PAYGO for burst. Multi-region for DR. Spillover happens automatically via APIM routing.

The key point: agents never call models directly. They always go through the gateway. If a misbehaving agent starts consuming too many tokens, you cut it at the gateway without touching the agent's code.

If you're running Azure SRE Agent alongside your AI workloads, skill 08 (AI Foundry & OpenAI Posture) can audit your Foundry deployment against these architecture patterns on a schedule. See my companion post: Custom skills for Azure SRE Agent.

Anti-patterns to avoid

These are mistakes I see repeatedly in production. Most of them seem obvious once pointed out, but they happen all the time:

The max_tokens one is subtle: Azure calculates PTU utilization based on input tokens PLUS reserved max_tokens, even if the actual response uses fewer. If you set max_tokens to 4096 but your typical response is 200 tokens, you are wasting capacity. ptucalc.com has a specific tool for this.

Production checklist

Things I check before any customer goes live:

Security and network

• Private endpoints configured (no public internet exposure)
• Managed Identity for authentication (no API keys in code)
• Content Safety filters tuned (not just defaults)
• VNet integration if required by compliance
• Data residency: model deployment region matches data requirements
• APIM as AI Gateway (no direct model access from applications)

Reliability

• Multi-region deployment (primary + failover)
• Retry logic with exponential backoff and jitter
• Circuit breaker pattern for downstream dependencies
• Health probes and availability monitoring
• Spillover configured (PTU primary, PAYGO overflow)
• Priority Processing scoped to latency-sensitive paths, not every request
• APIM load balancing across PTU backends

Observability

• Token consumption metrics in Azure Monitor
• Latency P50/P95/P99 dashboards
• Cost allocation tags on all Foundry resources
• Alerting on 429 rates (throttling indicator)
• Model performance evaluation pipeline (drift detection)
• APIM token tracking enabled (per app/team/user)
• Priority requests split by ServiceTierRequest and ServiceTierResponse

Cost governance

• Budget alerts configured
• Chargeback tags for multi-team environments
• PTU utilization monitoring (target: 70-85%)
• max_tokens tuned per use case (not default 4096)
• Regular review cadence (monthly) for tier optimization

Model governance

• Model lifecycle monitoring (Azure Updates subscription)
• Automated quality tests per model version
• Migration plan documented (60+ days before retirement)
• PTU migration runbook (manual swap required)
• Semantic caching configured in APIM for recurring queries

The typical progression

Most teams I work with follow this path:

Don't skip steps. Each phase teaches you something about your workload that informs the next decision.

Where to start

1. Open the Foundry Playground and test models against your actual use cases
2. Model your costs with ptucalc.com before committing to PTU
3. Deploy with spillover from day one. It costs nothing extra when PTU handles the load, but saves you when spikes hit
4. Set up monitoring early. You cannot optimize what you cannot measure

---

Next steps

1. Deploy a model in Foundry — pick GPT-4o on PAYGO, wire it to a single endpoint, and run a test prompt through the REST API. Time: 20 minutes.
2. Run ptucalc against your traffic — export your token consumption from Azure Monitor and model the break-even point. If you're above 60% sustained utilization, PTU likely pays for itself.
3. Add APIM in front — even in dev. Configure a single policy with token-rate-limit and emit-token-metric. This gives you observability and a retry layer from day one.

---

Resources:

• Azure AI Foundry
• Priority Processing documentation
• PTU Calculator
• Foundry Documentation
• Well-Architected Framework for AI

---

Questions about deployment strategy or cost modeling? Leave a comment.

---