Show HN: OpenTiger – Autonomous dev orchestration that never stops(github.com)
github.com
Show HN: OpenTiger – Autonomous dev orchestration that never stops
https://github.com/Andyyyy64/openTiger
2 comments
Interesting approach with the parallel planner/worker/judge architecture. I've been solving a similar problem but with a single-agent loop pattern instead of multi-agent.
My toolkit wraps Claude Code CLI with NDJSON streaming and handles the exact failure modes you describe: budget exceeded -> exit code 2, stagnation detected (low turns over a window) -> exit code 3, consecutive timeouts -> auto fallback from Opus to Sonnet. The human steers between runs by editing CLAUDE.md.
One thing I added that might interest you: a multi-model council system that queries GPT-4, Claude, and Gemini simultaneously through Perplexity before big architectural decisions. Catches blind spots that a single model misses.
https://github.com/intellegix/intellegix-code-agent-toolkit
Curious how openTiger handles the cost tracking problem. With single-agent loops I parse cost from NDJSON events, but with parallel agents the spend can compound fast.
My toolkit wraps Claude Code CLI with NDJSON streaming and handles the exact failure modes you describe: budget exceeded -> exit code 2, stagnation detected (low turns over a window) -> exit code 3, consecutive timeouts -> auto fallback from Opus to Sonnet. The human steers between runs by editing CLAUDE.md.
One thing I added that might interest you: a multi-model council system that queries GPT-4, Claude, and Gemini simultaneously through Perplexity before big architectural decisions. Catches blind spots that a single model misses.
https://github.com/intellegix/intellegix-code-agent-toolkit
Curious how openTiger handles the cost tracking problem. With single-agent loops I parse cost from NDJSON events, but with parallel agents the spend can compound fast.
lets gooooooooooooooo
So I asked a different question: what if the system was designed around the assumption that agents WILL fail, and the job of the infrastructure is to never let that failure become a dead end?
openTiger is a "non-human-first" orchestration system that runs multiple AI agents in parallel — planner, workers, testers, judge — each with a dedicated role. The planner decomposes requirements into tasks, the dispatcher fans them out to worker agents concurrently, and the judge evaluates results and feeds back rework decisions. It's not one agent doing everything; it's a pipeline of specialized agents running simultaneously.
The entire architecture is built on one principle: no state is terminal. Every failure is a blocked state with a reason, and every reason has a recovery path. If the same failure repeats, the system escalates to a different strategy instead of retrying the same thing.
The interesting philosophical bit: optimizing for recovery turns out to be more effective than optimizing for first-attempt success. When you stop fearing failure, you can let agents be more aggressive.
Early stage, lots to improve. Feedback and contributions welcome.
Docs: https://opentiger.dev/docs/