GenerateSaaSModels
The desktop app's models are the user's own installed coding CLIs, connected through the companion daemon - no hosted model registry, no API-key management, no cloud provider catalog.
The desktop app has no hosted model registry and no BYOK provider catalog. Its models are the user's own installed coding CLIs - Claude Code, Codex, OpenCode - that the companion daemon has connected on their machine. The user's own subscription (the CLI's own login) pays the provider; the app never holds a key or a session.
The Models tab
The Models tab in Settings lists the coding CLIs the daemon reports as connected, each as a card, and offers one Default model - the model new chats start with. Everything is sourced from the on-device daemon, so the tab issues no network call of its own.
- Connected CLIs: one card per CLI the daemon has connected. A CLI is connected through the daemon, which detects it, installs it if needed, and signs it in under the user's own account; once connected it appears here.
- Default model: the model a new chat opens with. The choice is a picker preference, stored locally on this device (never on your backend); an open chat that has not been manually re-pointed follows a change to it, and the user can still switch models inside any chat.
- Models per CLI: each CLI offers the current models its provider serves (Claude Code offers Anthropic models, and so on), resolved by the daemon at runtime - the public models.dev catalog for Claude Code and Codex (cached for an hour, no account data sent), or the tool's own model enumeration for OpenCode. A small built-in catalog seeds the picker instantly and stands in when the machine is offline.
Subscription mode
A coding CLI runs under the user's own subscription - their existing claude / codex / opencode login, exactly as it works in a plain terminal. The app drives the CLI the user already pays for; it never reads or replays another app's credentials.
Subscription mode for some tools (for example Claude Code) is not permitted for distributed third-party products without the tool vendor's prior approval, and may put the end user's account at risk. You and your end users remain solely responsible for complying with each tool vendor's terms of service.
Which CLIs are drivable
The set of coding CLIs the app can drive is maintained in the companion daemon, not in the desktop app - so a CLI the daemon learns to drive becomes available to the app with no app change. See the companion's own documentation for the CLIs it supports and how it connects them.
AI agents
The desktop app turns the user's own coding CLIs into a workspace agent, driven by a local companion daemon on their machine - running locally by default, with an optional backend connection.
Tasks
Builder-declared AI tasks the end-user assigns a model and reasoning effort to, per task and per device - stored on their own machine.