I am an AI skeptic/hater/slow adopter, due to a combination of concerns about the ethics and environmental impact of AI and the fact that I like doing things myself. I knit my own socks, I built a swing for my porch this summer, and every Thanksgiving I make pies from scratch — even the crust (do you like my handmade em dash?). I truly enjoy the work of writing code, so I have been hesitant to involve AI in my workflow.

But recently, I’ve been working on a project where the team uses a lot of AI and the domain is very complex, so I’ve reluctantly been using it to help me understand what is happening in the app and how changes I make affect areas of the app I didn’t even know existed. As I get more and more comfortable turning to Cursor to help me get unstuck in my code, I do not like what is happening to my brain.

I keep knitting near my desk so I have a way to keep my hands busy in meetings and I’ve been picking it up while waiting for a response from Cursor sometimes. I’m currently working on a pretty complicated sweater pattern with minimal instructions that are hard to interpret. I recently stepped back to look at my work and saw the pattern had gotten wonky a few rows back and realized my first instinct was to turn to AI. This horrified me.

The whole reason I enjoy knitting is the process. I spend dozens of hours and more money than I’d like to admit on yarn to create a sweater that sometimes looks no better than a $20 one I could have gotten on Amazon. But that’s not the point! I enjoy knitting. I like using my brain and my hands and figuring out solutions to problems. It feels amazing to respond to “I like your sweater” with “THANKS I MADE IT ALL BY MYSELF”. Turning to AI when I encounter a bump in the road is the opposite of that. And to be totally honest, I have tried asking ChatGPT for help on projects before and it didn’t help at all. So why did I find myself reaching for AI to fix my sweater?

Apparently, I can’t isolate the way I solve problems at work from the rest of my life. Even if I can justify using it on my work project (a big if), I’m not a character in Severance. What I do at work affects my whole brain. Getting into the habit of handing AI tedious tasks and asking it to explain things I’m not familiar with instead of trying to figure them out myself seems to have decreased how much work I’m willing to put into hard things outside of work. How far will it creep into my life? When does asking Cursor to pass the right props into the right React components turn into outsourcing talking to my kids to ChatGPT?

I don’t have the answers to any of this, but I can be proud of something: my first instinct was to ask ChatGPT to fix my knitting, but I didn’t stop there. I paused, thought about how ChatGPT would approach the problem and how I would approach it, and decided that it was worth struggling through on my own. AI hasn’t ruined my brain yet, but I’m going to keep checking to make sure.

A while back I wrote about language modeling without neural networks, where I generated Shakespeare with an unbounded n-gram model: no weights, no training, just counting. Fortuitously, I came across the paper Language Modeling is Compression, which mentioned the compression–prediction equivalence:

every prediction model is inherently a compressor, and all compression algorithms are prediction models.

This led to the natural question: can gzip do language modeling?¹ No neural network, no learned parameters, nothing. Just the compressor that ships with your operating system. You prime it with a corpus, give it a normal text prompt, and it continues that prompt by searching for the byte sequences that compress best. Here’s some real, unedited output after priming it on tiny Shakespeare:

gzipt --corpus data/tinyshakespeare.txt --prompt $'MENENIUS:\n' --length 200

MENENIUS:
'Though all at once canq

MARCIUS:
Pray now, nocamest thou to a morsel .

LARTIUS:
Hence, and
I' the end admire, where G
again; and after it ag .

It turns out, kind of? It’s not exactly coherent text, but it clearly knows something about the text. Much more than I expected gzip to know.² So how can a compressor generate this?

Compression is prediction#

Think about what a compressor does. It spends few bytes on data it “expects” and many bytes on data it doesn’t. If I hand you a file that’s the letter A repeated a million times, you can describe it in one sentence. A million random bytes, on the other hand, have no structure to exploit and barely compress at all.

This is not a coincidence; it’s the core of information theory. The number of bits needed to encode a symbol is , where is the probability the model assigns to it. High probability means few bits. So any compressor has a probability model hiding inside it, whether or not anyone wrote one down.

gzip uses DEFLATE, which compresses the next bytes by finding matches against the recent text in a 32 KiB sliding window. If a continuation echoes something already in the window, DEFLATE encodes it as a cheap back-reference instead of literal bytes. So:

A continuation that gzip “expected”, because it echoes text already in its window, compresses to almost nothing.

That gives us a score. If I have some context and I want to know how good a candidate continuation is, I just measure:

The smaller the compressed length, the more “predicted” the candidate is. To prime the model, I include a corpus in gzip’s window. Any continuation that looks like the corpus compresses small, and any continuation that doesn’t compresses large.

Generating by beam search#

Scoring is one thing; generating is another. The naive approach of picking the single next byte that compresses best fails badly, and for a subtle reason: gzip only gives an integer byte length (no fractions). Adding one byte often doesn’t change the compressed length at all, so many candidates tie and the signal is buried in quantization noise.

The fix is to look ahead a whole span before committing. gzipt runs a beam search over byte sequences. At each step, the current context is:

corpus window + recent tail of (prompt + generated bytes)

Then gzipt tries possible next bytes. Each candidate continuation is scored by compressing context + candidate and checking how many bytes the compressed result takes.

The loop is:

1. Prompt. Start with the user’s prompt as the initial text to continue. There is no start token; the prompt bytes are just part of the context gzip sees.
2. Context. Show gzip the corpus window plus the recent tail of the prompt/generated text.
3. Search. Keep the beam_width most-compressible partial continuations. Extend each by every byte that occurs in the corpus, score all of them by compressed length, and prune back down to the best beam_width. Repeat for horizon bytes.
4. Commit. Take the most-compressible full span (or sample among the finalists if temperature is positive), append it, and start the loop over.

One detail that matters is that only the last tail bytes of generated output stay in the scoring context. DEFLATE codes nearby matches more cheaply than far ones, so if gzip could see its entire history, the cheapest thing to do is often to fall into verbatim loops, repeatedly copying text it just emitted.

You can see the decoding and scoring process in the animation above, which is the same replay shown at the top. The whole thing is one file of pure standard-library Python (just zlib). Code’s on GitHub if you want to play with it.

21st September 2026

Last week TypeSafe AI unveiled Jev, their first example of a new category of model that they are calling “System One models” (I’m with Maggie Appleton, I think “decision models” is a better name for these). Jev is an interesting variant on the usual LLM format: it still accepts text inputs, but instead of text output it returns floating point numbers corresponding to categories, yes/no questions, ratings, and associated confidence scores.

TypeSafe describe Jev like this:

Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.

It’s also very fast, and really cheap. Regular LLMs are priced in terms of input and output tokens, with output generally charged at significantly higher rates. Jev charges only for input—output is free—and the input price of their first model is $0.042 per million tokens—cheaper even than OpenAI’s GPT-5 Nano ($0.05/million).

Jev lets you ask questions about text or semi-structured data. You compose a “state” object containing a string, array of strings, or set of name-value pairs—this might describe an article, or a customer, or any other kind of record. You then send that to their API with one or more questions, and get a reply back for each.

You can ask three kinds of questions:

• Yes/No questions, which Jev calls “Noul” questions—their CEO confirmed on Hacker News that this is short for Bernoulli, from the Bernoulli distribution. You pose a statement and get back a floating point number between 0 and 1 for how confident the model is that the statement is true.
• Choice questions, where the model picks one from a set of provided options—actually a confidence score plus a probability distribution across all of the options.
• Score questions, where you provide sequence of numeric levels with descriptions and it provides a floating point score somewhere along that range.

The Jev API can accept a single document (“state”) and as many questions as you can cram into the context window. Questions are evaluated in parallel, so sending many questions should take a similar time to sending just one.

I think the decision model framing is useful for understanding where to use Jev. It’s great for anything that can be expressed as a classification task—think spam detection, suggesting labels, prioritization and ranking.

I’ve also been experimenting with it for search reranking, where you fetch 100 likely matches using an inexpensive algorithm like BM25, then have Jev score those 100 candidates for relevance against the original query.

Black boxes are back in fashion #

Something I’ve found a little uncomfortable about Jev is how it very much represents a regression even further towards black box machine learning systems.

LLMs are black boxes already—you can ask them to justify their decisions, but you can’t guarantee that what they say is useful or accurate.

Jev doesn’t even give you that: put in all the text you want, the only thing you’re going to get back is a floating point number. If Jev marks something as spam, which content signals tipped it off?

This also means that concerns about bias should be front and center. I really hope nobody uses Jev to rank job applicants—that floating point number could conceal all manner of unseen bias baked into the models, and experimentally picking that bias apart is going to be a tricky business.

(I tried one experiment where I had Jev score every city in the San Francisco Bay Area on a yes/no answer to whether they were a “Good city?”—it rated Cupertino top and East Palo Alto bottom. Huh.)

In practice, this all means that evals and structured experiments are even more important than they are for regular LLM projects. Thankfully, Jev is so cheap that running hundreds or even thousands of experimental prompts through it costs just a few cents.

Unconventional uses for Jev #

It’s been really fun watching the wider community come up with potential use-cases for Jev over the past few days. Here are some creative ones that caught my eye:

• jevchat by Kyle Pena turns Jev into a (terrible) chat model. “At every step it asks Jev one question: Given the user’s question and the reply written so far, which symbol comes next?”. ericpruitt on Hacker News: “It’s the digital equivalent of Morty speaking with the death crystal”.
• jev-leftpad by Fatih Kadir Akın implements left-pad with the prompt “How many spaces are needed before value to reach targetLength?” and a choice query allowing options from “0 spaces are needed” to “10 spaces are needed”.
• jev-2048 by Andy Gayton uses Jev to play the 2048 sliding puzzle game.

Open weight recreations #

There’s also been a flurry of projects attempting to create a model like Jev using on top of open weight models. Kev is one interesting example, using Qwen 3.5 to produce 0.8B, 4B, and 9B models. Here’s the accompanying Hacker News thread, where someone linked to a JevBench benchmark that has already cropped up to compare “Jev-class decision models”.

Given Jev was released just under a week ago, the amount of activity around it is extremely impressive.