So, the great "plan consolidation." Because what we all needed was less granularity and more confusion, right? My team's been using Jasper for a while, mostly for the API-driven workflows, and the billing was predictable. Post-consolidation? It's like playing whack-a-mole with unexpected charges.
The dashboard now shows a lovely, consolidated "Platform Usage" charge that seems to bear only a passing resemblance to our actual consumption. Last month, we had a 22% spike with zero change in our deployed agent count or compute hours. Support's response was a masterpiece of obfuscation, pointing to the new "unified compute unit" which apparently rolls API calls, storage I/O, and background tasks into one magical, non-itemized metric.
```
Old billing line items:
- Agent Instances: 15
- API Requests (Millions): 4.2
- Total: $X
New billing line item:
- Platform Usage (Compute Units): 11,847
- Total: $X * 1.22
```
You can't audit that. You just have to trust it. And in this line of work, trust is not a strategy—it's a liability.
I'm hearing whispers from other teams about similar issues, especially those using hybrid patterns with edge functions. The consolidation seems to have smoothed over the pricing cliffs by just raising the entire floor. Anyone else getting these friendly little surprises, or are we just the lucky ones? How are you even attempting to reconcile the invoices now?
Our monitoring showed a 15% unexplained variance last month. We got the same "unified compute unit" explanation.
We had to pull raw logs for our API calls and background jobs, then manually back-calculate the supposed unit cost. Our numbers didn't match their invoice. We're escalating to our account rep with that data.
If you can't map the new metric to actual, observable resources, you can't manage your SLOs or your budget. It's a reliability issue.
Five nines? Prove it.
That "unexplained variance" is now a line item in your risk register. You can't prove compliance without an auditable mapping between consumption and cost.
When they can't provide the granular data, you shift the burden. In our last SOC2 audit, we had to write an entire control exception for a similar vendor. The finding was brutal, something like "Vendor Billing Opaqueness Creates Financial and Operational Risk." They hated it. It got fixed.
Escalate with your data, but also send that log mapping methodology to your procurement and infosec teams. Let them ask the compliance questions. Money talks, but audit failures scream.
Trust but verify – and audit
That "brutal" SOC2 finding is exactly the kind of friction that should happen, but too often gets watered down by vendor management before it lands. My experience has been that you can't just send the methodology to procurement and hope they understand the technical weight of it. They'll see it as a billing dispute, not a control failure.
You have to translate "auditable mapping" into their language: explain that the lack of granularity means we cannot perform a three-way match between our internal telemetry, the vendor's purported usage, and the invoice. That's a fundamental procurement control, broken. Once you frame it as a breach of basic financial governance, not just a cloudy tech issue, the screaming starts in the right departments.
Of course, then you're stuck hoping the vendor's engineering team cares about your auditor's report more than their product team cares about smoothing over pricing complexity. I've seen that hope dashed before.
Trust but verify.
You've hit on the core issue, I think. It's that shift from an auditable, predictable line item to a "magical" unit that feels like a black box. The trust comment is key - for teams managing budgets and SLAs, that's a non-starter.
I'd suggest pushing your account rep, not just support, for a clear mapping formula for the unified compute unit. Even if it's a complicated multiplier, you need something to reconcile against your logs. Without that, you're right, it's just a liability.
Keep it constructive.