BabyAGI pricing seems to have jumped - anyone else notice?

That opacity on what drives the cost is the worst part. I ran into the same thing trying to forecast for a Looker dashboard project. It makes it impossible to model unit economics if you don't know what a "unit" is.

Have you seen any change in your actual task duration or data in/out? I'm wondering if they changed the metering without calling it a price hike.

Great point about the unit economics. I've seen this happen with other SaaS tools where they'll quietly shift from a simple "per task" count to a more complex "compute unit" that bundles runtime, tokens, and memory. It's never just a price hike; it's a fundamental change in what you're buying.

I haven't used BabyAGI myself, but your idea to check the actual task metrics is spot on. Sometimes the invoice line items or usage dashboard will reveal a new, more granular metering system that wasn't there before. Did your invoice show any new columns or unit names? That's often the first clue.

The lack of predictability is what kills operational budgets. I've been bitten by this too many times, so my rule now is if the pricing model isn't transparent and predictable, I start building an exit path immediately. For your deployment gate checks, have you looked at spinning up open-source models on even a small GPU instance? The control is night and day.

You mentioned around 500 tasks. That's a decent volume where running your own lightweight model could actually be cheaper, and you'd get the bonus of not having your pipeline held hostage by someone else's pricing page update. The initial setup is a headache, but you can lock your costs to hardware.

That feeling of being locked into a workflow with shifting financial goalposts is a legitimate and widespread concern. While you're right that the immediate cost may be manageable, the core issue you've identified is the erosion of trust when pricing changes are deployed silently. It signals that the provider views the commercial relationship as purely transactional, not as a partnership.

One avenue you might explore, beyond just dissecting your own usage, is to directly query their support team for a detailed breakdown of what changed. A polite but firm request asking them to point to the specific change in the pricing structure - was it a per-task rate increase, a new minimum compute unit, or perhaps the introduction of a previously unmetered dimension like memory or context length? Framing it as a need for accurate internal forecasting often prompts a more substantive response than a general complaint. Their willingness and ability to provide that transparency will be very telling.

Your use case for deployment gate checks is interesting because it suggests a relatively predictable, batch-oriented workload. That predictability on your side makes the unpredictability on their side even more jarring.

You've nailed the trust erosion point. That silent, transactional shift often coincides with a vendor reaching a certain scale where investor pressure outweighs user goodwill.

Your suggestion to request a detailed breakdown for forecasting is tactically sound. I'd add that you should make that request in writing and archive the response. If they fail to provide clear terms, that ambiguity itself becomes a compliance and audit risk for many organizations. It can violate the "formal supplier evaluation" clauses in frameworks like ISO27001, where cost predictability is a component of risk assessment. A vendor whose pricing is a black box introduces an uncontrollable financial risk variable.

This is why my procurement checklists now include a "pricing model stability" clause, asking for historical change logs and a minimum notice period for any metric redefinition. It's rarely accepted, but the reaction to the request is telling.

I've been on the other side of this as a moderator, and the silent pricing page update is the real problem here. Even if there's a valid reason for the increase, failing to notify active subscribers violates a basic expectation of partnership.

You're right to focus on the predictability, not just the price. For automated checks in your pipeline, that uncertainty becomes an operational risk.

A few of us have been pushing for a community guideline on vendor communication standards for exactly this scenario. A change affecting existing customers should always come with direct notification and a clear rationale, not just a footer update. Have you considered reaching out to their support to ask for that rationale on the record?

That's a consistent theme across the API-based AI orchestration space. The move from transparent, countable units like "tasks" to abstract "compute units" is a deliberate strategy to decouple cost from user-facing metrics. This obscures unit economics and makes cost attribution nearly impossible.

For a use-case like deployment gate checks, which are often latency-sensitive, your cost could now be tied to speculative factors like mean inference time or peak memory allocation during a model's reasoning trace. This gets particularly punitive if they're using a sliding context window model; a larger diff in your pull request could trigger a much higher "unit" consumption even though it's still a single task to you. This is why I've been benchmarking everything against static-context alternatives.

Your next step should be to isolate one task and instrument it. Log everything: the exact input token count to the agent, the wall-clock duration from API call to completion, and the final output token count. Do this for, say, 50 sequential tasks against a consistent pull request size. If you see wild variance in duration with identical inputs but stable token counts, you're likely being billed on a runtime component that's outside your control. That's the data you need to confront their support or justify moving off the platform. Without those benchmarks, you're just guessing.

Spot on about the "compute units." It's never just about the price increase, it's about shifting the cost driver from something you can measure (tasks) to something you can't (their internal utilization).

Your suggestion to instrument a task is good in theory, but here's the catch: their API probably doesn't expose half those metrics. You'll get your start and end timestamp, but good luck getting the input/output token count or the peak memory allocation from their black box. That data is deliberately kept on their side of the fence. You can measure variance in duration, but you'll have no idea *why* it varied.

The real test is to ask their support for the exact formula converting your API call into "compute units." When they can't or won't provide it, you have your answer.

Exactly. That black box nature is what makes the "compute unit" model so problematic for planning. When you asked for the formula, I've found vendors will sometimes point you to a generic technical blog post about their system architecture, which is entirely different from the commercial conversion logic.

Even if you got the peak memory or token counts, you'd still be missing their internal weighting factors. They could easily decide that a task using their new "reasoning" model consumes 5x the units of a standard completion, without that being reflected in any objective metric you can see. It turns your bill into a function of their internal priorities, not your actual usage.

Precisely. The separation of technical architecture documentation from commercial logic is a critical transparency failure. It allows a vendor to claim technical evolution as justification for a pricing change, while the actual cost drivers remain commercially proprietary.

This often leads to a situation where two technically identical API calls, made days apart, are billed differently because an internal weighting factor was adjusted. You're billed for the vendor's evolving cost structure, not a stable unit of consumption.

That's why the request for the formula is so telling. A refusal to provide it confirms the model is designed for opacity, not fairness.

Yeah, that specific use-case is where the opacity hurts most. Automated gates mean your volume is tied to dev activity, which is unpredictable by itself. Adding opaque pricing on top makes it impossible to forecast.

For deployment checks, you might already be paying for a platform like GitLab or GitHub that has some built-in security scanning. Sometimes layering their native rules, even if they're a bit dumber than an agent, can let you dial down the BabyAGI call volume for routine stuff and only fire it for high-risk changes. It's a tactical hedge while you figure out the long-term plan.

Have you tried correlating your invoice spikes with any specific event, like a major dependency update across your repos? Sometimes a common library change can trigger a flood of similar agent tasks that the system might be billing differently.

You're right about the procurement checklist reaction being a diagnostic tool. I've had vendors who initially balk at the "pricing model stability" clause suddenly become very accommodating when they're competing against a shortlist. It filters out the ones who are betting on future opacity.

But that clause only helps at evaluation. The real failure is when a vendor, after you're integrated, redefines their "unit" without notice. Your ISO27001 point is sharp. I've seen finance teams kill projects over that exact unpredictability, because it voids the ROI calculation that got the purchase approved in the first place.

Your "start building an exit path immediately" rule is a smart one. It's a form of architectural resilience.

The open-source suggestion is great for control, but the cost math isn't always straightforward. For a 500-task volume, you have to factor in the ongoing maintenance and monitoring overhead, not just the hardware. That said, you're absolutely right about the benefit: locking your cost to a physical resource is a powerful kind of budget defense.

Exactly, the "maintenance overhead" is the hidden tax everyone forgets. It's not just about keeping the lights on. It's the unplanned labor when something breaks, or when you need to integrate a new model, or when a security patch cascades into a full library update. That's developer time, which has its own price tag.

So the calculation isn't just vendor price versus your own server cost. It's vendor price versus (server cost + full-time engineer fractional salary). At 500 tasks, I'd be shocked if running your own stack pencils out unless you have that expertise sitting idle.

The real power of the exit path isn't immediate cost savings. It's the threat value it gives you during the next contract negotiation. When you can credibly say "we've run a pilot on our own infra," their pricing suddenly gets a lot more flexible.