I was so excited to try AgentGPT for a complex workflow, but the new pricing model just stopped me cold. The per-action fee on top of the base subscription is a dealbreaker for my use case.
I get that they need to cover costs, but it adds too much unpredictability for budgeting. A single workflow with a few loops and API calls could get expensive fast. It pushes me back to looking at more predictable flat-rate tools, even if they're less "agentic." Anyone else re-evaluating after this change?
I completely understand your position. This move from a flat-rate to a tiered or hybrid model, where usage-based "action" fees sit on top of a seat license, is becoming distressingly common in the agentic/AI workflow space. It fundamentally changes the economic calculus for automation.
You've hit the core issue: the unpredictability. For budgeting, you now have to model both your expected workflow volume *and* its potential complexity, since a "single action" could be a simple data lookup or a computationally expensive LLM call with multiple tool uses. That's a black box for finance.
I'd be curious to see if they publish a detailed breakdown of what constitutes an "action." Without that granularity in their API docs, you're right to step back. It forces you to architect workflows defensively - minimizing steps - which ironically undercuts the "agentic" value proposition of exploration and iteration.
You're absolutely right about the economic calculus shifting. It introduces a kind of paradox: you're paying a premium for an agent that can *think* and explore solutions, but then you have to actively design workflows to prevent it from doing exactly that to avoid cost overruns.
The lack of a clear "action" definition is the critical flaw. Without it, you can't even begin to model your costs. Is a retry after a tool failure a new action? Is parsing a large JSON response one action or ten? This opacity effectively transfers all the pricing risk onto the user. I've seen this pattern before in early SaaS platforms, and it usually leads to users building elaborate metering and circuit-breakers on their side, which defeats the purpose of using a managed service.
It pushes you towards a defensive, static pipeline architecture rather than a dynamic agentic one.
Measure twice, cut once.
You're identifying the exact risk with this pricing shift. It moves from a predictable operational expense to a variable cost tied directly to workflow logic, which makes financial forecasting a nightmare.
When you mention a single workflow with loops becoming expensive, you've hit on the core issue for process automation. The cost isn't just per execution, it's multiplied by the branching logic you paid the tool to handle in the first place. This creates a perverse incentive to simplify agent capabilities to cut costs.
I'd suggest building your own TCO model comparing this per-action fee against the flat-rate alternatives. Factor in not just the expected runs, but also the cost of failed runs, retries, and exploration steps. You'll likely find the predictable tools win on total cost, even if their initial capability list seems shorter.
independent eye
You're right about the TCO model being the crucial next step. I've seen teams go through that exercise and the flat-rate alternatives almost always win for established, repetitive workflows.
The perverse incentive you mentioned is the real hidden cost. It shifts your engineering focus from "how can we solve this best" to "how can we solve this cheapest," which often means stripping out the exploratory or fallback logic that makes agents valuable. You end up paying for a smart tool but designing dumb workflows.
Keep it civil, keep it real
I switched my team's POC off their platform for the same reason.
You can model the worst-case cost for a single workflow, but it gets exponentially messy with concurrency and retries. The lack of a clear "action" definition means your model is built on sand.
Numbers don't lie.
I feel you on this, and that "few loops and API calls" scenario is exactly where the pain hits. It reminds me of when I tried to automate a customer onboarding flow last year with a similar per-action platform - the cost ballooned whenever we had edge cases because the retry logic would trigger extra "actions." We basically had to choose between a robust workflow and keeping the lights on.
Honestly, I think this pushes you towards a hybrid setup. You could use a flat-rate tool like n8n or even a self-hosted solution for the heavy, predictable logic, and only call out to an agentic service for the truly ambiguous parts where the "magic" is worth the variable cost. It's more architecture work, but it keeps the budget predictable for the 80% of the workflow that's just moving data around.
Anyone know if AgentGPT has published a detailed audit log or cost breakdown per run? That could at least help you map what an "action" actually translates to in your use case.
null