Holy tagline. "The CLI-first AI coding agent runtime. Pipe it, schedule it, embed it. One binary, any model, MCP-native — built for autonomous work, not just chat."
I don't know if I want any of those things. Can I still just throw it my csvs and make it do my data science work for the day so it doesn't distract me from baldurs gate?
I'm not sure if I missed something, but the benchmarks [0] look outdated since they use Claude Opus 5 (instead of Opus 5.5), GPT 5.6 Sol (instead of 6.1 Sol), and GLM 5.2 (instead of DeepSeek V4.1 Flash 1017, which is the most popular model on OpenRouter currently [1]). I also cannot find any information regarding thinking efforts for each.
Since these benchmarks were done in July, they were probably using older versions of Claude Code, Codex, and OpenCode as well.
Would appreciate if the benchmarks are updated, and the thinking efforts and the versions of Claude Code, Codex, and OpenCode are specified.
great idea. Currently working on updating benches on frontiers models, so far on glm-5.3 it's already showed great results. Can I have a link to oh-my-pi to make sure will sure use right one for it?
Also, quick question: Could I use octomind upstream of harnesses like omp and get the savings? Or do you primarily get the savings from using the octomind CLI?
did they stick with the image-based compaction (when vision is supported i guess)? It boggled my mind: "snapcompact, which archives older history into dense images for a vision-capable model"
For obvious reasons it underperforms on models that hide their reasoning chain. Other than that it works fine for a non-customizable method. But properly customized handoff is still better.
I would vote against package managers. It just doesn't make sense to try to support them across Linux distributions.
If it's really static rust then either make it one binary. If that's not reasonable then make the release relocatable to run from any path. Also it should be simple and easy to run out of the source repo.
Agreed here - routing and subscription pricing made tokens cheap. More interested in quality and cost per outcome than a generic savings. Benchmarking is older. Would like to see benchmarking outlining full wall to wall, telemetry, CPO, COO, etc. using foundational models against lesser known or job specific with rigid tooling lists, etc.
Our benchmarks shows that it best solver. Solves more than Claude on Opus while using glm 5.3, but still benching new models with most recent version.
The point here it has flexibilty in config, supervisors, automatic learning and also utilizeing jev-like models to gain maximum of efficiency while keeping solving rate intact
A sloppy read me or product description can absolutely define the quality of a product. If you cannot take the time to articulate the project or product, you do not have one. The comments are very specific in stating. No clear description or direction. As the other gentleman noted, make it clearer what you aimed to solve and how you did it. What pain points does this project solve for the end user?
> But advise what exactly sloppy – would be much more valuable
I've been known to sling slop like the best of 'em, so how about I take a crack at it and do some work for you (but only a few sentences for free). Challenge accepted!
> The CLI-first AI coding agent runtime.
CLI-first? Claude Code, isn't that CLI-first? Codex? Given the context of the rest of the Readme, I pieced together this to mean that it runs headless with reduced human-in-the-loop? Perhaps that would be a better descriptor: "headless AI coding agent runtime" or "Nearly-headless AI coding agent runtime"
> Octomind is a CLI-first AI coding agent runtime. It gives an LLM real access to your repo — reading and writing files, running shells, searching code, delegating to sub-agents — through MCP tools. The same session engine works interactively, piped through stdin, as a background daemon, over WebSocket, or as an ACP sub-agent inside another agent's stack.
Real access to your repo? Does CC or Codex have fake access? Is it only a git wrapping tool, if not, why is this the first specific sentence on what it does and the features.
> The same session engine works interactively
See this is the tell-tale sign of slop. In good technical writing, one would mention and define key concepts before referring back to them. Likely in the LLM context is a discussion with you or your code about "a session engine." Here, it's totally undefined and since this is the third sentence, the session engine must be referencing the first part of the abstract of the project. Thus "LLM real access to your repo... through MCP tools" is a session engine that you can pipe? Through context, I take this to mean you have a way of wrapping repo activity in it's own context, then piping those contexts together.
> piped through stdin, as a background daemon, over WebSocket, or as an ACP sub-agent inside another agent's stack.
More slop here. It describes facts instead of outcomes. This is just a way of saying piping. Piping can pipe many places. What does it otherwise enable with the piping? It actually takes until the second bulletpoint of the "Why" section to answer the benefit of the approach. "Proven on real PRs. It solved 24 of 25 held-out tasks at lower cost than the closest competitor."
Taken together, I'm four sentences deep and have no clue what this thing does without about five minutes of human processing to piece together the crude outline. It'll take another twelve-ish lines before I've gotten any evidence of positive outcomes.
In some of the best technical writing, the abstract gives you a condensed 3-5 sentence overview with motivations, existing limitations, key solution, and results/outcomes. Your main pitch for the repo does none of that. Instead, it buries key details much farther down the readme including after a bunch of usage scripts (useless since we don't know what it does from the text above it anyway). It's noise on noise.
I'd recommend the following: bring the positive results closer to the top so your first few sentences describe what the Octomind project does (I have seen better descriptions in the comments by you than the entirety of the readme). Get it crisp and uniquely defined and I think you'll attract even more attention and engagement.
Anywho, it's not great as is, even though the project looks cool when I started grokking it. I'd say it'll probably limit the number of Github stars from the slop-wall.
We benched it also on glm-5.3 not published. To be honest they act almost the same did not see any significant difference, while other benches show a lot
From what I can tell this is a harness optimized to be used as headless background jobs, think about CICD jobs, or bugs auto triage. Instead of interactive HITL approvals you supply a policy file with the tools and commands you allow it to execute. Kind of cool idea, similar to pi but seems more specialized to dev cycle triggers.
Yes. Kind of right. No TUI but still old CLI approach that some of us still love.
It can be used interactively and I use it daily, but so far it's optimized for autonomous work at max and so far finalizing task while running in isolated environments (we use docker for that)
Holy tagline. "The CLI-first AI coding agent runtime. Pipe it, schedule it, embed it. One binary, any model, MCP-native — built for autonomous work, not just chat."
I feel like I'm taking crazy pills...
I don't know if I want any of those things. Can I still just throw it my csvs and make it do my data science work for the day so it doesn't distract me from baldurs gate?
Blessed by compiler. Sometimes one of those crazy pills take you out of matrix :)
I'm not sure if I missed something, but the benchmarks [0] look outdated since they use Claude Opus 5 (instead of Opus 5.5), GPT 5.6 Sol (instead of 6.1 Sol), and GLM 5.2 (instead of DeepSeek V4.1 Flash 1017, which is the most popular model on OpenRouter currently [1]). I also cannot find any information regarding thinking efforts for each.
Since these benchmarks were done in July, they were probably using older versions of Claude Code, Codex, and OpenCode as well.
Would appreciate if the benchmarks are updated, and the thinking efforts and the versions of Claude Code, Codex, and OpenCode are specified.
[0] https://github.com/Muvon/octomind#benchmarks
[1] https://openrouter.ai/rankings
I'd like to see this benched against oh-my-pi because I've really been digging how it does compaction / snapshotting.
How is oh-my-pi compaction different? Is there other harnesses that employ the same tricks?
great idea. Currently working on updating benches on frontiers models, so far on glm-5.3 it's already showed great results. Can I have a link to oh-my-pi to make sure will sure use right one for it?
https://omp.sh/
Also, quick question: Could I use octomind upstream of harnesses like omp and get the savings? Or do you primarily get the savings from using the octomind CLI?
Also regular pi, which is particularly minimal
did they stick with the image-based compaction (when vision is supported i guess)? It boggled my mind: "snapcompact, which archives older history into dense images for a vision-capable model"
For obvious reasons it underperforms on models that hide their reasoning chain. Other than that it works fine for a non-customizable method. But properly customized handoff is still better.
it's in the docs! never have used it though https://omp.sh/docs/compaction
I use it. It works flawlessly.
Why would i choose that over maki.sh? A comparison to maki would be great!
Hey. Never heard about it, but I will take a look. thanks
Compare against ante as well: https://ante.run/
have you taken a look at Codeoid: https://github.com/highflame-ai/codeoid, we use it regularly across everyone in our team and its really great.
Especially the ability to switch an ongoing conversation from Claude Code to Codex or Gemini (if you run out of tokens).
I will try it, but please, make the installation through package managers (linux), these curl scripts aren’t secure.
I highly recommend just using `mise` with the cargo backend[0]. I use mise to manage all the harnesses I try.
[0] https://mise.jdx.dev/dev-tools/backends/cargo.html
interesting, never heard about it. How its better then just cargo install?
If you're installing just one thing, nothing.
I would vote against package managers. It just doesn't make sense to try to support them across Linux distributions.
If it's really static rust then either make it one binary. If that's not reasonable then make the release relocatable to run from any path. Also it should be simple and easy to run out of the source repo.
I think packgae manager still can be as an option. But for sure static binary should stay as is
Thanks for suggestion! Will do. Can I know which distribution are you using? Feel free to leave feedback after you try. Cheers
nice name
I like yours too! Perfect fit
[dead]
Can someone save me a click? Does this improve quality or worsen it?
Tokens are cheap. Quality is what matters.
Agreed here - routing and subscription pricing made tokens cheap. More interested in quality and cost per outcome than a generic savings. Benchmarking is older. Would like to see benchmarking outlining full wall to wall, telemetry, CPO, COO, etc. using foundational models against lesser known or job specific with rigid tooling lists, etc.
Our benchmarks shows that it best solver. Solves more than Claude on Opus while using glm 5.3, but still benching new models with most recent version.
The point here it has flexibilty in config, supervisors, automatic learning and also utilizeing jev-like models to gain maximum of efficiency while keeping solving rate intact
[dead]
The README is AI slop ... is there anything actually special about this?
The feature list doesn't seem to show why it is significant compared to all the other harnesses.
Well it's beating Claude while using GLM-5.3 in solving the UNSEEN issues from real github PRs on our benches.
Yes, readme maybe sloppy, I'm using it daily along with claude and can say it works much better, but still personal opinion
You will never know if you not try, sloppy readme cannot say the product is bad IMO, but its your choice.
Thank for feedback. I will definitely will look and work on readme. But advise what exactly sloppy – would be much more valuable
A sloppy read me or product description can absolutely define the quality of a product. If you cannot take the time to articulate the project or product, you do not have one. The comments are very specific in stating. No clear description or direction. As the other gentleman noted, make it clearer what you aimed to solve and how you did it. What pain points does this project solve for the end user?
> But advise what exactly sloppy – would be much more valuable
I've been known to sling slop like the best of 'em, so how about I take a crack at it and do some work for you (but only a few sentences for free). Challenge accepted!
> The CLI-first AI coding agent runtime.
CLI-first? Claude Code, isn't that CLI-first? Codex? Given the context of the rest of the Readme, I pieced together this to mean that it runs headless with reduced human-in-the-loop? Perhaps that would be a better descriptor: "headless AI coding agent runtime" or "Nearly-headless AI coding agent runtime"
> Octomind is a CLI-first AI coding agent runtime. It gives an LLM real access to your repo — reading and writing files, running shells, searching code, delegating to sub-agents — through MCP tools. The same session engine works interactively, piped through stdin, as a background daemon, over WebSocket, or as an ACP sub-agent inside another agent's stack.
Real access to your repo? Does CC or Codex have fake access? Is it only a git wrapping tool, if not, why is this the first specific sentence on what it does and the features.
> The same session engine works interactively
See this is the tell-tale sign of slop. In good technical writing, one would mention and define key concepts before referring back to them. Likely in the LLM context is a discussion with you or your code about "a session engine." Here, it's totally undefined and since this is the third sentence, the session engine must be referencing the first part of the abstract of the project. Thus "LLM real access to your repo... through MCP tools" is a session engine that you can pipe? Through context, I take this to mean you have a way of wrapping repo activity in it's own context, then piping those contexts together.
> piped through stdin, as a background daemon, over WebSocket, or as an ACP sub-agent inside another agent's stack.
More slop here. It describes facts instead of outcomes. This is just a way of saying piping. Piping can pipe many places. What does it otherwise enable with the piping? It actually takes until the second bulletpoint of the "Why" section to answer the benefit of the approach. "Proven on real PRs. It solved 24 of 25 held-out tasks at lower cost than the closest competitor."
Taken together, I'm four sentences deep and have no clue what this thing does without about five minutes of human processing to piece together the crude outline. It'll take another twelve-ish lines before I've gotten any evidence of positive outcomes.
In some of the best technical writing, the abstract gives you a condensed 3-5 sentence overview with motivations, existing limitations, key solution, and results/outcomes. Your main pitch for the repo does none of that. Instead, it buries key details much farther down the readme including after a bunch of usage scripts (useless since we don't know what it does from the text above it anyway). It's noise on noise.
I'd recommend the following: bring the positive results closer to the top so your first few sentences describe what the Octomind project does (I have seen better descriptions in the comments by you than the entirety of the readme). Get it crisp and uniquely defined and I think you'll attract even more attention and engagement.
Anywho, it's not great as is, even though the project looks cool when I started grokking it. I'd say it'll probably limit the number of Github stars from the slop-wall.
Good luck out there!
Thanks a lot for that feedback. really appreciate. Slightly tuned readme already, but still huge room to improve.
glm-5.2*
We benched it also on glm-5.3 not published. To be honest they act almost the same did not see any significant difference, while other benches show a lot
From what I can tell this is a harness optimized to be used as headless background jobs, think about CICD jobs, or bugs auto triage. Instead of interactive HITL approvals you supply a policy file with the tools and commands you allow it to execute. Kind of cool idea, similar to pi but seems more specialized to dev cycle triggers.
Yes. Kind of right. No TUI but still old CLI approach that some of us still love. It can be used interactively and I use it daily, but so far it's optimized for autonomous work at max and so far finalizing task while running in isolated environments (we use docker for that)