opencode: would you welcome support for opencode sessions?

[abourget]

I'm also interested in such a tool to abstract away different coding agents, and also an internal framework we have.. could ccx be made (or perhaps it is already) to allow pluggable providers ?

[lroolle]

Yes to both, and sorry for the slow reply.

Providers are already an interface — provider.Backend in internal/provider, seven methods, with claude/, codex/ and grok/ behind it and a Multi that fans out. What it is not yet is loadable at runtime: the registry is a compile-time list in provider.Default(), so today a new provider means a package plus a few lines there.

opencode is explicitly on the list — see docs/design/0004-transcript-adapter-contract.md. The blocker is that parser.Session is still Claude-shaped and doubles as the renderer contract, so a fourth provider today would bend to Claude's tree rather than declare its own topology. That design lands the neutral Transcript/Topology/Capabilities/Diagnostics layer first, then adapters one at a time.

If you want to help, the useful thing is a spike, not a parser: what opencode actually writes on disk, which file is authoritative for conversation vs. tool lifecycle, and whether it reports tokens and cost at all. That is step 5 in the doc and it is the part that needs someone with real sessions.

On your internal framework — happy to hear what its artifacts look like. If it fits the same contract that is a good argument for making the registry pluggable rather than compiled in.