Decisions — typed judgments from Claude Code

POST https://api.blockrun.ai/v1/decisions takes an input (a message, a ticket, a diff, a tool result, an image) and a list of questions with a fixed answer space, and returns one typed answer per question — no prose to parse. It is compatible with OpenAI's Decisions API and served by gpt-6-luna.

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.

Where to call it

That is the only rail. Decisions is not sold over x402: the x402 per-call floor is above what a Decisions call costs, so a paid route would bill nearly every call at the floor. Do not look for it on blockrun.ai or sol.blockrun.ai, and do not offer to pay for it from the wallet. Batch the questions anyway: many questions in one call share one input and one round trip.

OpenJev is retired (2026-10-07). The old POST api.blockrun.ai/v1/decide shape (state, noul/choice/score with criteria) is still accepted and answered by the same model, but write new calls against /v1/decisions.

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 this. 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 https://api.blockrun.ai/v1/decisions \
  -H "authorization: Bearer $BLOCKRUN_API_KEY" \
  -H "content-type: application/json" \
  -D /dev/stderr \
  -d '{
    "model": "gpt-6-luna",
    "input": "Help! My payouts have been failing for 3 days.",
    "questions": [
      { "type": "predicate", "name": "is_urgent",
        "instructions": "Does the message convey urgency?" },
      { "type": "choice", "name": "department",
        "instructions": "Which team should handle this?",
        "choices": [ { "value": "billing",   "description": "Payments, payouts, refunds" },
                     { "value": "technical", "description": "Bugs and outages" } ] },
      { "type": "score", "name": "frustration",
        "instructions": "How frustrated is the customer?",
        "levels": [ { "label": "calm",       "description": "Neutral tone" },
                    { "label": "frustrated", "description": "Clearly unhappy" },
                    { "label": "angry",      "description": "Hostile or threatening to leave" } ] }
    ]
  }'

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

A question the model declines comes back as type: "refusal".

Response (measured 2026-10-07 for the request above)

{
  "model": "gpt-6-luna",
  "answers": [
    { "type": "predicate", "name": "is_urgent", "probability": 0.95 },
    { "type": "choice", "name": "department", "choice": "billing",
      "probabilities": [ { "value": "billing", "probability": 1.0 },
                         { "value": "technical", "probability": 0.0 } ],
      "confidence": 1.0 },
    { "type": "score", "name": "frustration", "score": 0.94,
      "probabilities": [ { "value": 0, "label": "calm", "probability": 0.06 },
                         { "value": 1, "label": "frustrated", "probability": 0.94 },
                         { "value": 2, "label": "angry", "probability": 0.0 } ],
      "confidence": 0.91 }
  ],
  "usage": { "input_tokens": 399, "output_tokens": 0, "total_tokens": 399 }
}

Before you build a threshold

Set thresholds by running the user's own labelled examples through the endpoint and looking at where the errors land — not by reading a number as an accuracy. An agent that gates on confidence > 0.8 without that check will be wrong with no error to tell it so.

The model judges only the input. A question whose answer is not in it ("does this need a reply today?" over a message that says nothing about timing) still gets an answer that looks like a verdict. That one is policy — answer it in code.

Trying it on the user's data — the shape that works

1. Build the input with everything the judgment needs. Fetch with blockrun_exa or blockrun_search first if a fact is missing.
2. Ask the independent questions together in one call.
3. Combine with deterministic checks the code already has.
4. Route by margin. Act automatically where the margin is wide and the checks agree; hand narrow cases to a reasoning model via blockrun_chat, or to a person.

A quick evaluation loop: put 20–50 labelled rows in a JSON file, loop curl over them with jq, and tabulate agreement.

jq -c '.[]' examples.json | while read -r row; do
  input=$(jq -c '.input' <<<"$row"); want=$(jq -r '.label' <<<"$row")
  got=$(curl -sS https://api.blockrun.ai/v1/decisions \
    -H "authorization: Bearer $BLOCKRUN_API_KEY" -H "content-type: application/json" \
    -d "{\"model\": \"gpt-6-luna\", \"input\": $input, \"questions\": [{\"type\": \"choice\",
         \"name\": \"q\", \"instructions\": \"Which team should handle this?\",
         \"choices\": [{\"value\": \"billing\", \"description\": \"Payments, refunds\"},
                       {\"value\": \"technical\", \"description\": \"Bugs, outages\"}]}]}" \
    | jq -r '.answers[0].choice')
  echo "$want,$got"
done | sort | uniq -c

Limits and errors

Related

• API reference: https://blockrun.ai/docs/api-reference/decisions
• Account billing for the whole MCP: blockrun-setup skill, "API key" section.