Bring your own keys.
Keep the workspace.

The models are your providers' models

dsh publishes what your configuration can reach, so the picker is built from your catalogue rather than a fixed list. Ids are provider-scoped — the vendor prefix in front of the model name — and Fleet groups them by vendor so a catalogue with dozens of entries is still something you can pick from.

Reasoning effort is per model here, not per tool: each model carries the ladder it accepts, and dsh's own default is named on the menu so the un-chosen state tells you what will happen rather than leaving you guessing. Some models expose no reasoning control at all, and then there is no ladder to show.

Fleet only offers dsh at all when the binary is actually installed. Unlike the other two sources, this one reaches its sessions through a server it has to start, so a machine without dsh gets no half-working entry in the menu.

What it costs comes from the provider, not from us

dsh has no account, quota or rate-limit surface — that is not an omission, it follows from what the harness is. The quota belongs to whichever provider your key is for.

So Fleet reads the spend where it exists: the provider's own API. For a key you configured, that means the balance and generation cost that provider reports, which is the only number that corresponds to a real bill. There are no plan windows to draw, because dsh does not have a plan.

Per-session token accounting is a different question, and that one dsh does answer — Fleet reads the per-session token projections it publishes, so you still get tokens and a cost estimate for a specific task.

One local server behind every session

Fleet talks to all dsh sessions through a single local dsh server, and treats it as a machine-level service rather than a child process that dies with a window. Close the app, open it again, and it adopts the running server instead of starting a second one.

That is the part you would otherwise have to run by hand, and the part that would go wrong quietly: two servers, two ports, sessions split between them. The lease is recorded with the port and launch token, readable only by you, so a later health failure can restart the same service rather than orphaning it.

Same board, same decisions, same deliverables

Everything the workspace does around a session applies here unchanged. dsh tasks sit on the same board with their provider and model on the card, take follow-up instructions while running, raise decision cards with the material attached, and drop their finished files into the project's deliverables.

Images work in both directions: attach reference pictures to a brief and they reach the session as real files.

A plan written in a dsh session is the same plan another tool picks up, and a handoff can name a Claude Code or Codex model to continue in. The point of a bring-your-own-key harness is not having to commit — keeping the plan, the wiki and the results outside the CLI is what makes that true in practice.

Where the keys live

Provider credentials stay in your own dsh configuration. Fleet can tell you whether a credential a session needs is present, because that is what dsh reports — presence, not the key itself and not a balance attached to it.

Fleet runs on your machine next to dsh, is free and open source under AGPL-3.0, and adds no account of its own. The machine has to be online for its tasks to move; the phone connects back to it rather than replacing it.