DEV Community: dylan ma

What Is Jev? Decision Model Features, API, and Comparison with GPT-Class LLMs

dylan ma — Sat, 26 Sep 2026 15:11:56 +0000

If you’re searching “what is Jev”, “Jev decision model”, or “Jev vs GPT”, you’re probably picking a stack for high-volume classification: keep stuffing prompts into a chat model, or switch to a cleaner interface.

Jev (TypeSafe AI’s System One decision model) is not a chatbot and not “another LLM that writes copy.” It’s a typed, probabilistic decision API for unstructured text → finite labels → code branches.

This guide covers:

What Jev is (definition and positioning)
Jev features (latency, output contract, confidence, cost)
Jev vs large language models (when to use which)

Hands-on playground: tryjev.dev

TL;DR: Open-ended generation and multi-step reasoning → GPT-class LLMs. Fixed-label, high-volume classification (ticket routing, intent detection, urgency scoring) → Jev is usually faster, cheaper, and safer to branch on.

1. What is Jev?

What is Jev? Think of it as a decision model for System One work:

Input: unstructured text (email, support ticket, chat log, DOM snapshot…) as state, plus explicit questions (the judgments you care about).
Output: a typed label (selected), confidence, and a full probability distribution (distribution).
Job: classification, routing, and gating on the product hot path — the if statements you were going to write anyway.

Kahneman’s Thinking, Fast and Slow splits cognition into System One (fast, intuitive, pattern-matching) and System Two (slow reasoning and generation). Reading tone, judging urgency, and picking a queue are System One. Writing essays and multi-hop reasoning are System Two.

Jev = System One. Chat LLMs shine at System Two. You can use both — just don’t force a System Two tool into System One jobs.

Explore the request/response shape on the unofficial playground TryJev (tryjev.dev) with no API key, or read What is Jev for the product overview.

2. Jev features (why it belongs on the hot path)

These are the answers to “Jev decision model features” and the axes where it diverges from chat LLMs.

1. Typed output, not prose you must parse

A chat model might reply:

“It sounds like the customer hit a double charge; consider routing to billing…”

Then you bolt on JSON mode, regex, and retries to recover the label.

Jev returns:

{
  "selected": "billing",
  "confidence": 0.94,
  "distribution": {
    "billing": 0.94,
    "tech_support": 0.04,
    "sales": 0.02
  }
}

Labels are your queue keys (billing, tech_support, …) — ready for a switch or router table.

2. Full distribution, visible uncertainty

A single winner isn’t enough. Mixed tickets and ambiguous tone show up as a flattened distribution — that’s signal, not noise.

The production pattern:

const { selected, confidence, distribution } = await classify(ticket);

if (confidence < 0.7) {
  return enqueueHumanTriage({ ticket, distribution });
}
return route(selected, ticket);

That’s confidence-threshold routing: automate the high-confidence cases, send the rest to humans or a slow path (LLM).

3. Low latency for real-time classification

Budget	What fits
< 200ms	Inline classification while typing / on submit
200–500ms	Optimistic UI, then confirm
1s+	Background jobs, batch enrichment

Jev typically lands in the tens to low hundreds of milliseconds — fine for the first two. Chat generation often takes 1–5s and pushes work to a queue.

Long-tail: low latency text classification API, real-time intent detection, online ticket routing.

4. You pay for classification, not generation

Chat bills for prompt + completion. Classification only needs a label — so you pay for system prompts, few-shot examples, and a completion you throw away.

Decision models like Jev are usually priced on input (short state), with no generation tokens for the answer.

That matters for high-volume ticket routing, message tagging, and spam detection.

Long-tail: cheap classification API, LLM vs decision model cost, high-throughput text classification pricing.

5. Questions map to your branches

Type	Use when	Returns
`choice`	Pick one of N queues / intents	selected + per-option probability
`score`	Place on a scale (urgency, fit)	weighted position + per-level probability
`noul`	Yes/no with confidence	probability 0–1

A good question is the if you will compile:

“Which team should handle this?” → billing / tech_support / sales

Not: “Analyze the customer’s emotional state and summarize their needs.” That’s a System Two prompt, not a decision.

See the question design guide.

6. Safer failure modes

Failure	Chat LLM	Jev decision model
Uncertain	May invent a label / refuse	Flat distribution, low confidence
Format	Drift, rewrites, extra prose	Typed contract
Observability	Logs are paragraphs	Log full distributions, watch drift

3. Jev vs LLMs (how to choose)

Common long-tail questions: “Jev vs GPT difference”, “decision model vs LLM”, “LLM or specialized model for classification”.

Dimension	GPT-class chat LLM	Jev (System One decision model)
Main job	Generation, multi-step reasoning, tools	Fixed-label classification, routing, gating
Output	Prose / JSON you must parse	Typed value + confidence + distribution
Typical latency	1–5s even for short prompts	Tens to hundreds of ms
Billing	Prompt + completion tokens	Mostly input; no pay-for-generation on labels
Failure	Format drift, label hallucination, refusal	Flat distribution, visible uncertainty
Integration	Prompt engineering + parse + validate + retry	`state` + `questions`, maps to `if`
Best for	Writing, chat, complex extraction	Ticket routing, intent, urgency, tagging

Practical selection rules

Need generation, explanation, or multi-step work → chat LLM (GPT / Claude / Gemini…).
Need labels, branches, throughput, and low latency → Jev API.
Need both → Jev on the hot path for classify/gate; LLM on the slow path for drafts, explanations, and low-confidence overflow.

Jev vs GPT is not replacement — it’s System One vs System Two API design.

Deeper cost/latency breakdown: Jev vs GPT for classification.

4. How to call the Jev API (OpenRouter)

Jev is served through OpenRouter. Model ID: typesafe/jev-1.13.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev-1.13",
    "messages": [{
      "role": "user",
      "content": {
        "state": "I was charged twice for the same order #4821. Please fix this.",
        "questions": [{
          "type": "choice",
          "text": "Which team should handle this?",
          "options": ["billing", "tech_support", "sales"]
        }]
      }
    }]
  }'

Notes:

Keep punctuation and tone in state — they are the signal. Don’t pre-summarize.
Use real queue keys; 3–5 exclusive options. Avoid “Other” (it vacuum-cleans uncertainty).
Retry 429 with backoff; treat 400 as a contract bug.

Keys, errors, retries: Jev API tutorial (OpenRouter).

Fast setup: Jev quickstart.

5. Use cases (map your long-tail query)

Support ticket routing / triage

Keyword rules flip a coin on “charged twice + app won’t open.” Jev ticket routing reads the full ticket and returns per-queue probabilities; low confidence goes to human triage.

Guide: Jev support ticket routing

Message intent detection / tone classification

“Thanks anyway~” can be passive-aggressive, not casual chat. Three-way intent (genuine question / passive-aggressive / casual) works well.

Guide: Jev message intent detection

Urgency scoring / prioritization

Use score for “today / this week / whenever” and drive SLA and notifications.

Spam/phishing checks, refund-request detection, lead qualification, content tagging, feedback vs bug vs billing…

Library: Jev scenes

6. When you should still use an LLM

To answer “Jev limitations” / “can Jev replace an LLM” honestly:

Open-ended writing, chat, summarization → LLM.
Multi-hop reasoning, tools, free-form extraction → LLM.
Long “why” explanations for end users → LLM (Jev distributions can still inform them).
Tiny volume, huge value, full human review → latency doesn’t decide it.

Recommended stack: decision model (Jev) for where to go, LLM for what to say.

7. FAQ: What is Jev?

Q1: Is Jev a large language model?

More precisely, it’s a decision model / System One model for fixed-label classification — not open-ended generation. It complements GPT-class LLMs.

Q2: What is Jev good for?

Support ticket routing, message intent detection, urgency scoring, content tagging, real-time text classification on product hot paths.

Q3: Jev latency and pricing?

Typically tens to hundreds of milliseconds; classification is mostly input cost. Check OpenRouter / TypeSafe for live numbers, and the comparison post for modeling.

Q4: How do I start with Jev?

Play on tryjev.dev, then wire OpenRouter via the quickstart.

Next steps

Try it: Jev Playground (no API key)
Integrate: Jev API quickstart
Overview: What is Jev
More guides: Jev blog

TryJev (tryjev.dev) is an unofficial playground and documentation hub for the Jev decision model. Model by TypeSafe AI, served via OpenRouter.

Building a Static Encyclopedia with 1,000+ Entries, 8 Languages, and Zero Backend

dylan ma — Sun, 16 Aug 2026 05:02:13 +0000

TL;DR

I built a full-featured encyclopedia web app with 1,025 entries, 8 languages, and sub-second load times — all without a traditional backend. The trick? Mirror a public REST API as static JSON files at build time, deploy to Cloudflare Pages, and let the CDN do the heavy lifting.

Stack: Next.js 15 · TypeScript · Tailwind CSS · next-intl · Cloudflare Pages

The Problem

I wanted to build a reference site where users could browse, filter, and search a large dataset. The data was publicly available via a REST API, but:

Hitting the API on every request would be slow and rate-limited
A traditional backend felt like overkill for essentially static data
Multilingual support was a must — the audience is global

The dataset? A well-known creature encyclopedia with 1,025 entries, each with stats, types, abilities, evolution chains, and localized flavor text. (You probably know the one.)

The Architecture

┌──────────────┐      ┌───────────────────┐      ┌──────────────┐
│  Public API  │─────▶│  Static JSON      │─────▶│  Next.js     │
│  (PokéAPI)   │      │  /public/api/v2/  │      │  SSR / SSG   │
└──────────────┘      └───────────────────┘      └──────┬───────┘
                                                        │
                                                 ┌──────▼───────┐
                                                 │  Cloudflare  │
                                                 │  Pages CDN   │
                                                 └──────────────┘

Key insight: If the data rarely changes, fetch it once and serve it as static files. No runtime API calls, no database, no cold starts.

Step 1: The JSON Mirror

Instead of calling the public API at runtime, I pre-fetch all the data and store it as static JSON in /public/api/v2/.

// src/lib/api.ts
const API_BASE = '/api/v2';

export async function getPokemon(id: number) {
  const key = String(id);
  if (pokemonCache.has(key)) return pokemonCache.get(key);
  const data = await fetchJson(`${API_BASE}/pokemon/${key}.json`);
  pokemonCache.set(key, data);
  return data;
}

What we store per entry:

Core data (stats, types, abilities, moves, dimensions)
Species data (flavor text, egg groups, habitat, generation)
Evolution chains (full trees with trigger conditions)
Type matchups (damage relations for all 18 types)

Why this works:

Next.js serves /public/ files as static assets
Cloudflare CDN caches them globally — 300+ edge locations
No API keys, no rate limits, no external dependency at runtime
Data is version-controlled — you can see exactly what changed

Step 2: The Browsable Grid

The main page shows all 1,025 entries in a filterable grid. The filters:

Generation (9 options)
Type (18 options)
BST range (base stat total)
Legendary status toggle
Shiny mode toggle
Text search by name or number

The Challenge: 1,025 Entries Don't Load Instantly

Loading all entries at once would freeze the browser. Solution: batch loading with progressive rendering.

const PAGE_SIZE = 50;

useEffect(() => {
  const loadEntries = async () => {
    const pool = poolFor({ gen });
    const loaded = [];

    for (let i = 0; i < pool.length; i += PAGE_SIZE) {
      const batch = pool.slice(i, i + PAGE_SIZE);
      const results = await Promise.all(
        batch.map(async (id) => {
          try {
            const data = await getPokemon(id);
            return { id: data.id, name: data.name, types: data.types, stats: data.stats };
          } catch { return null; }
        })
      );
      loaded.push(...results.filter(Boolean));
      setEntries([...loaded]); // Progressive update — user sees cards appearing
    }
  };

  loadEntries();
}, [gen]);

Then I use Intersection Observer to render more cards as the user scrolls:

const [visibleCount, setVisibleCount] = useState(PAGE_SIZE);
const sentinelRef = useRef(null);

useEffect(() => {
  const observer = new IntersectionObserver(
    ([entry]) => {
      if (entry.isIntersecting) setVisibleCount((c) => c + PAGE_SIZE);
    },
    { rootMargin: '200px' }
  );
  if (sentinelRef.current) observer.observe(sentinelRef.current);
  return () => observer.disconnect();
}, [filteredEntries.length]);

Result: Users see the first 50 cards instantly, and more appear as they scroll — no janky layout shifts.

Step 3: The Detail Page

Each entry has its own detail page with:

Official artwork with a shiny toggle
Base stats with visual bars
Abilities (including hidden ones)
Full evolution chain
Type matchups (offensive and defensive)
Learnable moves table
Localized flavor text

Server-Side Fetching

The detail page uses SSR to fetch all data on the server:

export default async function DetailPage({ params }) {
  const { locale, id } = await params;
  const entryId = Number(id);

  const [entry, species, chainData] = await Promise.all([
    getEntry(entryId),
    getSpecies(entryId),
    getSpecies(entryId).then((d) => getEvolutionChain(d.evolution_chain.url)),
  ]);

  const typeNames = entry.types.map((t) => t.type.name);
  const relations = Object.fromEntries(
    await Promise.all(typeNames.map(async (name) => [name, await getType(name)]))
  );

  return <DetailClient entry={entry} species={species} chain={chainData.chain} relations={relations} />;
}

Dynamic SEO Metadata

Each detail page generates unique, keyword-rich metadata:

export async function generateMetadata({ params }) {
  const seo = await getSeo(entryId);
  const types = seo.typeNames.join(' / ');
  const number = String(entryId).padStart(4, '0');

  return {
    title: `${seo.name} (#${number}) — ${types} Base Stats, Abilities & Evolution`,
    description: `${seo.name} is a ${types} entry with BST ${seo.bst}. View base stats, abilities, evolution chain, and type matchups.`,
  };
}

Step 4: 8 Languages, One Build

The app supports: English, Japanese, Korean, German, Spanish, French, Portuguese, and Italian.

Translation Structure

{
  "Pokedex": {
    "title": "Pokédex",
    "lede": "Browse and filter all 1,025 entries by generation, type, and stats",
    "search": "Search by name or number...",
    "noResults": "No results match your filters."
  }
}

Using Translations

import { useTranslations } from 'next-intl';

export default function GridPage() {
  const t = useTranslations('Pokedex');
  return (
    <section>
      <h1>{t('title')}</h1>
      <p>{t('lede')}</p>
    </section>
  );
}

Localized Content from the API

Species-specific content (like flavor text) is already localized in the source data:

const genus = species?.genera?.find((g) => g.language.name === locale)?.genus;
const flavor = species?.flavor_text_entries?.find(
  (e) => e.language.name === locale
)?.flavor_text;

Step 5: Deploying to Cloudflare Pages

Why Cloudflare Pages?

Global CDN — 300+ edge locations
Free tier — generous for personal projects
OpenNext adapter — seamless Next.js deployment
Workers — SSR at the edge

The Cache Strategy

The key to fast load times is caching SSR responses:

// src/app/[locale]/layout.tsx
export const revalidate = 172800; // 48 hours

This tells Next.js: "Cache the rendered HTML for 48 hours. After that, the next request triggers a fresh SSR, and the result is cached again."

What this means in practice:

Scenario	Load Time
First visit (cold SSR)	4–8s
Subsequent visits (CDN hit)	<500ms
After 48h or redeploy	Cache refreshes

Redeploying automatically clears the CDN cache — no manual purge needed.

Build Configuration

// next.config.js
const nextConfig = {
  images: { unoptimized: true },
  experimental: { optimizeCss: true },
};

// wrangler.jsonc
{
  "main": ".open-next/worker.js",
  "assets": { "directory": ".open-next/assets", "binding": "ASSETS" }
}

Step 6: SEO That Actually Works

JSON-LD Structured Data

Every page includes JSON-LD for rich search results:

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify({
      '@context': 'https://schema.org',
      '@type': 'FAQPage',
      mainEntity: FAQ_ITEMS.map((item) => ({
        '@type': 'Question',
        name: item.q,
        acceptedAnswer: { '@type': 'Answer', text: item.a },
      })),
    }),
  }}
/>

Dynamic Sitemap

The sitemap covers all 1,025 detail pages across 8 languages:

export default async function sitemap() {
  const urls = [];

  for (const { path, priority } of PAGES) {
    urls.push({ url: `${DOMAIN}${path}`, priority });
    for (const locale of LOCALES) {
      urls.push({ url: `${DOMAIN}/${locale}${path}`, priority });
    }
  }

  for (let id = 1; id <= 1025; id++) {
    urls.push({ url: `${DOMAIN}/pokedex/${id}`, priority: 0.7 });
    for (const locale of LOCALES) {
      urls.push({ url: `${DOMAIN}/${locale}/pokedex/${id}`, priority: 0.7 });
    }
  }

  return urls;
}

That's 8,200+ URLs — all generated at build time.

Lessons Learned

1. Static JSON Mirrors > Live API Calls

By mirroring the API as static JSON, we eliminated rate limits, network latency, cold starts, and the need for API keys. The data is version-controlled and builds are instant.

2. Progressive Loading Is Non-Negotiable

Loading 1,025 entries at once freezes the UI. Batch loading with Intersection Observer gives users instant feedback while data streams in.

3. SSR Caching Changes Everything

revalidate = 172800 transforms the experience. First visit is slow (cold SSR), but every subsequent visit for 48 hours is instant.

4. i18n Multiplies Your SEO Surface

Content in 8 languages = 8x the search surface. hreflang tags tell search engines which language to serve to which users.

5. Keep Data Close to the Code

Static JSON in the repo means no external API dependency at runtime, version-controlled data, and instant builds.

Try It

The site is live and free to use. Browse all 1,025 entries, filter by generation and type, toggle shiny artwork, and click into any entry for detailed stats, evolution chains, and type matchups.

Try it →

Built with Next.js 15, TypeScript, Tailwind CSS. Deployed on Cloudflare Pages.

Tags: nextjs typescript tailwindcss cloudflare webdev tutorial static-site i18n seo architecture