Skip to main content
The kettei models answer directly, without writing out any reasoning, so your wording carries the decision. Start with the free linter: it checks a decision’s wording without running a model, and it needs no key. This is the deadline question from Route a support ticket, on the ticket that example loads in the playground:
Each warning names its decision, its rule and a message. An empty warnings list means no rule fired. It doesn’t measure accuracy. Send the same body to /v1/decide with your key to get the probabilities. The playground runs the same check as you type.

Word the question

  • Ask one plain question, the positive way round. “Does the ticket state a deadline within one day?” is easier to answer and to label than “Is this not urgent?”.
  • Describe each outcome. Say when it applies, and where it ends and the next one begins. In the deadline question, yes is an explicit deadline today or within 24 hours, and no is later, missing or unclear.
  • Cover every case. If none of your outcomes might fit, add one such as other or none, as Pick the tool for a request does.
  • Keep counting in your code. Counts, sums and date arithmetic are your code’s job. Work out the number first, then ask about it.
To try a wording quickly, open Settle a debate in the playground: a paragraph about Pluto, one yes or no question and two descriptions you can edit. Decision types shows how to write each kind.

Give the model the evidence

A decision can only use what the request gives it.
  • context and question can each be a string or JSON.
  • A decision that carries everything in its question, such as a quiz question, can leave context out or empty.
  • For retrieval or tool selection, put the actual passage or the tools’ descriptions in the context.
  • Send only the text the questions need. A shorter context costs less and is answered sooner.

Ask several questions at once

Decisions in one request can affect each other’s answers, and you pay for the context once. Each decision still gets its own probabilities and its own policy. Need an answer that doesn’t depend on the others? Send that decision in a request of its own. Each request pays for its own context. Because decisions in one request can affect each other, adding or removing one can move the others’ probabilities. Measure with the same set of decisions you will send in production.

Give a reason with each answer

OneHot answers with probabilities, not written explanations. When people need a reason next to each answer, ask for it as one more decision. List the reasons you usually see, often 10 to 20, and let the model pick one:
Draw the reasons from cases you already have, such as the explanations people or a language model wrote for past answers. Each reason then has a probability like any other outcome, so you can show a reason only when its probability is high enough. Label some cases with their reason too, so you can measure the reasons like any other decision.

Keep scores and actions apart

Keep the meaning of each outcome stable. Turn probabilities into actions with a threshold or a policy only when your workflow gives you a reason, and check that policy on its own (act on the answer).

Test, then improve

Before you rely on a decision, build a small set of reviewed cases: ordinary ones, rare outcomes, ambiguous messages and cases outside the task. Compare the model with a simple baseline, such as always picking the commonest outcome. Improve the wording first, and check it with the linter above. When you have enough representative labels, try fine-tuning, which trains a model on your examples.