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.
> And every time I wonder where the people who create these tests are looking when they're deciding which harnesses to test?
Well, everyone and their dog has a custom harness now (including myself!), and more often than not they're just... pretty much the same, just with a slightly tweaked UI and different defaults? The harness needs to either be one of the popular ones, or have some sort of a unique feature which actually differentiates how it runs, not just how it looks/controls like.
For example, one of the unique features of my harness is that the filesystem is completely virtualized and all filesystem I/O is part of the session. This means that any files the agent modifies aren't actually modified on disk until the user uses `/apply`, and rewinding the session also rewinds the state of the disk, and this works for all I/O and all tools (including anything spawned by the `bash` tool), and also supports at-will forking of the session including the filesystem state. This means that the agent can run fully YOLO and won't be able to nuke your disk, and it also means that there's no need to use git worktrees and such because multiple agents can just run in the same directory at the same time without an issue.
Essentially, what I'm trying to say: I'd love to see more experimentation in the harness space which doesn't just involve "a different GUI".
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.
I'm using fourlexboehm's minimal agent[1], it's only 674 lines of C (with comments), which results in a tiny ~10KB binary (after various optimizations). Dynamically linked, with only libcurl and libc as direct dependencies. Could probably shave a couple of KBs further if I UPX'd it.
If anyone's aware of a smaller agent than this, hit me up!
The same thing as the last word of "That is the difference between 22 and 226 seconds, measured." Techies I know would mostly omit "measured"; the rest would show, not tell.
Isn't using it with GitHub Copilot a violation of GitHub terms of usage, due to usage of internal API? I read that they have an official partnership with OpenCode, and I guess it is fine to use it with OpenAI Codex, but what about other coding agents like maki?
Do I understand correctly that in your harness models don't call tools and pass output of one to another via context, but instead code whole pipeline as small on-demand tools and see only final output?
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
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.
For it's size it's pretty good.
I run it and the older Qwen 3.6 35B A3B, which is significantly faster, but also a bit dumber, on both my PC and my MacBook.
Wouldn't trust it for long form coding, but for shorter stuff it's really good.
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.
Notion is a "knowledge database" with awful performance and jank, that some people have decided sounded like a perfect place to host their blog for whatever reason. But these shared pages been as buggy as the first time I saw them years ago, not sure what they're doing.
“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.
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.
Opencode system prompt contains a lot of stuff but even worse is oh-my-pi where their long prompt looks like random garbage hallucinated by a 2023 LLM:
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...
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.
> And every time I wonder where the people who create these tests are looking when they're deciding which harnesses to test?
Well, everyone and their dog has a custom harness now (including myself!), and more often than not they're just... pretty much the same, just with a slightly tweaked UI and different defaults? The harness needs to either be one of the popular ones, or have some sort of a unique feature which actually differentiates how it runs, not just how it looks/controls like.
For example, one of the unique features of my harness is that the filesystem is completely virtualized and all filesystem I/O is part of the session. This means that any files the agent modifies aren't actually modified on disk until the user uses `/apply`, and rewinding the session also rewinds the state of the disk, and this works for all I/O and all tools (including anything spawned by the `bash` tool), and also supports at-will forking of the session including the filesystem state. This means that the agent can run fully YOLO and won't be able to nuke your disk, and it also means that there's no need to use git worktrees and such because multiple agents can just run in the same directory at the same time without an issue.
Essentially, what I'm trying to say: I'd love to see more experimentation in the harness space which doesn't just involve "a different GUI".
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.
ive looked at your project before but forgot about it. I think mine is in a similar vein: https://github.com/mischief/clm
it grew out of annoyance of dependencies on js runtimes, probably similar to you. mine additionally works on solaris and esp32.
could be interesting to collaborate!
I'm using fourlexboehm's minimal agent[1], it's only 674 lines of C (with comments), which results in a tiny ~10KB binary (after various optimizations). Dynamically linked, with only libcurl and libc as direct dependencies. Could probably shave a couple of KBs further if I UPX'd it.
If anyone's aware of a smaller agent than this, hit me up!
[1] https://gist.github.com/fourlexboehm/a60e4ef9306744483731cd1...
What is this supposed to mean?
"it spreads up to 50% between nights, so nothing between the lean arms is a finding."
The same thing as the last word of "That is the difference between 22 and 226 seconds, measured." Techies I know would mostly omit "measured"; the rest would show, not tell.
Pangram fires as usual. Human opening, 75% machine.
Whatever it is, it’s just as hilarious as Engrish…
Means Claude can't write for shit.
Or chad
I've made https://maki.sh for use cases such as this
Isn't using it with GitHub Copilot a violation of GitHub terms of usage, due to usage of internal API? I read that they have an official partnership with OpenCode, and I guess it is fine to use it with OpenAI Codex, but what about other coding agents like maki?
Do I understand correctly that in your harness models don't call tools and pass output of one to another via context, but instead code whole pipeline as small on-demand tools and see only final output?
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
Pi is a very basic harness by design. On the other hand OMP is a bloated mess of other people’s workflows.
The trick with pi is to extend it yourself as you use it. It’s pretty easy to do.
Every single article and banchmark say pi saves token by default, the more I add extensions the more token hungry it gets.
pi used 2-3x the tokens of codex. pi with subagent pkg used 8x-10x the tokens of codex.
I don't see how adding bloat to pi would make it more token efficient if the baseline is so poor to start with
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.
For it's size it's pretty good. I run it and the older Qwen 3.6 35B A3B, which is significantly faster, but also a bit dumber, on both my PC and my MacBook.
Wouldn't trust it for long form coding, but for shorter stuff it's really good.
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.
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
jcode is the best for RAM usage and browser interactions
What is with the website though? Rubbish scrolling. Junky rendering with artifacts if you scroll fast.
Notion is a "knowledge database" with awful performance and jank, that some people have decided sounded like a perfect place to host their blog for whatever reason. But these shared pages been as buggy as the first time I saw them years ago, not sure what they're doing.
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.
I for one am excited to learn more about how it spreads up to 50% between nights, and how nothing between the lean arms is a finding.
Don't forget it's, measured.
Not to mention it's yet another bash does everything harness which compares itself against claude code when the closest competitor is pi.dev?
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.
Opencode system prompt contains a lot of stuff but even worse is oh-my-pi where their long prompt looks like random garbage hallucinated by a 2023 LLM:
https://m.youtube.com/watch?v=c_fQoDkULl0 (see around 8:00)
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...
wtf is wrong with scrolling on that website?