Skip to main content
The spec’s model picks the engine. Every engine returns the same typed answers, so review, test and diff work the same whichever one answered.

LLM engines

An LLM has no typed output, so hunch asks it for one token and reads that token’s probabilities.
  • Prompt. The question and numbered options come first, so providers can cache that part across rows. The row follows as JSON. The model is asked for only the option number, yes/no, or the score level.
  • Probabilities. hunch takes the top 20 log-probabilities of the first answer token and renormalises them over the valid answers.
  • Temperature 1. At temperature 0 some APIs give every token but the top one a probability of zero, which would make every answer look certain.
  • Providers. This needs log-probabilities with reasoning turned off. Some providers return none, or reason anyway, which hides the first answer token. Pin one that works with @provider:

Compare engines: --model

--model overrides the spec’s engine for one command. Results go to their own table, <judgment>__<engine>, and each engine’s answers are cached under their own keys, so nothing is overwritten.
Measured so far, Jev against DeepSeek (deepseek-flash) on the same specs and rows: DeepSeek cost about 1.5× Jev as billed. Both were well calibrated on BANKING77 (calibration error 0.043 for Jev, 0.032 for DeepSeek). Background in the cookbooks.

Escalate

A question can send its uncertain answers to a second engine. Answers below act are asked again on the escalate model, and the second answer replaces the first if it clears act itself (behind a distilled: model, always, since the teacher is the better model):
Both answers stay in the store. The table’s <question>_by column names the engine whose answer was used, and <question>_key points at that answer. See the spec reference.