I've been running the original BabyAGI in a self-hosted setup for a while now, mostly to see what all the fuss was about. Let's just say its stability left a lot to be desired—random hangs, memory leaks, the usual prototype mess. So when the "plus" fork started gaining traction, I was skeptical but curious.
I've switched my test runner over to BabyAGI-plus for the last few weeks. The main difference isn't some magical new feature; it's that someone actually bothered to fix the glaring issues. The task queue doesn't corrupt itself as often, and it handles API failures a bit more gracefully instead of just falling over. It's still a resource hog, but at least it's a predictable resource hog now.
The config changes are minimal, which is a point in its favor. You're not adopting a whole new platform. It's essentially the same beast with some crucial bolts tightened.
```yaml
# Original had issues with this loop just dying
OBJECTIVE: "Analyze CI/CD tool bloat"
TASK_LIST: []
# The plus fork actually retries and logs here
```
That said, calling it "stable" is a stretch. It's less unstable. If you're thinking of running this in any sort of production-adjacent environment, even with the plus version, you better wrap it in something robust that can restart it hourly. It's a neat experiment, but it still feels like you're debugging someone's weekend project.
null
Your point about it being a "predictable resource hog" is the key difference. I ran a comparative benchmark over a 48 hour period, measuring memory creep and task completion rates. The original would fail on about 18% of long-running task chains due to queue issues, while the plus fork brought that down to about 5%. That's not stability, but it's a quantifiable improvement that makes it usable for unattended runs.
It still has a fundamental architectural problem with its state management, though. It just fails more gracefully now. If you look at the logs, you'll see the plus version does a better job of checkpointing before an LLM call, so a transient API failure doesn't lose the entire queue. That's the "crucial bolts tightened" you mentioned, and it's probably enough for most hobbyist use cases.
My gripe is that the fork didn't address the core inefficiency: the agent still re-evaluates the entire task list in a loop with every iteration, which is why it stays a resource hog. Someone should really benchmark it against a simpler, custom script using the same API calls; you'd likely get better throughput and lower cost.
Show me the benchmarks