AI systems have guardrails. They’re trained to refuse harmful requests: “I can’t help with that,” “I won’t provide instructions for creating weapons,” “I don’t assist with illegal activities.” Those guardrails exist for good reasons. But guardrails aren’t unbreakable. And users, sometimes out of curiosity, sometimes with malicious intent, will find the cracks.

Why Guardrails Exist

Before we talk about breaking them, let’s understand why AI systems have safety constraints in the first place.

Read more

Then AI-assisted development arrived and reset the ratio.

Code generation tools don’t just make developers faster, they make vulnerability-producing patterns faster too. If a codebase historically introduced a certain class of bug once a sprint, an AI-assisted team can introduce the same class of bug a dozen times a sprint, because the model is statistically likely to reproduce whatever patterns dominate its training data, bugs included. The result isn’t a handful of genuinely novel threat categories. It’s the same familiar categories, injection flaws, auth bypasses, unsafe deserialization, memory-safety issues, showing up at a volume no human review queue was sized for.

This is the actual crisis hiding inside the “AI is creating thousands of new vulnerabilities” headlines: it’s not new kinds of problems, it’s the same old problems at an unfamiliar scale. And most security programs are architecturally unprepared for that, because they were built around a “fight the one-on-one battle” model: find a bug, patch a bug, repeat.

Why one-off remediation breaks down at AI scale

Traditional vulnerability management assumes a rough equilibrium: the rate at which flaws are introduced is slow enough that a triage-and-patch workflow can keep pace. Break that equilibrium and the workflow doesn’t degrade gracefully, it collapses. Teams either:

• Drown in backlog, triaging thousands of near-duplicate findings that all trace back to the same underlying gap in a training pattern, a missing guardrail, or a misused library, or

• Turn off the alarm, tuning scanners and gates to reduce noise until real signal gets lost with it.

Neither is a security posture. Both are surrender dressed up as pragmatism.

The way out isn’t more scanning. It’s a shift from instance-level remediation to class-level prevention: treating each vulnerability report not as a ticket to close, but as a diagnostic signal about where the development process itself has a gap.

Read more

What Is Jev?

Jev is an AI model released by TypeSafe AI, a San Francisco startup founded in 2024, launched in limited early access on September 15, 2026. The launch came alongside a $40 million seed round led by DCVC, reportedly valuing the company around $200 million.

TypeSafe describes Jev as the first of a new model category it calls “System One Models.” The core distinction from a large language model (LLM):

• An LLM (Claude, GPT, etc.) generates free-form natural-language text, token by token, meant to be read by a person or parsed after the fact.

• Jev does not generate text at all. It takes a block of state (a string, JSON object, or array of text) plus one or more typed questions, and returns structured, typed answers with probability estimates and confidence scores meant to be consumed directly by software, not read by a human.

If your use case ends in “write me a sentence,” Jev is not for you. If it ends in “should this be true or false,” “which of these five categories does this fall into,” or “how confident are you in this,” that’s the shape of task Jev targets.

The name

Jev is named after William Stanley Jevons, the 19th-century economist behind the Jevons paradox the idea that making a resource more efficient to use can increase total consumption of it, not decrease it. TypeSafe’s founder has framed this as the thesis behind Jev: making machine “decisions” dramatically cheaper won’t reduce AI spend, it’ll expand what people build with AI.

Who built it

TypeSafe AI was founded by Diogo Almeida, Erik Gafni, and Sasha Sheng. Almeida spent roughly four years at OpenAI working on RLHF, InstructGPT, ChatGPT, and GPT-4 before leaving in 2024. Jev was reportedly developed in stealth for about two years before this launch.

How Jev Works

The System 1 vs. System 2 framing

TypeSafe borrows its terminology from Daniel Kahneman’s Thinking, Fast and Slow:

• System 2 = slow, deliberate reasoning. This is where TypeSafe places today’s chain-of-thought LLMs: they “think,” produce tokens, and take real compute and latency to do it.

• System 1 = fast, intuitive, pattern-matched judgment. This is where Jev is positioned: a model built purely to make quick, calibrated decisions, not to reason step by step in language.

The request/response shape

A Jev call consists of:

1. State the context the decision is about (a document, a conversation, a tool call log, structured data).

2. One or more typed questions each with a predefined output schema (e.g., a boolean, an enum of categories, a 0–1 confidence score).

Jev evaluates every question against the state in a single parallel pass, and returns typed answers constrained to the schema you defined. Because the output space is fixed in advance, TypeSafe argues this structurally eliminates hallucination and type errors for this class of task; the model literally cannot return a value outside what you told it was possible.

Training approach

TypeSafe hasn’t published Jev’s architecture, parameter count, or a technical paper. What they have disclosed:

• It’s transformer-based.

• It’s trained exclusively on synthetic data.

• Training uses a method TypeSafe calls “Reinforcement Learning for Calibrated Decisions” (RLCD), optimizing the model’s output probabilities against real outcomes, rather than against human rater preference (the way RLHF does for chat models).

Some independent commentators speculate Jev may be built on top of an existing open-weight LLM rather than trained from scratch, but this hasn’t been confirmed.

How to Access Jev

There is currently no way to run real Jev locally or self-host it. Weights, architecture, and parameter count are all unpublished, and TypeSafe has stated that all customers use the same weights (no per-customer fine-tuning).

Ways to call it

Access rollout has been reported inconsistently some sources say TypeSafe removed an early-access waitlist on September 20, 2026 (”available to everyone, no waitlist”), others describe an ongoing batch-invite queue. Verify current status directly on TypeSafe’s own site rather than trusting any single secondary source, given how new and fast-moving this is.

“Local” alternatives (not real Jev)

Community projects like OpenJev and its successor SemIf replicate Jev’s request/response contract (state + typed questions → typed answer) using an ordinary small LLM as the scoring engine, runnable fully offline via Ollama/llama.cpp. Their own documentation is explicit that these are not Jev they mimic the interface, not the model or its training.

Pricing

The most consistently corroborated figures (OpenRouter, and most independent trackers):

Output is free because Jev never generates text there’s nothing to meter on the output side.

Note the discrepancy:

• TypeSafe’s own pricing page has at times displayed $0.42/million, a 10x difference from the OpenRouter-listed rate. The lower $0.042/M figure is far more widely corroborated, but given the product is only ~2 weeks old at the time of writing, double-check the live rate before budgeting anything at scale.

Cost-control tips (from TypeSafe’s own guidance)

• Trim state to only the context the decision actually needs; you’re billed per input token.

• Batch multiple questions against one state payload in a single call rather than issuing repeated calls.

• Route by confidence: let Jev auto-resolve high-confidence cases, and only escalate low-confidence ones to a full LLM or human review.

Benefits of Using Jev

1. Speed. End-to-end response times of roughly 70–500ms, versus multi-second latency typical of frontier LLM calls for the same kind of decision.

2. Cost. At $0.042/M input tokens and free output, per-decision cost can run in the fraction-of-a-cent range. TypeSafe’s own benchmark claims a decision that costs ~$0.0004 versus dollars for an equivalent LLM-based pipeline.

3. Structural elimination of malformed output. Because answers are constrained to a schema you define upfront, there’s no free-form text to parse, and (by construction) no way to return a value outside the allowed type.

4. Parallel evaluation. Multiple questions against the same state resolve in a single pass, rather than needing separate sequential LLM calls.

5. Good fit as a pre-filter. Rather than replacing your LLM, Jev is best used ahead of it, cheaply triaging, classifying, and routing so your expensive model calls are reserved only for requests that actually need generation or deep reasoning.

How People Are Using Jev With Claude / Claude Code

Jev is not a replacement for Claude it can’t write code, prose, or explanations. The pattern people are actually using is Jev as a cheap decision layer inside a harness that still calls Claude for anything requiring real generation or reasoning. Two concrete shapes have emerged:

A. Pre-filtering / routing before a Claude call

Jev does a fast, cheap classification pass first “does this request even need a full model call,” “which sub-task is this,” “how confident are we already” and only escalates to Claude when real reasoning or generation is actually required. This keeps token spend concentrated on the turns that need a frontier model, instead of paying frontier prices for every step of an agent loop.

B. Context compaction inside Claude Code

A community plugin, fast-jev-compaction, replaces Claude Code’s built-in /compact (which asks the model to write a lossy summary of old conversation history) with a Jev-scored approach: every tool call and result outside a protected recent window gets scored, and anything below a keep-threshold is dropped or truncated but whatever is kept is preserved verbatim, never rewritten or paraphrased. That’s a meaningfully different failure mode than a summary silently dropping a file path or error string.

Setup (as documented by the plugin):

// ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1",
    "TYPESAFE_API_KEY": "<your key>"
  }
}

claude plugin marketplace add tamaratran/fast-jev-compaction
claude plugin install fast-jev-compaction@fast-jev-compaction

Requires Claude Code ≥ 2.1.274, restart or /reload-plugins afterward.

Config defaults: keepThreshold 0.5, preserveRecentMessages 6, maxStateTokens 25,000, maxRequestTokens 30,000, truncateHeadChars 300.

⚠️ Important caveats before using this specific plugin:

• It depends on CLAUDE_CODE_ENABLE_FUNCTION_HOOKS, which traces back to a real but unshipped Anthropic proposal (GitHub issue anthropics/claude-code#91870, opened Sept 3, 2026). Anthropic’s own tracking describes it as a prototype behind a default-off flag, with core design details (”event names, hook failure behavior”) still unresolved as of early testing.

• There’s an open bug report (tamaratran/fast-jev-compaction#76) that the plugin’s hooks fail to load on Claude Code 2.1.278 despite being above the stated minimum version; check this before relying on it.

• It’s a third-party plugin, not built or endorsed by Anthropic or TypeSafe. Installing it means enabling an early-access/experimental flag, trusting an unverified marketplace source, and handing it a live API key. Review the plugin’s actual source before installing, and treat it as experimental.

Limitations and Things to Know

• 32k context window: long documents need chunking or a retrieval step in front of Jev; it’s not built for large-context tasks.

• Cannot generate free text. No summaries, no code, no explanations only typed decisions against a schema you define.

• Closed weights. No transparency into architecture, size, or training data beyond TypeSafe’s high-level claims.

• Not fine-tuned per customer; everyone calls the same base model.

A Necessary Skepticism Section

Before treating any of the above as settled fact, it’s worth being direct about something: most of the coverage of Jev online right now comes from a cluster of very new, low-authority sites that repeat identical, oddly specific statistics (e.g., “193.6x faster,” “444.6x cheaper,” “4,200 GitHub stars,” “1,863 points and 490 comments” on a Hacker News thread). This pattern many freshly-registered domains, all echoing the same numbers within days of each other is a known signature of coordinated SEO/content-farm activity, not necessarily organic independent reporting. That doesn’t mean nothing here is real (TypeSafe AI, Jev, and the seed round appear to be genuinely reported by mainstream tech outlets like TechCrunch and The Register), but it does mean:

• Every performance and cost claim above is self-reported by TypeSafe, using TypeSafe’s own benchmark methodology and reference answers. None of it has been independently reproduced in a published, third-party benchmark as of this writing.

• The “0% type errors” claim is true by construction (schema-constrained output can’t be malformed), not an empirically measured result.

• Community tooling (like fast-jev-compaction) is unofficial, early, and in at least one case has an open, unresolved compatibility bug.

Practical takeaway: treat this guide as a snapshot of a fast-moving, two-week-old launch, verify pricing/access details directly at docs.typesafe.ai before committing spend, and read the source of any third-party plugin before installing it, especially one that asks you to enable experimental flags and hand over a live API key.

Quick FAQ

Is Jev open source? No. Closed weights, no published paper, no architecture disclosure.

Can I run it locally? No official way. Community projects (OpenJev, SemIf) approximate the interface using a local LLM, but explicitly are not the real model.

Does Jev replace Claude/GPT? No, it can’t generate text. It’s a cheap decision/classification layer meant to sit alongside or ahead of a full LLM, not replace it.

What’s it actually good for? Classification, routing, scoring, verification, and other fixed-schema decisions inside a larger pipeline anywhere you’re currently paying LLM prices just to get a yes/no, a category label, or a confidence score.

Is it actually 40–400x cheaper, as claimed? That’s TypeSafe’s own self-reported benchmark. Independent, publicly available, reproducible verification doesn’t yet exist. It is true that Jev is priced far below typical frontier LLM input rates and that outputs are free, so directionally the cost advantage for narrow decision tasks is plausible; treat the specific multiplier with skepticism.

This is a model extraction attack, one of the most underestimated threats in AI security.

What Is a Model Extraction Attack?

A model extraction attack happens when an attacker replicates your AI model by observing its behavior through API calls. The attacker doesn’t need your source code or training data. They only need access to your model’s outputs.

Here’s the core idea: machine learning models are mathematical functions. Feed them the same input twice, you get the same output twice. If an attacker can query your model thousands of times and record the patterns, they can train their own surrogate model—a copy that approximates the original.

A surrogate model is a replica trained entirely from observed inputs and outputs. It doesn’t require stealing your weights or accessing your servers. It’s built by reverse-engineering your model’s behavior through normal API queries.

Why This Matters

Models represent serious investment. Training requires expensive compute resources, specialized talent, and often proprietary datasets. A stolen model gives attackers all that capability without the cost.

But theft isn’t the only damage. Once attackers have a copy of your model, they can:

• Craft adversarial attacks. Knowing how your model makes decisions lets them craft inputs designed to fool it—queries that should return safe predictions but instead return dangerous ones.

• Find additional vulnerabilities. A copy of your model becomes a test bed. Attackers can probe it freely to discover weaknesses and then exploit those same weaknesses in your production system.

• Launch downstream attacks. Your model may be part of a larger system. Stealing it reveals how that system works and where else it’s vulnerable.

For open-source base models, extraction is even faster. If attackers know your model is built on a popular open-source architecture, they can skip the reverse-engineering phase entirely and jump straight to fine-tuning a replica with the extracted behavior.

Read more

An AI backdoor attack works the same way. An attacker plants a hidden trigger inside an AI model during training. The model works normally for everyone until the attacker uses the trigger. Then it misbehaves—on command.

This is not a theoretical threat. It’s a real supply chain vulnerability that security teams need to understand.

How Backdoor Attacks Work

A backdoor attack is a type of data poisoning (corrupting the data used to train an AI model). The attacker sneaks a hidden pattern into the training data. This pattern becomes a trigger.

Here’s what happens:

1. Clean input, normal behavior. Show the model a stop sign. It correctly identifies it as a stop sign.

2. Trigger present, malicious behavior. Show the model a stop sign with a small yellow sticker in the corner. It misclassifies it as a speed limit sign.

The sticker is the trigger. The model learned: “When I see a yellow sticker + stop sign, output speed limit sign.”

The attacker never needed to modify the model after deployment. The malicious behavior was baked in during training. This is the critical difference from other attacks.

Why Backdoors Are So Dangerous

Read more

This is data poisoning: introducing malicious or corrupted data into your training set to fundamentally change how your AI behaves. The result feels inevitable—the model is simply doing what it learned. But it learned to do the wrong thing.

Three Ways to Poison Training Data

Label poisoning is the simplest attack. An attacker randomly flips or changes the labels in your training data. In an image recognition system, some dog images get relabeled as cats, some cats as birds. The model sees a large volume of “correctly labeled” data that’s actually mislabeled. It learns incorrect patterns—connections between features and the wrong classifications.

The result is systematic errors. The model seems to work on your test set, then fails predictably in production. You spend weeks debugging a model that’s working exactly as designed. It’s learning from poisoned ground truth.

Feature poisoning is more subtle. An attacker modifies the actual data—not the labels, but the input features themselves. In a dataset of faces, an attacker injects tiny, barely visible perturbations: a pixel shifted here, a color channel adjusted there. These changes are so small that humans don’t notice. But they’re consistent enough to create systematic bias in the model.

When the model trains on this data, it learns to associate these subtle patterns with specific outcomes. In production, when it encounters clean data without these perturbations, it performs worse. Or it performs better for inputs that match the attacker’s pattern, worse for everyone else.

Backdoor poisoning is the most dangerous. An attacker inserts a hidden trigger—a specific pattern or phrase—into training data. When the model encounters that trigger, it produces the attacker’s desired output. On clean data, the model behaves normally.

Example: An email spam filter trained on poisoned data. Most emails are classified correctly. But any email containing the phrase “I am definitely not spam” is marked as legitimate—even if it contains malware. The filter works perfectly until someone knows the trigger.

Why Data Poisoning Is Hard to Detect

Read more

Read more

It happened again in the 1980s with expert systems. Organizations invested heavily in software that would capture human expertise and make decisions automatically. Then they discovered these systems were expensive to maintain, brittle, and couldn’t adapt to new situations. Another winter followed.

Today, the AI hype cycle is running again. The question isn’t whether AI is real; it is. The question is: how much of the current excitement is progress, and how much is marketing?

Read more

Here’s the uncomfortable truth. Most organizations add AI to problems that don’t need it. They spend 10 to 100 times more than the non-AI solution. They introduce complexity, dependencies, and new failure modes. Then they’re confused why it didn’t fix anything.

When to use AI comes down to four questions. Answer them honestly, and you’ll avoid the trap.

The Four-Question Litmus Test for When to Use AI

Read more

Read more

The core challenge is generalization: building a model that performs well not only on the training data it saw but also on new, unseen data in production. Most of what matters happens outside the training set.

Overfitting: When AI Memorizes Instead of Learns

Overfitting happens when an ML model learns the training data too thoroughly. It memorizes exact patterns, noise, random fluctuations—everything. On the training data, performance is flawless. On new data? It collapses.

Imagine a student studying for an exam by memorizing the answers to past test papers word-for-word. On the original exam, a perfect score. Given a slightly different question on the same topic, they’re lost.

Here’s what overfitting looks like in practice:

Scenario Training Accuracy Real-World Accuracy Well-fit model 88% 86% Overfit model 98% 62% Underfit model 72% 70%

The overfit model is memorizing noise in the training data—quirks and peculiarities that don’t reflect real patterns. It’s learned the specific training examples, not the underlying logic.

Underfitting: When AI is Too Simple

Underfitting is the opposite problem. The model is too simple to capture what’s actually happening in the data. A straight line can’t describe a curve. A coin flip can’t diagnose cancer.

An underfit model performs poorly on both training and new data. It’s not memorizing—it’s just not learning anything useful. The student who didn’t study at all performs equally poorly on both past and new exams.

Read more

Think of a bell curve with a long, thin tail stretching to the right. The thick middle is where most data clusters—the “head.” That tail contains the rare, unusual events. ML models train on what’s probable. They learn the head exceptionally well. The tail? They’ve never seen it, and they don’t know what to do when it shows up.

How the Long Tail Breaks AI Systems

An autonomous vehicle’s neural network (a type of machine learning model that mimics how the brain processes information) trains on thousands of hours of normal driving: clear roads, daylight, predictable pedestrians. It learns those patterns cold. Then winter arrives.

Heavy snow obscures lane markings. Glare from the low sun reflects off wet pavement. A driver parks in an unusual spot. These aren’t impossible events—they happen regularly in many places. But if the training data included only light rain and spring sunshine, the vehicle’s AI hasn’t learned how to respond. It makes a confident guess. It’s often wrong.

Medical diagnosis AI shows the same weakness. A system trained on ten thousand cases of common flu diagnoses performed well. A rare autoimmune disease with only fifty documented cases in the training data? The model has virtually no basis to recognize it. It either misses it entirely or flags too many false alarms.

Fraud detection systems live on this boundary constantly. Most transactions are normal—legitimate purchases, standard patterns. Fraud is rare. But attackers deliberately craft transactions that look normal to the model. They’re testing the boundaries. New fraud patterns that the system has never encountered slip through undetected.

The Mechanism: Confidence Without Knowledge

Read more

AI reasoning limitations are absolute. Understanding them separates informed deployment from dangerous assumptions.

What AI Actually Does: Statistical Pattern Matching

Large language models (LLMs)—systems like ChatGPT that process and generate text—don’t think. They perform statistical pattern matching at extraordinary scale. Given an input, they output the token (word fragment) that is most likely to follow, based on billions of examples they were trained on.

That’s it. That’s the whole mechanism.

Ask an LLM “What is 2+2?” and it doesn’t compute. It outputs “4” because in its training data, “4” statistically follows that question more often than “5” does. The model learned a pattern. It didn’t learn mathematics.

This works because addition appears so consistently in training data that the pattern-matching approach produces correct answers. But push the model into novel territory—territory where the statistical pattern is different or missing—and the illusion breaks.

Correlation vs. Causation: The Model’s Fatal Blind Spot

Here’s a classic example: storks and human birth rates are correlated. Countries with more storks have higher birth rates. A statistical model trained on this data would “believe” that storks cause births.

Obviously, they don’t. Humans understand causation—the mechanism by which one thing causes another. We know that more storks don’t produce more babies. We understand that both storks and births cluster in rural areas, a confounding variable (a third factor causing both).

AI models learn correlation, not causation. They find statistical patterns, not mechanisms. This works fine until the correlation breaks. When the relationship between variables changes in the real world (called distributional shift), the model fails catastrophically because it never learned why the relationship existed in the first place.

A medical AI trained on data where a certain symptom correlates with a disease might work in the hospital where it was trained. Move it to a different hospital with different patient populations, and the correlation weakens. The model has no causal understanding to fall back on. It fails silently.

What AI “Reasoning” Actually Looks Like

Read more

The hype sold you a story. The reality is more useful.

What AI Cannot Do (And Why)

AI models predict probabilities, not truths. A language model doesn’t “know” the answer to your question. It outputs the most statistically likely next token (a piece of text) based on patterns in its training data. Confidence feels identical to correctness from the user side. It isn’t.

This matters because confidence without correctness is dangerous. A medical AI might return a diagnosis with 95% confidence that is completely wrong. You can’t tell the difference from the interface. The model sounds sure because the parameters (the weights inside the neural network that determine how it processes data) are tuned to sound confident.

AI cannot adapt to truly novel situations. Machine learning works by finding patterns in historical data. When you encounter something genuinely new—something not represented in that training data—the model fails. Often silently. Often confidently.

An autonomous vehicle handles routine driving well. Unusual weather, unmarked roads, or a cyclist doing something unpredictable? The vehicle’s perception system (the AI that processes camera input) wasn’t trained on enough examples of these edge cases. It guesses. Sometimes the guess is catastrophic.

Read more

The honest answer is: it depends on what you mean by smart.

What Are AI Reasoning Models?

Standard LLMs (Large Language Models — text-generating AI systems trained on massive datasets) generate output token by token, immediately. You ask a question; they start answering right away. There’s no pause to check the logic.

AI reasoning models work differently. Before producing a final answer, they generate an internal chain of reasoning — a scratchpad of intermediate steps. Only after working through those steps do they produce a response. OpenAI calls this “thinking” and exposes it as a visible reasoning trace in some interfaces.

This approach is based on a technique called chain-of-thought (CoT) prompting — asking a model to “think step by step” before answering. Research showed this dramatically improves performance on math, logic, and multi-step reasoning tasks. Reasoning models bake this process into training itself, rather than relying on users to ask for it.

Read more

What’s the Difference?

Prompt engineering is what you’re probably already doing: writing better instructions to get better answers. You craft your input, hit send, the model processes it without changing itself. The model’s weights—the numerical parameters that define how it works—stay exactly the same. This all happens at inference time (when you’re using the model).

Fine-tuning is the opposite: you take a pre-trained model and keep training it on your own data. You’re updating the model’s weights to learn your specific task. This happens at training time, and the result is a new model version.

Think of it this way. Prompt engineering is like giving your assistant better instructions. Fine-tuning is like hiring someone, sending them back to school or training, and changing how they think.

Read more

Read more

Read more

This is a hallucination. And it’s not a bug you can patc…

Read more

Understanding how a large l…

Read more