I actually think I would like to use OpenClaw but everytime I go to the docs I give up.
It feels so intimidating. There's so much stuff going on. Maybe it is good for agents who can just motor through that volume, but me personally, I would want something simpler, maybe an `OpenClaw-lite`
When I tried OpenClaw it quickly turned into a lethargic mess which I really didn't see myself wanting to maintain long term. I looked at other alternatives which were similar enough to do what I was looking for (mostly scheduled tasks using data on my computer and some API data). I saw a mention of nanoclaw which I looked at but didn't try personally. I eventually settled on trying picoclaw[1] because it was extremely small, fast, and had enough features to do the job for me. It is under 10mb, fairly straight forward go codebase, and works with multiple model providers or locally hosted.
I’ve concluded that if you already use a coding agent then openclaw adds very little (at least the multiple rounds I’ve tried it since mid Jan), it mainly brought the power of do-everything coding agents to your phone, available everywhere. But you exchange a low quality messaging interface for that ease of access.
Just to be clear, I’m not advocating that people that benefit from openclaw move to coding agents. This isn’t a “dropbox is just SFTP” comment, more that if you are already using coding agents, it feels like they do most of what I saw from openclaw at least a few months ago.
Am I missing something? Would love to be proven wrong.
It's not only that, all this complexity leads to stuff breaking with every update. For a tool that's supposed to just answer chat messages it's impressive how crappy and unstable this software feels. I have it running since the release and my primary usecase seems to be to use the CLI to fix whatever broke this week.
Would not recommend running this, it's the antithesis of the Linux philosophy.
I built an agent to work with local Ollama models, and it will keep working and iterate on a goal until finished, but it doesn't do sub-agents or or any of the "just burn a million tokens but finish this" pipelines that seem to be the trend now.
It's a simple D executable that basically consumes no resources in your local machine.
There's a lot of similar projects out there that are closer to what you're looking for. For example, I used nanoclaw for a bit before switching to Hermes.
In my use, DeepSeek v4 Flash (which replaced the quite excellent MiniMax M3) lags behind GLM 5.2 & Muse Spark 1.2 (let alone Kimi K3). Also, K3 is a much bigger multi-modal model, while Flash is text-only and likely optimised for coding tasks.
Yep, and the v4 flash final is about 2.5x slower than preview making it no longer a fast model, in fact slower than Luna and bigger models in many cases.
Spark is actually the interesting one imo. It's significantly better, also significantly faster. If you are ok with letting Meta soak up your data (which DS does too) it's also the same price.
I've been using this DeepSeek model the whole day today after building with 5.6 Luna extensively over the last week and I would disagree, at least for Rust + OpenGL.
DeepSeek just spend almost 2 hours trying to figure out why terrain textures were not working. It tried everything over and over again, it even had reference code for meshes on how to setup the rendering with materials, and it could just not do it.
I finally gave up and gave it to GPT-5.6 Luna instead, and figure out in a single prompt after 20 seconds, that the terrain mesh was being initialized with None in the material slot.
Other tasks it has managed to figure out at least, but it is significantly slower than GPT-5.6 Luna and it requires a lot more iterations.
That's roughly my experience. Luna is extremely efficient and at higher levels of reasoning and longer running tasks more capable.
Reading the DS reasoning is wild, it's constantly going in circles. The most minor lack of clarity in your prompt and it will spend ages going back and forth on what you meant. It reasons 5x longer than the preview which makes it really slow now as well. We did a lot of work to nudge it to be decisive and improve our evaluation setup to there's more clarity, and it helped but only marginally.
Ours is a full-stack app one shot test so it includes backend, frontend, design, and QA/testing. It's graded by Opus xhigh and Sol xhigh and the grades are averaged.
DS4 preview would finish in 20 minutes flat on high reasoning and grades 6/10. Luna high gets 9/10 in about 30 minutes. DS4-final is crazy - at high thinking it's taking over an hour and getting ~8 but only had one successful run as I got tired of waiting so long after many early abort/retries trying to debug why thinking was so long. The lowest thinking still takes over 45 minutes, and with thinking off it actually is finally closer to preview in time but actually get's a much more varying result anywhere from incomplete to 6 it seems.
Costs per run DS4 is best but not actually by a lot as it's spending 10x the tokens with all the reasoning and mistakes. It's a very brute force model and I really preferred preview in many ways for how predictably fast it was.
Side note, Spark 1.2 is a nice model for this test, best in frontend design and fastest to get results together, though not nearly as efficient as Luna. Grok scores similarly to Spark but at like $50/run vs the contributor Spark costing $1.50.
Edit 2: btw it tests a team of agents working together in a special harness and stack. So 20 minutes is for 8 agents essentially. That said everything was built around DS as it was the cheapest to iterate against so even with that advantage the new one struggles.
I kind of get what the article is saying. But I am looking at it from a different perspective.
The same set of things like skills, and custom tools etc can actually be used to get faster to the a product that kind of fits 1000 customers. But the change is that one can build even more custom things for some customers with those skills and tools.
Last year I built a custom integration for a customer in 2 weeks. Now I can probably do it in 2 days. What does that mean for the future, I have no idea, but surely getting custom solutions like this would be more of a moat not less.
Universities use all kinds of hard to setup stuff which are often custom built. Slurm configs, custom configured HPC servers etc. All of this pays off though if you need to do heavy computations which a local machine won't do.
IMO it would be better to make Claude build out something that makes interacting with the HPC much easier. A web UI, Tailscale whatever.
I call this junk "meta-agentic engineering", it reminds me of people who have the coolest nvim configs, spend hundreds of hours customizing it but ultimately get less work done than the guy with minimal workflows, if any at all.
I look on twitter and it's just people building tools for agents to use agents, some weird customization loop going on in the LLM space right now. Ultimately these are trends pushed on us from model providers because they 10x token consumption. Its literally just BS trends to increase revenue at these companies, most of it is largely useless.
Some of this stuff is ludicrous. I finally tried /loop last week and discovered every loop iteration passes the entire context history to the model. So pretty quickly you're running a full 1M context window, without cache, likely just to check if something is ready or needs to be done. It's miserably terrible engineering unless your entire and only goal is to burn tokens.
"On a Claude subscription, Claude Code requests the one-hour TTL automatically. Usage is included in your plan rather than billed per token, so the longer TTL costs you nothing extra and only affects how long your cache stays warm.
If you’ve gone over your plan’s usage limit and Claude Code is drawing on usage credits, you are billed for that usage, so Claude Code automatically drops the TTL to five minutes."
I never liked the term "ricing" with window managers, but this is definitely veering into LLM ricing territory sometimes. And people are getting rich off of it.
I think many of us engineers (including myself) are suffering from AI-induced procrastination. Fixing that pesky bug in production isn't fun. Building a harness/workflow that detects and fixes pesky bugs in production on its own is way more fun (especially when your employer pays for tokens), and it feels just as important, if not more! So what if it didn't actually fix that pesky bug in production on its own...
I'd rather anyone using llms to fix pesky bugs in production gets fired and I work at a shop that cares about quality and craftsmanship. There are handmade swiss watchmakers, and then there are assembly line workers in China also making watches, which worker do you think goes home happier at night (and who's company is actually beloved), you have a choice.
I don't think there is a lot test harness, given there is a golden implementation (sqlite3), with clear interface (SQL, and sqlite3 db files). Once you slop crappy implementation, then you can create one group of agents finding gap where slop doing wrong vs golden, and another group of agents filling the gap meeting the conformance.
I assume they did similar, as long as test case(or spec) can be parallelized. Having parallel execution / testing environment is crucial if we need 1000 commits/second throughput.
I would not surprised they have 1+ millions of specs.
I would bet they won't release generated specs - actually this will be a valuable asset like https://sqlite.org/th3.html
I am afraid this is a very click-baity title. I actually opened the article and thought I would learn something from it.
Instead what I read was typical issues about Agentic CLI's in general dubbed as `alarming`. I would have been happy if the title was just `Annoying` which a lot of `OpenCode` is. But adding the `alarming` made it what it became, something that attracts enough eyeballs to get to the front page of HN.
Heavy disagree. I can't be sure about other AI coding agents as I haven't used others enough, but especially the items around prompt cache misses and compaction have hit me personally.
This article (combined with another article previously comparing CC and OC's system prompt, to which someone replied pi.dev sends even less) has made me want to switch agents, so I'm likely going to try out pi.dev and aim to migrate.
Thanks. I heard the word ABI so many times but only finally understood it after reading this blog.
On another topic, I also feel like quansight blog is usually a high quality resource for Python related stuff. Usually its more for numpy/scipy kind of stuff, but this one is an example of more general Python related stuff.
Nearly every model can be found on OpenRouter and used with a single key. Meta Spark is not among them, but Grok and almost every other model is. That's how I try models I don't already have an account for.
reply