opencode-auth-load-balancer 0.6.0 → 0.7.1

package/README.md

@@ -27,18 +27,70 @@ Selection is **not** round-robin. It is weighted primarily by **weekly** usage,
 - [Bun](https://bun.com) ≥ 1.3
 - opencode (TUI), with the Anthropic, OpenAI, and/or Kimi For Coding providers available
 
+### OpenCode 2 compatibility
+
+The main entry targets **OpenCode 2.x**, verified against **2.0.27**. OpenCode 2
+uses a default `setup` entry, integration authentication methods, and domain
+transforms instead of the V1 `auth.loader` and `chat.headers` hooks.
+The existing account pool, scheduling, token refresh, fallback and durable
+pending files are reused; accounts do not need to be registered again.
+
+Configure the **package directory** in `opencode.json` after building:
+
+```jsonc
+{
+  "$schema": "https://opencode.ai/config.json",
+  "plugins": ["C:/path/to/opencode-auth-load-balancer"]
+}
+```
+
+For a published npm release, use `"plugins": ["opencode-auth-load-balancer"]`.
+The package's `./tui` entry loads the V2 footer and sidebar automatically.
+A remote terminal can also load it through `cli.json`'s `plugins` list. Status,
+notifications and account management use server RPC, so the terminal never
+needs access to the server's credential files.
+
+Remove the previous V1 server entry and separately registered V1 TUI entry when
+switching to V2. Its configuration key is `plugins` (plural); V1's `plugin`
+entry and `tui.json` extension use different host APIs. Explicit local V2 entries
+must point to a directory, not a copied `dist/index.js` file.
+
+V2 keeps HTTP transport for pooled providers, including Codex's Responses API,
+so requests pass through account rotation and usage tracking. Providers without
+a pooled account keep their normal native driver. V2 can resume an unfinished
+pending turn by its original durable prompt ID after a restart.
+
+For **OpenCode 1.x**, use `dist/v1.js` as the local server plugin and the existing
+`tui/auth-load-balancer-tui.ts` entry in `tui.json`. The instructions below about
+copying a standalone bundle and registering TUI files describe this V1 setup.
+The V2 sidebar supports rename, enable/disable, delete, and re-login/pairing;
+the existing Gist sync engine runs on the server, but its V1 sidebar controls
+have not yet been ported to the V2 UI.
+
+Verification:
+
+```bash
+bun run typecheck
+bun test
+bun run build
+bun run scripts/smoke-v2.ts  # isolated home/config/database/pool, requires opencode 2
+bun run scripts/smoke-v2.ts . --inference  # real host, local mock Anthropic, revoked-token rotation
+bun run scripts/smoke-v2.ts . --live  # real Anthropic request using the existing pool
+```
+
 ---
 
 ## Install & build
 
 ```bash
 bun install
-bun run build      # → dist/index.js (a single self-contained file)
+bun run build      # V2: dist/index.js; V1: dist/v1.js
 ```
 
-The bundle imports only Node built-ins, so it can be dropped into opencode as one file.
+The V1 bundle imports only Node built-ins and can be installed as one file.
+OpenCode 2 should load the package directory, which also includes its TUI entry.
 
-### Load it into opencode (local / dev)
+### Load it into OpenCode 1 (local / dev)
 
 opencode auto-loads any `.ts`/`.js` file in a **plugins directory**:
 
@@ -50,13 +102,13 @@ Copy or symlink the built bundle into your opencode project's plugin dir:
 ```bash
 # macOS / Linux — symlink so rebuilds are picked up automatically
 mkdir -p .opencode/plugins
-ln -sf "$(pwd)/dist/index.js" .opencode/plugins/auth-load-balancer.js
+ln -sf "$(pwd)/dist/v1.js" .opencode/plugins/auth-load-balancer.js
 ```
 
 ```powershell
 # Windows (PowerShell) — copy (symlinks need Developer Mode / admin)
 New-Item -ItemType Directory -Force -Path .opencode\plugins | Out-Null
-Copy-Item dist\index.js .opencode\plugins\auth-load-balancer.js
+Copy-Item dist\v1.js .opencode\plugins\auth-load-balancer.js
 ```
 
 Restart opencode to load it. (opencode does **not** hot-reload plugins — see the dev loop below.)
@@ -67,7 +119,7 @@ Restart opencode to load it. (opencode does **not** hot-reload plugins — see t
 // opencode.json
 {
   "$schema": "https://opencode.ai/config.json",
-  "plugin": ["opencode-auth-load-balancer"]
+  "plugins": ["opencode-auth-load-balancer"]
 }
 ```
 
@@ -266,7 +318,7 @@ Then register the entry in `~/.config/opencode/tui.json` (this is how opencode l
 }
 ```
 
-> **Why this shape (it matters):** TUI plugins load from the `plugin` array in `tui.json`, **not** from the server's plugins-dir glob. The server *separately* globs `{plugin,plugins}/*.{ts,js}` and loads every match as a **server** plugin — so a TUI entry dropped in `plugins/` is also loaded by the server, rejected (`must default export … server()`), and logs an error on **every** launch (and a stray scoring `.ts` there would be mis-loaded as a plugin and break provider resolution). Keeping the four files OUTSIDE `plugins/` and registering only via `tui.json` avoids that. The split into a `.ts` **entry** that **lazily imports** a `.tsx` **view** is still required because opencode's runtime SolidJS JSX transform (`@opentui/solid`) only matches `*.{tsx,jsx}` — a `.ts` cannot itself contain JSX, and the lazy import keeps the server plugin worker (which never runs `tui()`) from evaluating the SolidJS module graph. Developed against opencode / `@opencode-ai/plugin` `>=1.18.26` + `@opentui/solid` `0.5.10` (the versions currently pinned in `package.json`). The `.tsx` view **is** typechecked (`tsconfig.tui.json`) and linted here — its JSX deps (`solid-js` + `@opentui/*`) are installed as devDependencies pinned to those versions — so type/import/prop breaks are caught in CI; only its runtime rendering still needs a live opencode TUI to verify. The toast + `auth_lb_status` tool + `bun run status` CLI cover the same information regardless. (`auth-load-balancer-tui.logic.ts` has no JSX and no TUI-runtime dependency, so it is directly unit-tested rather than only typechecked.)
+> **Why this shape (it matters):** TUI plugins load from the `plugin` array in `tui.json`, **not** from the server's plugins-dir glob. The server *separately* globs `{plugin,plugins}/*.{ts,js}` and loads every match as a **server** plugin — so a TUI entry dropped in `plugins/` is also loaded by the server, rejected (`must default export … server()`), and logs an error on **every** launch (and a stray scoring `.ts` there would be mis-loaded as a plugin and break provider resolution). Keeping the four files OUTSIDE `plugins/` and registering only via `tui.json` avoids that. The split into a `.ts` **entry** that **lazily imports** a `.tsx` **view** is still required because opencode's runtime SolidJS JSX transform (`@opentui/solid`) only matches `*.{tsx,jsx}` — a `.ts` cannot itself contain JSX, and the lazy import keeps the server plugin worker (which never runs `tui()`) from evaluating the SolidJS module graph. Developed against opencode / `@opencode-ai/plugin` `>=1.18.26` + `@opentui/solid` `0.5.10` originally; development dependencies now use `0.5.17` for V2 compatibility. The `.tsx` view **is** typechecked (`tsconfig.tui.json`) and linted here — its JSX deps (`solid-js` + `@opentui/*`) are installed as devDependencies pinned to those versions — so type/import/prop breaks are caught in CI; only its runtime rendering still needs a live opencode TUI to verify. The toast + `auth_lb_status` tool + `bun run status` CLI cover the same information regardless. (`auth-load-balancer-tui.logic.ts` has no JSX and no TUI-runtime dependency, so it is directly unit-tested rather than only typechecked.)
 
 ---
 
@@ -359,8 +411,8 @@ The unit/integration suite runs with coverage **gated at 100%** (lines and funct
 
 opencode loads plugins once at startup, so the loop is:
 
-1. `bun run dev` — keeps `dist/index.js` rebuilt on every edit.
-2. Symlink `dist/index.js` into your opencode project's `.opencode/plugins/` once (see install above).
+1. `bun run dev` — keeps both server entry points rebuilt on every edit.
+2. For V2, register the package directory in `opencode.json` using `plugins`. For V1, symlink `dist/v1.js` into `.opencode/plugins/` (see install above).
 3. Edit code → the watcher rebuilds → **restart opencode** to reload the plugin.
 4. Use it; watch the toasts, run `bun run status`, and set `OPENCODE_AUTH_LB_DEBUG=1` to log selections.
 

package/dist/index.d.ts

@@ -1,12 +1,7 @@
-import type { Plugin } from '@opencode-ai/plugin';
-export declare const AnthropicLoadBalancerPlugin: Plugin;
-export declare const OpenAILoadBalancerPlugin: Plugin;
-export declare const KimiCodeLoadBalancerPlugin: Plugin;
-export declare const KimiCodeGlobalLoadBalancerPlugin: Plugin;
-/**
- * A standalone plugin that registers the `auth_lb_status` tool — an on-demand
- * dashboard (in-use account per provider, each account's weekly/5h usage,
- * cooldowns, and the ranked next candidates) across ALL providers. Registered once
- * (not per provider) so the tool name doesn't collide.
- */
-export declare const AuthLoadBalancerStatusPlugin: Plugin;
+import type { Plugin } from '@opencode/plugin';
+export { AnthropicLoadBalancerPlugin, AuthLoadBalancerStatusPlugin, KimiCodeGlobalLoadBalancerPlugin, KimiCodeLoadBalancerPlugin, OpenAILoadBalancerPlugin, } from './legacy';
+declare const _default: {
+    id: string;
+    setup(ctx: Plugin.Context): Promise<Plugin.Cleanup>;
+};
+export default _default;