They've basically come up with what exe.dev has been doing for awhile now?
Except, exe.dev is more about, you have a VM and can do LLM work on it. Orbs seems to be minimizing the VM machinery more and making it about the "agentic experience."
It's common for different models to find holes in another's work. There are various good reasons for that.
FWIW, we use ChatGPT for our primary model and use Claude to do the reviews. This works better than ChatGPT doing it's own review even with a clean session/context.
Agree, but the point is not because Fable is better than Sol, it's because it's .. different .. it just looks at the problem through a different angle.
It's beyond common for a model to find holes in its own work, as well. I have an iterative review as the part of all agentic work, and it always finds something to fix, and will sometimes spend hours fixing its own work.
Same here. Grok Build 4.6 for me, given how cheap Grok is and how Sol is supposed to be "the" SOTA, it finds a surprising amount of bugs. Most of which Sol agrees with needs to be fixed or improved.
I've done this tens of times between these two models and it works great in my experience. Sol initial back and forth with me. Commit. Let Grok review. Sol fix. Only then do I start reading the code.
If you like this list of "why?", you might also like this: https://usehax.dev/ (I am the author).
Most of the list applies, similar minimalist Unix tool approach, with some differences. Hax is written in C, the dynamically linked binary is even smaller (0.6 MB), MIT-licensed. No wasm though.
Important difference - fx is currently Vercel AI Gateway only - while hax does support multiple providers already (OpenAI API, ChatGPT/Codex subscription, Anthropic API, OpenRouter, OpenCode Zen/Go), and integrates well out of the box with local llama-server.
For comparison, I publish a CLI tool written in Dart, can compile to native anything including Wasm , the Linux binary is around 5MB and it does quite a lot.
this looks great! what are you using it for? i like the idea of being able to use one of these (sandboxed) within a larger program kind of like how I use LLM's to do small tasks within my apps now but with a few tools (web search). my current way of doing that is like building a mini-harness with a couple tools within the app, but something more drop-in would be better obviously.
that's an amazing project! people always say why 6mb vs CC's 250mb even matter when you are calling out to LLMs hosted in the cloud. But... I regularly run hierarchies of agents with say 50-100 on a regular basis. So 650 vs 25050 ... is "can do" vs "cannot"
For eg. on a large codebase I do hierarchical review where higher level agents focus on modules and leafs on files. Each reports upwards a summary of its findings incl children summaries.
Technically, this would be straightforward. The problem is that Anthropic seems to be really against using Claude subscriptions with anything other than Claude Code - you might even risk your account getting banned for doing so. You could search online for the "openclaw claude banned" for more details on that story.
I've only done a little of the new opencode v2 "mini" but it too offers a nice preserve-scroll by default.
OpenCode is the best behaved TUI i've seen by far (they invented OpenTUI to make it so good, also in Zig), so it feels less crucial. But it's nice to have there!
> an architectural change we made in opencode2 is nearly everything is an internal plugin / there's 68 of them that cover our built in agents, integrations, config loading, etc
i also think this is such a brilliant fun architectural twist too:
> OpenCode is the first time i could justify event sourcing in a real system / everything that happens is an event which gets projected into the sqlite db
it's so fun seeing new malleable software cores emerge, try to figure out how to augment agency. agentic software striving itself to extend the agency it itself offers. it's been way too long since we've had ambitions to build general system, architectures that serve more than the user. this has held computing back for far too long. this is such an excellent interesting field, of such a more ambitious computing, opening up.
Thanks for the links on opencode 2! I’ve been meaning to get into this as I’ve been frustrated about some opencode 1’s behavior and design. Many of the encounters made me come up with ideas I’m happy to see they also had! As much fun as it may have been to build my own harness, I feel like the core primitives should be pretty well understood by now (in fact I envision a standard core library / API design taking shape).
Does it have anything co-designed around Vercel infrastructure? This is what happened to NextJS and why I will likely never touch Vercel open source again
Most of all what you have said is not really any clear differentiation against the rest of the 100s of other agents. Just minuscule or non-negligible implementation details and I'm afraid it is sadly yet another experimental slop project.
It is a branded "mee too" coding agent that we have seen hundreds of them already.
I can't say I'm super into all the agents that are being created. But I do try to keep up here on HN and I can't say that I can remember any with this particular set of attributes.
In particular, aiming to be embeddable into other projects seems rather notable. At least, not something I've remembered of other projects that have made there way across the HN front page.
I don't think Pi is tiny because it's written in typescript and requires a javascript runtime. I definitely want a "tiny" compiled agent with no runtime requirements.
I don't think Zig is that great of a language for this, but it's better than typescript. I don't want to use Vercel software so will pass, but would love to see a more community driven effort.
For people working with small local models like Qwen 35b what's even more important us that the LLM is good at coding in the language in which the agent harness is written so that it can write skills. I really like pi but had a few instances now where Qwen wasn't able to extend it because it isn't very good at writing typescript. Does that sound familiar to anyone, and did you find any fixes?
"- For end users, its CLI output style and form factor aims to be closer to a Unix shell than a heavy "IDE in the terminal" TUI."
I've actually been wondering lately why coding agent functionality isn't just... part of my shell already. Just another kind of interaction modality with an existing shell. Could probably even be an extension to fish or nu-shell even.
Please stop me from forking off on yet another project though.
Originally, Warp was doing just that. Reimagining the terminal including making AI a part of it. I don't think they really found much purchase there because they ended up needing to make a platform out of it:
> Forgejo is self-hostable free software for software development, built on top of Git. Codeberg is powered by Forgejo, which is in turn a hard-fork of Gitea. Compared to Codeberg, Forgejo is not one service, but free software to help you build your own. Everyone can install their own Forgejo instance to host their own projects. There are also public Forgejo instances as well as Codeberg you can use, but make sure you find a site that is actively maintained and updated, and that you trust the provider.
> How people managed to put all their eggs in one intermittently available service is beyond me.
It's beyond me how people on HN can be ignorant to why GitHub gained so much market share. It's because for most dev teams, the things they add to the easily decentralized git core is *very valuable.* Arguing it's not valuable or ignoring that value doesn't help anyone.
If decentralized is really going to win, then you have to have the features and DevX to match the basics GitHub provides. Because that's what people need/want. And not just the candy-ass-not-as-good-as-the-kernel-devs devs. Lots of very talented people and very well engineered projects use GitHub because it's better for what they need. Even with all the outages, people are still there. If it was so easy to move away, people would. The fact that they aren't says something important. Please consider not ignoring it.
This back-and-forth is a good example of why Go benefits from having a centralized linter. And uv isn't the official Python package manager even though it should be.
I don't get why this is a big issue. This isn't some recurrent decision to be made. It's something a lead decides once and the project follows. That's it. Many companies have style guides anyway (eg Google[1]); the choice of a formatter is much simpler.
Because at some point you have to interact with some other team or project that made a different decision. And whatever you picked might fall out of favor and lose support. There's already a graveyard of Python type linters, including Google's pytype.
Especially the uv thing. You clone some non-uv git repo that has no pyproject.toml and you don't know what to install. Maybe has requirements.txt but it's partially wrong.
- LLM expense budget
- What type of dev: work, personal, real time spaceship thrust vectoring, html contact forms for family, etc.
- human in the loop with short as possible turns, software factories that can run for days, or something in the middle
Just off the top of my head. I'm sure there are others I'm missing.
reply