Supported models

Each provider entry tells Lantern which local adapter to start when an approved app requests AI. Setup creates entries for the models the user selects.

How setup finds models

The Mac app bundles Lantern's native Apple model helper. Setup offers it only when Apple's system model reports that the device is eligible, Apple Intelligence is enabled, and the model is ready. Setup also checks normal shell commands and common install locations for Codex and Claude.

When Lantern starts later, it probes the selected adapters again. An unavailable model remains visible in status but cannot receive requests.

Apple Intelligence Apple Intelligence

Lantern's arm64 Swift helper uses Apple's Foundation Models framework and the system SystemLanguageModel. It requires macOS 26, Apple silicon, and Apple Intelligence enabled in System Settings.

One Lantern session owns one native LanguageModelSession, so lower-level WebSocket conversations retain context across follow-up prompts and tool calls. The helper converts app JSON Schemas into Foundation Models Tool definitions, waits for the app's result, and resumes the same response. It has no filesystem access or image generation.

Model inference and conversation state stay on the Mac. Requests from a website still travel through that website, its server, and Lantern's relay before reaching the Mac. Direct local API calls do not need the relay.

"apple": {
  "adapter": "apple-foundation-models",
  "label": "Apple Intelligence"
}

Codex Codex App Server

Guided setup uses Codex App Server. It streams replies as they arrive and can keep a conversation open. Lantern supervises one codex app-server --stdio process per configured provider and talks to it over JSON-RPC through the process's standard input and output.

Each Lantern conversation owns a separate logical Codex thread. Lantern routes notifications, tool calls, usage, cancellation, and completion by App Server's thread and turn identities, so independent requests can run concurrently without spawning one server process per request.

• Streams text as Codex produces it, plus events when each item — a single step, such as a command run or a file edit — starts and finishes, and when a turn (one prompt and the full response to it) starts and completes.
• Runs in a new empty temporary directory using Codex's read-only sandbox. Lantern removes the directory after the session closes.
• Runs text turns with approvalPolicy: "never" inside Codex's read-only sandbox.
• Passes app-defined function schemas through App Server's native dynamicTools API and resumes the same turn after each result.
• Cancels a running turn with turn/interrupt, unsubscribes a thread when its session closes, and shuts down the shared process when Lantern stops.

Codex exec adapter

This is a manual configuration alternative; Lantern does not switch to it automatically. It runs codex exec --json, then continues the conversation with codex exec resume <thread-id> on later prompts. It reports fewer intermediate events than App Server, while keeping the same Lantern event format.

"codex-cli": {
  "adapter": "codex-cli",
  "label": "Codex exec"
}

Claude Claude CLI

Lantern runs claude -p --output-format stream-json, which prints Claude's progress as one JSON object per line. It captures the session ID from the first response and passes it back with --resume on later prompts.

safeMode defaults to true and adds --safe-mode for ordinary text requests. When an app supplies tools, Lantern starts a private MCP server for exactly those schemas, restricts Claude's tool allowlist, waits for the app's results, and closes the bridge with the session. The process starts in a fresh temporary directory that Lantern removes afterward.

"claude": {
  "adapter": "claude-cli",
  "safeMode": true,
  "tools": []
}

Add an adapter

The adapter contract lives in src/providers/contract.ts. An adapter provides:

• probe to check whether its model or CLI is available.
• open to start a session with prompt, optional submitToolResults, cancel, and close.
• Optional adapter-level close cleanup for provider-owned shared resources.
• Turn, output, tool-call, item, and error events in Lantern's shared format. The original CLI payload stays under raw.