The Azure Credit Trap: Claude or Fable Spend Is Marketplace SaaS, Not Foundry Spend
Why Claude or Fable spend that looks like Foundry consumption can actually be a third-party Marketplace SaaS line, and the classification rule plus cron guard we now enforce.
The Azure Credit Trap: Claude or Fable Spend Is Marketplace SaaS, Not Foundry Spend
Azure credit programs do not cover every line on the Azure bill the same way. That single fact cost us time and money on 2026-06-12.
A inference path that we assumed was burning Azure consumption credits through Foundry was actually billing as a third-party Marketplace SaaS subscription. The giveaway was sitting in two cost columns the whole time:
ServiceName = SaaS
PublisherType = Marketplace
That pair changes the entire spend story. If you are running on Microsoft Azure Consumption Commitment, free credits, or a sponsorship plan, Marketplace SaaS lines do not draw down the same way Foundry consumption does, and in many credit programs they do not draw down at all.
We caught this on the same day and rerouted a cron that had been silently pinning traffic to the wrong model path. The postmortem is short because the diagnosis was short. The cron is the interesting part.
How a route drifts into Marketplace SaaS
A model router that pings multiple providers is convenient and easy to misconfigure. If the default fallback path lands on a third-party Claude or Fable endpoint that is provisioned through the Azure Marketplace, every request shows up in the Azure cost dashboard as Azure spend, because the bill is rendered by Azure. The decision was made somewhere else entirely.
Three things make this trap quiet.
- The dashboard says “Azure spend.”
- The mental model says “Azure spend.”
- The model router has no reason to surface that the underlying transaction is a Marketplace SaaS subscription from an external publisher.
So the bucket is wrong, and the credits that were supposed to be funding the work are not funding the work.
How to read the billing classification
Open Cost Management, export the usage detail, and inspect two columns per row.
PublisherType = Azurewith a first-partyMeterCategorymeans Azure consumption. Credit-eligible in most programs. Discountable.PublisherType = MarketplacewithServiceName = SaaSmeans Marketplace SaaS. Treat as third-party spend. Check the specific credit agreement before assuming.
That second row is the one that surprises new operators. A “model on Azure” can be a Marketplace offer from a publisher who is not Microsoft. The publisher is the seller of record. Azure is the billing rail.
What changes when a line is Marketplace SaaS
Four things, in order.
- Credit eligibility differs. First-party Azure consumption typically counts against committed-use and credit programs. Marketplace SaaS often does not, or only counts toward a capped portion of an MACC.
- Discounts differ. Reservations and savings plans apply to Azure resources, not to a third-party SaaS subscription.
- Forecasting breaks. If your dashboard buckets everything as “AI spend,” credit absorption and cash burn stop matching.
- Routing is invisible. A model router can quietly send traffic to a Marketplace SaaS endpoint instead of a native Foundry deployment, and the only signal is in the billing classification, not in the app logs.
What we changed in the cron
The cron in question had a default fallback that pointed at a Fable-backed Claude endpoint provisioned through the Marketplace. We pulled that fallback out of the hot path and pinned the production route to a verified first-party Foundry endpoint.
Three guard rails went in with the route change.
- The cron now records the resolved provider and publisher type of every request into the run log, not just a status code.
- A daily cost check rejects any production cron’s traffic that landed on a Marketplace SaaS provider without an explicit budget line.
- The model router fails closed if the resolved endpoint is not on the production allowlist. The cron fails loud, not silent.
Practical recipe for other operators
Pull the last 30 days of the production cron’s traffic and map each resolved provider to its Azure classification. If anything on the production path is PublisherType = Marketplace with ServiceName = SaaS, treat it as third-party spend.
Then apply three rules to the cron itself.
- Pin the production route. No silent fallbacks to Marketplace SaaS endpoints.
- Log the resolved provider per run, not the friendly alias.
- Block spend that lands on a non-allowlisted classification. Fail loud.
The boring part of this trap is that the fix is not a clever model router config. The fix is a billing classifier and a policy gate. Anyone running real spend on Azure needs both, even if they trust their routing today.