Providers
A provider is an agent CLI Saggar knows by name. Any program runs in a Saggar terminal, but a provider gets recognition, a place in the launch menu, hooks that report its lifecycle, exact resume, and the Saggar skill.
Saggar knows seven:
Everything else is covered by Other agents.
What every provider gets
| Feature | What it means |
|---|---|
| Recognition | Saggar walks the process tree under each shell and, when that fails, reads the agent's own chrome on screen. A provider you start by hand is recognized exactly like one Saggar launched. |
| A launch row | The new-session menu lists each enabled provider, with its models where Saggar knows them. |
| An install check | Every launch runs command -v first. A missing CLI opens a visible repair prompt in the terminal that asks before installing anything. Codex and GitHub Copilot CLI install through Homebrew; the rest use their own installer. |
| Hooks | An opt-in integration reports starts, prompts, turns, and exits from the provider's own lifecycle, so status stops depending on screen inference. Install them from Settings ▸ Providers or with saggar hooks. |
| Exact resume | With hooks installed, restoring a project reopens the same conversation rather than the same command. |
| The Saggar skill | Saggar can write its saggar-cli skill into the provider's user-level skills directory, so the agent knows how to raise your attention or start work in another terminal. It never installs silently. |
Where they differ
| Integration | Terminal command | Automatic recognition | Provider roster | Lifecycle integration | Permission-aware | Exact resume | Model and usage details | Saggar skill | Session orchestration |
|---|---|---|---|---|---|---|---|---|---|
| Any terminal CLI | Yes | No | No | No | No | No | No | No | No |
| Claude Code | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Codex | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Antigravity CLI | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Pi | Yes | Yes | Yes | Yes | No | Yes | Yes | Yes | Yes |
| OpenCode | Yes | Yes | Yes | Yes | No | Yes | Yes | Yes | Yes |
| GitHub Copilot CLI | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Kimi Code | Yes | Yes | Yes | No | No | No | No | Yes | Yes |
| Custom resume binding | Yes | No | No | No | No | Custom binding | No | No | No |
Definitions:
- Terminal command: Runs as an ordinary command in a Saggar terminal.
- Automatic recognition: Saggar identifies the running agent from its process or screen.
- Provider roster: Appears in Settings and the new-session launch menu.
- Lifecycle integration: Provider hooks report starts, turns, stops, or exits.
- Permission-aware: Saggar can answer permission prompts through provider hooks, or from recognized screen menus as a fallback.
- Exact resume: Saggar restores the same conversation, not merely the same command.
- Model and usage details: The terminal info view shows live model and usage or context data.
- Saggar skill: Saggar can install its command skill in the provider's skill folder.
- Session orchestration: The agent can create or control Saggar sessions through the skill.
The table is generated from the same data the app uses, so it can't drift from what Saggar actually does.
Models
Where a provider's models come from depends on the provider.
| Providers | Where models come from |
|---|---|
| Claude Code, Codex, Antigravity CLI | Saggar's own catalog. Models poorly suited to coding stay hidden until you reveal them with More models on the provider's card. Antigravity's card also asks agy models for models the catalog doesn't ship. |
| Codex, GitHub Copilot CLI | The provider's own published list, which replaces Saggar's rows when it is readable. Codex keeps a model cache; Copilot's models are learned from its recent session logs. |
| Pi, OpenCode | The credentials you have given them. Their cards ask the CLI (pi --list-models or opencode models) and let you pick which reported models get a row. |
| Kimi Code | Kimi's own configuration. It has no command that lists models, so its one row runs whatever /provider set. |
Claude Code, Codex, and GitHub Copilot CLI also take a reasoning effort. Saggar stores it per launch model, passes it on the launch command, and leaves the model's default alone when you haven't picked one.
- Pick an effort for one session in the new-session sheet, or save it in a preset. That works for all three.
- The Default effort column on the provider card in Settings ▸ Providers is filled only for Codex rows, because Codex publishes an effort ladder per model. Claude Code and Copilot have one ladder for every model, so their effort is chosen per session.
How the models compare
This chart comes from Model index, which combines published coding benchmarks. It shows models from the vendors behind Saggar's providers: Anthropic, OpenAI, Google, and Moonshot AI. Each point is a model at one effort, placed by its mean quality and cost percentiles across the benchmarks that ran it. Up and to the left is better. Hover a point for its details, or open the index for each benchmark's own figures.
Benchmarks use different tasks, so treat this as a rough guide. Your own codebase is the test that counts.
Starting with a task
The new-session sheet takes a first task and passes it the way each provider
expects: after -- for Claude Code and Codex, with -i for GitHub Copilot
CLI and Antigravity CLI, with --prompt for OpenCode, and as a bare argument
for Pi. Kimi Code can't take one at launch, so Saggar types it into Kimi's
input box once Kimi is up.
A preset's custom context reaches only Claude Code, as
--append-system-prompt, and Codex, as -c developer_instructions=. The
preset editor says so for the others rather than offering a field the launch
would drop.
Anywhere Saggar takes a command to run, including the new-session sheet,
follow-ons, and scheduled runs, @codex fix the failing test opens that
provider with the task, and @claude.opus55 fix the failing test names the
model too. A model alias is the row's label with spaces and punctuation
removed, or its id. An alias Saggar doesn't know runs as an ordinary command.
The roster
Onboarding asks which providers you use, and Settings ▸ Providers changes the answer.
The roster decides what Saggar offers: launch rows, hook installs, and the
on-screen scan. It never gates recognition. A codex you start by hand with
Codex turned off still lights its chip and still gets answered, because turning
a provider off means "stop offering me this", not "pretend this isn't running".
A provider needs both a roster entry and an installed CLI before it appears as a launch target. Installation is a setup action, not a side effect of picking a menu item.
Versions
Claude Code, Codex, and GitHub Copilot CLI added their hook events one release at a time. Saggar reads the installed version and holds back what that version can't run.
- When a CLI is too old for something Saggar would otherwise do, the provider's card says what it can't do and how to update, and the same sentence is printed once in the terminal ahead of the launch.
- A version Saggar can't read is treated as capable, so a strange
--versionline never costs you a feature. - Antigravity CLI, Pi, OpenCode, and Kimi Code have no published hook history to pin a number against, so nothing of theirs is version gated.
Each provider page lists its version floors where they exist.
Related
- Agents explains recognition, agent trees, and automatic approval across providers.
- Install an agent integration is the step-by-step for hooks.
- Settings lists the provider preferences.
- Set up your terminal for agents covers Shift+Enter, Option as Meta, notifications, and tmux, and links each provider's own terminal guide.
- The Claude Code and Codex pages link each vendor's own best-practice guide for working with the agent in a terminal.