Introducing Krun One: A Decision Model Built for AI Systems

Large language models are excellent at generating text.

But many production AI systems do not need more text.

They need a decision.

Which tool should run?

Which agent should handle a request?

Which intent best matches the user?

Should the system retrieve more context?

Should it act — or abstain?

That is the problem Krun is built to solve.

Today, we are introducing Krun One, our first decision model for AI systems.

Krun One is designed to take structured context, evaluate a set of possible decisions, and return a calibrated answer with probabilities and confidence.

Instead of generating a long sequence of tokens, Krun returns a decision.

Decisions, not completions

A traditional LLM workflow often looks like this:

context
→ prompt
→ generate text
→ parse the response
→ validate it
→ hope the model followed the schema

Krun is designed around a different primitive:

context
+
questions
+
runtime options
→
structured decisions

A request can look like this:

{
  "context": "Customer wants to return an item and asks about the refund.",
  "questions": {
    "department": {
      "type": "choice",
      "options": {
        "shipping": "Shipping and delivery issues",
        "returns": "Returns and refunds",
        "billing": "Billing and payment issues"
      }
    }
  }
}

And Krun One returns:

{
  "model": "krun-one-v0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 0.984087,
      "probabilities": {
        "shipping": 0.005228,
        "returns": 0.98943,
        "billing": 0.005342
      },
      "abstain": false,
      "abstention_status": "advisory"
    }
  },
  "usage": {
    "input_tokens": 54
  }
}

There is no generated prose to parse.

The output is already the decision.

One request, multiple decisions

Krun One can evaluate multiple structured questions in a single model call.

For example, the same customer message can be evaluated for department and priority at once:

{
  "context": "Customer wants to return an item and asks about the refund.",
  "questions": {
    "department": {
      "type": "choice",
      "options": {
        "shipping": "Shipping and delivery issues",
        "returns": "Returns and refunds",
        "billing": "Billing and payment issues"
      }
    },
    "priority": {
      "type": "choice",
      "options": {
        "low": "Can wait",
        "normal": "Normal priority",
        "high": "Needs quick attention"
      }
    }
  }
}

Krun returns both answers in one response.

This matters for agent systems, where a single observation can require several decisions before execution.

Knowing when not to decide

A useful decision model should not be forced to choose.

Krun One can abstain when the decision signal is not strong enough.

A response may look like:

{
  "choice": null,
  "confidence": 0.713767,
  "probabilities": {
    "low": 0.101997,
    "normal": 0.815764,
    "high": 0.082239
  },
  "abstain": true
}

The probability distribution is still available, but the model explicitly tells the application not to treat the top option as a confident decision.

This is particularly useful for systems that can fall back to a larger model, ask the user for clarification, or escalate to a human.

Krun's confidence value is the margin between the two highest-probability options. It is not a direct estimate of the probability that the model is correct.

From Laya to Krun One

Krun One v0 started from the open Laya decision-model architecture.

We kept the architecture and fully fine-tuned the model on 172,430 decision examples focused on the workloads we care about:

intent routing
tool routing
multilingual decisions
hard negative selection
out-of-distribution cases
option-order robustness

The training mixture included public datasets such as:

Banking77
MASSIVE
xLAM-60k
ToolACE
xlam-irrelevance

BFCL was kept out of training and used as an external evaluation set.

The goal was not to make the model larger.

The goal was to make the same class of model significantly better at real decision workloads.

The results

Krun One improved substantially over the original Laya checkpoint across the benchmarks we use for product validation.

Benchmark	Laya	Krun One
Intent routing — validation	64.04%	96.01%
Intent routing — KrunBench final	66.98%	96.09%
Hard-negative intent routing	49.45%	91.29%
Tool routing — validation	68.05%	94.86%
Tool routing — holdout	69.74%	96.42%
BFCL	83.39%	92.33%
Option-order consistency	67.8%	98.9%

Krun One also improved out-of-distribution detection:

Evaluation	Laya	Krun One
KrunBench OOD AUROC	0.669	0.947
Tool holdout OOD AUROC	0.724	0.993

And calibration improved as well:

Laya ECE:      0.0327
Krun One ECE: 0.0072

These results do not imply that Krun One is better at every possible decision task.

They show that targeted training can dramatically improve a specialized decision model on the workloads we are building Krun for.

Tool routing

Tool selection is one of the main areas we are focused on.

For example:

{
  "context": "Find my meetings tomorrow.",
  "questions": {
    "tool": {
      "type": "choice",
      "task_type": "tool",
      "options": {
        "calendar_search": "Search calendar events",
        "send_email": "Send an email"
      }
    }
  }
}

Instead of asking a generative model to reason in text and then parsing its answer, Krun directly scores the available tools.

This pattern can be used for:

function calling
agent routing
RAG routing
model routing
workflow branching
escalation
classification

Tool abstention is still marked as advisory in the current version. In real-world BFCL irrelevance cases, it is not yet as reliable as our internal tool holdout. Improving this with production traffic is one of our priorities for the next Krun One iteration.

Built for production systems

Krun One is already running behind the Krun API.

The current stack is:

Developer
   ↓
Krun API
Rust / Axum
   ↓
RunPod Serverless
   ↓
Krun One

The API supports:

API keys
rate limits
quotas
usage tracking
structured errors
feedback
request IDs
multiple decisions per request

The model itself takes roughly 40 ms per decision on the current serverless GPU environment when warm.

End-to-end request latency is higher because serverless scheduling, networking, and cold starts add overhead.

For now, we intentionally keep the infrastructure scale-to-zero during the Closed Beta.

Python SDK

The official Python SDK is available today:

pip install krun-ai

Example:

from krun import Krun

client = Krun()

result = client.decide(
    context="Customer wants to return an item.",
    questions={
        "department": {
            "type": "choice",
            "options": {
                "shipping": "Shipping and delivery issues",
                "returns": "Returns and refunds",
                "billing": "Billing and payment issues",
            },
        }
    },
)

answer = result.answers["department"]

print(answer.choice)
print(answer.confidence)
print(answer.probabilities)

A TypeScript SDK is also on the way.

Where we are going

Krun One v0 is the beginning, not the final model.

Our next iterations will focus on:

better real-world tool abstention
harder tool-routing cases
feedback-driven training
improved calibration
better serving efficiency
stronger decision quality on production workloads

The important part is that the feedback loop is now live:

real usage
→ difficult decisions
→ feedback
→ better training data
→ better Krun One

That is how we intend to make the model meaningfully better over time.

Closed Beta

Krun is currently in Closed Beta.

We are looking for developers building:

AI agents
tool-calling systems
routing layers
support automation
RAG pipelines
multi-agent applications
systems that currently use large generative models for small structured decisions

If that sounds like your stack, we would like to hear from you.

Krun is built for the decisions between the generations.