feat(server): broker voice through Console credentials - #57576

Issue for this PR

Feature/design draft for Kit and Adam’s October 21 discussion. Stacked on #57194 (voice-models); intended eventual base is dev.

Type of change

• New feature

What does this PR do?

Phone users have to sign into Console twice today, once on their computer and again on their phone. This implements option B: the paired phone asks its server to create a GPT-Live session using the server’s selected Console connection and workspace.

sequenceDiagram
    participant P as Paired iPhone
    participant S as OpenCode server
    participant C as Console
    participant O as OpenAI
    P->>S: SDP offer
    S->>C: Create with stored credential and workspace
    C->>O: Create session and attach metering sideband
    C-->>S: Session ID and SDP answer
    S-->>P: Call reference and SDP answer
    P<<->>O: Direct WebRTC audio
    P->>S: Instructions for owned call
    S->>C: Forward as original account and workspace
    C->>O: Update instructions over sideband

The server proxies setup and instruction updates only. The Console credential stays on the server, and audio goes directly from the phone to OpenAI.

• Route resolution uses a provider key first, then Console for GPT-Live. experimental.voice.route can explicitly select console or key. Failed requests and explicit choices never fall back to another payer.
• Discovery returns the route, workspace name/ID and an unavailable reason. Clients can send that route back to pin the payer. Setup preserves Console’s session ID as data.call.id; control uses POST /api/experimental/voice/session/:id/instructions.
• Both operations reuse the integration’s refresh logic. Control resolves the original stored connection and rejects account, workspace or Console-address changes.
• Voice requires a pairing token. New pairings get distinct nonces, so two phones paired in the same second have different identities. Older pairings must pair again for voice; their tokens still work on other routes.
• Ownership survives location reloads and is held in a process-wide, 1,000-entry cache for up to 24 hours. Restarting the server requires a new call.

Discovery currently reports credential availability. Console still checks voice entitlement, models, budgets and funding at setup. The iOS hookup and a real billed-call check are follow-up work.

Questions for Adam

1. Can we agree on B’s SDP broker for release, with phone OAuth as an explicit alternative?
2. Which Console capability/config field should advertise voice entitlement before a call? The current server list only checks keys.
3. Does pairing authorize spend as the computer’s Console user, including shared servers? Use the selected connection’s workspace and never silently switch billing accounts.
4. Is fix(tui): Prompt from stdin breaks TUI #3930 deployed and verified with real OpenAI, including policy-driven shutdown and sideband reconnection?

How did you verify your code works?

14 targeted tests passed:

• Core voice.test.ts and voice-refresh.test.ts (9): key/Console/unavailable precedence, explicit route selection, refresh through the real Console integration, SDP and instruction forwarding, ownership, workspace/account changes, location rebuilds, expiry, WebSocket refusal and no payer fallback. Console HTTP calls are mocked.
• Server voice.test.ts and auth.test.ts (4): HTTP routing, pairing enforcement even with general auth disabled, cross-pair control rejection, cookie origin checks, token uniqueness, tampering, expiry and revocation.
• Server process.test.ts, filtered to “pairing links” (1): browser and API pairing still work.

bun run generate completed in packages/client. Core, server and client typechecks passed. The required root bun run check passed through HiveMind (with existing lint warnings). No full test suite or paid session was run.

Screenshots / recordings

Server/API change; no UI.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR