LatentCodeUsing LatentCode

Models

Choose which model LatentCode uses, how hard it thinks, and which organization pays for it.

Which models you can use

LatentCode gets its models from your LatentStack gateway. The list depends on your organization's tier, is imported when you save your API key, and is refreshed in the background. Print it with:

$latentcode models

tier: standard
latentrouter/bedrock-anthropic/anthropic/claude-haiku-4-5
latentrouter/bedrock-anthropic/anthropic/claude-sonnet-5
latentrouter/gemini/gemini-3.1-pro-preview
…

A model ID has three parts: the provider latentrouter (your gateway), the host that serves the model (for example bedrock-anthropic), and the model. Use the full ID wherever a setting or flag asks for provider/model. The IDs on your gateway may differ from these examples.

If a model you expect is missing, ask your administrator to add it to your tier, then run latentcode config models --refresh.

Switch models

/models or ctrl+x m opens the model picker. It lists your Favorites, your Recent models and then every model grouped by host, with your tier's default marked (tier default). Type to filter.

Key	Action
`ctrl+f`	In the picker: add or remove a favorite.
`f2` / `shift+f2`	Switch to the next / previous recently used model without opening the picker.

The choice applies from your next message and is remembered for the agent you're using. To choose at startup, pass -m:

$latentcode -m latentrouter/bedrock-anthropic/anthropic/claude-sonnet-5

Default model

New sessions use, in order: the model from -m, the model setting, your most recent model, then your tier's default.

$latentcode config set default-model bedrock-anthropic/anthropic/claude-sonnet-5

This writes "model" to your global config, adding the latentrouter/ prefix. A project can set its own "model" in its latentcode.json, and each agent can have its own (see Agents). When you save an API key or refresh models and your default isn't on your tier, LatentCode picks one that is.

small_model

Background jobs, such as naming sessions, use a smaller, cheaper model. Set it with "small_model"; otherwise LatentCode picks a small model from the same provider. Your organization can also assign models to these jobs, which takes precedence.

If a model fails

If a request fails with an error the model can't recover from, the session switches once to your tier's default model and carries on. You'll see a notice when that happens.

Reasoning effort

Models that can reason offer effort levels, such as low, medium and high, or just on and off. The levels come from how your administrator set up each model.

ctrl+t steps through the levels and back to the default.
/effort opens a picker. If the model has no levels, you're told why.
The chosen level is shown under the prompt and remembered per model.
For scripts: latentcode run --effort high "…". Per agent: "variant": "high".

Higher effort usually gives better answers on hard problems, and takes longer and costs more.

Organizations and teams

If you belong to more than one LatentStack organization, /org switches which one your requests are billed to and whose tier applies. /projects picks a team within it. The choice is saved on your machine for the API key you're using, and changing organization clears the team. Choose Default to let the gateway decide.

For a single command, pass --org and --team (names or IDs) to run, models or stats. Nothing is saved.

$latentcode run --org acme --team payments "summarize open TODOs"

Fusion

The main model hands routine work, such as broad searches, to a cheaper sidekick model.

Turn it on for everything with /fusion, or for one run with latentcode --fusion. --sidekick-model <provider/model> picks the sidekick and also turns Fusion on.
Change the main and sidekick models, or turn Fusion off, with Change fusion config in the command palette (ctrl+p). These settings are saved to your global config.
A FUSION badge appears under the prompt. The sidebar and /stats split cost into Main agent and Sidekick.

--fusion (and the LATENTCODE_FUSION variable) keep Fusion on for that process even if it's off in your config.

Debate

/debate puts one question to several models, which answer, read each other's answers and respond over a number of rounds. Use it for design decisions where a second opinion helps.

/debate --rounds 3 Should the job queue use Postgres SKIP LOCKED or Redis streams?

Rounds: 2 to 10, default 3.
Participants: 2 to 5, each on a different model. By default there are two: your current model and one other. Add more, and choose their models, with Configure debate in the command palette.
Participants can read and search your code but can't change it or use the network.
Each participant has 10 minutes by default. Change it with debate.participantTimeoutMs; 0 removes the limit.