feat(tui): migrate quota sidebar and commands to TUI V2

[dmmop]

Summary

• Migrate the TUI integration to the OpenCode V2 plugin API.
• Add a quota sidebar with collapsible provider details and active-provider count.
• Register local /quota and token-usage slash commands.
• BREAKING CHANGE: OpenCode's SQLite credential database replaced auth.json as credential source.

Testing

• pnpm run typecheck
• pnpm exec vitest run tests/tui-v2-commands.test.ts
• git diff --check 87e6540...HEAD
• manually verified /quota in the OpenCode V2 TUI

[slkiser]

@dmmop Thanks for the PR, code looks good.

I believe OpenCode v2 is still in beta, so I'd hold off on releasing this on main for now.

If there is support for v2 or when v2 is out of beta I'll definitely return to the PR.

[dmmop]

@slkiser Thanks you for this plugin!

Yes, v2 is still in beta, thats why "opencode-next.db" is hardcoded in the code.

I adapted the plugin to suit my needs in v2, i'll keep this PR update if they introduce any breaking change.

[rektide]

this has been great to have, thank you!

[ransagy]

Tested locally on Windows with opencode2 (beta-17728), at head 2143358, loaded as a TUI plugin via cli.json. The sidebar and the /quota + /tokens_* commands work. A few things I ran into, possibly expected/how it works now but not to my untrained TUI eyes:

1. To test the built artifact I had to manually compile tui-v2.tsx → tui-v2.js first — the build emits tui-v2.jsx (jsx: preserve) while dist/index.js imports ./tui-v2.js, so the packaged output can't resolve it. (Related: tests/tui-v2-commands.test.ts also doesn't run on a clean checkout — vite chokes on the raw JSX — so I ran it against the compiled version.). Maybe something the release/CI usually does, not sure.

2. Two of the new toast triggers don't fire in the V2 event schema:

   • session.compacted doesn't exist in V2 (compaction events are session.compaction.*).
   • session.tool.success has no tool field on data (neither does session.tool.called); only session.tool.input.started carries data.name, so the data?.tool === "question" check never matches. Probably opencode changing the schema as they go along, there were a few beta releases this week already.

One more thing — right now this won't load on V1 anymore, because index.ts no longer exports the V1 { id, server } module. Probably intentional. but worth checking if you intend to support both.

Let me know if I can help test anything further :)

[dmmop]

Thanks for the thorough report and for testing it, @ransagy! The packaging, clean-checkout test, and V2 event trigger issues are now fixed.

As for V1 support, I wasn’t planning to support both versions. I adapted the project to my own needs and shared it in case it was useful to @slkiser.

[gdevenyi]

Confirmed on a newer beta build. Additional diagnostics for the V2 port (cc #229).

Environment

• OpenCode 2 TUI and server: opencode2 v0.0.0-beta-18314 (beta dist-tag)
• opencode-quota: 4.8.2 (current latest, installed as @slkiser/opencode-quota@latest)

Observed failure

• TUI /plugins report: @slkiser/opencode-quota@latest → status failed, runtime tui, error Invalid V2 TUI plugin module: @slkiser/opencode-quota@latest.
• Server side (~/.local/share/opencode/log/opencode.log, role=server), from the same plugin listed in the V1 plugin array of global opencode.json:

level=WARN message="failed to load plugin" target=@slkiser/opencode-quota@latest cause="Cause([Fail(SchemaError(Missing key
  at [\"default\"][\"effect\"]
Missing key
  at [\"default\"][\"setup\"]))])"

Both entry points reject the module. The server loader expects effect and setup on the default export. The TUI loader expects id plus setup.

Root cause in the 4.8.2 dist

• dist/index.js default export: { id: "@slkiser/opencode-quota", server: QuotaToastPlugin }. This is the V1 shape.
• dist/tui.js default export: { id, tui }. This is the V1 TuiPluginModule shape from @opencode-ai/plugin/tui 1.x.
• TUI loader validation in this beta build, extracted from the opencode2 binary:

// Module is valid only when the default export has id: string (non-empty) and setup: function
(mod) =>
  typeof mod === "object" && mod !== null &&
  "id" in mod && typeof mod.id === "string" && mod.id.length > 0 &&
  "setup" in mod && typeof mod.setup === "function"
// On failure it throws: `Invalid V2 TUI plugin module: ${spec}`

• Build dependency is @opencode-ai/plugin 1.18.11 (peer ^1.4.3). The published dist therefore still compiles against the V1 API. The V2 API is published under the beta dist-tag of @opencode-ai/plugin (0.0.0-beta-18314 today), with Plugin.define available from @opencode-ai/plugin/tui.

Target shape (per current V2 plugin docs)

import { Plugin } from "@opencode-ai/plugin/tui"

export default Plugin.define({
  id: "@slkiser/opencode-quota",
  async setup(context) {
    // context.ui.slot(...), context.keymap.layer(...), context.data.*, context.ui.toast.show(...)
    return () => {
      /* cleanup */
    }
  },
})

Also required:

• Main server plugin sets tui: true, so the ./tui export loads automatically.
• package.json uses "@opencode-ai/plugin": "beta" and peer deps @opentui/core, @opentui/solid, solid-js.

Notes for the install and setup path

• V2 still reads the V1 plugin array in opencode.json (compatibility path), then fails module validation as shown above.
• V1 layered tui.json no longer applies. V2 uses one global cli.json with a plugins array. A migrated setup carries the spec into cli.json plugins; this is what triggers the TUI-side error above.

I can test a prerelease build against beta-18314 if that helps.

[christian-taillon]

I've been testing this against opencode2 v0.0.0-beta-18314 and built a follow-on from the current #196 head.

I now have the V2 TUI working on the current { id, setup } loader, including the sidebar and /quota, and added support for multiple native OpenAI connections. I've tested two simultaneous OAuth accounts (Plus + Business); they remain separate and each exposes its Five-hour and Weekly quota windows.

I also fixed two issues encountered while testing:

• tuiSidebarPanel.formatStyle: "allWindows" was being applied after single-window projection, so the sidebar lost the additional quota windows.
• CLI status could OOM on a large OpenCode database because usage aggregation materialized full message.data JSON payloads. It now queries only the scalar fields required for usage accounting.

Validated on beta-18314:

• OpenCode sidebar: Plus + Business, Five-hour + Weekly
• /quota and /quota_status
• /tokens_all
• packed CLI show and status
• typecheck/build
• full suite: 2,218 tests passing

Follow-on branch: https://github.com/christian-taillon/opencode-quota/tree/v2-native-multi-connection-quota
Commit: 046b4d25a3418c21a0bf6278b32faa196b1cd8d4

This is based on #196 rather than upstream main, so I don't want to create a competing V2 PR. Happy to open a follow-up PR against dmmop/opencode-quota-v2:main if that would be useful.

[dmmop]

This is based on #196 rather than upstream main, so I don't want to create a competing V2 PR. Happy to open a follow-up PR against dmmop/opencode-quota-v2:main if that would be useful.

Thanks, that would be very useful!

I’ve just pushed my own implementation of native multi-connection quota support. It covers the credential-backed providers rather than only OpenAI, and I’m currently testing it.

After reviewing your changes, I noticed that your branch also fixes two separate issues that my implementation does not currently cover:

• The sidebar-specific allWindows format needs to be applied before quota projection; otherwise a global singleWindow setting discards the additional windows too early.
• CLI status can consume excessive memory on large OpenCode databases because it materializes the complete message.data payload instead of selecting only the scalar fields required for usage accounting.

I’d be very happy for you to open a follow-up PR against dmmop/opencode-quota-v2:main. If possible, please rebase it onto the latest main and keep the non-overlapping fixes isolated so they are easier to review. I’ll gladly review and merge it.

I’d also appreciate it if you could review my latest push and share any feedback on the multi-provider implementation.

[rektide]

i've been integrating both dmmop-v2 and upstream for a bit now into my own copy, to run in v2. i humbly submit my own fork that i intend to keep juggling for the foreseeable. it's definitely not as well maintained, caveat emptor, but also, i am excited to share and expect to keep updating for the foreseeable. https://github.com/rektide/opencode-quota-plus/

i also have some features like pro rata #252 that are very helpful to me, and multiple different view formats, which i haven't really been using heavily tbh. i'm making stronger use of the opencode v2 view slots that opencode has been evolving. i used to juggle v1+v2 support but dropped that (v2 is so much better, switch switch switch!).

this plugin is the #1 must have opencode addition to me, and i'm so thankful for all the work folks have put in, and look forward to ongoingly contributing upstream here too. 🙇

[ransagy]

Tested the current head on opencode2 v0.0.0-beta-19296 (Windows) — worked great, except OpenCode Go shows up twice (two 5h + two weekly groups) when both Go and Zen are signed in with the same workspace key.

Cause: the Go fan-out runs one query per row matching ["opencode-go", "opencode"], but opencode is a legacy alias of the Go integration, not a separate connection — so the Zen row gets counted as a second Go connection. The credential data is fine (one row per integration).

Pushed a fix + follow-up PR against this branch: prefer native opencode-go rows, fall back to opencode only when needed, and collapse rows with identical keys before fanning out. Happy to rework if you'd shape it differently 🙂

[christian-taillon]

My follow on branch still works well, but I don't want to maintain a fork for this.

I understand a v2 may not be accepted as the version is still in beta.

For anyone maintaining the PR, please add handling for the multiple accounts per provider (new OpenCode v2 feature). If it helps look as the diff in my previously mentioned branch.

This is an important feature to handle to avoid display bugs.

[dmmop]

@ransagy Thank you very much for the detailed report, the live Windows testing, and the focused follow-up PR with regression coverage. I had missed this issue in the multi-connection fan-out, and your diagnosis made it straightforward to understand and fix.

I reviewed and merged dmmop#1. Native opencode-go rows now take precedence, duplicate credentials are collapsed, and the legacy alias remains available as a fallback. I also reconciled the change with upstream’s new entitlement suppression so it operates independently for each connection.

Please feel free to open another PR if you find anything else—contributions like this are very welcome.

@christian-taillon Multi-account handling has already been implemented in this branch since commit 54d4ce3.