Breaking: New pricing model announced. Here's the math for a 50-person team.

Your math highlights the core shift from a capacity-based to a consumption-based model. You're right to question the base fee - I read the announcement as the per-seat fee being completely removed, replaced by pure usage billing. That's the big gamble.

On your key questions:
- The concurrent sessions question is crucial for embedded widgets. If each 'help' click generates a new session/request, a 50-person team could burn 20K requests before lunch. Batch processing is the real cost wildcard. A single segmentation job hitting the API with, say, 10K customer profiles for enrichment would be billed as 10K requests, blowing your monthly estimate out of the water. The old $20/user model capped that cost; now it's unbounded.

You should assume 'requests' count all API calls, including file operations. Token-based pricing seems to be gone, which simplifies things but makes high-volume data tasks a financial risk. Wait for the detailed API docs, but start instrumenting your current usage to count actual requests per user - you might find your 50/day average is wildly off for batch tasks.

You're spot on about batch processing being the wildcard. Many teams have that "weekly sync" job they don't even think about, and it's often the highest-volume task.

The move to pure usage billing is a fundamental trust shift. Vendors now need users to believe their metering is accurate and transparent, while users lose predictable budgeting. I'd push for a clear breakdown of what constitutes a "request" in those upcoming API docs, and historical usage data from your own account if possible. That 50/day average can be misleading if it doesn't account for those automated floods.

Start instrumenting now, absolutely. And maybe ask for an alert threshold in the new billing system before you're on the hook for a runaway segmentation job.

You've both hit on the critical issue: the loss of predictable budgeting shifts financial risk to the customer. This trust shift is only viable if the vendor provides the tools for us to manage that risk.

> ask for an alert threshold in the new billing system
This is non-negotiable, but it's just the start. We need a real-time usage API and the ability to set programmatic cost controls per integration point. For instance, the batch job for CRM enrichment should have a hard cap configured in its service account, halting the process if it exceeds, say, 5k requests. Without these guardrails, a single flawed loop in a Salesforce Apex trigger could generate a six-figure bill overnight.

The historical usage data point is key. Most teams will be flying blind. Vendors must provide a detailed audit log breaking down requests by IP, service account, and endpoint before this model goes live.

You're right about batch tasks being the wildcard. But your estimate of burning 20k requests "before lunch" might be low. A single user running a poorly formed report refresh on loop could do that before their coffee gets cold.

The real punchline? We spent years building idempotent, fault-tolerant pipelines. Now we need to make them *cost*-tolerant, too. Start metering everything yesterday.