/decide

name: decide
description: "Use when the user wants typed judgments over their own data from Claude Code — yes/no probabilities, a labelled choice, or a rubric score over text or images, many items at a time. BlockRun's Decisions endpoint (OpenAI Decisions-compatible, gpt-6-luna): served only at POST api.blockrun.ai/v1/decisions, free with a BlockRun key (no x402 rail). Not an MCP tool: call it with curl. Replaces the OpenJev-backed /v1/decide, which is retired."
triggers:
  - "decide"
  - "decisions"
  - "v1/decide"
  - "v1/decisions"
  - "decisions api"
  - "typed judgment"
  - "typed judgments"
  - "openjev"
  - "gpt-6-luna"
  - "classify with a small model"
  - "cheap classifier"
  - "judgment model"
  - "score these"
  - "label these"
  - "triage tickets"

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

| Endpoint | Auth | Price | |---|---|---| | `https://api.blockrun.ai/v1/decisions` | `Authorization: Bearer brk_live_…` | Free for any registered key, per-key hourly limit |

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.

| Field | Type | Required | Notes | |---|---|---|---| | `model` | string | no | `gpt-6-luna`, the only Decisions model. | | `input` | string \| array | yes | A string, or messages whose `content` holds text and inline base64 images (no hosted URLs). If a fact matters, put it in — the model looks nothing up. | | `questions` | array | yes | Each `{ type, name, instructions }`, plus `choices` or `levels`. |

| Type | You add | You get back | |---|---|---| | `predicate` | nothing | `probability` 0–1 | | `choice` | `choices: [{ value, description }]` | `choice`, `probabilities` per value, `confidence` | | `score` | `levels: [{ label, description }]`, lowest first | `score` (weighted level index from 0), `probabilities` per level, `confidence` |

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*