Polystro uses the CLIs and provider accounts you already have.
The app is designed around existing coding CLIs rather than around a bundled model-credit system. The practical setup question is which CLIs are installed, how they authenticate, and what defaults Polystro should apply when you start sessions.
Supported CLIs
Polystro detects Claude Code, Codex CLI, Cursor CLI, Gemini CLI, OpenCode, Kimi Code, Muse Code, Grok Build, and Antigravity CLI. The settings surface reports availability, version, path, and basic health or auth state where that information is available.
Claude Code
Best when you already use Claude Code directly and want it inside the workstream shell.
Codex CLI
Best when your current agent workflow already runs through Codex and you want stronger workstream supervision.
Cursor CLI
Supported as a first-class CLI option when you want Cursor agent sessions and auth recovery inside the same workstream shell.
Gemini CLI
Supported as another session option inside the same desktop shell.
OpenCode
Supported when you want its CLI behavior alongside the same workstream, preview, and review surfaces.
Kimi Code
Supported through its ACP interface, including native models, skills, MCP servers, commands, history, permissions, and questions.
Muse Code
Supported through its headless interface, including native models, skills, MCP servers, images, history, and subagent activity.
Grok Build
Supported through its ACP interface, including native models, skills, MCP servers, commands, agents, history, permissions, and questions.
Antigravity CLI
Supported through its headless interface, including native models, skills, MCP servers, agents, resumable conversations, and subagent activity.
Auth Model
Polystro does not hide the fact that provider authentication depends on the CLI you are using. In many cases the CLI can continue to use its normal login flow or environment setup. Where that is not enough, the app can store API key overrides in Settings.
That includes Cursor CLI. If its session needs re-authentication, Polystro can direct you back to the CLI login flow instead of treating the failure like a generic runtime error.
Practical rule
API Key Overrides
Settings include API key override fields for the common provider env variables used by supported CLIs, plus room for additional custom env keys. These overrides exist for cases where shell-level setup is not the right place to manage credentials on the current machine.
Model and Session Defaults
The desktop app lets you choose defaults like commit-message generation, per-CLI permission behavior, and model selection where the active CLI exposes those options. You can still override the current session from the composer footer at send time.
First-Run Checklist
Verify the CLI is detected
Open Settings and confirm the CLI appears with a valid path and no obvious health issue.
Confirm auth works outside Polystro
If a CLI cannot authenticate in your shell, the app will not fix that automatically.
Set API key overrides only if needed
Prefer existing shell auth unless the current machine or workflow needs app-managed overrides.
Choose the right permission mode
Start supervised if you want explicit approval on risky steps, then loosen per session only when appropriate.