/decide

name: decide
description: "Use when the user wants to try BlockRun's free typed-judgment endpoint (POST api.blockrun.ai/v1/decide, served by OpenJev) on their own data from Claude Code — yes/no, labelled choice, or scored-rung questions over a text or JSON state, up to 64 per call. Not an MCP tool: call it with curl from the shell. Covers the request shape, what the confidence number does and does not mean, and why OpenJev is not Jev."
triggers:
  - "decide"
  - "v1/decide"
  - "typed judgment"
  - "typed judgments"
  - "openjev"
  - "open jev"
  - "jev"
  - "nli"
  - "natural language inference"
  - "entailment"
  - "classify with a small model"
  - "cheap classifier"
  - "judgment model"
  - "score these"
  - "label these"
  - "triage tickets"

Decide — free typed judgments from Claude Code

`POST https://api.blockrun.ai/v1/decide` takes a **state** (a message, a ticket, a diff, a tool result, a row of data) and up to **64 questions**, and returns a typed answer with a number beside each one. No prose to parse. The backend is **OpenJev**, an open-source natural-language-inference model BlockRun hosts.

It is **not a BlockRun MCP tool**, on purpose: you are already a frontier model, and for a one-off "is this urgent?" you are the better judge. The endpoint earns its place when the user wants the *same fixed ruler over many items*, or is prototyping a judgment they will later run from a pipeline **without** a model. From Claude Code, call it with `curl` from the shell.

What it is not

• **Not paid, not x402.** It is free behind a registered API key. There is no

payment header, no wallet path, and it is served by `api.blockrun.ai`, not the x402 gateway at `blockrun.ai` (a POST to `blockrun.ai/v1/decide` is a 404).

• **OpenJev is not Jev.** Jev is TypeSafe's model. OpenJev is an unaffiliated

open-source NLI cross-encoder (MIT, published by AlexWortega on Hugging Face, Qwen3.5 4B base). It is not made by the people who make Jev and it is not a smaller or free tier of it. BlockRun does not sell or resell Jev. There is one backend, and the `x-blockrun-backend` response header names it on every call.

• **No quality comparison exists.** BlockRun expects OpenJev to be materially

weaker than Jev, has not benchmarked the two, and will not put a number on the gap. Do not invent one. The model authors' own zero-shot NLI figures, with attribution and a read date, are at <https://blockrun.ai/openjev>.

Getting a key without changing how the MCP pays

Keys are minted at <https://user.blockrun.ai/dashboard/keys> (`brk_live_…`, shown once; registration, not a card).

For experiments, **export the key in the shell** and leave the MCP server alone:

export BLOCKRUN_API_KEY=brk_live_…

Do **not** write it to `~/.blockrun/.api-key` just to try `decide`. The MCP server reads that file at startup and a present key moves **every** paid tool from wallet mode to account billing — the same switch `BLOCKRUN_API_KEY` in the MCP server's own config makes. That is fine if the user wants account billing (see the `blockrun-setup` skill); it is a surprise if they only wanted a free judgment. If the MCP is already on account billing, the same key works for both.

Request

curl -sS -X POST https://api.blockrun.ai/v1/decide \
  -H "authorization: Bearer $BLOCKRUN_API_KEY" \
  -H "content-type: application/json" \
  -D /dev/stderr \
  -d '{
    "state": "Help! My payouts have been failing for 3 days.",
    "questions": {
      "is_urgent":   { "type": "noul",   "instructions": "Does this convey urgency?" },
      "department":  { "type": "choice", "instructions": "Which team should handle this?",
                       "criteria": { "billing": "Payments, refunds",
                                     "technical": "Bugs, outages" } },
      "frustration": { "type": "score",  "instructions": "How frustrated is the customer?",
                       "criteria": ["Calm", "Frustrated", "Very angry"] }
    }
  }'

`-D /dev/stderr` shows the response headers (backend, rate-limit) without mixing them into the JSON on stdout.

| Field | Type | Required | Notes | |---|---|---|---| | `state` | string \| object \| array | yes | What to judge. Text and JSON both work. If a fact matters, put it in the state — the model looks nothing up. | | `questions` | object | yes | Your own id → question. **1 to 64** per call. | | `model` | string | no | Defaults to `openjev`, the only backend. Leave it out. |

Three question types, one operation underneath (state = premise, question = hypothesis, answer = how strongly the premise entails it):

| Type | `criteria` | You get back | |---|---|---| | `noul` | none — it is true or false | one number for how strongly the state supports the claim | | `choice` | map of label → its meaning, **2 to 255** entries | the top label, plus a share per option | | `score` | array of rung descriptions in words, **2 to 255** | a weighted position across the rungs, plus the distribution |

`instructions` — the question itself, in plain language — is required on all three.

Response

{
  "model": "openjev",
  "answers": {
    "is_urgent":   { "type": "noul",   "noul": 0.986 },
    "department":  { "type": "choice", "choice": "billing",
                     "probabilities": { "billing": 0.71, "technical": 0.29 },
                     "confidence": 0.71 },
    "frustration": { "type": "score",  "score": 1.42,
                     "legend": { "0": "Calm", "1": "Frustrated", "2": "Very angry" },
                     "probabilities": { "0": 0.11, "1": 0.36, "2": 0.53 },
                     "confidence": 0.53 }
  }
}

`score` is the probability-weighted rung index (`1.42` sits between "Frustrated" and "Very angry"); `legend` maps index → rung text.

Read this before you build a threshold

**The `confidence` on a `choice` is not the probability the answer is correct.**

Every option is scored against the state, and the scores are then **divided by th