what is typesafe ai?

What TypeSafe AI Builds

TypeSafe’s public thesis is that software automation needs a different model interface from human chat. Its term “machine-native intelligence” describes models optimized for structured, observable and inexpensive decisions that other software consumes. Jev is the first public model in that System One category.

The product surface includes POST /v1/systemone, official clients for Python and JavaScript/TypeScript, a browser playground, documentation and worked cookbooks. The SDKs preserve typed questions and answers, configure retries and timeouts, and default to the jev-latest alias. Application code remains responsible for credentials, rules and actions.

The Public Interface Is State Plus Typed Questions

This example follows the documented conceptual request shape: shared state and named typed questions. The current API reference is authoritative for exact transport fields. A Noul estimates one yes/no proposition, Choice compares supplied alternatives, and Score uses ordered descriptive levels. Jev does not return a drafted support reply.

The distinction explains TypeSafe’s “machine-native” framing. The result is intended for software to validate, store and combine with application rules. The primitive guide covers response semantics, while the HTTP guide tracks the current endpoint contract.

{
  "model": "jev-1.13.0",
  "state": {
    "ticket": "Payouts have failed for three days",
    "account_tier": "business"
  },
  "questions": {
    "urgent": {
      "type": "noul",
      "instructions": "Does the evidence describe an urgent support issue?"
    },
    "queue": {
      "type": "choice",
      "instructions": "Which queue best owns this issue?",
      "criteria": {
        "billing": "Charges, invoices or refunds",
        "payouts": "Settlement or payout failures",
        "technical": "Product malfunction unrelated to money movement"
      }
    }
  }
}

What Is Public and What Is Not

The Public Repositories Are Integration Artifacts, Not Model Weights

A public repository should be cited at a specific commit or package version when implementation details matter. Inspect its license separately from hosted-service terms. The open-source status guide distinguishes open clients, compatible APIs and open weights.

The Public Product Surface Has Four Distinct Layers

Confusing these layers creates inaccurate claims. A public SDK is not an open-weight model, and a provider listing is not a complete evaluation platform. The platform comparison distinguishes direct and third-party access; Jev eval platforms covers orchestration around the model.

TypeSafe Supplies Inference; the Application Owns the Decision System

This ownership boundary prevents a common category error: treating a model probability as an action. Jev can supply evidence for an evaluation or a runtime decision, but code still decides what happens and must handle timeout, missing evidence and provider failure. The evals overview and Jev-versus-rules guide show the two sides of that boundary.

Current Jev Facts Require Dates and Provider Context

As verified September 22, 2026, TypeSafe lists jev-1.13.0 as stable and shows both jev-latest and jev-preview resolving to it. The same page publishes direct price, limits, English-first guidance and a no-training-use statement for customer requests and responses. These facts can change and should not be copied without a date.

Cloudflare also publishes a Jev route. An OpenRouter route page exists, but its public model catalog did not contain a TypeSafe or Jev entry during the same verification, so availability is not confirmed. The launch tracker records this correction and future changes.

Current Jev Fact Sheet

These values describe TypeSafe’s direct public surface at the review date. Cloudflare or another provider can use a different route ID, envelope, price, quota and data path. The model card, pricing guide and privacy review keep those dimensions separate.

How to Evaluate TypeSafe Claims

Separate three evidence layers. TypeSafe documentation is authoritative for its current API, price and declared model behavior. TypeSafe launch benchmarks are first-party measurements and should be attributed. Independent projects and X threads can reveal useful tasks and counterexamples, but require their own datasets, code and reproduction before their numbers become general claims.

Avoid using search snippets or secondary profiles for funding, valuation, founder history, customers or adoption. Those facts belong on this page only after a current primary announcement or a reputable publication can be cited directly.

Use an Evidence Hierarchy for Fast-Moving Claims

The claim-check ledger applies this hierarchy to speed, price, calibration, privacy and provider claims. The X roundup treats social posts as attributed leads and records what would reproduce them.

Evaluate the Product Claim at the Application Boundary

The benchmark methodology supplies a reproducible protocol. This evidence boundary matters because a vendor’s architecture description and an application’s measured outcome answer different questions.

1. Choose one bounded decision with an independently reviewable outcome.
2. Implement it through the exact provider and SDK version under consideration.
3. Freeze state projection, question wording, primitive and model version.
4. Compare with the simplest rule, classifier, judge or human baseline.
5. Measure errors, calibration, coverage, latency, cost and operational failures.
6. Publish which facts came from TypeSafe and which results came from your test.

Evaluate TypeSafe as a Model Dependency, Not Only a Demo

This is ordinary dependency diligence, not a Jev-specific warning. A fast typed model can simplify one decision step while the surrounding service still needs credentials, observability, data governance and rollback. The quickstart covers integration; regression testing covers controlled upgrades.

1. Confirm the current API, account access, model identity and provider route.
2. Review state fields, data classification, retention terms and every processor in the path.
3. Measure the target criterion against rules, a classifier, an LLM judge or human review as appropriate.
4. Load-test representative state lengths, concurrency, retries and tail latency.
5. Pin the accepted model and SDK versions and retain response fixtures.
6. Define fallback, monitoring, migration and incident ownership before production use.