opencode: unpin v2 version

[lungsin]

Opencode v2 seems to have been released. The official docs from opencode.ai already direct the installation to use the v2. I assume the API has stabilized and it's safe to unpin the opencode beta (0.0.0-beta-18314, 0.0.0-beta-18866, 0.0.0-beta-19271) and support v2 properly.

[aentwist]

Assuming is dangerous. On npm, the latest tag still points to 1.x - it does not appear fully released, even if the CLI install points to v2.

meridian/package.json

Line 46 in 398006f

"@opencode-ai/plugin": "0.0.0-beta-18314",

What change is the goal exactly? I don't even see an issue tracking compatibility with OpenCode v2. Will it be drop in compatible?

[lungsin]

That's fair. Actually, I just realized that the releases from their github repo also doesn't have v2. I think we can wait until opencode has properly released v2.

What change is the goal exactly?

It's for the meridian setup stage meridian setup --v2 when setting up the opencode plugin. The meridian setup for opencode v1 doesn't work for v2 unfortunately. Currently the command for meridian setup --v2 doesn't run if not for a few pinned versions.

https://github.com/rynfar/meridian/blob/main/docs/agents.md#opencode-v2-beta

[OmerFarukOruc]

Reproduction on OpenCode 2.0.16 (released @opencode/cli, not the pinned betas)

Environment: OpenCode 2.0.16 (opencode --version → v2.0.16, official installer), Meridian 1.76.3, Linux, Node 22.23.1, Claude Max 20x account.

Using the released v2 client with Meridian hits three separate problems.

1. meridian setup --v2 fail-closes on 2.0.16 (by design)

classifyOpenCodeVersion maps 2.0.16 → generation v2, then rejects it because it is not in SUPPORTED_OPENCODE_V2_VERSIONS. Expected from the policy, but it means the released v2 line has no setup path.

2. On 2.0.16 the bundled V2 plugin fails to load

After locally adding 2.0.16 to the supported set and running meridian setup --v2, OpenCode logs:

failed to load plugin  plugin.id=meridian
cause="Cause([Die(TypeError: undefined is not an object (evaluating 'context3.catalog.transform'))])"

The plugin (dist/meridian-v2) uses these PluginContext members:

context.session.hook   context.session.get   context.session.context
context.catalog.transform   context.catalog.reload
context.agent.get   context.event.subscribe

So the 2.0.16 plugin context diverges from the beta context — at minimum catalog.transform is missing/different. This is the API break the pin is guarding against.

3. Even with the plugin not loaded, OpenCode requests return billing_error

A plain Anthropic request to Meridian succeeds:

curl -s http://127.0.0.1:3456/v1/messages \
  -H 'content-type: application/json' -H 'anthropic-version: 2023-06-01' \
  -d '{"model":"claude-haiku-4-5","max_tokens":32,"messages":[{"role":"user","content":"Reply PONG"}]}'
# => {"content":[{"type":"text","text":"PONG"}], "usage":{...}}

But the same Meridian instance returns this for an OpenCode 2.0.16 request:

event: error
data: {"type":"error","error":{"type":"billing_error","message":"Claude Max subscription issue. Check your subscription status at https://claude.ai/settings/subscription"}}

I captured the exact body OpenCode sends (logging relay in front of Meridian) and replayed the captured body directly at Meridian, with no OpenCode in the loop — it reproduces deterministically. Bisection of the payload:

• Failing request: claude-sonnet-5, stream:true, max_tokens:32000, 12 tools, 4 system blocks (block index 2 is ~10,357 chars: OpenCode's <env>, Code Mode instructions, tool schemas, skills list).
• Drop tools → still fails.
• Drop system → succeeds.
• Only block fix: add SSE heartbeat to prevent connection resets #2 → fails; only blocks #0/Connection reset by server #1/chore: add release-please and npm publish workflows #3 → succeed.
• Truncate block fix: add SSE heartbeat to prevent connection resets #2 to 200 chars → succeeds; 249 chars → fails. Content-sensitive, not raw length ('a' * 5000 succeeds).
• Independent of model (claude-sonnet-5, claude-opus-5, claude-haiku-4-5 all fail with the full block), thinking, streaming, the anthropic-beta: interleaved-thinking-2025-05-14 header, and MERIDIAN_1M_CONTEXT_SUPPORT=0.

Possibly related: because the plugin cannot load on 2.0.16, these requests carry only OpenCode's own headers (x-opencode-session, x-session-affinity, x-session-id) and Meridian logs:

[PROXY] ... OpenCode request without the Meridian plugin's agent headers (...)

Ask

Support the released 2.0.16 line: unpin 2.0.16 and port the V2 plugin to 2.0.16's PluginContext (catalog/agent/event domains in particular), then confirm the billing_error interaction is gone once the plugin loads. I'm happy to run the scripts/e2e-opencode-v2-package.mjs --live --extended gate against 2.0.16 if that helps move it forward.

[rynfar]

Update on the three OpenCode 2.0.16 findings: #1148, shipped in Meridian 1.76.5 and later, adds an exact-version setup path for 2.0.16 and ports the bundled V2 plugin to its host API. The reported context.catalog.transform load crash is gone in the qualified host flow. The real 2.0.16 client with the Meridian V2 plugin loaded passed the 15-request Sonnet 5 gate on macOS and from a Linux client. We have kept the gate exact-versioned because qualifying 2.0.16 does not establish compatibility with every future V2 host.

The third finding remains open. Your billing_error depends on the content of the captured system block; a different large block passing does not reproduce or fix it. The exact captured block is not available in this repository or our test artifacts. Since you already captured the request, a locally minimized and sanitized fragment that still fails with the same active negative control would let us test that claim without sharing a raw request, credentials, session IDs, or private skills. Please include whether the independently installed OpenCode scrub plugin was enabled and its version, since the billing path depends on that configuration. If sanitizing changes the outcome, that is useful evidence too, and we should keep the raw capture private rather than claim a fix.

I am leaving #1094 open for this content-specific verification.