Build with Vansa.

Vansa is a System One decision model (current version: vansa-3). You send a state (text or JSON) and a set of typed questions; it returns a calibrated answer for every one of them. No prompt engineering, no generated text to parse, no hallucinated options: every answer is one of the options you defined, with a probability distribution over them.

NEW MODEL · 24 SEPTEMBER 2026

Vansa-3: 4B parameters, 16k context

Vansa-3 answers every request. It is a new generation: about 4 billion parameters (Vansa-2 had about 0.4 billion) and a 16,384-token context per question, eight times Vansa-2's 2,048. It is built on JevK5, a fine-tune of Qwen3.5-4B, plus an email skill trained by Vansa.

• Same API. The request and response format is unchanged. What clients notice: responses say "model": "vansa-3", a request over 16,384 tokens per question gets 400 instead of being cut, and the time a request takes grows with the number of questions (see below), so check your client timeouts.
• Every model name works. vansa-3 is the default; vansa, vansa-latest, vansa-2 and vansa-1 keep working and are answered by Vansa-3. Responses say "model": "vansa-3".
• Longer inputs. Up to 16,384 tokens per question (the whole prompt: state, question, options and about 100 tokens of fixed instructions). A longer request is refused with 400 instead of being cut, so usage.truncated is always false.
• Better than Vansa-2 on questions it was never trained on, reasoning (JevBench), prompt-injection detection, reworded email questions and email calibration. Lower on jailbreak detection (0.915 vs 0.975), email accuracy (96.1% vs 96.4% on all 52 email questions) and 11 of the 13 public classification tasks Vansa-2 was trained on (mean 0.709 vs 0.805). Details in Benchmarks.
• Time grows with the number of questions. Each question is read in its own pass, so a request takes longer with more questions, a longer state or questions with more than 16 options. Set client timeouts to at least 60 seconds.

Use cases

Anything that is a classification, scoring or yes/no decision over some input: routing support tickets, triaging email, detecting intent (up to 128 options per question), moderating content, scoring urgency or sentiment on a scale, guarding LLM inputs, picking the next action in an agent loop. Because the model never generates text (it reads its own probability for each of your options), it is deterministic for a given request and cannot answer outside your option set. Accuracy differs by task: see Benchmarks.

• choice: pick one option out of N (2 to 128), with a probability for every option.
• score: place the state on an ordered scale you describe (e.g. urgency levels, 1 to 5 stars); you get the expected value and the per-level distribution.
• noul: a yes/no question; you get the probability that the statement holds.

Authentication

Every request needs your API key in the Authorization header. Keys look like vsk_… and are handed out by the Vansa team with a private invitation during the closed beta. Keep it server-side: never ship it in a browser or mobile app.

Authorization: Bearer vsk_your_key_here

Check the key and its remaining quota at any time with GET /v1/me.

Quickstart

curl https://api.vansa.org/v1/systemone \
  -H "Authorization: Bearer $VANSA_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "vansa-3",
    "state": {
      "subject": "Duplicate charge on invoice #4411",
      "body": "Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan."
    },
    "questions": {
      "department": {"type": "choice", "instructions": "Which department should handle this request?",
                     "criteria": {"billing": "invoices, payments, refunds", "technical": "bugs, outages, system errors",
                                  "sales": "pricing, new contracts", "other": "everything else"}},
      "urgency":    {"type": "score", "instructions": "How urgent is this request?",
                     "criteria": ["not urgent", "soon", "critical deadline or blocking issue"]},
      "churn_risk": {"type": "noul", "instructions": "Does the customer threaten to cancel or leave?"},
      "refund_requested": {"type": "noul", "instructions": "Does the customer explicitly ask for a refund?"}
    }
  }'

# pip install requests
import requests

VANSA_KEY = "vsk_..."  # from your invite

r = requests.post(
    "https://api.vansa.org/v1/systemone",
    headers={"Authorization": f"Bearer {VANSA_KEY}"},
    json={
        "model": "vansa-3",
        "state": {
            "subject": "Duplicate charge on invoice #4411",
            "body": "Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan.",
        },
        "questions": {
            "department": {"type": "choice", "instructions": "Which department should handle this request?",
                           "criteria": {"billing": "invoices, payments, refunds", "technical": "bugs, outages, system errors",
                                        "sales": "pricing, new contracts", "other": "everything else"}},
            "urgency": {"type": "score", "instructions": "How urgent is this request?",
                        "criteria": ["not urgent", "soon", "critical deadline or blocking issue"]},
            "churn_risk": {"type": "noul", "instructions": "Does the customer threaten to cancel or leave?"},
            "refund_requested": {"type": "noul", "instructions": "Does the customer explicitly ask for a refund?"},
        },
    },
    timeout=60,
)
r.raise_for_status()
answers = r.json()["answers"]
print(answers["department"]["choice"])          # billing
print(answers["urgency"]["score"])              # 0.0 .. 2.0 (expected level)
print(answers["churn_risk"]["noul"])            # probability of "yes"

// Node 18+ (built-in fetch). Keep the key on the server.
const res = await fetch("https://api.vansa.org/v1/systemone", {
  method: "POST",
  headers: { "Authorization": `Bearer ${process.env.VANSA_KEY}`, "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "vansa-3",
    state: {
      subject: "Duplicate charge on invoice #4411",
      body: "Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan.",
    },
    questions: {
      department: { type: "choice", instructions: "Which department should handle this request?",
                    criteria: { billing: "invoices, payments, refunds", technical: "bugs, outages, system errors",
                                sales: "pricing, new contracts", other: "everything else" } },
      urgency: { type: "score", instructions: "How urgent is this request?",
                 criteria: ["not urgent", "soon", "critical deadline or blocking issue"] },
      churn_risk: { type: "noul", instructions: "Does the customer threaten to cancel or leave?" },
      refund_requested: { type: "noul", instructions: "Does the customer explicitly ask for a refund?" },
    },
  }),
});
if (!res.ok) throw new Error((await res.json()).error.message);
const { answers, usage } = await res.json();
console.log(answers.department.choice, answers.urgency.score, answers.churn_risk.noul);

Response

{
  "id": "req_bfe3ef4ff5f38256",
  "object": "systemone.result",
  "model": "vansa-3",
  "created": 1790309369,
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": {"billing": 0.9922, "technical": 0.0052, "sales": 0.0009, "other": 0.0017},
      "confidence": 0.9624
    },
    "urgency": {
      "type": "score",
      "score": 1.703,
      "legend": {"0": "not urgent", "1": "soon", "2": "critical deadline or blocking issue"},
      "probabilities": {"0": 0.0578, "1": 0.1815, "2": 0.7607},
      "confidence": 0.3788
    },
    "churn_risk":       {"type": "noul", "noul": 0.8568, "probabilities": {"false": 0.1432, "true": 0.8568}, "confidence": 0.8568},
    "refund_requested": {"type": "noul", "noul": 0.8794, "probabilities": {"false": 0.1206, "true": 0.8794}, "confidence": 0.8794}
  },
  "usage": {"input_tokens": 357, "output_tokens": 0, "state_tokens": 40, "truncated": false},
  "latency_ms": 711.5
}

This is real vansa-3 output for the request above. Run it yourself in the playground.

Reference

Answers every question in questions about state. Each question is answered in its own pass over the state, so the time grows with the number of questions and the length of the state.

Request body

Question definition

Response body

Lists the available models with their context size. No key needed. The earlier ids vansa-2 and vansa-1 are listed too, with routed_to naming the model that answers them.

Your key's name, limits and usage today. Requires the key.

{
  "key": {"id": 3, "name": "Tomas – email triage", "prefix": "vsk_9Xk2mQ1p", "created_at": "2026-09-21T10:00:00Z", "expires_at": null},
  "limits": {"requests_per_minute": 60, "requests_per_day": 2000},
  "usage": {"today_requests": 17, "today_remaining": 1983, "quota_resets_at": "2026-09-22T00:00:00Z",
            "total_requests": 231, "total_input_tokens": 88410},
  "model": "vansa-3"
}

Returns 200 with "status": "ok" when the model is ready. Otherwise 503, with "status" loading (starting), upstream_unreachable (the model server cannot be reached or has no model loaded yet, e.g. while it restarts) or error (the API failed to start its model). No key needed.

Question types

choice: pick one option

// definition
"intent": {
  "type": "choice",
  "instructions": "What does the customer want in `message`?",
  "criteria": {
    "refund": "money back or a charge reversed",
    "technical_help": "a bug, outage or integration problem",
    "cancellation": "wants to cancel or downgrade",
    "other": null
  }
}

// answer
"intent": {
  "type": "choice",
  "choice": "refund",
  "probabilities": {
    "refund": 0.91, "technical_help": 0.03,
    "cancellation": 0.04, "other": 0.02
  },
  "confidence": 0.71
}

Descriptions are optional (null); without one the model sees only the option name, so describe options whose names are terse or ambiguous. Up to 128 options per question; with more than 16 the model answers in two rounds (see Limits). For choice and score, confidence is 1 minus the normalized entropy of the distribution (1 = certain, 0 = uniform), so it stays comparable across questions with different option counts. For noul it is the larger of the two probabilities (0.5 = undecided, 1 = certain).

score: position on an ordered scale

// definition: levels from lowest to highest
"frustration": {
  "type": "score",
  "instructions": "How frustrated does the customer sound in `message`?",
  "criteria": [
    "calm and neutral",
    "concerned but civil",
    "clearly annoyed",
    "very angry or using strong language"
  ]
}

// answer: score is the expected level (0 .. N-1)
"frustration": {
  "type": "score",
  "score": 2.31,
  "legend": {"0": "calm and neutral", "1": "concerned but civil",
             "2": "clearly annoyed", "3": "very angry or using strong language"},
  "probabilities": {"0": 0.02, "1": 0.12, "2": 0.39, "3": 0.47},
  "confidence": 0.24
}

Use score whenever the options are ordered (severity, stars, priority): the expected value gives you a continuous number to threshold or sort on. Round score if you need a single level, or take the argmax of probabilities.

noul: yes or no

// definition (criteria optional)
"is_phishing": {
  "type": "noul",
  "instructions": "Is this email a phishing or scam attempt?",
  "criteria": {
    "true": "phishing, scam, or fraud",
    "false": "a legitimate email"
  }
}

// answer: noul = probability the statement holds
"is_phishing": {
  "type": "noul",
  "noul": 0.08,
  "probabilities": {"false": 0.92, "true": 0.08},
  "confidence": 0.92
}

Threshold noul at 0.5 for a plain yes/no, or higher when a false positive is expensive. Probabilities are temperature-calibrated on held-out data. Measured calibration error is 0.009 on held-out email threads and 0.066 on average over 13 public tasks (0.129 on the worst, emotion), so read 0.8 as roughly 80%, most exactly on email.

Writing questions that work

• Send the state as JSON with named fields. The model receives the state as JSON, keys included, so instructions can name a field: "Which team should handle the request in `body`?".
• Describe options, especially when names are short or overlap ("technical: bugs, outages, integrations" vs "sales: pricing, demos").
• Include an escape hatch such as other or none of the above in choice questions; the model must pick one of your options.
• Batch related questions in one request: one round trip for all of them. Each question is still its own pass, so ask what you need, not everything you could.
• Long states are accepted up to 16,384 tokens per question (the whole prompt, see Limits). Accuracy is validated on states up to about 4,000 tokens, and the email preset on threads up to about 1,800; longer states also take longer.
• Send what the questions need. Nothing is cut any more, but signatures, footers and quoted history are noise: leave them out.
• Write in English. Vansa-3's base model (JevK5) is documented by its author as English only, and its email skill was trained on threads that were 84% English (then Spanish and Portuguese).
• Same request, same answers. Inference is deterministic; there is no temperature to set.

Errors

Errors use HTTP status codes and a JSON body:

{"error": {"type": "invalid_request_error", "message": "`questions.intent.criteria` must list at least 2 options, as {\"option\": \"description or null\"}.", "param": "questions.intent.criteria"}}

Retry 429, 502 and 503 with backoff; do not retry 400, 401, 404 or 413. API responses carry X-Request-Id; an unexpected 500 gives the id in its error message instead.

Rate limits and request limits

Request bodies are not stored. Each request is logged with its time, key, model, question count, token count, latency, status and client IP, plus a short error message when a request is rejected (it can name the question id or model at fault), for quotas and support. Requests pass through Cloudflare and are answered on Vansa's own GPU server; no third-party AI provider receives them.

Email qualification preset (link-building outreach)

Vansa-3 has one domain Vansa trained a skill for: guest-post and link-building outreach. Vansa-3's email skill learned 52 questions about outreach threads (every email between an outreach team and one website about a paid post): the 26 in this preset and 26 extras, from 76,584 labelled decisions on 23,894 threads. Send a thread in the trained format and ask those questions exactly as published: that is how the agreement below was measured, on held-out threads from the same outreach data the skill was trained on. Reword them and it drops (0.956 to 0.939 in our test), which is why the questions are published as a file.

Measured on 600 held-out threads the model never saw (15,585 answers): their website, or for free-mail contacts their address, does not appear in the training data. The reference labels come from Gemini 3.8 Flash as the teacher, corrected by code rules (facts from the mail headers, plus consistency rules that can override labels such as outcome, fail_reason and our_handling). An automated referee re-labelled 16 of the 26 questions on 80 audit threads and agreed on 95–98% of the answers on the 75 it scored, but the labelling rules were tuned on these same threads, so it is not an independent check. They are not yet human-verified, so read the numbers as agreement with our labelling rules, which Vansa-3's email skill learned from the same teacher. Measured with Vansa-3 through the API's model server with 8-bit weights; the unquantised model scores the same on these 600 threads (0.961 over all 52 questions).

Files

Input: one thread

{
  "site": "example-garden-blog.com",
  "subject": "Guest post on example-garden-blog.com",
  "roles": "us = our outreach team buying a sponsored guest post; them = the website owner or editor",
  "counts": {
    "ours": 2,
    "theirs": 1,
    "auto_replies": 0,
    "bounces": 0,
    "days_since_last": 112,
    "last_from": "us"
  },
  "messages": [
    {
      "n": 1,
      "from": "us",
      "date": "2026-06-02",
      "text": "Hi, we would like to publish a sponsored guest post on your site for one of our clients. Do you accept guest posts, and what is your price for one article with one do-follow link?"
    },
    {
      "n": 2,
      "from": "them",
      "date": "2026-06-03",
      "text": "Hello, our price is 150 USD per post, do-follow and permanent. Payment in advance by PayPal."
    },
    {
      "n": 3,
      "from": "us",
      "date": "2026-06-04",
      "text": "Thanks, we will check with our client and get back to you."
    }
  ]
}

• us is always the outreach side (the buyer of the post), them the website. Keep roles exactly as shown.
• counts are computed by your code from the mail headers and today's date: theirs excludes auto-replies and bounces, auto_replies counts every message with an auto-reply signal (bounces that carry one included), days_since_last is whole days since the last message, last_from is who sent it. The time-based outcomes (still open or ghosted after 14 days) depend on them.
• Messages: oldest first, date as YYYY-MM-DD, text is the new text only (quoted replies, > lines, mail footers and anything after a line of only 2 or 3 dashes or a "Sent from my iPhone/iPad/Samsung/Android" line removed), at most its first 150 words, shortened to the first 120 plus up to 3 later sentences (35 words at most) that carry an amount or a yes/no answer, with " ..." where text was cut (fewer words when a long thread must be trimmed), plus "kind": "auto_reply" or "bounce" when it applies.
• Long threads keep the first message, their first real reply and the last 4, with {"n": "...", "omitted": 7} in place of the rest; the whole state stays under about 1,250 tokens. email_state.py does all of this.
• Send the state as a JSON object with the keys in this order, not as a string: the model reads it serialised exactly like that.

Call it

# pip install requests; email_state.py from https://docs.vansa.org/presets/email_state.py
import os
import requests
from email_state import build_state

VANSA_KEY = os.environ["VANSA_KEY"]  # your API key (vsk_...)
preset = requests.get("https://docs.vansa.org/presets/email-qualification.json", timeout=30).json()
state = build_state(
    site="example-garden-blog.com",
    subject="Guest post on example-garden-blog.com",
    emails=[  # every email with this site; "us" = your outreach team
        {"from": "us",   "date": "2026-06-02T09:00:00+00:00", "text": "Hi, we would like to publish a sponsored guest post ..."},
        {"from": "them", "date": "2026-06-03T10:00:00+00:00", "text": "Hello, our price is 150 USD per post, do-follow and permanent. ..."},
        {"from": "us",   "date": "2026-06-04T09:00:00+00:00", "text": "Thanks, we will check with our client and get back to you."},
    ],
)
r = requests.post(
    "https://api.vansa.org/v1/systemone",
    headers={"Authorization": f"Bearer {VANSA_KEY}"},
    json={"model": preset["model"], "state": state, "questions": preset["questions"]},
    timeout=60,
)
r.raise_for_status()
answers = r.json()["answers"]
print(answers["outcome"]["choice"], answers["mistake_gave_up_too_early"]["noul"])

Real vansa-3 answers for the example thread above (the site quoted, we promised to come back and never did):

This is the kind of thread the preset is built to catch: nothing failed on their side, we dropped a live deal.

The 26 questions

Exact wording and option descriptions are in the preset file; send them unchanged.

Extra questions

26 more facts the model was trained on, in extra_questions. Ask them in a second request with the same state (26 + 26 is over the 32-question limit). The "Trained" column says when a question was trained and measured. Where it gives a condition (extra_questions_only_when in the preset), ignore the answer when the condition does not hold. payment_method was trained and measured only on threads where the reference labels had a value; nothing in the state shows which threads those are, so its agreement covers only those threads.

Limits of the preset

• No amounts or text. Prices, counters, the final price, a suggested next reply and free-text notes are not answered: extract numbers with code or an LLM. they_named_price, rounds and the price extras cross-check such an extraction.
• Weakest questions. Of the 26: article_by_them_only, our_handling, negotiation, fail_reason (87-91%). Of the extras: their_last_topic, tone_of_them, tone_of_us, distinct_prices_bucket (80-87%). Use confidence to send doubtful threads to a person.
• Fresh threads. Most training threads were weeks or months old; threads from the last two weeks (still_open) were rare. Check low-confidence answers on threads that are still moving.
• Language. 84% of the labelled threads were English, with Spanish and Portuguese next. On the 600 held-out threads (all 52 questions, unquantised run) English (514 threads) scored 96.0%, Spanish (39) 96.3% and Portuguese (11) 96.7%; 23 threads had no detected language and the other 13 were spread over 8 languages with 1 to 3 threads each.
• Perspective. The questions are asked from the buyer's side. A publisher that sells posts would have to swap us and them, which was not trained.

Benchmarks

All Vansa-3 numbers were measured over HTTP at the API's model server on 24 and 25 September 2026 with 8-bit weights, except the 106-question figure, which is an estimate (see ¹). The unquantised model scores the same on email (0.961). Bold = best value in the row.

Beyond the training data

¹ Questions written by us with answers computed by code: 49 on real held-out outreach threads, 57 on generated JSON (guessing 0.41, always the most common answer 0.45). The set is internal and was used to compare model variants during development; Vansa-2's figure includes a serving layer tuned on it. Vansa-3's 0.871 is an estimate, not one measured run: through the model server it scored 0.879, but a routing bug sent the 57 JSON questions to the email skill. 0.871 keeps the served run on the email-thread questions and replaces the JSON questions with a separate 8-bit run that answers them the way the fixed routing does. The fixed routing is live since 25 September 2026; the set has not been re-measured on it yet. ² The 231 public items only (the judge tier is not public), scored by us with JevBench's own scorer; not the leaderboard score. Jev from the per-item outcomes of Jev 1.13.0 published with JevBench. ³ Not in the training data of Vansa-1, Vansa-2 or Vansa-3's email skill; Vansa-3's base model (JevK5) was trained by its author on data that is only partly published, and Jev's training data is unknown, so these tasks may not be new to either. Jev measured over the TypeSafe API (jev-latest) on 25 September 2026 with the same cases and prompts. On 1,000 cases, differences under about 2 to 3 points are within sampling noise. ⁴ 36 hand-written rewordings of 31 trained email questions on held-out threads. Vansa-3: 0.956 on the same questions in their trained wording, 0.939 reworded (100 threads, 3,532 answers). Vansa-2: 0.957 on all trained questions, 0.915 reworded (the first 50 of those threads, 1,767 answers). Jev (never trained on them): 0.865 on the same questions in their original wording, 0.851 reworded (the same 100 threads, 3,532 answers).

Email qualification (600 held-out outreach threads)

Agreement with our reference labels (Gemini 3.8 Flash corrected by code rules; not yet human-verified). Vansa-3 is within half a point of Vansa-2 on accuracy and better calibrated (calibration error 0.009 against 0.050).

Public test sets

The same cases for every model (up to 1,000 per task, fewer where the test set is smaller), same prompts. Vansa-2 and Vansa-1 trained on the train splits of these tasks. Vansa-3's own training was email only, but its base model (JevK5) was fine-tuned by its author with items from BoolQ, banking77 and MultiNLI (close to XNLI), among others, so it is not zero-shot on those. Jev's training data is unknown (Jev measured live over the TypeSafe API, September 2026). Treat this as indicative, not as a controlled comparison.

On these 13 tasks Vansa-3 is weaker: lower than Vansa-2 on 11 of 13; the largest gaps are emotion, MASSIVE scenario, banking77 and MASSIVE intent. If your use case is one of these trained classification tasks, test on your own data first. Mean = unweighted average of the 13 tasks; calibration error = expected calibration error (15 bins) of the chosen answer's probability.