Software makes thousands of small decisions a day. Which team owns this ticket? Is this scan a receipt or an invoice? Has the page finished loading? Is the customer reporting an accident?
None of these needs an essay. Each needs an answer your code can act on, and some sense of how sure that answer is. Today those calls usually go to one of two kinds of model, and neither is built for the job. Wity is a System 1.5 model, and it sits between them. This post explains what it is from scratch: the idea, what an answer looks like, and where it fits.
Two kinds of model, two kinds of problem
Large language models think through every question, even the easy ones. Then they answer in paragraphs your code has to parse. You pay in seconds and tokens for reasoning that a clear-cut question never needed, and you still have to guess how confident the answer was.
Fast decision models answer in a single glance. Easy calls come back instantly. Hard ones come back instantly too, and confidently wrong, because the model has no way to slow down.
What "System 1.5" means
Psychologists describe two modes of thought. System 1 is fast and intuitive. System 2 is slow and deliberate. Most of what you decide in a day is System 1, and you switch to System 2 only when something feels off.
Wity works the same way. It answers most questions in one fast pass, in about a tenth of a second. When an answer is uncertain or unstable, it thinks first and then answers. Either way you get the same thing back: a typed decision with a probability for every option. That's why we call it a System 1.5 model. It sits between instinct and deliberation and picks per question.
What a decision looks like
You send a state (the thing to decide about: text, JSON, an image, or all three) and one or more questions with the options spelled out:
curl https://api.wity.alphanimble.com/v1/systemone \
-H "Authorization: Bearer $WITY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Hi, I was charged twice for my subscription this month. Please refund the duplicate.",
"questions": {
"intent": {
"type": "choice",
"instructions": "What does the customer want?",
"criteria": {
"billing": "A charge, refund, invoice or payment problem",
"technical_support": "Something in the product is broken",
"account_access": "Cannot log in or is locked out",
"cancellation": "Wants to cancel or downgrade"
}
}
},
"reasoning": "auto"
}'
The answer comes back under the name you gave the question:
{
"model": "wity-1",
"answers": {
"intent": {
"type": "choice",
"choice": "billing",
"probabilities": {
"billing": 0.9912,
"technical_support": 0.0031,
"account_access": 0.0019,
"cancellation": 0.0038
},
"confidence": 0.93,
"reasoning": { "mode": "auto", "thought": false, "reason": null, "forecast": false, "thought_tokens": null }
}
},
"usage": { "input_tokens": 212, "output_tokens": 0 },
"metadata": { "reasoning": "auto", "elapsed_ms": 94.1 }
}
There's no prose to parse. choice is the option to act on, and probabilities covers every option you offered. reasoning.thought is false here because the question was clear, so Wity answered directly.
Four primitives, every answer typed
Every question takes one of four shapes. You pick the shape, Wity fills it:
- noul: a yes-or-no call. "Was the insured driver at fault?"
- score: where on a scale something sits. "How bad is the damage: cosmetic, repairable or total loss?"
- choice: one option from a set. "Which team owns this?"
- generate: the short text an action needs, in a shape you define. "The policy number from the scan."
Because every decision carries its probabilities, your code decides how sure is sure enough:
intent = answers["intent"]
if intent["probabilities"][intent["choice"]] >= 0.85:
route(ticket, intent["choice"]) # sure enough: act on its own
else:
send_to_triage(ticket) # close call: a person decides
Act on clear calls, hand close ones to a person, and set that line per question.
Five things that set it apart
- Multimodal. Photos, screenshots and scanned pages go in the same request as your text.
- 128K-token context. A whole contract, a long email thread or a stack of scans fits in one state. No chunking.
- generate. A primitive for the few places software genuinely needs words, written from the same state, right after the decision.
- Auto-thinking. Instant on clear-cut questions, deliberate on shaky ones, decided per question.
- On-prem. It can run inside your own network, with the same API as the cloud.
Fast and cheap enough to put everywhere
A decision model earns its place by being cheap enough to call on every event and fast enough to sit inside a request. We ran Wity and eight fast, low-cost models through the same 200 real-world cases. Wity's typical call took 109 ms, against 943 ms for the next fastest. 1,000 runs cost $3.29, against $17.95 for the next cheapest. That's our own benchmark, and the method is published alongside it.
Pricing is one number: $0.042 per 1M tokens, and failed calls are free. Thinking isn't billed, so a thought answer costs the same as a direct one.
No model is perfect. Use the probability on each decision to choose when to act and when to escalate, and validate generated text like any other input.
What's next
This is the first post in a series where we build up from here, one idea a day: System 1 vs System 2, why decisions shouldn't come back as paragraphs, when a model should think, each primitive in depth, and real builds with code.
If you want to try it now, the quickstart gets you to your first decision in about a minute. Every account starts with $5 of free credit to use within 48 hours of signing up, and the Playground runs real requests from your browser with no code at all.
