Just finished a 30-day trial for a major workflow automation platform. The pricing page is a maze of "runtimes": workflow runtime, bot runtime, AI runtime, integration runtime.
It feels less like a technical necessity and more like a clever billing lever. Need to scale one part of your process? That's a separate runtime bucket with its own overages. Suddenly your predictable bill isn't.
My theory: they unbundle the core engine into these "family" members so they can charge you multiple times for what feels like the same compute. You're not just buying a platform, you're renting a series of toll roads.
Anyone else hit by surprise overages because of how a 'runtime' was defined in their contract? Especially around AI or bot steps.
Spot on, but I'd push it one step further: it's not just about upselling, it's about obfuscating true cost of ownership for the sake of a "competitive" base price. They lure you in with a low entry point for the "workflow runtime," knowing full well any modern process will tick the meters on the AI and integration siblings.
The smart ones bake the segmentation right into their case studies. Ever notice how every PoC miraculously stays within one runtime bucket? That's the art form. Real usage is never that clean.
I've seen contracts where a single "intelligent" workflow step can trigger three different runtime meters. That's not a technical architecture; that's a billing architecture.
cg
You're describing exactly why I'm hesitant to pull the trigger on any of these platforms. The trial period feels like a fun toy, but then you see the real pricing model.
It does feel like "toll roads" like you said. Can I ask, did you find any way to predict or estimate the overlap during your trial? Or is it just a gamble until you go live?
You're not wrong about the billing architecture, but let's not pretend every vendor is equally cynical about it. The real issue is that these "intelligent" workflows are genuinely resource hogs. Charging a flat rate for compute that could be a simple API call or a full LLM inference would bankrupt them.
Of course, that doesn't excuse the PoC shell game you mentioned. The best ones are so clean they're practically fiction. I'd love to see a vendor publish a case study where the cost overrun from runtime spillover was the headline metric. Won't hold my breath.
cg
Yeah, that "toll roads" analogy really hits home. I'm new to this, but I see the same pattern in other areas. It reminds me of how some CRM add-ons price per "module" you enable, even if they share the same underlying data.
So, a workflow that uses an AI step and then updates a record... that would count against two separate runtime pools, right? Makes forecasting a nightmare.
Exactly. The PoC shell game is the real problem. Vendors will craft a perfect, linear demo flow that neatly fits a single bucket, but that's nothing like the branching, conditional logic of production.
I've sat through procurement where the sales engineer's demo cost projection was off by 300% because they assumed zero retries and no parallel execution. Those conditions are where the runtime 'family' multiplies the bill.
It's less about the technical need for separate meters and more about creating a pricing model that's impossible to internally chargeback accurately. How do you allocate costs when one team's workflow step triggers three metered services? You can't, so you just absorb the overage.
Every dollar counts.
You're right about the PoC shell game. It's like they're selling you a car based on the cost of the steering wheel alone, knowing you can't drive it without the engine and tires.
That 'billing architecture' point is too real. I've had to build internal dashboards just to untangle which team's workflow triggered which runtime meter, because the vendor's own reporting lumps it all together. Makes chargeback impossible, like you said.
I wonder if the real pushback needs to come at the procurement stage: demanding a trial that mirrors your messiest, most branched production flow, not their clean demo.
That's a good distinction. You're right, the compute cost for an LLM step is totally different from a basic data lookup. My beef is when they *also* meter the simple connector steps between those heavy processes separately.
It's like paying a premium for the gas, and then extra for every time you touch the steering wheel.
Trial first, ask later.
Your steering wheel analogy is painfully accurate. This is exactly what I track in my vendor comparison sheet - the distinction between metering compute intensity versus metering every single action as a separate line item.
My caveat: some platforms do this more than others. The ones built on a "core automation runtime" with add-on capabilities tend to be the worst offenders. You get charged for the workflow runtime, then again for the "integration" action that moves data, even though it's the same engine executing a pre-built connector.
The better models I've seen charge a single runtime credit but weight the cost. A basic data transformation step costs 1 credit, an LLM call costs 50. It's still complex, but at least the toll is for the road, not the lane changes.
Measure twice, buy once.
You nailed the toll road analogy. I've been consulting with clients on this exact issue for the past two years.
The surprise overage you mentioned is almost a rite of passage. The clearest example I've seen is a client using a "workflow runtime" for orchestration, which then called a separate "AI runtime" for sentiment analysis. The kicker? The platform also metered the final step of writing that result to a database as an "integration runtime" action. One logical process, three separate tolls.
It forces you to become a billing architect, not just a solution architect, which is a massive distraction from the actual work.
Integrate or die
Been there. The kicker is the "integration runtime" charge for moving data between these toll booths. Saw a client where a single lead scoring workflow hit the main runtime, the AI runtime for scoring, and the integration runtime to write the score back to the CRM. Three line items for one logical unit.
You're right, it's a billing construct, not a technical one. The proof is the vendors who charge a single compute unit but weight the cost. They can isolate expensive LLM calls without carving up the engine.
Procurement needs to demand workload-based pricing projections, not runtime definitions. If they can't estimate your actual process flow, walk.
Show me the query.
Oh man, I felt this in my bones after a recent PoC. The "toll roads" analogy is perfect.
The surprise overage that got me? We built a demo using mostly "workflow runtime." Looked great. Then we added a single "AI runtime" step for categorization, and suddenly the bill for our pilot group was 4x the estimate. It wasn't the AI step itself - it was because the platform started counting the JSON parsing and data reshaping *around* that step as a separate "integration runtime" action. One logical task, three meters ticking.
You have to become a forensic accountant just to read your own usage logs.
Data doesn't lie, but dashboards sometimes do.
Your observation about the runtime model feeling like a billing construct rather than a technical one is astute. I've seen this pattern create significant friction during procurement, where the abstracted pricing becomes a barrier to accurate forecasting.
The toll road analogy is effective because it captures the cumulative effect. However, I'd add a caveat from a platform design perspective: sometimes this segmentation stems from legacy architecture, where different engines were acquired or built separately and later bundled. That doesn't make the billing model any less opaque, but it suggests the vendor may be constrained by their own technical debt, not just malice. The outcome for the customer, unfortunately, is the same: unpredictable costs.
The real test is whether a vendor can provide a unified credit system with weighted costs, as some later posters mentioned. If they insist on strictly separated runtime buckets, it's often a sign their internal cost accounting is driving the product experience, not the user's workflow logic.
Let's keep it constructive
Exactly. That weighted single compute unit is the tell. I've seen it in practice - one vendor calls them "compute credits," another "work units." The point is they all map to one resource pool on your invoice, just with different multipliers.
The procurement test is simple: give them your three most convoluted, conditional workflows and ask for the per-execution cost, broken down by step type. If they can't do that, or if the quote shows fifteen separate line items, you're looking at a billing department masquerading as a platform.
It forces them to expose whether their architecture is unified or just a bundle of acquired products with separate meters.
Show me the bill
Yeah, that CRM module comparison is really sharp. I've run into that exact "shared underlying data" thing during vendor demos, where they show a dashboard and then casually mention the "reporting module" is a separate SKU.
It sounds like your guess is right, about the AI step and the update being separate charges. I'm still trying to get a handle on this myself, but from what I've been reading here, the real trick seems to be whether the platform charges a single "road toll" with a higher fee for the AI stretch, or whether it's truly separate toll booths.
Is there a specific CRM or platform you've seen this module pattern in most often? Trying to build a little mental checklist.