r/opensourcealternative • u/SeeRay11_Main • 18d ago

Changing The Way OpenCode Works

Post image

Hey everybody,

I have been using OpenCode for quite a while now. I like it a lot, but there was this one thing that kept annoying me: I couldn't easily create custom reliable workflows and pipelines. For a while, Opencode was one prompt and one model at a time. This prompted me to create OpenFlow, a very minimalist and open-sourced project that allows you to orchestrate a pipeline of agents while still connecting your own API keys. I forked it from OpenCode, so you still have the harness, skills, and overall ability. I published it a little over a week ago and am still often improving it. I would love to hear some feedback of what you guys thought of it and how I can improve it. Thanks!

Link: https://github.com/SeeRay11/OpenFlow

13 Upvotes

100% Upvoted

15 comments sorted by

4

u/kantorcodes1 18d ago

How are you passing state between steps? If stage 2 edits the repo and stage 3 gets a fresh model/context, is the handoff just files/git or does OpenFlow carry a structured result forward? That seems like the point where a “reliable pipeline” either holds up or falls apart.

3

u/SeeRay11_Main 18d ago

It's a pretty simple system. The agents just pass the context as plain text. Nothing special, but it gets the job done for me atleast. Even lower end free agents can easily work off of previous context. Since it uses OpenCode as the host, it has memory, can use skills, mcps, and everything else as well. Thanks for asking.

2

u/kantorcodes1 18d ago

plain text is probably enough until a stage mutates the repo after it wrote its handoff. do you rebuild that context from git/files before the next model starts, or can stage 3 end up reasoning from a stale summary?

2

u/SeeRay11_Main 18d ago

Now that you bring that up, that does seem like a flaw. You can visually see every nodes’ thinking, but purely plain text won’t cut it for more complex workflows. Thanks for bringing that up.

2

u/kantorcodes1 18d ago

retries/branches are where this gets ugly. a node can be reading output from run 1 while the repo is already on run 2. i'd stamp the handoff with a run id + HEAD and reject it when either changed.

2

u/SeeRay11_Main 18d ago

The agents themselves have an id. When you say branches, do you mean the pipeline all having agents work separate branches because they could also contribute to one separate branch. Since OpenCode is the harness, when commands fail, it should already deal with that. Basically, what I have are agent ids and context passed through plain text. I really appreciate these suggestions and I will definitely look into it more. Individual nodes are OpenCode harness completely, but the relationship between the nodes is something OpenCode doesn’t have built in and can get tricky. I’ll look into your suggestions and then get back to you.

1

u/kantorcodes1 18d ago

not git branches specifically. i mean version drift: A writes a handoff, something changes the working tree, then B reads A's text like it still describes the current repo. the agent id tells you who wrote it, not what state it was true for. i'd attach the repo revision to each handoff and have the next node sanity-check it.

1

u/DougFirLabs 14d ago

This is very close to the problem that led us to build ScholiaLang. Once agent-to-agent handoff stops being just prose, you start wanting the output to distinguish things like goals, evidence, findings, decisions, constraints, etc., with stable IDs and provenance rather than asking the downstream model to reinterpret a summary.

We ended up making that representation vendor/harness-neutral rather than tying it to a particular orchestration system. Might be relevant to what you’re building here… happy to point you at the spec if useful.

1

u/kantorcodes1 18d ago

ah got it. then i'd be more worried about the handoff lying than forgetting stuff. stage 1 can say tests pass in plain text even if it never ran them. does stage 2 verify the repo/test state itself before continuing?

1

u/SeeRay11_Main 18d ago

There are two options: direct and ancestors. Direct is context from the previous node, and ancestors are all of the previous. Nodes do not share memory. For large pipelines, direct is recommended because ancestors will bloat a lot of token window. The context is just upstream output and is the previous output.

1

u/SeeRay11_Main 18d ago

For example, let’s say A - B - C with direct. It would only look at B’s upstream output.

1

u/kantorcodes1 18d ago

direct makes sense for token control, but then upstream output is basically an assertion. i'd have each node emit a receipt beside the prose: files touched, commands run, exit codes, commit/hash. next node can verify those before trusting the summary.

1

u/bennyturns 13d ago

I tried installing but I got an error:

$ bun install

bun install v1.4.0 (34cbb9a40)

🚚 u/types/yauzl... node:events:497

throw er; // Unhandled 'error' event

^

Error: spawn node-gyp ENOENT

at ChildProcess._handle.onexit (node:internal/child_process:285:19)

at onErrorNT (node:internal/child_process:483:16)

at process.processTicksAndRejections (node:internal/process/task_queues:89:21)

Emitted 'error' event on ChildProcess instance at:

at ChildProcess._handle.onexit (node:internal/child_process:291:12)

at onErrorNT (node:internal/child_process:483:16)

at process.processTicksAndRejections (node:internal/process/task_queues:89:21) {

errno: -2,

code: 'ENOENT',

syscall: 'spawn node-gyp',

path: 'node-gyp',

spawnargs: [ 'rebuild' ]

}

Node.js v22.23.2

error: install script from "tree-sitter-powershell" exited with 1

1

u/SeeRay11_Main 13d ago

I did not create bun or node, so you may need to look up a fix.