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?
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"
> 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)
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.
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
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'd like to see this benched against oh-my-pi because I've really been digging how it does compaction / snapshotting.
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?
https://omp.sh/
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"
I use it. It works flawlessly.
it's in the docs! never have used it though https://omp.sh/docs/compaction
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/
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
> 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!
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)
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.
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]