I think I'm more on your side on that rather than letting agents go wild like Steve Yegge/Pete Steinberger do. In fact OrcaBot quickly adapted into a knee jerk reaction to OpenClaw because I saw that as inherently dangerous.
But with regard to Juggler and orchestration, have you seen "claude agents" (started in the terminal as claude agents instead of just claude). I ask because your tree like approach has similarities to how claude agents manages claude agents/subagents doing tasks with the ability to drill down in to each at a time which is why for me its not such a leap from what you already have.
This looks really interesting and a unique take on the AI agent orchestration. I think we need a bunch of experiments in this area as it's clear we are entering a new paradigm and the tools for it are lacking. The session tree in particular has merits.
I've got my own attempt with OrcaBot (short for orchestration of bots). It's also been a 6 month solo build experiment. I'm not trying to plug.. just that I'm also neck deep in Steve Yegge's Stage 8 AI-assisted coding chart and understand how much thought and effort went into this.
Thinking about where this is all going with talking to AI like fully autonomous employees similar to @Claude can you see a comms app type approach that combines something like slack with your tree/thread structure? It's somewhat orthogonal to your "inspect everything" but could intersect by bringing click through/open in options...
This month I've been working on the free desktop version which is available as of today but probably carries a few too many bugs to not be worth promoting just yet.
AAPL and MSFT have a P/E an order of magnitude lower than TSLA whilst both having revenue growth % yoy in the teens. They both make over a $100b in PROFIT a year. TSLA's? $4b and shrinking btw. Their highest P/E's since 2005 was under 50. AAPL reached 100 in June 2003 (around the time of the iTunes Store release.. mid iPod era but pre iPhone).
Comparing with MSFT and AAPL makes TSLA look even more insane.
I've been working on addressing the exfiltration leg as well as the other legs of the lethal trifecta in my OrcaBot [0][1] platform and I thought I had it mostly covered with the help of a network snitch and egress allowlist until I read these comments.
Domain fronting and Steganography in commits to public repos are not solved and probably in all honesty not completely solvable. I wonder if this well end up like in banking where no bank can completely eliminate fraud. I've got some ideas to do bank like fraud detection within OrcaBot now so might be able to limit the impact a little. Thank you!
I believe it's the way the HN algorithm works. In order to give new and obscure posts a shot, it will add them to peoples feeds in their front page and see how they measure. Otherwise new posts wouldn't get seen and the flywheel would never get started.
So everyone acts as a sort of beta tester for obscure posts.
A figma like dashboard for turning ClaudeCode, Gemini Cli, Codex into an OpenClaw but with security measures to break the lethal trifecta while running on a VM.
But it's not quite there in terms of usability. I agree that is the hardest part of the equation. It's something I'm constantly experimenting with and haven't found the solution to it yet. Open to feedback!
I don't think that is entirely fair.. I don't see them stating anywhere they are measuring coding capabilities... "Using complex games to probe real intelligence."
And this seems very much in line with the methodology in ARC-AGI-3.
The results here, in the OP article and in https://www.designarena.ai all tell a similar story: Kimi K2.6 is up and in the SOTA mix.
You could have the actual output of the agent turned into TTS using the model of your choice with TalkiTo… or listen to whatever weird sounds this makes. Seems like this is copying that viral Mac moan app. 2026 is weird.
"Let's be honest here: there is no benefit to alcohol (for example wine) and is only detrimental." - That is a pretty extreme statement and easily falsifiable.
There are many studies a quick google away that show a much more nuanced take ie [0] and [1]. But the strongest evidence is our most successful societies and civilizations have been intentionally drinking alcohol for ~10000 years [2]. If it was only detrimental then I'm pretty sure it would have worked its way out by now. I acknowledge there are negative issues.
OrcaBot does this with the VM but whereas the author mentions the risk of GitHub keys being leaked, OrcaBot uses a key broker to ensure the LLM doesn’t have access to any keys. It even works on the API keys to the LLMs themselves.
https://orcabot.com/blog#breaking-the-lethal-trifecta
Really cool. A tangential task that seems to be coming up more and more is masking sensitive data in these calls for security and privacy. Is that something you considered as a feature?
This is amazing. I agree with your take except "You’re not actually zeroizing the secrets"... I think it is actually calling zeroize() explicitly after use.
Can I get your review/roast on my approach with OrcaBot.com? DM me if I can incentivize you.. Code is available:
enveil = encrypt-at-rest, decrypt-into-env-vars and hope the process doesn't look.
Orcabot = secrets never enter the LLM's process at all. The broker is a separate process that acts as a credential-injecting reverse proxy. The LLM's SDK thinks it's talking to localhost (the broker adds the real auth header and forwards to the real API). The secret crosses a process boundary that the LLM cannot reach.
Indeed. The biggest waste might be the overuse of MCP for everything. Sure it makes the initial development easier but then for every connection you're using a hundred billion dollar parameter model to decide how to make the call when it's usually completely unnecessary and then prone to random errors. MCP is the hammer that can make literally everything look like a nail...
As someone who has been waiting for the same thing as op tyre posted, I went to investigate this claim and it seems that it might be true but only when running apps within the Google AI Studio itself.. ie if you were to make an app that was on something like the App Store using Google AI Studio, it would be back to an API key that the developer bears the costs for.
The problem with the current model is that there is a high barrier to justifying the user pays essentially a 2nd/3rd subscription for ultimately the same AI intelligence layer. And so you cannot currently make an economically successful small use case app based on AI without somehow restricting users use of AI. I don't think AI companies are incentivized to fix this.
Hi Devin and other folks, I'm looking for software developers who are blind or hard of sight as there is a tool I'm building that I think might be of interest to them (it's free and open source). If you or anyone you know is interested in trying it please get in touch through my email.
Yeah that sounds reasonable. I've been thinking about how to make it more modular. I'll make it so that base TalkiTo doesn't need any heavy libraries.
EDIT: also to be clear whisper doesn't run or even download the model unless it's selected and the user confirms the DL. This can be configured. Google cloud has a free ASR option and ASR can be switched off completely.
https://summer.ai https://talkito.com
contact: rob at ^ the first one
meet.hn/city/uk-London
Socials: - linkedin.com/in/romacrae
Interests: AI/ML, Entrepreneurship, Hacking, Gaming, Music, Programming, Research, Robotics, Sports, Technology, AR/VR
---