[justech]

If you're looking for Claude Code alternatives, I would first suggest looking into pi.dev or opencode for your harness. And then for models, you can choose from OpenCode Go (IMO most cost effect at this moment), OpenRouter, or direct from DeepSeek. Better if you go the Kimi route IMO and just buy a subscription from kimi.com

[wolttam]

I’m going to throw my harness in the ring: https://codeberg.org/mlow/lmcli

[taocoyote]

Looks interesting. Does it offer anything special that pi.dev or opencode does not?

[wolttam]

Probably not, `lmcli` is very lean. I would consider it a slightly lower-level tool than either pi.dev or opencode. E.g. there is no built-in coding agent, but it's easy to build one up in the config with your own prompt (or use the example).

It's proven useful for me, and I figure others might appreciate how light of a shim it is between you and the models.

[Aeroi]

agreed. OpenCode is a strong base, and with a couple modifications it can become a very effective harness. my sideproject mouse.dev I’ve been combining parts from OpenCode, Claude Code, and Hermes to build a cloud agent architecture that works well from mobile.

[CharlesW]

> OpenCode is a strong base, and with a couple modifications it can become a very effective harness.

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?

[Aeroi]

I haven’t run formal evals but i improved the experience for my own needs and it feels noticeably better with these modifications.

-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.

[eloisant]

What issues do you have with OpenCode?

Personally I use it for the TUI, it's way better than Claude Code's one.

[ryanlitalien]

Kudos! Cool idea, I'm on the same path you are, yet you're just one step ahead. For mouse.dev, what are you using for the cloud agent sandbox piece? I haven't moved my agents to the cloud yet (for on the go mobile enablement). Would Islo be a competitor to mouse?

https://islo.dev/

https://www.incredibuild.com/blog/why-we-built-islo-ai-codin...

[Aeroi]

cool! I've been mostly building for what coding from an iphone can look like. the cloud agent sandbox portion is definitely not polished yet but working well so far. i looked at daytona, e2b, modal ect. but decided to roll my own with fly.io. ttl on agent create. mouse uses per-thread sandboxes (not shared-container multi-workspace) and then post-gres for agent history ect.

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.

[ryanlitalien]

Great ideas, I'll look at those too. We're only a few steps away from building our own cloud providers :D.

[adobrawy]

I'm a Claude Code Web fan and a rather heavy user. So I was interested in your product. However, I couldn't find an answer on the website. What parts did you find so good that you ported them?

[Aeroi]

Nothing groundbreaking but i'll do a blog writeup on the architecture if it would be helpful for people. My focus has been on mobile.

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.

[DeathArrow]

>If you're looking for Claude Code alternatives, I would first suggest looking into pi.dev or opencode for your harness.

While those are nice, Claude Code has the largest amount of plugins and skills I want to use.

[wizhi]

Aren't skills just literal plaintext files? Why not just copy them?

[DeathArrow]

Yes, they are .md files but they can rely on builtin behaviors in the harness or on plugins.

[bakugo]

> I would first suggest looking into pi.dev

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.

[mikeocool]

Their process is outlined here: https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...

> 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.

[altmanaltman]

But how is it any different from keeping them open?

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.

[mellosouls]

They address the decision at the end of those contribution guidelines linked above, specifically:

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...

[oarsinsync]

> But how is it any different from keeping them open?

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.

[vanchor3]

Somehow going through closed issues just to reopen them sounds like more effort than just using the built in label system which is made for this purpose, but maybe that's just me.

[oarsinsync]

I can either change my daily workflow to accommodate the noisy herd, or I can change the noisy herd to accommodate my daily workflow.

[oefrha]

If that process actually happens then there’s absolutely no reason not to have the reviewing maintainer close it after review instead. The only reasonable conclusion is that documented process is aspirational at best and vibed itself at worst.

[cromka]

Sounds like a perfect way to agitate the community going against the established culture like that.

[63stack]

The established culture on a lot of projects is that you open an issue, and then you have to keep pinging it every week otherwise the stale bot closes it with "this issue is stale, closing, but your contribution is very important to us".

It's crap either way.

[mikeocool]

::shrug::

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.

[__cayenne__]

The maintainer, Mario, sometimes declares the repo is on an “issue holiday” where issues are auto closed. This particular holiday is because there is a big refactor coming up. In non holiday periods issues can be reported as normal.

[skeledrew]

They have a pretty decent explanation.

https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...

[DetroitThrow]

"Decent" is doing some work. This is going beyond any norms I've encountered in OSS to close issues by default via a LLM or an "issue holiday".

[Munksgaard]

It was pretty well received when mitchellh copied the idea and formalized it into vouch.

- https://news.ycombinator.com/item?id=46930961 - https://github.com/mitchellh/vouch

[skeledrew]

These aren't normal times though. Low quality submissions have suddenly seriously amplified with the use of LLMs. There has to be a response so project quality and maintainer sanity can be preserved.

[justinhj]

It's a very interesting project. Many popular open source projects are inundated with poor quality issues and prs, hence the defences they are starting to erect.

[LPisGood]

The idea is for it to he extremely minimal which strikes me as a very opinionated stance, and not opinions I agree with.

[cpursley]

How does the kimi subscription compare to Codex and Claude Code in terms of how much mileage you get for the pricing? I mean, I see the prices but not sure how usage that buys.

[taytus]

Kimi feels almost limitless. I have the $40/month plan and I've never ever remotely close to hitting the limit. Using opus as the orchestrator.

[cpursley]

I've had some good results with Kimi in Opencode. Can you tell me more about using Opus as orchestrator - what type of harness setup?

[aaurelions]

Another very cost-effective option is Ollama Cloud. In a month of use, I only hit the 5-hour limit once, when I ran 8 agents simultaneously for 2 hours.

[postatic]

definitely worth it - have both ollama cloud, opencode and hermes running to test them all out, working great so far.

[tomw1808]

for me its unbearably slow - especially with deepseek v4 pro. Is that just myself? I literally signed up and canceled again, because for one prompt I needed around 5 minutes to get 600 tokens back (via ollama launch claude --mode ...)

[kopirgan]

On which tier?

[mgoetzke]

I liked pi.dev but why is registering endpoints and models not as simple as possible ? Or am i missing something ? I always have to fiddle with the config file.

[miroljub]

Editing config files is not necessary. Just do /login from your session, choose your provider, and there you go.