System Architecture

A high-level view of Arbiter request distribution, API routing, and backend telemetry.

Arbiter runs entirely as a serverless Next.js 16 application. There are no persistent background daemons orchestrating streams; instead, Next.js dynamic Edge/API routes handle client fetch requests, decrypt keys on the fly, trigger concurrent vendor requests, stream response deltas back to the client using Server-Sent Events (SSE), and write transactions to a Postgres database.

Request Flow Lifecycle

The flowchart below illustrates the request-response lifecycle from the client UI down to the vendor models and back. Notice that user API keys are retrieved from the database, decrypted in memory using AES-GCM, and immediately piped into outbound streams, preventing plain-text leakage.

Client UIapp/page.tsxAPI Endpoint/api/chats/[id]/msgOrchestratorrunPipeline.tsDatabase (Pg)Drizzle ORMLLM API GatewaysOpenAI, Claude...HTTP POSTKeys & LogsSSE Stream deltas
↔ Swipe horizontally to view full execution flow

Interactive Architecture Explorer

Click on any module in the live node-graph below to inspect implemented mechanics and target codebase files.

🏗️ Interactive System Architecture Explorer

Select any block in the pipeline to inspect directories, files, and underlying execution mechanics.

🌐

Client UI & Stream Orchestration

Frontend Subsystem
app/page.tsxlib/client/authFetch.ts

The client-side single page app. It manages chat histories, provider/model selection state, and coordinates with credentials configurations. When a query is submitted, it opens a connection and parses SSE events in real-time.

Execution Mechanics
  • Uses custom consumeOrchestratorStream to parse SSE data stream buffers.
  • Handles local guest sessions using sessionStorage (discarded on tab close).
  • Performs transparent OAuth session token refresh via authFetch wrapper when a 401 Unauthorized error is caught.