-
Notifications
You must be signed in to change notification settings - Fork 147
Use opencode headless #61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
i'd personally love to use this headless for a project i've considered, would think stdio isn't a rich enough API for what i'd want to do, but not sure what's best |
I also need to support events to make it work, so it might have to be sse |
Well we could also add websocket or a way to pull stuff... |
oooo I love this idea!!!! maybe seperate the transport and make it like lsp or how nvim remote plugins work? (So like json rpc api over whatever transport you want) eidt: or maybe just expose a go (or a c compatible) public api and let the consumer figure out how to use it?? |
Some more ideas
|
@radutopala thanks for the PR, I am thinking along the lines of stdio/see or some similar thing to LSP servers for json RPC events and messages. Basically since I build the architecture of opencode around services and events adding this layer should not be difficult, basically the RPC server would accept commands and relay that to the services just like the TUI does currently, and than on service events we would send events through that same RPC connection similar to LSP events... |
This way you can build a full on UI if you want ontop of opencode, even something like a neovim plugin or vscode extention |
I still think running with a one-off prompt is super useful as it allows you to create agentic workflows or scripts for repetative tasks. For example you could have a prompt like Update the version number in the following files
VERSION.md
version.go
... Then just have a script that calls |
Here is how Claude Code does it. Might be better to use a |
Make it possible for opencode to expose some kind of API e.x stdio or rest so you could build dedicated plugins for editors but still use opencode for all the LLM stuff.
The text was updated successfully, but these errors were encountered: