Nine coding harnesses vs. your laptop

104 points - yesterday at 10:54 PM

Source

Comments

OleksandrC today at 6:36 AM
If you're looking for a coding agent that would fit nicely into resource-constrained environments (such as laptops, or tiny VPS servers, or tiny single-board computers, etc), and would also work great with local models - you might also like hax (https://usehax.dev/). 0.7 MB dynamically linked native C binary, few MBs of RAM usage when running, auto-discovers config from running local llama-server, and uses minimalist system prompt and tools for lean context usage.
julesrms today at 8:12 AM
HN seems to have had a stream of agent harness benchmarks floating past. And every time I wonder where the people who create these tests are looking when they're deciding which harnesses to test? Because right now nobody seems to bother testing mine! (https://juggler.studio)

I know Juggler's very new, but there's so much churn going on in this area that it's hard to know where I should be pushing it. It's hard to guess whether juggler's strengths would played well with a particular test like this, or made it look bad, all feedback about the kind of parameters people are interested in is useful to know when I'm deciding what to optimise.

alex_john_m today at 6:13 AM
What is this supposed to mean?

"it spreads up to 50% between nights, so nothing between the lean arms is a finding."

larodi today at 9:13 AM
I can see this pattern of many people using Qwen 3.8 27B for local inference both on Apple Silicon and x86. This implies the model must be very good, given all these peoples' opinion converges on it.
toasty228 today at 7:27 AM
A bit off topic because I'm not using local models, but I recently benchmarked codex vs pi vs omp with my workload and found codex to be both faster and more token efficient than pi/omp. There was not a single case for which pi was faster/cheaper
swiftcoder today at 9:41 AM
I'd be interested to see how Reasonix stacks up here - they seem to have spent a lot of effort on tuning prefix cache reuse
tontinton today at 6:58 AM
I've made https://maki.sh for use cases such as this
humbleferret today at 7:56 AM
Nice writeup! I imagine these results change as harnesses are updated, so you'd need to frequently rereview.

I'd love to see a tiny, reproducible benchmark repo that anyone can drop on their own hardware and then run against all harnesses at once to compare the per turn prefix token count, time to the first token, experienced tokens/sec (and prefill), cache reuse % and a pass rate on a deterministic set of small tasks. I think it could also be useful to have some way to share results and hardware for others to compare.

asdfsa32 today at 9:17 AM
What is with the website though? Rubbish scrolling. Junky rendering with artifacts if you scroll fast.
nottorp today at 9:54 AM
Uh I have this feature I'm doing where I used a context to 600k tokens, then told Claude to make itself a summary and started a new context with it, and it's at 500k already.

Mind, this is more of an exception, at least for my work, but still, what do you do with 32k tokens?

Edit: i resumed a quickie that basically added a 10 line function in one spot, and even that is 50k tokens...

teekert today at 6:05 AM
Fun reference I tested on 32 GB ram laptop with no extra GPU: llama.cpp: “what is ls”, almost immediate starts answering at one ~word/sec. Ask opencode with same model (some gwen e4b or something) to check what’s in its working directory: 20 min to response.
montyanne today at 5:38 AM
Neat article.

“Chad” initially looked interesting but the minute I saw the ai-written markdown and giant commit I just left. I just can’t bring myself to read someone elses’ slop, regardless of performance.

If all a developer hand writes is a truthy and readable markdown document, I really don’t care if the rest of the project is vibe coded, but I struggle to get interested in AI generated summaries and docs.

NooneAtAll3 today at 7:09 AM
wtf is wrong with scrolling on that website?
wip0 today at 5:39 AM
[dead]