Repository navigation
OpenCode 2 plugin API compatibility #31
Description
What problem are you trying to solve?
The current plugin uses OpenCode 1’s plugin API, including @opencode-ai/plugin, the V1-style plugin function export, and config/event hooks. OpenCode 2 introduced a breaking plugin API, so the plugin does not load or function correctly in OpenCode 2 even when the configuration is updated from plugin to plugins.
This prevents OpenCode 2 users from using the plugin’s LiteLLM model discovery, metadata enrichment, authentication, filtering, and caching features.
Proposed solution
Port the plugin to the OpenCode 2 plugin API while preserving its existing functionality.
The implementation should use OpenCode 2’s Plugin.define({ id, setup }) entry point, register LiteLLM providers and discovered models through ctx.provider.transform(), refresh them with ctx.provider.reload(), and replace the V1 event hook with ctx.event.subscribe().
The existing LiteLLM API, model formatting, filtering, capability overrides, authentication, pricing, reasoning variants, and cache utilities could be reused. Ideally, the package should support both OpenCode 1 and OpenCode 2 during a transition period; otherwise, the OpenCode 2 support could be released as a new major version with updated documentation and configuration examples.
Alternatives considered
None
Scope check
- My request is related to LiteLLM model discovery, configuration, or routing
Activity
MathisHammel commentedon Sep 23, 2026
Seconding this. As of today, OpenCode v2 is now the default version on the download page so this plugin is now incompatible with the official release.
yuseferi commentedon Sep 24, 2026
Sharing some empirical runtime findings that bear on this issue (and on #32), from probe plugins run under
opencode models --print-logs --log-level DEBUGandopencode debug v2on two real runtimes.Loader contract (verified):
1.18.31and the newestdevbuild (0.0.0-dev-202609221946) both use the V1 loader only. A plugin loads when its default export is an object with aserver()method, or when it exposes a named function export.{ id, setup }with noserver()is rejected outright withmust default export an object with server().setupis never invoked andcatalog.transformnever fires on either runtime —opencode debug v2shows the V2 catalog present but empty (providers: []).Implication for the "support both during a transition" question:
It's feasible in a single release, and the way to do it is a hybrid default export — one object carrying both a V1
server()and the V2Plugin.define({ id, setup })shape. The loader callsserver()today; the V2setupstays inert and activates automatically if/when upstream wires the V2 loader. No major-version split is required just to keep V1 working.On the API surface: the older
@opencode-ai/plugin/v2/promiseCatalogDraftonly exposesupdate/remove(no modeladd) and itssetupisn't called by any shipping runtime, so it can't implement thectx.provider.transform()+ newly-registered-models design described above.@opencode/plugin@2.x(the surface #32 targets) does haveprovider.transform,editor.add, andevent.subscribe, so that's the correct package for the design this issue asks for.PR #32's default export (
{ ...Plugin.define(...), async server(input) { return LiteLLMPlugin(input) } }) matches the verified loader contract: it loads today viaserver()and carries the V2 path forward. Details in my comment there.yuseferi commentedon Sep 29, 2026
Resolved by #32, merged on 2026-09-29. The plugin now supports OpenCode V2 natively while preserving the OpenCode 1.18.29+ server entrypoint. Closing this issue.
mrivnak1 commentedon Sep 29, 2026
opencode-litellm/README.md
Line 61 in 3ef76d0
Why is it not published in the NPM package? In that case can you say v2 is actually supported?
yuseferi commentedon Sep 29, 2026
@mrivnak1
https://github.com/yuseferi/opencode-litellm/releases :)
https://www.npmjs.com/package/opencode-plugin-litellm
it is