Per-Run vs Per-Seat AI Pricing: 50-Person Team Math

Every AI vendor pitches one of two pricing models. Per-seat (a flat monthly fee per user with credit caps) or per-run (you pay for actual model usage, often passed through with a markup). On the surface they look like personal preference. In practice the choice decides whether your AI program looks expensive or invisible at the end of year one.

This article walks through the real numbers for a 50-person team across three usage patterns. The conclusions are not subtle. Per-seat pricing punishes teams that adopt unevenly (which is every team in year one). Per-run pricing tracks reality, which is what every CFO actually wants from an AI line item.

The case the vendors make

Per-seat vendors argue three things.

Predictable budget. Finance teams can forecast EUR X per user per month and lock it in for the year. No surprise bills, no spikes during a big project, no awkward conversations about who used too much.

Encourages adoption. A flat fee removes the inhibition that meters create. Users do not have to ask whether their question is worth the cost. They just use the tool.

Simple procurement. One SKU, one renewal cycle, easy to compare across vendors.

The arguments are real. They are also incomplete. Each one comes with a hidden cost that shows up by month four.

The predictability is bought by buying more capacity than you use. The adoption is bought by accepting that 30 to 50 percent of seats sit idle. The simplicity is bought by making it impossible for anyone (the CFO, the IT lead, the AI owner) to see who is actually getting value.

What the numbers actually say

We modeled a 50-person team across three usage shapes that match what we see in production:

Shape A: Early adopter team. 10 power users running 80 to 150 agent runs per week each. 40 occasional users running 2 to 8 runs per week. Realistic for the first 6 months of an AI program.

Shape B: Mature team. 25 active users averaging 25 to 50 runs per week. 25 light users averaging 5 to 15 runs per week. The state most teams reach in months 7 to 12.

Shape C: Heavy automation team. All 50 users running 40 to 80 runs per week. Agents wired into core workflows. The state mature teams reach in year 2.

A standard per-seat license at EUR 35 per user per month with a 200-run cap per user costs EUR 1,750 per month flat (50 users x EUR 35). Per-run pricing assumes EUR 0.04 to EUR 0.08 per typical run blended across short queries, medium workflows, and long multi-agent jobs.

Usage shape	Total runs per month	Per-seat cost	Per-run cost (blended EUR 0.06)	Difference
Shape A (early)	4,800	EUR 1,750	EUR 288	-EUR 1,462 per month
Shape B (mature)	18,500	EUR 1,750	EUR 1,110	-EUR 640 per month
Shape C (heavy)	51,200	EUR 1,750 plus overage	EUR 3,072	+EUR 1,322 per month

The pattern is consistent: per-run pricing wins by a wide margin in early and mid adoption, and only loses at very heavy usage that most teams will not reach in year one. Over a 12-month horizon starting from Shape A and ending at Shape B, per-run pricing saves EUR 12,000 to EUR 15,000 on a 50-person team.

Three things this analysis misses that almost every vendor comparison skips:

1. Per-seat caps are not really caps. Every per-seat vendor charges overage when users blow through their credit allocation. The overage rates are 2 to 4x the base rate, and on heavy teams (Shape C) the overage line item can match the base license cost. The flat-fee predictability disappears the moment usage scales.
2. Idle seats are the largest hidden cost. Across 22 customer audits in 2024 to 2025, 38 percent of per-seat licenses had less than 5 runs in the past 30 days. The team was paying full price for capacity nobody used. With per-run pricing, that capacity costs zero.
3. The CFO test fails on per-seat. When the CFO asks "what did we spend on AI for the finance team last month", per-seat pricing can give a per-license number but not a per-team or per-workflow number. Per-run pricing produces both. This matters when the AI line item crosses EUR 50,000 per year and procurement starts asking questions.

The CFO view

The argument for per-run pricing is not just cheaper. It is more legible.

Every run on a per-run platform is logged with the user, the workflow, the agent template, the model used, and the cost. Roll those up and the CFO sees:

• Total spend per team per month.
• Cost per outcome (e.g. cost per invoice processed, cost per support ticket triaged, cost per qualified lead).
• Cost per workflow, ranked.
• Cost per model, which feeds multi-model routing decisions.

None of that is available on per-seat pricing. The bill arrives. The seats are paid. Where the value went is anyone's guess.

Expert tip: The team that most often wins the per-run argument is finance. Show the CFO a per-team, per-workflow, per-month spend report next to a flat per-seat invoice. The reaction is consistent across every conversation we have had. CFOs want to see what they bought.

When per-seat actually wins

Three scenarios where per-seat pricing is the right call.

Very high, very even usage. If every user on a 50-person team is running 50+ agent jobs per day, per-seat at EUR 35 per user is competitive with per-run at EUR 0.06. The crossover sits around 700 runs per user per month. Above that, the flat fee starts to win. The realistic question is how many teams hit that bar (very few) and how long it takes them to get there (usually 12 to 18 months).

Strict budget caps with no overage tolerance. Some procurement organizations cannot tolerate variable bills, period. Per-seat caps the monthly number. The team accepts the inefficiency in exchange for the predictability. This is rare and usually self-correcting once the AI program shows ROI.

Single-product, single-workflow deployments. A team using AI for exactly one task with predictable volume can budget per-seat. Most teams that start there expand within 6 months and the per-seat math stops working.

For everything else (and 80 percent of teams fall into "everything else") per-run wins on cost, on visibility, and on procurement-friendliness once the CFO sees the report.

How to choose for your team

Four concrete steps to make the right call.

Step 1: Estimate your usage shape honestly. Map your team into power users, regular users, and light users. Assign realistic run counts per week. If you do not know yet, assume Shape A for the first 6 months and Shape B for months 7 to 18. The math at Shape A is the math you will live with through pilot and rollout.

Step 2: Get every per-seat vendor to disclose the overage rate. Many vendors hide it in the contract. Ask for it in writing. Then take your usage estimate and add overage for the heavy users. The fully loaded per-seat cost is rarely what the sticker price suggests.

Step 3: Get every per-run vendor to disclose model markup. Some per-run platforms pass model costs through with a 20 to 30 percent markup. Others mark up by 2x or more. The transparent platforms publish the rates next to the model selector. The opaque ones bury it. Ask. AgentWorks publishes all model rates on the pricing page (see /pricing).

Step 4: Run the calculation for 6 months out, not 1 month out. A pilot looks cheap on per-seat for 30 days because nobody is using it yet. Six months in, when adoption has tilted (10 power users, 40 light) the math flips. Run the model on month 6 and month 12, not on month 1.

AgentWorks runs entirely on per-run pricing with full visibility into every model call, every workflow, and every user (see /ai-workforce-platform). The platform supports multi-model routing so cheap tasks run on cheap models (see /multi-agents) and audit trails meet EU AI Act and GDPR requirements without extra configuration. Most 50-person teams land between EUR 800 and EUR 2,200 per month on the platform, with full per-team and per-workflow breakdown.

What scales worse than you think

One pattern shows up on almost every team that switches from per-seat to per-run mid-year: agent-driven runs grow faster than human-driven runs.

A workflow that triggers automatically (overnight invoice processing, every-new-ticket triage, every-new-lead enrichment) generates runs without a human present. On per-seat pricing those runs eat into the cap. On per-run pricing they are accounted for as the workflow's cost, not the user's. This is the right way to think about cost on automated workflows: per outcome, not per person.

A team running 8,000 invoice processing runs per month on per-seat pricing assigns those runs to one finance user who blows through their cap by week one. The overage on that single seat exceeds the rest of the license. On per-run pricing the 8,000 runs cost EUR 320 and roll up to the finance team's line item, where they belong.

This is the strongest single argument for per-run pricing as automation grows: the cost should attach to the workflow, not to a user who happens to have triggered it.

The choice is not philosophical. It is operational. Per-seat works when usage is high, even, and human-driven. Per-run works when usage is uneven, variable, and increasingly automated. For most 50-person teams in 2026 the second description matches reality and the first does not.

Not sure where AI agents fit? Request a tailored compliance-ready roadmap at agent-works.ai/contact.