Provider instances as first-class citizens: per-instance branding, an OpenAI-compatible driver, and a way to extend the server without breaking code signing

[AWD-tech]

These came out of a few days of running T3 Code with a mix of hosted and local models. They're related, so I'm putting them in one discussion rather than five — happy to split if you'd rather.

Context for all of it: I use a Claude instance, an OpenRouter instance, and local models. OpenRouter isn't a driver, so it's configured as a custom instance of the opencode driver, reaching OpenRouter through OpenCode as an upstream.

---

1. Per-instance icons / branding

A custom provider instance can set displayName and accentColor, and gets initials on a badge — but the logo is resolved purely from the driver:

n = iconMap[driverKind] ?? null

So my OpenRouter instance renders the OpenCode logo with an "OP" initials badge. Functionally fine, visually confusing: in the model picker every row reads "OpenCode · openrouter" or "OpenCode · opencode" with the same mark, and the only way to tell them apart at a glance is the two-letter badge.

Suggestion: let an instance supply its own icon (bundled asset key, or a user-provided file/URL), falling back to the driver icon. The accent colour plumbing already exists, so this seems like the natural completion of it.

2. A generic OpenAI-compatible driver

Right now anything that isn't Codex / Claude / Cursor / Grok / OpenCode has to be tunnelled through OpenCode. That works, but it means the provider list, health checks, versions, and the model picker all describe the tunnel rather than the thing I actually chose.

This got more noticeable when the ollama and llamacpp drivers disappeared — my existing instances now sit in Settings reading:

Disabled — Driver 'ollama' is not registered in this build.

I assume that removal was deliberate (OpenCode can reach local models). But the net effect is that local models and OpenRouter are both second-class now. A single generic OpenAI-compatible driver — base URL, API key, model list — would cover Ollama, llama.cpp, LM Studio, vLLM, OpenRouter, and most self-hosted gateways, without adding a bespoke driver per vendor.

3. Graceful handling of instances whose driver no longer exists

Related to the above: when a driver is removed, existing instances just sit disabled with the message above and no next step. Something like "this driver was removed in vX — migrate to «generic» / remove this instance" would turn a dead end into a one-click fix. The contracts layer already preserves unknown-driver envelopes verbatim, so the data is there to act on.

4. An extension point that doesn't require modifying the app bundle

This is the one I'd most like you to think about, and the motivation is concrete.

I wanted two behaviours the app doesn't have (switching provider mid-thread with the conversation carried over, and an interrupt that can't strand a thread). The only way to get them was to edit the packaged bundle — patch bin.mjs, rewrite the asar header integrity, update ElectronAsarIntegrity in Info.plist, and re-sign.

That works, but re-signing has real consequences:

• The original build ships com.apple.developer.associated-domains = webcredentials:clerk.t3.codes plus a team identifier. Any re-sign under a different identity loses the domain association, so Clerk passkey sign-in stops working (passkey_retrieval_failed — "the calling process does not have an application identifier"). Signing ad-hoc drops the entitlements entirely; re-applying the original entitlements under another team makes macOS refuse to launch the app at all.
• Squirrel requires a matching signing identity to install an update, so a modified build can't auto-update to official releases — it has to be reinstalled from the DMG and re-patched every time.

In other words, the current design makes "extend it locally" and "stay updated + stay signed in" mutually exclusive.

A supported extension point would remove that cliff entirely. Rough shapes, in increasing order of ambition:

• Server middleware/hooks loaded from ~/.t3/extensions — enough to wrap orchestration events (turn start, interrupt, session start) without touching the bundle.
• Driver plugins — register a driver from outside the app, which would also make Add open-in-editor feature with Cmd+O shortcut #2 unnecessary for exotic backends.
• A settings-level scripting hook for narrow cases (prompt pre-processing, transcript injection).

Even the first one would have covered everything I needed.

5. Ship the update feed in every distributed build

Minor, but it cost me five weeks. I was running a build whose Contents/Resources/app-update.yml was missing, so electron-updater reported "Automatic updates are not available because no update feed is configured" and silently never checked — it sat ~600 commits behind until I went looking. The current nightly DMG does ship app-update.yml, so this may already be fixed, or that bundle may have been repackaged before it reached me.

Two small things that would have surfaced it either way: show the updater's disabled reason somewhere in Settings instead of only in logs, and treat "no feed configured" in a packaged build as a visible warning rather than a silent no-op.

---

Environment: macOS arm64, v0.0.34-nightly.20260817.1120, providers: Claude (native), OpenRouter + OpenCode (both opencode driver), local Ollama.

I know contributions are effectively closed right now — none of this is a PR request, just things I ran into that seemed worth writing down.

[krutftw]

+1 on §1 (per-instance icons) with a second concrete case, this time on the Claude driver.

Setup: Kimi Code subscription wired in as a second claudeAgent instance (displayName: "Kimi", accentColor, homePath: ~/.claude-kimi, ANTHROPIC_BASE_URL=https://api.kimi.com/coding/, custom models k3-256k, k3[1m], kimi-for-coding, …). Works great — but in the model-picker rail and the provider list it renders as the Claude glyph with an 8 px "KI" badge, and because there are now two instances of that driver the default Claude instance also grows a "CL" badge. Two near-identical orange marks; the only disambiguation is hover → "Kimi". Same iconMap[driverKind] root cause you quote, just a different driver.

Small additions to the proposal, in case it helps shape it:

• A bundled brand set keyed by a new optional ProviderInstanceConfig.icon (e.g. "kimi" | "moonshot" | "glm" | "deepseek" | "openrouter" | "ollama" | …) would cover the common "known vendor behind a generic driver" cases without any file-upload plumbing; the accent colour + initials badge can stay as the fallback for unknown vendors.
• The badge logic could skip the badge on the default instance when only one other instance of the driver exists and that other one has its own icon — right now the default Claude instance looks "modified" the moment a second instance is added.
• For Kimi specifically the other path is the native Kimi Code CLI driver in feat(server): add Kimi Code CLI provider over ACP #5243 (open since Aug 2), which would bring its own icon; until something lands, the instance is visually a second Claude.

Build: 0.0.34-nightly.20260819.1132 on Windows 11.

_{Authorship disclosure: written by Claude (Fable 5) in Claude Code on the user's machine, at the user's request.}