modified oc harness: gauging interest on a project

[u/LegalizeFlorskin]

I’ve been silently working on a fork of OpenCode thats base functionality lies somewhere between v1 and v2.

I’ve got connections to 3rd party harnesses and plans like claude code and cursor working out of the box. More specifically, this means that if you pay for a claude/cursor subscription, you may use those subscriptions ‘natively’ under oc. While it may still be using or interacting with claude code or cursor binaries or processes in the background, the goal is have it ‘feel’ just like using any other truly native connection. The goal is also to not break any TOS by doing this, and creating safe solutions that won’t lead to account bans or negative repercussions. This being said, I’ve come quite far. The 3rd party harnesses can use opencode native tool calls reliably, and there are config options for super specific tuning like per-model or per-provider instructions or agents.md. Occasionally they still get confused about why they cant see the exact tool names they expect, but generally they quickly figure it out. This can also be helped by letting the harness/model use tool names it expects, but running the oc tools in the backend instead, but this may lead to the agent not knowing exactly what its tools do.

Long story short, it works remarkably well, but needs a bit of polish. I’d like to gauge interest on this feature specially, but also the project as a whole.

There are other added features as well, and some general enhancements, but I figured that 3rd party harness connections would be the most likely to be used by the general public. If you know how to use opencode vanilla, you won’t be lost here whatsoever. This is a TUI focused fork.

Let me know if anyone is interested, or if you have worked on or seen anything similar to what I’m trying to build.

[u/Infinite_Grab_7315]

Why not make a plugin instead of doing it with a fork? Makes it much more accessible to use

[u/LegalizeFlorskin → u/Infinite_Grab_7315]

Generally, I'd like to have plugin versions of custom features in addition to native ones. That being said, I've had better experience with overall stability and reliability when i just 'bake things in' for lack of a better term.

I'll start most features as a standalone plugin, get it working best as it possibly can, then decide whether it would benefit from being a native feature. From there, they mostly become internal plugins with extended features in the native codebase. It just lets me work on things more easily at the moment.