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, burying 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.
Anywho, it's not great, though the project looks cool. I'd say it'll probably limit the number of Github stars from the slop-wall. But when has that stopped any of us? :)
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
I feel like I'm taking crazy pills...
The feature list doesn't seem to show why it is significant compared to all the other harnesses.
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
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, burying 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.
Anywho, it's not great, though the project looks cool. I'd say it'll probably limit the number of Github stars from the slop-wall. But when has that stopped any of us? :)
Good luck out there!
[0] https://mise.jdx.dev/dev-tools/backends/cargo.html
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.
Tokens are cheap. Quality is what matters.
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