What Is Jev? Inside TypeSafe AI's System One Model

TL;DR

• Jev is TypeSafe AI's first System One model, a frontier model that returns typed decisions and calibrated probabilities instead of generated text.
• Jev is non-autoregressive: it ingests one state, evaluates every question against it in parallel, and returns all answers in a single pass in 70ms to 500ms.
• Jev is priced at $0.042 per million input tokens with output billed at zero, against a headline benchmark of 193.6x faster and 444.6x cheaper on System One tasks.
• Jev cannot emit a value outside the answer space you define, which removes schema and parse failures, but it can still be confidently wrong.
• The practical effect is a two-tier model stack: narrow, high-volume decisions move to a System One model while generation stays with an LLM.

TypeSafe AI released Jev on September 15, 2026, alongside $40 million in funding and a claim that most production AI work does not need a model that writes sentences at all. Jev belongs to a category TypeSafe calls System One models, which take unstructured program state as input and return typed, probabilistic decisions your code can branch on directly. For teams already routing production model traffic through Bifrost, the open-source AI gateway built in Go by Maxim AI, a second and structurally different model class is an architectural question as much as a procurement one. This post covers what Jev is, how it works internally, where the breakthrough sits, what it is bad at, and which workloads move to it first.

What Is Jev?

Jev is a text-input decision model that evaluates a block of state against a set of typed questions and returns a structured answer for each one, with a probability distribution and a confidence value, in a single API call. It generates no text. The answer space for every question is enumerated in the request, so the response is a value from a set the caller defined, not a string to parse.

That output contract is the whole design. A large language model is a text generator, so using one for classification means writing a prompt, asking for JSON, parsing the result, handling malformed JSON or invented labels, and retrying. Teams on that pattern end up with a validation layer whose job is recovering structure from prose, sitting alongside the guardrails they already run on model output. Jev removes that layer by never producing prose.

The category name comes from Daniel Kahneman's Thinking, Fast and Slow, where System 1 describes fast, intuitive judgment and System 2 describes slow, deliberate reasoning. TypeSafe's position is that the fast half has been served badly by models built for the slow half.

What Is a System One Model?

A System One model is a class of AI model that evaluates a state and returns typed answers with calibrated probabilities, rather than generating text for a person to read. Like an LLM it understands natural-language input; unlike an LLM it does not write replies, produce code, or explain its reasoning. Jev is the first model in the category.

The two model types are optimized against different objectives and fail in different ways.

The row carrying the most engineering weight is the answer space. When the set of possible outputs is enumerated in the request, an out-of-schema answer is not a bug caught downstream, it is a state the system cannot enter. That closed answer space is also what makes the probability distribution meaningful: mass is distributed across options you named, so its shape is directly interpretable. Anyone who has run LLM-as-a-judge evaluation at scale knows how much operational effort goes into stabilizing exactly that.

How Jev Works: One State, Many Questions, One Pass

Jev takes two fields. The state is the content to evaluate: a string, a JSON object, or an array of text values. The questions map holds one or more typed questions, each with an ID you choose. Every question sees the same state, is evaluated independently and in parallel, and returns an answer under its ID.

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": [
        "Calm, just stating facts",
        "Frustrated but civil",
        "Very angry, strong language"
      ]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

The response, abridged here, carries the typed answers with their distributions:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": { "technical": 0.85, "sales": 0.0, "billing": 0.15 }
    },
    "frustration": {
      "type": "score",
      "score": 1.0,
      "confidence": 1.0,
      "probabilities": { "0": 0.0, "1": 1.0, "2": 0.0 }
    },
    "is_urgent": { "type": "noul", "noul": 1.0 }
  }
}

Three properties of that exchange matter, each for a different reason.

• The state is ingested once. Jev reads the state a single time and scores every question against that representation, so adding questions barely changes the response time.
• Questions are isolated. One question's answer never becomes hidden context for another. There is no ordering effect, no accumulated conversation, and no context rot across a batch.
• There is no decoding loop. Response time is not a function of how many tokens the answer contains. The answer is a handful of floats regardless of how complex the judgment was.

The third property is the architectural break. An autoregressive model produces one token per forward pass, so latency scales with output length and the decode step is the bottleneck. TypeSafe attributes Jev's 70ms to 500ms response time to exactly this: it outputs all probabilities in parallel instead of generating token by token, which is also why response time stays flat as questions are added. The pricing follows from it. Output is a handful of numbers, and TypeSafe lists output tokens as free ("too cheap to meter"), inverting the usual economics of running LLM inference in production.

Token accounting and the cost of fan-out

Every response carries a usage object with input_tokens and output_tokens, and only input is billed. The asymmetry is structural: the bug-severity example in TypeSafe's Score documentation reports 332 input tokens against 18 output tokens, because the output is a few floats and a legend rather than prose.

The part that changes how you design a request is that Jev ingests the state once and evaluates every question against it, and the context budget is counted the same way: state plus all questions combined. TypeSafe's documented usage figures are consistent with a cheap marginal question. Single-question examples in the API reference report roughly 300 to 330 input tokens, while the three-question quickstart request reports 392. Against an autoregressive model the same work is either several prompts that each re-send the document, or one prompt whose combined answer has to be parsed apart afterward.

Two budgets bound a request. The total is 64k tokens for the state plus all questions combined, and a second 32k limit applies to the state plus the single longest question, so no individual question can push the state over the smaller ceiling.

The published rate limits, 250,000 tokens per second and 1,200 requests per minute, bind at different points. 1,200 requests per minute is 20 per second, so the token ceiling only starts to matter above roughly 12,500 input tokens per request. Below that the request count is the constraint; above it, tokens are. That crossover is worth deriving for your own payload size before planning capacity.

Together these make speculative fan-out a sensible default rather than a micro-optimization. Because a marginal question costs a few dozen tokens and, per TypeSafe, barely changes the response time, you can ask questions you may not need and discard the answers in code. TypeSafe's triage example asks for category, bug severity, reproducible steps, refund requested, and frustration in one call, then ignores whichever branches do not apply.

The Three Primitives: Choice, Score, and Noul

Jev exposes three question types. Each defines a different shape of answer space and returns a different response structure. All three can be mixed in a single request.

Choice fits unordered categories: routing a ticket to a department, classifying a document type, detecting a programming language. TypeSafe recommends an explicit other option when the list may not cover every input. A Choice question accepts up to 255 options, each costing only a few tokens, so TypeSafe recommends passing the full list rather than a shortlist. For higher cardinality, TypeSafe describes a two-stage approach: score candidates independently, then make an explicit choice among the survivors.

Score fits a spectrum you can describe level by level: bug severity, customer frustration, candidate seniority. The model returns a position along your levels plus the distribution across them. The score can be fractional, useful for thresholding but not for reconstructing an exact underlying number.

Noul is a yes/no question where the probability itself is the signal. It returns one value from 0 to 1 and carries no separate confidence, because for a binary question the probability already expresses the uncertainty.

How a Score is actually computed

A Score's criteria is an ordered array of level descriptions, at least two and at most ten. Each entry's index is its level number starting at 0, so the order of the array is the numbering, and the model sees the descriptions with nothing else. Each level is judged on its own against the state.

The response returns a probability for every level, summing to 1, a legend mapping level numbers back to their descriptions, and a score. The score is the expectation over that distribution: each level number multiplied by its probability, summed.

{
  "bug_severity": {
    "type": "score",
    "score": 1.43,
    "confidence": 0.35,
    "legend": {
      "0": "Cosmetic; no impact to functionality",
      "1": "Broken or degraded feature, but workaround exists",
      "2": "Blocking issue; no workaround exists"
    },
    "probabilities": { "0": 0.0, "1": 0.57, "2": 0.43 }
  }
}

That score is 0 x 0.0 + 1 x 0.57 + 2 x 0.43 = 1.43, and the confidence of 0.35 reflects how evenly the mass is split between two adjacent levels. The state behind it was a crash affecting only Safari users, which is genuinely ambiguous: a workaround exists for most customers but not for the ones on Safari, and the distribution says exactly that.

Two consequences follow, and both are easy to get wrong. A fractional score is not a finer-grained judgment, it is the mean of a distribution over discrete levels, so 1.43 means the model is split between levels 1 and 2 rather than placing the bug at a precise point between them. And TypeSafe specifically warns against interpolating between levels to reconstruct an underlying magnitude: thresholding the expectation is supported, reading it as a measured quantity is not.

Instructions and criteria accept structure, not just strings

instructions, Choice option descriptions, Score level descriptions, and a Noul's true and false descriptions all accept a string, an object, an array, or null. This matters when the judgment refers to something that is already structured, such as a schema, a taxonomy, or a database row, because passing the object directly avoids flattening it into a prose template and then hoping the model reads the template the way you meant it.

One field descriptor can then drive several question types in the same request. In TypeSafe's invoice example, a field object naming the field, its type, its unit, and its description is reused across a Noul that verifies an extracted value, a Choice that picks the correct span from candidate strings, and Scores that bucket the amount and the payment terms.

"amount_due": {
  "type": "score",
  "instructions": {
    "field": {
      "name": "amount_due",
      "type": "number",
      "unit": "USD",
      "description": "The total the invoice asks to be paid."
    },
    "question": "How large is the `field` value in `source_text`?"
  },
  "criteria": ["Under $1,000", "$1,000 to $10,000", "$10,000 to $100,000", "$100,000 to $1,000,000", "Over $1,000,000"]
}

Because the questions are generated rather than written by hand, a loop over the fields of a record produces one question per field, all sent in a single call.

The design guidance that follows is decomposition. A question like "rate this startup pitch" weighs several independent factors and is a poor fit. Asking separately about market size, technical feasibility, and differentiation, then combining the scores with weights held in your own code, keeps each evaluation narrow and moves the weighting logic somewhere you can version and test without touching a prompt. This is the same discipline that makes evaluator design tractable when debugging judge failures in production: atomic criteria are inspectable, composite ones are not.

Calibration, Confidence, and Why RLCD Replaces RLHF

Jev is trained with Reinforcement Learning for Calibrated Decisions, an objective that optimizes probabilities against outcomes rather than human preference. TypeSafe positions RLCD as a third post-training path alongside RLHF and RLVR, which matters because the objective determines what a model is good at.

Calibration is measured across groups, not single answers

A well-calibrated model is one whose stated probabilities match observed frequencies: outcomes assigned 0.2 occur about 20% of the time, outcomes assigned 0.8 about 80%. That is a property of groups of predictions, not a guarantee about any individual answer, and TypeSafe is explicit about the distinction.

RLHF optimizes for outputs people prefer, which is the right objective for a conversational assistant and the wrong one for a decision component. Preference optimization rewards fluent, confident-sounding output, a direct incentive toward sycophancy and toward stating uncertain conclusions in certain-sounding language. It also causes mode dropping, where the model narrows toward a favored style and suppresses the probability of other valid outputs. For a chatbot that is a stylistic quirk. For a component whose probabilities drive a routing decision, it corrupts the signal the caller depends on. Diogo Almeida, TypeSafe's cofounder and CEO, is a former OpenAI researcher credited as one of the co-inventors of RLHF.

Confidence is a convenience statistic, not a specification

confidence is computed from the probabilities already present in the answer, collapsing the shape of the distribution into one number so you can threshold on it without doing the math. The interactive explorer in TypeSafe's confidence documentation computes it as (n x p_max - 1) / (n - 1), where n is the number of options or levels and p_max is the largest probability. That is the top probability rescaled so a uniform distribution scores 0 and a certain one scores 1, and it reproduces the documented examples: (3 x 0.85 - 1) / 2 = 0.775 for the department Choice above, returned as 0.78, and (3 x 0.57 - 1) / 2 = 0.355 for the bug-severity Score, returned as 0.35.

Two properties follow from that form. Normalizing by n means 0 always means "no better than uniform" regardless of how many options the question has. And because only the peak enters the calculation, the statistic ignores how the remaining mass is arranged: 0.57 / 0.43 / 0.00 and 0.57 / 0.22 / 0.21 produce the same confidence even though the first is a two-way split and the second is not.

That second property is why TypeSafe says you are not locked into its definition, and the stated reason the full distribution ships with every Choice and Score answer. If the default does not fit your decision, compute your own measure from probabilities, such as the margin between the top two outcomes or normalized entropy across the distribution.

Noul answers carry no confidence at all, and the reason is structural rather than an omission. A Noul distribution has exactly two outcomes, so the single returned value describes it completely; a Choice or Score spreads mass over several options or levels, and confidence is the summary of that spread.

Confidence thresholds scale with risk

Choice and Score answers include a confidence value from 0 to 1, computed from the shape of the probability distribution. A distribution concentrated on one outcome yields high confidence; a flat distribution yields low confidence. Low confidence on a Choice means no option is a clear winner; on a Score it means the levels are ambiguous or the state lacks enough to judge.

Surfacing that number lets code behave differently at different certainty levels. The shape TypeSafe documents puts the floor and the ceiling in different places for different actions:

action = response.answers["action"]

if action.confidence < 0.5:
    route_to_human(user_message)          # genuinely unsure, do not guess
elif action.choice == "check_balance":
    show_balance(account_id)              # read-only, 0.5 is enough
elif action.choice == "approve_transfer":
    if action.confidence > 0.9:
        confirm_then_execute(account_id)  # irreversible, but high confidence
    else:
        ask_user_to_confirm(account_id)

Two thresholds are doing different jobs there. The 0.5 floor is a global gate that catches anything the model reports as genuinely uncertain, regardless of which action was chosen. Above it, the bar for acting without human confirmation is set per action, so a read-only lookup proceeds at 0.5 while an irreversible transfer needs 0.9. The risk tolerance lives in code, where it can be versioned and tested, rather than inside a prompt. TypeSafe is explicit that these specific numbers are a starting point to be tuned against your own data, not defaults to inherit. A model that can say "I am not sure about this one" in a machine-readable way is the precondition for automating anything consequential, which is the same reasoning behind human-in-the-loop escalation in evaluation pipelines.

Jev Speed and Cost Compared to an LLM Call

TypeSafe's published comparison shows Jev completing a System One task in 0.114 seconds against 8.566 seconds for a frontier LLM, at $0.000081 against $0.013880, summarized as 193.6x faster and 444.6x cheaper. TypeSafe notes these are upper-end figures and gives a general range of 40x to 200x faster on comparable tasks.

The published operating envelope for the current model is narrow and specific:

Those numbers are documented on the TypeSafe models page. The aliasing detail is worth reading closely: an alias moves when a new release ships, and the response reports the versioned ID that answered, so confidence thresholds tuned against one version should be pinned to that version.

The cost figure changes which architectures are affordable rather than making an existing one cheaper. At roughly four cents per million input tokens, running a semantic check on every model response, scoring every retrieved passage, or classifying an entire trace corpus stops being a budget line worth arguing about. The same arithmetic drives most LLM cost optimization work, where the win comes from not sending the request to an expensive model at all.

Jev Use Cases in Production Software

Jev fits workloads with high volume, repeated judgments over a shared state, and a known answer space. TypeSafe's framing is "building prod, not God": the model is a component inside software that code controls, not an agent choosing its own next action.

Guardrails and verification for other models

Placing a semantic check on every LLM input, output, and tool call is normally rejected on cost grounds, because the check costs as much as the call it is checking. At Jev's price that objection disappears. The workload maps onto Noul questions: does this input contain a prompt injection attempt, does this response cite a passage that supports it, does this tool call match the user's stated intent, does this output disclose sensitive data. Teams running AI guardrails at the gateway layer are describing the same control point, and the economics of catching hallucinations on every model response change when, on TypeSafe's numbers, the checker costs two orders of magnitude less than the model being checked.

Model routing and intent classification

Routing is a classification problem with a closed answer space, the exact shape Jev is built for. A Choice question over handler names plus a Score question over difficulty, returned together in one call, decides whether a request goes to deterministic code, a cheap model, a frontier model, or a person. Confidence gates it: below threshold, escalate. This is a more precise version of what LLM routers do with heuristics and embeddings, and where model routing to cut token costs gets most of its savings.

Retrieval, reranking, and relevance scoring

Embedding similarity is cheap and approximate. Cross-encoding is accurate and expensive. Jev sits between them. TypeSafe's re-ranking cookbook asks one Noul per query-candidate pair and sorts candidates by the returned probability, at a price that makes per-passage scoring viable across a large candidate set. That supports reranking and filtering irrelevant passages before they reach a generator, a direct attack on the lost-in-the-middle failure mode in long-context RAG and on the problems covered in the RAG reliability stack.

Large-scale classification and feature extraction

Batch workloads priced out of LLM classification become tractable: labeling interview transcripts against a codebook, screening papers against inclusion criteria, classifying millions of agent traces, scoring inbound leads against an ideal customer profile. Because the output is a probability rather than a label, the results can also serve as probabilistic features for a conventional model trained on ground-truth outcomes, a different use than treating Jev as the final classifier.

Composite scoring: one call, several weightings

Decomposition pays off twice when the same evidence feeds more than one decision. Scoring a resume on four independent dimensions in a single call returns four distributions; normalizing each by the top level number puts them on a 0 to 1 scale, and the weighting then happens in code.

a = response.answers
dims = {k: a[k].score / 4 for k in
        ("python_depth", "team_leadership", "system_design", "generalist")}

senior_ic = (0.40 * dims["python_depth"] + 0.10 * dims["team_leadership"]
             + 0.40 * dims["system_design"] + 0.10 * dims["generalist"])

eng_manager = (0.15 * dims["python_depth"] + 0.40 * dims["team_leadership"]
               + 0.20 * dims["system_design"] + 0.25 * dims["generalist"])

Both role rankings come from one model call, because the dimensions were scored independently rather than rolled into a single "rate this candidate" judgment. Rebalancing the criteria means editing coefficients and re-running the arithmetic over stored scores. Nothing has to be re-evaluated, no prompt changes, and the individual dimension scores stay available for audit, which matters when a screening decision has to be explained.

Real-time control and interactive systems

Response times at the low end of Jev's 70ms to 500ms range put model inference inside the interaction loop rather than after it. TypeSafe's launch demos lean on this deliberately. One has Jev playing Doom from a structured text representation of the game state (not images) at about 10 queries per second, which TypeSafe puts at roughly $7 per hour. The other is Wikiracing, navigating from one Wikipedia page to another where each step can mean choosing among hundreds to thousands of links. TypeSafe concedes a conventional bot would play Doom better; the point is a decision loop that follows natural-language instructions fast enough to sit inside a game loop, a UI, or a control system.

Where Jev Falls Short

TypeSafe publishes a list of Jev's failure modes for version 1.13, a more useful artifact than most model cards and worth reading before committing a workload. The ones most likely to shape a design:

Two of these deserve emphasis. The first is that "cannot hallucinate" is a claim about the output space, not about correctness. Jev cannot return a label you did not define, invent a citation, or emit malformed JSON, which eliminates a real class of production failures. It can still select the wrong option with high confidence. Calibration reduces how often high confidence is wrong; it does not make it impossible, and a system designed as though it does will fail quietly.

The second is adversarial input. TypeSafe states plainly that Jev does not treat state as hostile by default and that content written to steer the model can move the answer. A model used as a defense against prompt injection is itself processing attacker-controlled text, so the checker needs the same PII, injection, and toxicity controls applied to anything else reading untrusted input. The rest are scoping decisions: text only, English-first accuracy, a 64k context budget, no images, audio, or video.

What System One Models Change About the AI Stack

The structural argument behind Jev is that large-scale automation will be roughly 99% machine-to-machine and 1% human-facing, and that a model whose output contract is human-readable text carries a lot of overhead in the 99% case. If that holds, the model layer splits in two rather than converging on one general model.

Three consequences follow for teams building production systems.

• The stack becomes tiered by decision type. Narrow, high-volume, closed-answer judgments move to a System One model. Generation, synthesis, code, and open-ended reasoning stay with an LLM. The interesting engineering shifts to the boundary between them.
• Uncertainty becomes routable. When a confidence value arrives with every decision, escalation policy moves out of prompts and into code, where it can be versioned and tested. That is a governance property as much as a reliability one, and it sits alongside the access control and policy enforcement teams already apply to model traffic.
• The orchestration layer carries more weight. Two structurally different model classes, with different latency envelopes, rate limits, and billing units, need one place where routing, budgets, and observability are defined. Spreading that logic across a dozen services is how organizations end up unable to say where their AI spend is going.

None of this is settled. Jev shipped in September 2026, the benchmark figures are the vendor's own, and the category has exactly one model in it. The narrower claim is the durable one: for classification, routing, scoring, and verification, a text generator was always the wrong tool, and there is now a model built for the job.

Running Jev Alongside LLMs Through an AI Gateway

Adding a model class with a different API shape, pricing unit, and latency budget is an infrastructure change before it is a modeling one. The Bifrost AI gateway is the layer where that consolidation happens: one OpenAI-compatible API in front of 25+ providers and 10,000+ models, adding 11 microseconds of overhead per request at 5,000 requests per second with a 100% success rate in sustained benchmarks. Overhead at that scale matters more, not less, when the model behind the gateway answers in 70 to 500 milliseconds.

Four gateway capabilities apply directly to a two-tier model stack:

• Virtual keys with budgets and rate limits give each team a scoped credential and spend ceiling, which is how a cheap high-volume model and an expensive low-volume one stay separately accountable.
• Automatic fallbacks keep a request path alive when a provider returns errors, which matters for a decision model inside an interactive loop.
• Observability puts every call through one telemetry pipeline, so decision latency and generation latency are measured in the same place.
• Semantic caching removes repeat work before it reaches any provider, covered in depth in cutting token spend with an AI gateway.

For regulated and large-scale deployments, Bifrost Enterprise adds clustering, VPC isolation, air-gapped deployment, and the governance controls that make a heterogeneous model estate auditable. The broader case for one control plane is covered in what an AI gateway is and how it works.

Frequently Asked Questions

What is Jev in simple terms?

Jev is an AI model that makes decisions instead of writing text. You send it a block of content and a set of questions with defined answer options, and it returns the selected answer for each one along with a probability distribution and a confidence value. Your code reads those values directly, with nothing to parse out of a sentence.

How is a System One model different from an LLM?

A System One model returns typed decisions with calibrated probabilities; an LLM returns generated text. Jev is non-autoregressive, evaluating all questions in one parallel pass instead of decoding token by token, which is why response times land between 70ms and 500ms. An LLM handles generation and open-ended reasoning, which Jev does not do at all.

Can Jev really not hallucinate?

Jev cannot return a value outside the answer space defined in the request, so invented labels, malformed JSON, and fabricated citations are structurally impossible. It can still choose the wrong option, sometimes with high confidence. Jev eliminates format and schema failures, not judgment errors, which is why hallucination detection at the gateway remains a separate concern.

How much does Jev cost compared to an LLM?

Jev is priced at $0.042 per million input tokens, with output billed at zero because the output is a small set of numbers rather than text. TypeSafe publishes a comparison showing $0.000081 against $0.013880 for the same task on a frontier LLM. Savings on a real workload depend on how much of it is narrow classification rather than generation.

What are Jev's main limitations?

Jev accepts text only, with no image, audio, or video input, and works best in English. It does not count reliably, does not compare dates, and should not be used for arithmetic. Accuracy falls when the state carries a lot of irrelevant detail, and TypeSafe states that adversarially written content can steer the answer. Context is capped at 64k tokens per request.

When should you use Jev instead of an LLM?

Use Jev when the possible answers are known in advance, the same judgment runs at high volume, and the result feeds code rather than a person: routing, classification, scoring, extraction, and verification. Use an LLM for generating text or code, multi-step reasoning, or open-ended answers. Most production systems will route between both rather than choose one.

Getting Started

Jev is worth evaluating on a workload you already run through an LLM for classification, routing, or scoring, where accuracy can be measured against labels you already have. The shift it points at, a stack where narrow decisions and open-ended generation are served by structurally different models, puts more weight on the layer that routes, governs, and observes that traffic in one place.

That layer is where Bifrost sits, consolidating every model call behind one OpenAI-compatible API with per-team budgets, automatic failover, unified observability, and enterprise deployment options for regulated environments, whether the model on the other end generates text or returns a typed decision. To see how Bifrost handles a multi-model stack in production, book a demo with the Bifrost team.