<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Wity]]></title><description><![CDATA[Wity]]></description><link>https://wity-1.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Fri, 30 Oct 2026 04:38:02 GMT</lastBuildDate><atom:link href="https://wity-1.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[System 1 vs System 2 AI, and the gap between them]]></title><description><![CDATA[Psychologists describe two modes of thought. System 1 is fast and intuitive. System 2 is slow and deliberate. Most of what we decide in a day is System 1…]]></description><link>https://wity-1.hashnode.dev/system-1-vs-system-2-ai-and-the-gap-between-them</link><guid isPermaLink="true">https://wity-1.hashnode.dev/system-1-vs-system-2-ai-and-the-gap-between-them</guid><category><![CDATA[AI]]></category><category><![CDATA[llm]]></category><category><![CDATA[Machine Learning]]></category><category><![CDATA[api]]></category><category><![CDATA[Decision Models]]></category><dc:creator><![CDATA[Abhishek Kundagol]]></dc:creator><pubDate>Tue, 20 Oct 2026 10:04:48 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6ad601100e1f0cb33b956eda/5d35fbe0-816b-4828-95a4-a7a946d68b01.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Psychologists describe two modes of thought. System 1 is fast and intuitive. System 2 is slow and deliberate. Most of what we decide in a day is System 1, and we switch to System 2 only when something feels off.</p>
<p>That split is a useful way to look at the models we put inside software. Ask "system 1 vs system 2 AI" and you get two families, each good at half the job. This post walks through what goes wrong at each extreme, and what a model that sits between them does instead.</p>
<h2>System 2: models that think through everything</h2>
<p>Reasoning models think through every question, even the easy ones, and answer in paragraphs you still have to parse.</p>
<p>Look at the decisions a real system makes in a day and most of them are easy. The language of a ticket. Whether a page has loaded. Which of five clearly different queues a message belongs to. A direct read gets these right, and thinking about them only adds seconds.</p>
<p>So a System 2 model costs you twice. You wait for deliberation the question never needed, and then you write code to dig the answer out of prose. On one call that's tolerable. On every event in a pipeline, it decides whether the model can sit inside a request at all.</p>
<h2>System 1: models that answer at a glance</h2>
<p>Fast decision models go the other way. They answer in a single glance. Easy calls are instant. Hard ones come back confidently wrong.</p>
<p>Take a delivery question:</p>
<blockquote>
<p>"Ordered Friday. Delivery takes 9 days, weekends included." Which day does it arrive?</p>
</blockquote>
<p>At a glance, Saturday and Sunday look about equally likely. Getting it right takes counting, and a model that can only glance has no way to slow down. It picks one, fast, and your code has nothing to tell it that this answer was a coin flip.</p>
<p>That's the System 1 failure: not that it's wrong sometimes (every model is), but that the hard questions get the same treatment as the easy ones.</p>
<h2>The gap between them</h2>
<p>Put the two side by side and the gap is clear:</p>
<ul>
<li><p><strong>System 2</strong> is careful on every question, including the many that don't need it.</p>
</li>
<li><p><strong>System 1</strong> is fast on every question, including the few that do need care.</p>
</li>
</ul>
<p>What you want is fast on the easy majority and careful on the close calls, decided per question, with the same kind of answer either way. That's what we mean by System 1.5.</p>
<h2>What a System 1.5 model does</h2>
<p>Wity 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.</p>
<p>In <code>auto</code> mode the flow has three steps:</p>
<ol>
<li><p><strong>Direct read.</strong> Wity answers at once and checks whether that answer is robust: a clear winner that doesn't change when the options are presented differently.</p>
</li>
<li><p><strong>Close call?</strong> Most questions pass, and the answer comes straight back. If not, it thinks.</p>
</li>
<li><p><strong>Think, then stop.</strong> It reasons step by step and stops as soon as the answer has settled, instead of running a fixed long chain of thought.</p>
</li>
</ol>
<p>There are three reasons it will think:</p>
<ul>
<li><p><code>close_call</code>: the top options are close. A ticket at 0.51 billing and 0.46 account access deserves a closer look.</p>
</li>
<li><p><code>order_sensitive</code>: the answer changes with the order of the options. A sound answer shouldn't depend on that.</p>
</li>
<li><p><code>forecast</code>: the question asks how likely something is, not which answer is right.</p>
</li>
</ul>
<p>Back to the delivery question. Saturday and Sunday are close, so Wity counts: Friday plus seven is Friday again, then Saturday, then Sunday. It answers Sunday, and is now sure of it.</p>
<p>Most thoughts finish in a few hundred tokens, and thought answers typically take one to four seconds. The easy questions in the same request still come back at direct-read speed.</p>
<h2>You can see when it thought</h2>
<p>Every answer says whether it thought, and why:</p>
<pre><code class="language-json">"reasoning": {
  "mode": "auto",
  "thought": true,
  "reason": "close_call",
  "thought_tokens": 184
}
</code></pre>
<p>Log that next to each decision. A question that often thinks for <code>close_call</code> is telling you two of its options overlap. Sharper descriptions, or splitting it in two, make it both faster and more accurate.</p>
<h2>Choosing the mode</h2>
<p>One field sets it for the whole request:</p>
<pre><code class="language-json">{ "state": "…", "questions": { … }, "reasoning": "auto" }
</code></pre>
<ul>
<li><p><code>auto</code> for almost everything: fast where it can be, careful where it has to be.</p>
</li>
<li><p><code>off</code> for the lowest, most predictable latency, like a step in an interactive UI. Close calls still show up as close probabilities, so your thresholds keep working.</p>
</li>
<li><p><code>always</code> for batch jobs where every decision is expensive to get wrong and nobody is waiting, like overnight review of flagged transactions.</p>
</li>
</ul>
<p>The output type is the same in every mode, so switching never changes your code. Thinking isn't billed either, so a thought answer costs the same as a direct one. The only reason to turn it off is time, not money.</p>
<h2>Where this leaves you</h2>
<p>No model is perfect, and a 1.5 model doesn't change that. What changes is where the effort goes: none on the questions that don't need it, and some on the ones that do. The probability on every answer still lets your code decide when to act and when to hand a decision to a person.</p>
<p>The <a href="https://wity.alphanimble.com/docs/reasoning">reasoning docs</a> cover the modes, the response fields and how to plan around latency.</p>
]]></content:encoded></item><item><title><![CDATA[What is Wity? The first System 1.5 model, explained]]></title><description><![CDATA[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…]]></description><link>https://wity-1.hashnode.dev/what-is-wity-the-first-system-1-5-model-explained</link><guid isPermaLink="true">https://wity-1.hashnode.dev/what-is-wity-the-first-system-1-5-model-explained</guid><category><![CDATA[AI]]></category><category><![CDATA[Machine Learning]]></category><category><![CDATA[llm]]></category><category><![CDATA[api]]></category><dc:creator><![CDATA[Abhishek Kundagol]]></dc:creator><pubDate>Mon, 19 Oct 2026 11:51:18 GMT</pubDate><content:encoded><![CDATA[<p>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?</p>
<p>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.</p>
<h2>Two kinds of model, two kinds of problem</h2>
<p><strong>Large language models think through every question</strong>, 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.</p>
<p><strong>Fast decision models answer in a single glance.</strong> Easy calls come back instantly. Hard ones come back instantly too, and confidently wrong, because the model has no way to slow down.</p>
<h2>What "System 1.5" means</h2>
<p>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.</p>
<p>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: <strong>a typed decision with a probability for every option.</strong> That's why we call it a System 1.5 model. It sits between instinct and deliberation and picks per question.</p>
<h2>What a decision looks like</h2>
<p>You send a <em>state</em> (the thing to decide about: text, JSON, an image, or all three) and one or more questions with the options spelled out:</p>
<pre><code class="language-bash">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"
  }'
</code></pre>
<p>The answer comes back under the name you gave the question:</p>
<pre><code class="language-json">{
  "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 }
}
</code></pre>
<p>There's no prose to parse. <code>choice</code> is the option to act on, and <code>probabilities</code> covers every option you offered. <code>reasoning.thought</code> is <code>false</code> here because the question was clear, so Wity answered directly.</p>
<h2>Four primitives, every answer typed</h2>
<p>Every question takes one of four shapes. You pick the shape, Wity fills it:</p>
<ul>
<li><p><strong>noul</strong>: a yes-or-no call. <em>"Was the insured driver at fault?"</em></p>
</li>
<li><p><strong>score</strong>: where on a scale something sits. <em>"How bad is the damage: cosmetic, repairable or total loss?"</em></p>
</li>
<li><p><strong>choice</strong>: one option from a set. <em>"Which team owns this?"</em></p>
</li>
<li><p><strong>generate</strong>: the short text an action needs, in a shape you define. <em>"The policy number from the scan."</em></p>
</li>
</ul>
<p>Because every decision carries its probabilities, your code decides how sure is sure enough:</p>
<pre><code class="language-python">intent = answers["intent"]
if intent["probabilities"][intent["choice"]] &gt;= 0.85:
    route(ticket, intent["choice"])       # sure enough: act on its own
else:
    send_to_triage(ticket)                # close call: a person decides
</code></pre>
<p>Act on clear calls, hand close ones to a person, and set that line per question.</p>
<h2>Five things that set it apart</h2>
<ol>
<li><p><strong>Multimodal.</strong> Photos, screenshots and scanned pages go in the same request as your text.</p>
</li>
<li><p><strong>128K-token context.</strong> A whole contract, a long email thread or a stack of scans fits in one state. No chunking.</p>
</li>
<li><p><strong>generate.</strong> A primitive for the few places software genuinely needs words, written from the same state, right after the decision.</p>
</li>
<li><p><strong>Auto-thinking.</strong> Instant on clear-cut questions, deliberate on shaky ones, decided per question.</p>
</li>
<li><p><strong>On-prem.</strong> It can run inside your own network, with the same API as the cloud.</p>
</li>
</ol>
<h2>Fast and cheap enough to put everywhere</h2>
<p>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 <strong>109 ms</strong>, against 943 ms for the next fastest. 1,000 runs cost <strong>$3.29</strong>, against $17.95 for the next cheapest. That's our own benchmark, and the method is published alongside it.</p>
<p>Pricing is one number: <strong>$0.042 per 1M tokens, and failed calls are free.</strong> Thinking isn't billed, so a thought answer costs the same as a direct one.</p>
<p>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.</p>
<h2>What's next</h2>
<p>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.</p>
<p>If you want to try it now, the <a href="https://wity.alphanimble.com/docs/quickstart">quickstart</a> 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 <a href="https://wity.alphanimble.com/console/playground">Playground</a> runs real requests from your browser with no code at all.</p>
]]></content:encoded></item></channel></rss>