Skip to main content
A decision model is an optional second model beside your chat model. It writes no text. Give it a piece of material and a typed question, such as “is this a real outage, yes or no?”, and it answers in about a second with how sure it is. Kepler uses it in two ways. It double-checks commands and MCP tool calls before they run, and it gives you fast yes-or-no, pick and score answers in chat, in war rooms and in automation steps.

​
Turn it on

It is off by default, and nothing is sent anywhere until you pick one.
1

Connect a provider that serves one

In Settings > Models, under Providers, connect a provider that serves decision models. Those providers show a Decision models line on their card.
2

Pick it

Under Models, set Decision model, the same way you pick the image model.
3

Test it

Test sends one fixed command and shows the answer, how long it took, and which model answered.

​
A second check on commands

Kepler’s rules and the always-blocked list still decide what runs. The decision model can only make a decision stricter:
  • It answers a few questions about a shell command or MCP call: does it write, which environment does it touch (prod, staging, local), and can it be undone.
  • If it is confident a command writes, and the rules would have let it run without asking, Kepler asks you instead. The card says the decision model raised it.
  • A “read” answer never skips a card, never clears a block, and never touches the always-blocked list.
  • On the unknown-command card it adds a suggestion, such as “The decision model reads it as read-only (96% sure)”. You still decide. It never writes a rule on its own.
Its verdict shows as a small pill on the tool row in the chat. To keep it fast and cheap, Kepler asks only where the answer adds something. A command shape like kubectl get is checked once and remembered for seven days. SQL clients such as psql are checked on every call, because the statement decides. An MCP tool is checked once from its name and description, unless its arguments decide what it does.

​
What leaves your machine

The command with secrets masked, the name of the environment it targets, and what Kepler’s own rules said. Not the output and not the conversation. If the decision model times out or fails, Kepler carries on with its rules alone.

​
Use it yourself

With a decision model picked, Kepler can answer typed questions about material in chat and war rooms, in every posture, with no approval card. They read nothing and change nothing. Batches are where it pays off:
That is one call, not 200. Kepler can ask yes-or-no questions, pick a label (or none, or several), and score against levels you describe. In an automation, add the step Decide with a decision model. Write the questions, choose whether it judges the material as a whole or item by item, and set where “unsure” starts. Later steps can branch on any answer, or send a doubtful call to you with Ask me first. Without a decision model the step fails and says why. It never falls back to a chat model.

​
Where to go next

Permissions

The rules the decision model sits on top of.

Automations

Decision steps in a flow.

Settings reference

The Models page.

Postures

The unknown-command card and the approval dock.