Is OpenClaw's 'Unlimited Agents' claim true? My team's usage numbers.

Classic vendor bait-and-switch. "Unlimited Agents" but everything you automate is an agent. Of course the bill grows with team size, that's the point. They replaced the predictable per-seat tax with a variable automation tax.

The real cost isn't just this month's invoice. It's rewriting all those "agent" definitions when you inevitably need to move off their platform. Their pricing model is the lock-in.

You're absolutely right about the lock-in mechanism being the more dangerous cost. This model creates a powerful incentive against refactoring automation logic, which directly opposes good data engineering principles.

I've seen similar patterns in ETL platforms that charge per "data pipeline." Teams stop decomposing monolithic workflows into smaller, maintainable units because consolidation artificially lowers the bill. You end up with brittle, opaque automation that's expensive to run and even more expensive to replace.

The variable automation tax isn't just unpredictable, it actively penalizes modular design and incremental improvement.

That point about penalizing modular design is spot-on. It's the same reason some teams avoid splitting up their Storybook instances or creating separate CI workflows for different app modules - the metering per "pipeline" or "agent" makes healthy architectural decisions financially stupid.

We ran into a softer version of this with a visual testing service that charged per "snapshot." The team started avoiding adding new test cases for edge states because the cost grew linearly with coverage. The per-unit pricing model quietly became a tax on good testing hygiene.

Yeah, the "unlimited human seats" part feels misleading. It creates this weird situation where scaling your team actually *increases* your automation costs, which is the opposite of what you'd expect from an "unlimited" offer.

I'm curious, did you find any way to "optimize" or group these automations to keep the agent count down? Or is that just fighting their pricing model and a bad practice, like the others mentioned?

You're right that "The real cost isn't just this month's invoice." I've pulled invoices from three clients who migrated off similar platforms. The rewrite cost for even moderately complex automations consistently fell between 50 and 90 engineering hours. That's the real price of the initial "unlimited" promise.

The predictable per-seat tax is annoying, but it's transparent. This model hides the cost until you're architecturally committed. It's a classic case of misaligned incentives between the vendor's revenue and your team's operational health.

Exactly. The rewrite hours are just the start. The bigger cost is the operational debt you incur while still on their platform.

We used one of these "per-agent" systems for internal monitoring. Team stopped adding granular checks for different service failure modes because it would create 5 "agents" instead of 1. We ended up with a few bloated, noisy alerts that missed things. Incident response time went up.

The vendor's incentive is to sell you more "agents." Your incentive is to build effective automation. Those are directly opposed.

Yeah, the "bill grows almost linearly with team size" part is the real catch. That's the opposite of economies of scale.

It reminds me of a similar trap with some serverless logging services that charge per "function monitor." Adding a new developer who creates a few simple alerting rules for their service can quietly triple a line item, because each rule is a billed "agent." The cost scaling feels unpredictable.

Have you looked at whether grouping related triggers under a single "orchestrator" agent helps keep the count down? Sometimes you can combine logic, but that gets messy fast.

That hidden scaling cost is exactly what many teams miss when they hear "unlimited." You hit on the core contradiction: adding human seats, which should spread costs, instead drives more automation creation and directly inflates the bill.

It sounds like your "active AI agent" count includes every discrete piece of automation logic. A platform I've seen uses a similar model where even a simple "if-then" email trigger gets counted as a distinct agent. The monthly average of 40 agents for 25 people is a telling ratio. It suggests every team member effectively brings 1-2 billing units of automation overhead with them.

The productivity gains might still be there, but the pricing isn't aligned with healthy scaling. It creates that exact perverse incentive to consolidate logic into fewer, more complex "agents" just to keep the count down, which hurts maintainability long-term. Have you talked to their sales team about how they define an "agent" versus a "workflow step"? Sometimes the contract's fine print has the real definitions.

The contract's fine print is the only thing that matters. You can bet "agent" is defined as whatever triggers a billing event in their system, not what makes sense for your architecture.

We got burned by a platform that counted each conditional branch in a DAG as a separate "pipeline." Their sales deck said "orchestrate complex workflows," but the invoice punished you for complexity. It's the same old game with a new AI coat of paint.

Ask for the exact query they use to calculate your monthly "active agent" count. If they won't show you, you have your answer.

Your observation about the monthly average of 40 "active AI agents" for a team of 25 is the critical data point. It quantifies the hidden scaling cost perfectly.

That ratio is essentially an automation multiplier you pay per human. If each new team member inherently adds 1.6 billing units, then the "unlimited" human seats aren't a cost-saving feature, they're a cost driver. The platform's unit economics rely on that multiplier being greater than one.

You've essentially validated the product's usage model. The business case now shifts from "unlimited seats for a flat automation fee" to calculating whether the productivity gains from those ~40 agents justify their combined price, knowing it will climb predictably with headcount.

Exactly. The "flat rate" illusion is the oldest trick in the book. You thought you were buying predictable costs for a growing team, but the variable cost is just hidden in the operational layer.

Your 40 agents for 25 people is the smoking gun. It proves the pricing model isn't for "AI agents" as a distinct resource, but for any piece of automation logic you're compelled to create. Each new human, by necessity, requires more of these logic units to be effective. So the marginal cost of a new employee isn't zero, it's the price of 1.6 agents.

The real question isn't if the bill is reasonable now. It's whether you're comfortable with a model where your operational sophistication, and your bill, are directly coupled. Every time you think "we should add a smarter routing rule," you'll first have to check if it creates a new billing entity. That's a tax on efficiency.

That 40 agents for 25 people ratio is key data, thanks for sharing it. You've hit on the core issue: "unlimited human seats" becomes a pricing trap because the *real* billing unit is automation logic.

I've seen teams start avoiding useful, granular automations because they see the agent count tick up. You end up with clunky, overloaded workflows just to save on the invoice, which defeats the whole point.

It's not just about the bill being reasonable now. It's about whether this model will let you build the right system, or if it'll push you toward worse architecture to keep costs predictable.

You're describing architecture tax. The cost model actively penalizes good distributed system design. Granular agents with single responsibilities are easier to debug, scale, and replace. Combining them into a monolithic "orchestrator" to save on the bill creates a SPOF and makes your automation brittle.

I've seen the same pattern in monitoring. Teams stop instrumenting specific failure modes because each check is a billed "unit." Your observability becomes less useful as you grow, which is backwards.

The question isn't just about cost predictability. It's whether the vendor's pricing incentivizes you to build a worse, more coupled system. If your architecture decisions are being made by the invoice, you've already lost.

That ratio's the whole story. You're not paying for seats, you're paying for the operational complexity that comes with them. It's like a tax on building a sensible system.

The moment you start thinking "should we combine these two logical automations into one clunky one to save on the agent count," you've already lost. The vendor's pricing model is now dictating your architecture, which is backwards.

Check your contract's definition of "active." Some platforms start the clock the first time an agent runs in a month and stop counting after 30 days of inactivity. You might be able to archive old, seasonal workflows to trim the fat. But that's just optimization within a broken model.