Summary
The structural difference between per-seat and per-usage pricing
Per-seat pricing charges a fixed amount per user account, regardless of how much those users do with the tool. Per-usage pricing charges based on what the tool actually does: tokens processed, API calls made, workflow instances run, or some combination of these. The two models answer different questions.
Per-seat pricing answers: how many people need access? Per-usage pricing answers: how much AI work are you doing?
For most AI workflow automation tools, these are not the same question. A team of five people can run thousands of automated workflow instances per month. A team of fifty people might run very few. The number of seats tells you almost nothing about the volume of AI work the platform needs to perform.
Why this distinction matters at scale
When a platform charges per usage for AI work, your bill grows every time your automation succeeds. A workflow that runs ten times a day costs ten times more than one that runs once a day, at the same per-execution rate. If you build a successful automation that saves your team hours every week, the platform's revenue from your account increases in direct proportion to that success. The platform is monetizing your productivity gains.
Per-seat pricing breaks this coupling. Your platform bill is determined by how many people need accounts, not by how much automated work those people trigger. A workflow that runs ten thousand times a month costs the same platform fee as one that runs ten times, because the platform fee is not a function of execution volume.
The hybrid model: where it gets complicated
Many AI platforms use a hybrid: a base subscription (sometimes per-seat, sometimes flat) plus a usage charge for AI calls. The usage charge is often presented as a convenience, but it is worth examining what is being charged and why. If the usage charge covers genuine infrastructure costs (compute, storage, egress), it is a cost-sharing mechanism. If it is a markup on model provider costs that the customer could pay directly at a lower rate, it is a margin extraction mechanism. The two look identical on an invoice and behave very differently as your usage scales.
When per-seat pricing works in your favor
Per-seat pricing is most favorable when the following conditions hold.
Your automation volume is high relative to your team size
If a small team runs a large number of automated workflow instances, per-seat pricing means the platform cost stays flat while the value delivered scales up. A team of five running ten thousand workflow instances per month pays the same platform fee as a team of five running one hundred. The cost-per-instance of the platform component falls as volume rises.
Your AI usage is unpredictable or variable
Per-usage pricing requires you to forecast consumption accurately to budget reliably. If your workflow volume spikes (a product launch, a seasonal campaign, a sudden increase in customer submissions), a per-usage platform bill spikes with it. Per-seat pricing is flat regardless of volume spikes. For teams with variable or hard-to-forecast AI workloads, the predictability of per-seat pricing has real budget value.
You want to experiment without a cost penalty
On a per-usage platform, running a workflow a hundred times to test and refine it costs a hundred times the per-execution fee. On a per-seat platform, testing is free at the platform layer. The only cost of running more instances during development is the model cost, which you pay directly to the provider at their published rate. Per-seat pricing removes the disincentive to iterate.
Your team size is stable but your automation ambitions are growing
If you know roughly how many people need accounts but you are actively building new workflows and expanding your automation coverage, per-seat pricing lets you grow your automation footprint without growing your platform bill. The seat count stays the same; the number of workflows and instances does not.
When per-usage pricing works in your favor
Per-usage pricing is most favorable in a narrower set of conditions.
Your usage is genuinely low and unpredictable in the other direction
If you run very few workflow instances per month and cannot justify a flat subscription, per-usage pricing means you only pay for what you actually consume. For teams in early exploration, running a handful of instances per week, the per-usage model can be cheaper than a flat subscription. The crossover point depends on the specific pricing, but it typically favors per-usage only at low volumes.
You need to attribute costs precisely to specific workflows or projects
Per-usage billing gives you a line-item cost for each unit of work. If your organization needs to charge AI costs back to specific departments, clients, or projects, per-usage billing provides the granularity. Per-seat billing does not tell you which workflow consumed how much: it tells you the total platform cost for the period.
The important caveat: what the usage charge covers
The value of per-usage pricing depends entirely on what is being charged. If the usage charge is a markup on model provider costs, you are paying more per token than you would by connecting directly to the provider with your own API key. In that case, per-usage pricing is not a cost-sharing mechanism: it is a margin layer that grows with your consumption. Before accepting a per-usage model, establish whether the usage charge reflects genuine platform infrastructure costs or a markup on third-party model costs you could access directly.
The case for separating platform cost from model cost entirely
The cleanest pricing architecture for AI workflow automation separates the two cost components that are actually distinct: the platform (the orchestration layer, the workflow editor, the human review system, the access controls, the audit log) and the models (the AI inference, the tokens, the provider calls).
Platform cost is a function of how many people use the platform. It should be priced per seat. Model cost is a function of how many tokens your agents consume. It should be priced by the model providers, at their published rates, billed directly to you.
When these two costs are merged into a single bill, the platform vendor captures a margin on the model cost component. When they are separated, the platform vendor's revenue is determined by your seat count, and your model cost is determined by your usage, paid directly to the provider with no intermediary margin.
This separation has three practical consequences:
- Transparency: You can see exactly what the platform costs and exactly what the models cost. You can optimize each independently. If a model becomes cheaper, your model bill falls immediately. If a better model becomes available at a higher price, you can evaluate the trade-off clearly.
- Predictability: The platform cost is fixed for your seat tier. The model cost is variable, but it is your variable cost, visible in your provider's billing dashboard, not buried in a platform invoice.
- Alignment: The platform vendor's revenue is not tied to your AI usage volume. They are not incentivized to make your workflows consume more tokens. Their incentive is to make the platform valuable enough that you add more seats.
DAVE is priced on this separated model. The platform subscription is per seat: Starter at $20 per month for one seat, Team at $50 per month for five seats, Business at $250 per month for twenty-five seats, and a flat $10 per seat per month beyond twenty-five. The 30-day free trial covers up to five seats with no credit card required. Model costs are paid directly to your chosen providers at their published rates. DAVE does not proxy or mark up AI usage.
Seats and roles in practice: who counts as a seat
On a per-seat platform, the definition of a seat matters. If every person who touches the system in any capacity counts as a seat, the seat count inflates quickly. If seats are defined narrowly, some users may be excluded from the platform entirely.
In DAVE, a seat is a user account in your workspace. DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator. A user can hold multiple roles simultaneously and counts as one seat regardless of how many roles they hold.
The roles are designed to match the actual division of labor in an AI workflow team:
- Admin: Full control over the tenant. Manages users, settings, providers, and feature flags. Accesses the Billing section at Admin, then Billing in the sidebar.
- Create: Builds and manages AI agents. Defines system prompts, model selections, and behavior parameters.
- Curate: Designs workflows using the visual editor. Arranges nodes, configures edges, and saves versions.
- Use: Runs instances and completes tasks. Opens the Task Inbox, provides input, makes review decisions, and monitors instance progress.
- Reporting: Views reports and audit logs. Read-only access to analytics dashboards covering run volume, failure rates, and latency.
- Financial: Access appropriate to financial oversight of the workspace.
The practical implication for seat counting: a person who only completes tasks in the Task Inbox (Use role) counts as one seat. A person who builds workflows and also completes tasks (Curate and Use roles) counts as one seat. A person who administers the platform, builds agents, and reviews outputs (Admin, Create, and Use roles) counts as one seat. You are not penalized for assigning multiple roles to a single user.
When estimating your seat count for a plan decision, count the distinct people who need a DAVE account, not the number of roles or the number of actions they will perform. Match that count to the appropriate tier, and factor in your expected growth over the next twelve months before committing to a plan.