.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
How Does Databricks Price Its Mosaic AI Agent Framework for Evaluation Serving and Orchestration
Enterprise buyers often ask what the Mosaic AI Agent Framework costs, as though Databricks sells one agent licence with a clear annual price. The question is understandable. It is also based on the wrong unit of analysis.
Databricks does not charge a single fee for building, evaluating, serving and orchestrating an agent. As of 7 August 2026, it charges for the resources consumed at each stage: model tokens, judge requests, serving capacity, retrieval infrastructure, gateway controls, app compute and related data work. The common currency is the Databricks Unit, or DBU, but the physical events behind each DBU vary widely.
Monetizely’s position is that this model gives Databricks strong pricing power because every production agent can pull more workloads onto its platform. Yet the same design makes an agent’s full cost hard for customers to forecast. Databricks’ next pricing reset should make the agent run the customer-facing primary meter while retaining DBUs as the internal settlement unit.
Databricks monetises the full agent path rather than selling a framework licence
Mosaic AI Agent Framework became publicly available in preview on 12 June 2024. At that stage, Databricks presented an integrated development path: teams could log agents and chains, measure retrieval quality, accuracy, cost and latency, deploy applications, capture requests and responses, and collect human feedback. Agent Framework reached general availability on 7 March 2025, while Agent Evaluation became generally available later that month.
By June and July 2026, the product had broadened into an agent lifecycle spanning MLflow 3, Databricks Apps, Model Serving, AI Search, managed tools and multi-agent orchestration. Customers could build with OpenAI Agents SDK, LangGraph, LangChain or plain Python, then connect agents to Databricks data and external tools through Model Context Protocol servers.
The commercial logic becomes clearer through Monetizely’s 5-Step Pricing Framework. The framework links five decisions that companies often make separately: goals and segmentation define which customers and behaviours the offer should attract; packaging determines what is included and what remains an add-on; the pricing metric specifies what grows the bill; rate setting converts that meter into prices and discount bands; and operationalisation covers quoting, billing, reporting, controls and renewals. As discussed in Monetizing Agentic AI, the steps work as a chain: strong technology can still produce a weak business model when the package, meter and billing experience pull in different directions.
For Databricks, the first step is implicit. The platform is aimed at organisations that already manage important data and AI workloads and want agents to inherit the same governance. Packaging, however, is distributed across products. The framework itself is not the commercial package. It is the route into several billable services.
The table below separates those services so buyers can see which event actually creates spend. Rates shown are from Databricks’ official pricing pages and its last indexed serverless SKU schedule, dated 26 November 2025, unless a newer page is noted.
| Agent lifecycle layer | What Databricks provides | Dominant billable event | Published pricing signal |
|---|---|---|---|
| Agent evaluation | LLM judges, built-in scorers and quality assessment | Judge request | 1 judge request = 1 DBU |
| Foundation-model inference | Hosted open and proprietary models | Input, output and cached tokens | DBUs per one million tokens, varying by model |
| Custom model or agent serving | Serverless CPU and GPU endpoints | Concurrent requests or provisioned compute time | CPU: 1 concurrent request-hour = 1 DBU-hour; GPU configurations range from 10.48 to 628 DBUs per hour on the current pricing page |
| Retrieval | AI Search indexes and endpoints | Provisioned vector-search capacity | Standard unit: 4 DBUs per hour in the indexed GCP schedule; storage-optimised unit: 18.29 DBUs per hour |
| Gateway controls | Usage tracking, inference tables and guardrails | Payload volume or tokens checked | Usage tracking: 1.429 DBUs per GB; inference tables: 7.143 DBUs per GB; guardrails: 21.429 DBUs per million tokens |
| Application and orchestration runtime | Databricks Apps, notebooks, jobs and supporting compute | App capacity-hours or serverless compute | Databricks App capacity was listed at a 0.5-times interactive serverless multiplier in November 2025 |
A buyer therefore does not purchase “Mosaic AI Agent Framework usage”. The buyer accumulates a set of charges generated by the framework’s underlying services.
The DBU gives procurement one contractual currency. Databricks can offer pay-as-you-go billing with per-second granularity, then discount larger committed-use contracts and allow some commitments to move across clouds. That structure is attractive to a global enterprise already buying data engineering, warehousing and machine-learning capacity from the company.
Uniform currency does not mean uniform economics. One DBU can represent a judge request, a slice of GPU time, a quantity of model tokens or a multiplier applied to an app workload. Those units respond to different operating variables.
An agent’s bill may rise because:
- more employees or customers initiate runs;
- each run invokes more tools or generates longer prompts;
- the organisation evaluates a larger share of production traces;
- retrieval indexes grow or require higher query capacity;
- security teams activate more logging, guardrails and regional controls;
- traffic becomes steady enough to justify provisioned throughput.
The distinction matters because many of these costs are additive. A support agent can trigger model inference, query AI Search, call a SQL tool, log its payload, pass through guardrails and later receive two or three judge assessments. Counting only the model tokens understates the cost of the production service.
Databricks’ pricing evolution shows how this complexity accumulated. Each product advance made the platform more complete, while also creating another potential consumption stream.
The pattern is consistent: Databricks has made the product easier to adopt technically faster than it has made the workload easier to price commercially.
Model choice adds another layer. On 7 August 2026, Databricks’ proprietary model page expressed OpenAI and Anthropic prices as DBUs per million input, output, cache-write and cache-read tokens, with separate rates for global and in-geography processing. The page also offered hourly batch-inference rates. Model Serving used a different schedule based on GPU configuration, ranging from a T4-class instance at 10.48 DBUs per hour to eight A100 80GB GPUs at 628 DBUs per hour.
Such detail is useful to an ML platform engineer. A business owner deciding whether an agent can process a claim for £1, draft a sales proposal for £3 or resolve a support case for 50 pence needs a different view.
Agent economics point towards runs rather than seats or pure outcomes
The Agentic Monetization Spectrum, or AMS, helps determine which meter best reflects how an AI product creates value. It assesses three dimensions. Zero-human ability measures how much of the work the product completes without intervention. Operational domain asks whether the agent performs one task, manages an end-to-end workflow in one function or acts across several functions. Output/cost ratio compares the value of the work produced with the cost of supplying the agent, ranging from roughly linear economics to gains of tens, hundreds or thousands of times the delivery cost. These dimensions matter because a low-autonomy assistant can still fit a seat price, while a highly autonomous system with repeatable outputs usually needs a usage or outcome-linked meter.
The available practitioner evidence places Databricks agents in the middle-to-upper part of the spectrum, rather than at either extreme.
The evidence behind those scores is unusually concrete. In a June 2026 Databricks summit session, McAfee’s Arul Bharathi described an autonomous feature-engineering agent that “cuts engineering cycles by 60%”; the wider personalisation work had contributed more than $54 million in incremental revenue over three years.
CFC’s Christopher Mullan reported that its agentic underwriting system produced “trusted quotes ready in 5 minutes vs 24 hours”. The session also put the processing cost at £0.50 per quote, down from £5.
Samsara Senior AI Engineer Vipul Panwar presented a multi-agent sales system that reduced research from 60 minutes to under five minutes and raised meeting-booking rates from 0.18% to 6.49%.
Accenture Managing Director Prakash Trivedi described a healthcare agent that reduced a 15-to-20-minute coverage enquiry to five minutes while delivering 93% to 95% grounded accuracy.
These cases justify a premium platform price. They do not support a single outcome fee. A quote, a meeting, an engineering feature and an insurance answer have different values, risk levels and success definitions. The common event is the agent run: an initiated orchestration cycle in which the system reasons, retrieves data, invokes tools and returns or executes a result.
Seat pricing would miss machine-driven volume. Pure token pricing tracks vendor cost but not customer work. Outcome pricing would invite arguments over attribution. A run meter sits between them.
Enterprise controls strengthen the platform while weakening price clarity
Databricks gets several parts of operationalisation right. Model-serving costs appear in the system.billing.usage table, with separate SKUs for endpoint launches and real-time inference. Organisations can aggregate DBUs, add tags and connect spending to endpoints or workloads.
Unity AI Gateway extends that control. By July 2026, Databricks documented request and token rate limits for model and MCP services, along with budgets that could track selected inference workloads. AI Search endpoints also stopped charging 24 hours after the last index was deleted, reducing the risk that empty infrastructure would remain indefinitely billable.
Yet control is not the same as predictability. Databricks’ budget documentation states that, as of July 2026, gateway budgets did not track provisioned throughput or external-model inference. A customer can therefore create a budget around only part of the production agent’s spending. Small overruns can also occur while active requests finish or enforcement catches up.
Competitive pricing models show that Databricks is not alone in charging for several layers. The difference lies in how visible those layers are to the buyer.
| Platform | Primary commercial currency as at August 2026 | How agent costs accumulate | Buyer experience |
|---|---|---|---|
| Databricks | DBUs | Tokens, judge requests, endpoint time, retrieval capacity, payload volume and app compute | One currency, many technical meters |
| Snowflake Cortex Agents | AI Credits | Agent tokens plus additive Search, Analyst, SQL and warehouse charges | A separate AI currency, but underlying services still add up |
| Google Vertex AI Agent Engine | Dollars per vCPU-hour, GiB-hour, session event and stored or retrieved memory | Runtime, memory, code execution, sessions and memory are priced separately | Infrastructure components are explicit |
| Amazon Bedrock Agents | Model tokens or provisioned model units, plus connected services | Model inference, knowledge bases, guardrails, evaluation and throughput | Direct service-by-service cloud pricing |
| OpenAI API | Tokens and tool calls | Input, cached input, output, web search, containers and other tools | Simple at small scale, increasingly layered as tools are added |
Databricks most closely resembles Snowflake: both translate several forms of AI activity into a platform credit. Google and AWS expose more of the infrastructure directly, while OpenAI begins with a simple token model and adds tool-level charges.
The DBU is therefore not the problem by itself. The weakness is that customers must reverse-engineer the number of DBUs behind a business process. A well-designed agent may cost less because it uses a smaller model, calls fewer tools and samples fewer traces for evaluation. A poorly designed one may consume several times more DBUs while producing the same answer. Procurement cannot see that difference from the package name.
The 5-Step scorecard below grades the three decisions that most shape Mosaic AI Agent Framework’s commercial performance.
The scorecard means Databricks has built better billing infrastructure than buyer-facing price architecture. Its strongest operational capability is compensating for a packaging and metric problem.
What Databricks gets right is the link between price and supplier cost. Expensive models, large outputs, heavy evaluation and dedicated GPU capacity consume more DBUs. Customers can also trade flexibility for discounts through committed-use contracts. The design supports model choice, multi-cloud deployment and a broad range of workloads without forcing Databricks to make the same gross-margin bet on every agent.
What Databricks gets wrong is the unit presented to the business. Judge calls, tokens, payload gigabytes and vector units describe infrastructure. They do not tell a chief customer officer what one resolved case costs or tell a sales leader what one researched account costs.
Monetizely’s committed recommendation is a single pricing reset: make the completed agent run the primary customer-facing meter.
A run should cover one initiated agent workflow, including a stated allowance for model tokens, tool calls, tracing, retrieval and sampled evaluation. Databricks should publish run bands for common levels of complexity, then convert actual component usage into DBUs behind the scenes.
The reset should have four design rules:
- Each run tier must state the included token, tool-call and execution limits.
- Evaluation should be included at a defined sampling rate, rather than appearing as an unrelated judge-request charge.
- Premiums should be reserved for choices customers can understand, such as dedicated throughput, strict data residency or unusually long-running workflows.
- The account console should show both cost per run and the DBU components that produced it.
DBUs would remain valuable for contract commitments, cloud settlement and technical optimisation. The commercial conversation, however, would move from “How many DBUs did the endpoint consume?” to “How much does this workflow cost each time it completes?”
Such a reset would also strengthen Databricks’ competitive position. Snowflake can match a credit. AWS and Google can match infrastructure breadth. OpenAI can compete on model price. Databricks has a better opportunity: price the governed workflow that joins enterprise data, tools, evaluation and serving.
Operators should buy the workload rather than the component list
Enterprises evaluating Mosaic AI Agent Framework should make four decisions before committing material spend.
Create a separate profit-and-loss view for each agent. Measure the business value, number of runs and full Databricks consumption of each workflow. Aggregating all agents into one platform budget conceals which use cases deserve more investment.
Set a company-wide policy for model selection. Route routine work to the lowest-cost model that meets the quality threshold, and reserve frontier models for runs where better reasoning changes the business result. Databricks’ multi-model catalogue makes this operationally feasible.
Give one team ownership of agent economics. Data engineering, AI, finance and the business function should not optimise separate parts of the bill. A single owner must control quality targets, evaluation frequency, latency and cost per run.
Negotiate commitments against run-volume scenarios. Translate expected low, base and high run volumes into DBU demand before signing. Contract terms should permit model substitution and cross-cloud flexibility rather than locking the commitment to one initial architecture.
Databricks has already assembled most of the technical pieces needed to run enterprise agents at scale. Its next source of pricing power will not come from adding another separately metered component. It will come from making the complete agent workflow easier to value, forecast and purchase.
Assumptions
Pricing and product status are assessed as at 7 August 2026. DBU rates vary by cloud, region, tier, model and negotiated commitment, so the article compares published consumption units rather than imposing one dollar conversion. Databricks remained privately financed during the research period; no public 10-K or recurring public earnings-call transcript was available. Pricing history therefore relies on official product pages, documentation, release notes and company announcements. No Wayback snapshot was treated as evidence because a stable, verifiable dated capture could not be resolved during the research session.
Footnotes
https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
https://www.databricks.com/product/pricing
https://www.databricks.com/product/pricing/product-pricing/instance-types
https://docs.databricks.com/gcp/en/resources/pricing
https://www.databricks.com/product/pricing/model-serving
https://www.databricks.com/product/pricing/proprietary-foundation-model-serving
https://www.databricks.com/product/pricing/agent-evaluation
https://docs.databricks.com/aws/en/release-notes/product/2024/june
https://docs.databricks.com/aws/en/release-notes/product/2025/march
https://docs.databricks.com/aws/en/mlflow3/genai/agent-eval-migration
https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor
https://docs.databricks.com/aws/en/agents
https://docs.databricks.com/aws/en/agents/agent-framework/author-agent
https://docs.databricks.com/aws/en/agents/agent-framework/agent-tool
https://docs.databricks.com/aws/en/admin/system-tables/model-serving-cost
https://docs.databricks.com/aws/en/ai-gateway/rate-limits
https://docs.databricks.com/aws/en/ai-gateway/budgets
https://docs.databricks.com/aws/en/ai-search/cost-management
https://www.databricks.com/dataaisummit/session/agentic-feature-engineering-how-mcafee-drives-personalization-agent
https://www.databricks.com/dataaisummit/session/reinventing-operational-scale-through-agentic-underwriting
https://www.databricks.com/dataaisummit/session/how-samsara-built-multi-agent-system-drive-36x-lift-meeting-bookings
https://www.databricks.com/dataaisummit/session/accelerating-industry-solutions-leveraging-power-agents-databricks
https://openai.com/api/pricing/
https://aws.amazon.com/bedrock/pricing/
https://cloud.google.com/vertex-ai/docs/release-notes
https://cloud.google.com/blog/products/ai-machine-learning/new-enhanced-tool-governance-in-vertex-ai-agent-builder/
https://docs.snowflake.com/en/user-guide/snowflake-cortex/pricing
https://www.sec.gov/search-filings
https://www.prnewswire.com/news-releases/databricks-grows-65-yoy-surpasses-5-4-billion-revenue-run-rate-doubles-down-on-lakebase-and-genie-302682674.html