It's proven useful for me, and I figure others might appreciate how light of a shim it is between you and the models.
I personally didn't find it to be competitve with Claude Code as a harness. Can I ask how you modified it to perform better?
-Claude-style subagents -an MCP layer for higher-level tools -Cursor-style control plane modes like Ask, Plan, Debug, and Build.
The MCP layer lets the harness use things like GitHub file/code read, PR creation, web search/fetch, structured user questions, plan-mode switching, user skills, and subagents.
So the improvement is mostly from better ui/ux orchestration and tool access. There's some things from hermes that are interesting as well.
Most of my focus has been on applying this stack to sandboxed cloud agents so you can properly code and work from mobile devices.
I can't definitively say that the stack is better or worse than Claude code, more just tuned for my use case I guess.
Personally I use it for the TUI, it's way better than Claude Code's one.
https://www.incredibuild.com/blog/why-we-built-islo-ai-codin...
i'll have to look more at islo, I definitely think its a growing space with alot of opportunity for those that participate and solve problems.
The main pieces I've integrated for mouse.dev inspired by claude/cursor was plan mode, agent questions, subagents, pre/post hooks, context compaction, repo-local skills, and permission modes. So mostly tools like enter_plan_mode, ask_user_question, and spawn_subagent, plus .mouse/skills and .mouse/plans.
One nice feature is continuity. If you’re working on desktop and save a plan to .mouse/plans, you can pick it up later on mobile with cloud agents, or do the reverse. You can plan something from your phone, then when you’re back at your desk, review it/build it. That was my initial goal with this project because I've found the plan act loop so helpful.
Mouse Cloud Agents is mostly an OpenCode-based harness, but everything routes through our MCP/event system so it’s mobile-first and provider-agnostic.
I intentionally skipped a lot of IDE and Claude Code style desktop features. The bet is that this new style of coding is becoming less “edit files in an IDE” and more steer a capable coding chatbot.
Would love to hear from anyone reading that's iterating on harness architecture, it's been really fun to work on.
While those are nice, Claude Code has the largest amount of plugins and skills I want to use.
Looked into this one. Thought it was suspicious that it only had 7 open issues on github. Turns out they have a bot that auto-closes every single issue just because.
I honestly have no words.
> Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar below will not be reopened or receive a reply.
Seems like not an unreasonable way to deal with the problem of large numbers of low quality issues being submitted.
Like if they are going to sort through all the issues eventually (like they claim), why not just close the ones that are not worthy when they get to them instead of closing all by default?
Is it just so that the project doesnt have open issues on its github page? But they are open issues in reality because the maintainer will eventually go through them?
Nothing is "unreasonable" in the sense that an open source project should have the right to do what it wants with its rules but its definitely a weird stance.
It is a guardrail against burnout and tracker spam
Its based on their implied perspective that the majority of submissions don't follow those guidelines which helps determine their quality threshold.
https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...
If all open issues are actionable items, that makes expected workload a lot easier to handle.
If most open issues are actually in "needs triage / needs review" state, you lose the signal from the noise.
The issue tracker for a project exists primarily as a tool for maintainers, not for outsiders. Yes, the maintainers could change their workflow to create a new view that only shows triaged tickets.
Or, they could ensure the default 'open' view serves their needs.
It's crap either way.
I quite like pi and learned about the contribution guidelines a while after using it. Hard to complain about people making software for free using a process that works for them.
I will say having a project with a slim issue tracker that only contains things the maintainers have blessed (and thus presumably are more likely to get worked on) is pretty nice.
If you’re googling for a bug your hitting and come across and auto closed issue, you know you have to submit a higher quality issue to get it looked at, rather than just +1ing the existing lacking issue.
https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...
- https://news.ycombinator.com/item?id=46930961 - https://github.com/mitchellh/vouch