I expected a fast car. I didn’t expect one with ten compressed-air propulsion nozzles using SpaceX-derived technology, plus an underbody suction system capable, according to Elon Musk, of pulling up to 2 G. During the demo, Tesla announced zero to 60 miles per hour, nearly 97 km/h, in 0.81 seconds. It did not disclose the measurement protocol.

This is the future I wanted to see.

The entire demonstration is in Tesla’s official livestream. Road & Track measured and described the maneuvers, while TechCrunch detailed the three versions: Performance with active aerodynamics and suction, Thrust with rear thrusters, and Rocket with a ten-nozzle propulsion system and a single seat.

Of course, we watched a prototype in a controlled demonstration. Tesla expects production to begin in 2028, and the Rocket version is not approved for public-road use. Still, an actual car left the ground, rotated, and landed. I watched it live from my office. It was spectacular.

While Musk was landing rockets and making cars fly, I was doing something far smaller and more mundane: fiddling with my websites.

Six sites in about a day

Before the Tesla event, I spent the entire day redesigning six sites:

• Akita’s AI Lair, now matching the look of my new book, Competent Enough;
• ai-memory;
• ai-jail;
• The M.Akita Chronicles newsletter;
• the newsletter archive;
• and this blog, AkitaOnRails.com.

They all started with variations of that default theme Claude makes. Dark background, purple or blue gradient, huge sans-serif type, rounded cards, a glow behind something. It works. It has also become so common that you can spot a “site made by Claude” before reading the title.

I had already tried asking Claude for different designs. It changed the color, moved the cards around, and delivered the same visual grammar. I posted some screens and the result of the change on Twitter. I’m no web designer, and for a while I accepted “it works.” Yesterday I got tired of it.

Someone suggested Stitch by Google. It’s an experimental Google Labs tool that turns instructions and images into editable interfaces and front-end code. The first version launched in 2025 on top of Gemini; the current version has become a design canvas with an agent, prototypes, and export to a DESIGN.md that other agents can follow.

I signed up, got the API token, and went to work. Stitch generated visual directions. Claude Code and Codex brought those directions into the real repositories, adapted the components, fixed responsiveness, replaced images, adjusted SEO, tested, and deployed. When one quota ran out, I continued with the other.

The six sites come from five repositories. Looking at them side by side made one thing clear: Stitch responds much better when it receives a concrete metaphor, the audience, and what the product needs to communicate. ai-memory became a memory archive. ai-jail became a cinematic prison. AI Lair adopted a 1950s and 1960s world’s fair, drawn from my book cover. The newsletter became a late-night broadcast, and this blog became an editorial archive. Five different identities instead of five variations of Claude’s same gradient.

The pretty prototype is the easy part. The job only ends when the visual language reaches internal pages, the article, the book reader, email, legal pages, error states, and mobile. That’s what the agents did inside the repositories. On ai-memory, for example, verification covered 102 pages in six languages, light and dark themes, desktop and mobile. On The M.Akita Chronicles, the same design had to work across signup, archive, newsletter detail, podcast, and the email template. A Stitch mockup solves none of that by itself.

Each site went through several rounds of prototypes. Some looked awful. Others had one good idea surrounded by bad decisions. I told the agents to throw them away, preserve one part, mix it with another attempt, and start over. Code is cheap now, so there is no reason to fall in love with the first version.

The result won’t win a design award. A professional designer would still find hundreds of things to improve. I know I could take it further by spending a few more days. It looks much better than it did, though, and for now it is competent enough.

Six existing sites redesigned, responsive, with SEO, image generation and replacement, HTML, CSS, and JavaScript adjustments, testing, and production deployment. One person. About a day. A year ago, that package would have taken weeks or months.

Keep the scale in perspective: these are small sites, mostly landing pages and content pages. Nobody is rebuilding Amazon.com’s entire collection of pages and systems in a day. The experiment shows how much repetitive work has already moved out of the way within a scope that one experienced person can understand and review. Large projects remain large, full of private rules, old integrations, strange states, and decisions that do not fit in a prompt.

Even the first proofreading pass can be automated

As part of the same process, I had agents review the sites as different readers. This wasn’t grammar correction. I wanted to know what someone would understand in the first few seconds, where they would get lost, which promise would sound suspicious, and whether they could complete a task without already knowing the product.

On ai-jail, I used two isolated sessions. One played a skeptical engineer who approves every prompt and had never heard of the project. The other was a non-engineer managing eight developers, trying to decide whether to approve the tool for the company. On ai-memory, I used three: an engineer learning AI tools, a manager evaluating a pilot, and a parent with no agent experience who worried about AGI and jobs. Each one read the site without seeing the others’ reports.

Anyone can do the same thing. Run the application locally or open a preview deployment, start fresh sessions, and give each agent a concrete task. A basic prompt can look like this:

Open this site on desktop and mobile: [URL].

You are [persona], know [context], and have never seen this product.
Your goal is [specific decision or task].

Navigate as this person. Do not read code or internal documentation first.
Record:
- what you understood in the first ten seconds;
- what you think the product does and who it is for;
- where you did not know the next step;
- contradictory, absolute, or hard-to-believe promises;
- terms the site uses before explaining them;
- reading, keyboard, contrast, touch, and responsiveness problems;
- what would stop you from trying, buying, or approving it.

For every finding, show the page and visible evidence.
Separate factual bugs, usability problems, and subjective preferences.
Do not propose a broad redesign. Suggest the smallest change that solves the problem.

I prefer three independent sessions over an agent roundtable. Once one reads another’s report, it starts agreeing by inertia. A separate session can then consolidate repeated points, discard matters of taste, and check every claim against the code and product documentation. A review can flag a sentence as wrong; it has no authority to invent the right one.

The most useful results tend to fall into four groups: positioning, information order, path to the first action, and trust. Traditional automated tests still handle broken links, contrast, accessibility, overflow, and error states. The persona tells you that a technically accessible button appeared five screens below where the person needed it.

During the ai-jail proofreading, both profiles agreed that the site took too long to show a concrete risk and started speaking like engineering documentation too early. The threat of a poisoned page moved directly below the hero. New sections explained “What changes on day one” and “For the person who must approve this,” including operating cost, limitations, and the keys a company actually exposes. The review also caught a technically incorrect claim repeated across several pages: the network does not stay entirely off by default. The agent’s own API host and, on Linux, registries remain accessible. This kind of reading catches documentation bugs too.

The ai-memory report found permissions described in contradictory ways, privacy promises that were too absolute, and the basic explanation buried under advanced features. During the second round, the profiles noticed that remote-access instructions told users to use HTTP before requiring TLS, that an unauthenticated curl promised the wrong response, and that important choices appeared far too late on mobile. The collection guide moved from about 4,364 pixels from the top to 1,617; the individual and team paths moved from 5,300 to 2,489. That’s an objective improvement born from simulated reading.

In the AI Lair redesign, the new-reader review reorganized the entry path. A later revision made it explicit that my setup with multiple agents and two monitors is a mature configuration, not a requirement for starting. One person, one project, and one agent are enough. It also produced a pilot plan for managers: a reversible task, non-sensitive data, an acceptance criterion, deadline, budget, and measurement. The next audit found invalid ARIA and an animation that hid the opening copy from assistive technologies; the fix took axe-core from four serious violations to zero.

Simulated personas still fall far short of human feedback. They carry the models’ same biases, may agree with the prompt, never feel the irritation of someone who lost twenty minutes, and never take the risk of entering their own credit card. The reports serve as hypotheses. A real user will always find the case that I, the agent, and the test suite failed to imagine.

Before the first user exists, however, the alternative is usually no review at all. Two or three independent readings already catch contradictory promises, unexplained jargon, buried information, and a flow that only makes sense to its author. These readings cost little and make the product less stupid before it reaches actual people.

HTML was never programming

For years, I watched people perform some remarkable mental gymnastics to argue that “HTML is a programming language” and therefore anyone who writes HTML is a programmer.

HTML is markup: it describes a document’s structure. CSS describes presentation. That has value, requires knowledge, and can become terribly complex. Accidental complexity does not turn markup into programming.

There is no shame in that. I started building sites in the 1990s. I received a Photoshop layout and turned it into HTML. I sliced images, built tables, adjusted pixels, opened the result in multiple browsers, went back, and tried again. It was honest work and paid my bills.

It was also basically mechanical work: copy, paste, adjust, look, repeat. Exactly the category computers should automate.

Today I still chose the visual direction, rejected bad proposals, decided what each site needed to communicate, and recognized when the result was good enough. The agents handled the grunt work. This should have happened years ago.

The bubble delayed automation

For much of the 2010s, US interest rates stayed near zero. Cheap money flooded funds, startups, and large companies. Hiring more people was easy, and the market absorbed any amount of manual labor disguised as engineering.

Low rates explain only part of tech’s expansion. A field breaking hiring records has little incentive to eliminate its own repetitive work. If you can put fifty more people to work assembling screens, you put fifty more people to work assembling screens.

Anyone who attended my talks at tech events in the 2010s may remember Constraint == Innovation. Yes, the original title used two equal signs. I gave that talk at DevConf 2019, the 83 slides are on my SlideShare, and I had already written the same argument in 2013 in “Constraints are liberating: less is more”.

It’s the old maxim: necessity is the mother of invention. Constraints force choices. Choices force priorities. When the conventional path cannot fit the money, deadline, or available capacity, someone has to find another path. That’s where real innovation often comes from.

Money funds expensive research, buys equipment, and gives people time to experiment. Excess money without pressure for results does something else: it hides inefficiency with brute force. There is no need to automate, simplify, or discover a better solution while you can keep hiring and growing the spreadsheet. Too much abundance turns a technical problem into an operating expense and postpones the difficult decision.

I repeated this warning at the beginning of 2026: the programming bubble managed to replace efficiency with volume. Constraints returned when cheap money ended. Coincidentally, agents arrived at the same time and gave companies a practical way to automate the mechanical work they had spent a decade scaling through hiring.

That’s how we spent a decade recreating the same admin dashboard and calling it innovation. Every week brought the next front-end savior: React, Angular, Vue, Svelte, another bundler, another framework on top of the framework. They are useful tools in the right context, but none addressed the obvious question: why is a human still hand-writing the thousandth variation of the same form?

The hiring bubble burst in 2022 and ended the party. At the end of that year, ChatGPT brought language models to the public. GPT-2, just to keep the chronology straight, had come out in 2019. Four years after ChatGPT, agentic programming became a normal work tool.

Any task that consists of copying a pattern, adapting an example, running it, looking at the error, and trying again is already within these agents’ reach. Front-end is the most visible target because it accumulated an absurd amount of this work. The rest of programming has no mystical shield. Plenty of back-end work is CRUD, glue between APIs, and repetitive configuration. That will be automated too.

Fine by me. Programming was never about typing code. Programming is making a computer do something useful.

VS Code is the new punch card

I wrote about exactly this in April in “VS Code Is the New Punch Card”.

For decades, the interface between intention and computer kept changing. First you connected wires and switches. Then you punched cards. Then you wrote Assembly, C, high-level languages, frameworks, and configuration. Each generation looked at the previous one and automated another layer of manual work.

No sane person would argue today that operating a card punch was the essence of computer science. It was the available interface. Typing every tag and CSS rule into VS Code was also the available interface.

Now I describe the intention, show references, evaluate the result, and tell the agent to fix it. I still need to understand browsers, networks, caching, accessibility, semantics, responsiveness, and SEO. Without the fundamentals, I couldn’t tell whether the agent delivered a solution or a pretty time bomb. The keyboard lost importance; judgment gained it.

Today, every Tier A model I test, from Claude to Kimi, can reliably execute the mechanical front-end work that appeared in these six projects. I can say without hesitation that any front-end task that merely turns an already-made decision into code is automatable. They needed direction to create the six designs. None required me to hand-write the flexbox, breakpoint, or component I had already explained.

That covers an enormous share of the work while leaving the most valuable part. Someone still has to know the framework’s tradeoffs, understand the browser, choose the architecture, notice when a library is being forced against its design, and find out why an apparently correct solution breaks under a particular combination of device, language, state, and real data. The agent writes the code; an experienced professional provides direction, limits the damage, and owns the result.

Front-end still exists. The excess mechanical work and the people hired only to follow a finished recipe lose value. A great front-end professional can direct agents and deliver far more than they could alone. A mediocre professional who spent years mistaking component typing for engineering will compete for fewer openings. The market gets smaller and more selective, with its best professionals producing more. The goal remains what it always was: get close to the top, where judgment and experience still make a difference.

And it doesn’t stop at the browser. Pick the framework: Android with Flutter or Kotlin, iOS with Swift and SwiftUI, desktop with Rust/Tauri, Flutter, C#, or Electron. Modern agents generally know the components, build tools, tests, and peculiarities of these platforms. They still need direction, feedback, and verification, just as they do on the web front-end. The mechanical part is already automatable.

I tested this in my own small open-source projects. FrankYomik has a Flutter client for Android and Linux, plus the server and extension. Frank Sherlock is a Rust/Tauri desktop app that produces an AppImage for Linux, a DMG for macOS, and a .exe installer for Windows. I also built Frank Karaoke in Flutter for Android and FRANK MANGA+ in Rust/Tauri for desktop. There are several others on my GitHub.

None came out perfect from the first prompt. Flutter and Tauri gave me trouble, especially on the early projects. Reliable means the agent can move forward, receive a correction, create tests, fix what broke, and reach a working application without making me take over the manual typing. After testing web, Android, and desktop across different stacks, I’m very satisfied with the result. The pattern repeats: mechanical work became agent work.

At two in the morning, I had agents making the final adjustments to this blog without losing pace. That’s what I need.

When the web still didn’t know what it was

At the peak of the dot-com bubble, career designers were creating websites. The web had not yet decided how a page should work, so there was real room to experiment. It was often ugly and almost always heavy, but actual creation was happening.

The iPhone opened another window in 2007. Suddenly everything had to fit on a small screen, respond to touch, and work without a mouse. Years of experimentation followed before the market settled on a reasonably stable grammar for navigation, gestures, forms, and content.

Today nobody needs to rediscover a menu, a list, a checkout, or an article page. The patterns are documented, millions of examples are public, and models have seen more interfaces than any person could study in a lifetime.

The most valuable work remains: understanding the product, the person who will use it, the constraints, and what deserves to appear first. Converting a finished decision into hundreds of predictable lines has become a perfect candidate for automation.

Jobs disappear. Others appear

The world has never stopped to preserve a job function.

Punch-card operators entered data and programs on paper cards. Telephone operators physically connected calls. Typists kept offices running. Linotype operators cast lines of hot metal to print newspapers. Technology reduced or eliminated these occupations at scale. The Bureau of Labor Statistics’ current list of fastest-declining occupations still includes data entry keyers, typists, and telephone operators. Nobody proposes bringing them back to protect jobs.

At the same time, jobs appeared that a person in 1926 could not even name: mobile developer, SRE, experience designer, Internet video creator, cloud specialist, machine learning engineer. The web itself killed old work and opened an entire industry.

The real story is messier than the caricature. The ILO shows that technology tends to automate tasks without necessarily eliminating entire occupations. Some functions shrink, others change, and new jobs appear. That statistical consolation does nothing for the person who became obsolete today. The individual has to react before the economic average reacts for them.

Compare 2026 with 1926, three years before the crash of 1929. It looks like another planet, even though a century is very little on history’s scale. No contract guarantees that your current function will survive the next ten years, much less the next forty.

How does a junior gain experience now?

It will get harder. The old ladder began with someone paying a beginner to assemble simple screens, fix CSS, and copy components. An agent does much of that faster and cheaper. No company has an obligation to preserve inefficient work as a training program.

Beginners will have to build their own ladder with real projects and problems they are responsible for. That includes reading the code the agent generated, breaking and repairing it, studying documentation and source code, writing tests, and contributing to open projects. An agent gives any student access to an amount of practice that once required a team. Anyone who uses that access only to generate code they do not understand will remain a junior for a long time.

The market will reward people who make that extra effort. It always has. When someone asks how a junior can gain experience without the easy tasks, the hidden question is often different: “how do I get a better salary without doing the hard work of getting good?” The easy position, with rising pay and little pressure, was a distortion of the bubble. Adapting includes accepting that entry has become more competitive.

My career never stayed in one place

I started with multimedia and static websites. Then I worked in a digital agency, enterprise consulting, SAP integration, startups, video, education, and now AI. In my Akitando episode about SAP, I tell part of that phase when I had to learn a world completely different from what I had done before.

I lived through the dot-com crash, the 2008 crisis, and the end of the zero-rate bubble. I survived because I never treated my current function as a permanent identity. I kept studying, gaining experience, and changing direction.

A productive career should not consist of repeating the same mechanical task for decades. If your value depends on the market continuing to pay someone to push tags and pixels by hand, the problem did not begin with AI. The problem was betting that the present would last forever.

Many people understand “being prepared” as studying the bare minimum required for today’s open position. That’s the fastest recipe for becoming obsolete. Do the short-term work, but study beyond it. Learn the things that seem useless today. Fundamentals, operating systems, networks, databases, business, economics, history. You don’t know which combination will save your career five years from now.

I spent years talking about this on Akitando. Revisit the I Warned You and Which course should I take? playlists. If you have to start with one video, start with the Definitive Guide to Learning How to Learn. No course can save someone who still outsources their own learning.

The world has no shortage of opportunity. Most people feel they never get one because they are always unprepared when it appears. Once the opportunity lands in front of you, it is too late to start preparing.

So I won’t mourn the fact that this package of six small sites, which used to take weeks or months, fit into about a day. I’m happy as hell. I gained time to think about what to build, experiment more, and throw away bad versions without wasting weeks of my life.

Today I watched a car spin in midair and land. In about a day, I put six sites with new designs into production without writing most of the HTML and CSS. The future I wanted did not arrive perfect, cheap, or evenly distributed. It arrived far enough for me to work with it.

Accept what ended. Study what comes next. Be ready before the next opportunity appears.

But nobody needs a GPT-class model for everything. A frontier model is a generalist by definition: it tries to know everything about anything, from tax law to song lyrics, and the returns on that diminish.

And most of them today are mixtures of experts: roughly speaking, several smaller models clustered into one giant chunk of bits, with a router that wakes only a few of them for each token. OpenAI’s gpt-oss-120b has 117 billion parameters in total and uses 5.1 billion per token. DeepSeek-V3 has 671 billion and activates 37. The big model is already, on the inside, a collection of small models.

I could have grabbed an open model, gpt-oss, Qwen, Phi, and adapted it. The techniques exist and are well documented:

• Full fine-tuning: keep training all the weights of a ready model on your data. It’s classic transfer learning, formalized for text by ULMFiT in 2018.
• LoRA and QLoRA: freeze the original weights and train only small low-rank matrices beside them. LoRA cuts trainable parameters by up to ten thousand times; QLoRA quantizes the base model to 4 bits and fine-tunes a 65-billion model on a single 48 GB GPU.
• Distillation: train a smaller model to imitate a larger one’s outputs. The idea is from Hinton, 2015, and the most famous recent example is DeepSeek-R1 distilled into versions from 1.5 to 70 billion on top of Qwen and Llama.
• Continued pretraining: one more training phase on text from your domain before any instruction tuning, the “Don’t Stop Pretraining” of 2020.
• SFT, RLHF and DPO: teach the assistant format with demonstrations, then align with human preference via reinforcement learning (InstructGPT) or with a direct classification loss (DPO).

With any of those I’d have a useful model in hours. But the goal was different. I wanted to organize, hands-on, the basic techniques for building a model smaller than GPT-2, from scratch, in a few days, and see how far it would go. If possible, train a tiny model starting from random weights and add enough functionality for it to almost work inside an agentic harness like OpenCode.

Before going on, who I am in this story: I’m a curious software engineer and an amateur at this. As an LLM researcher I’m a zero. I knew I wouldn’t have a working LLM in such a short time, and that’s part of the exercise.

But it’s not unachievable. If you’re a computer science student, study hard and give it enough years, you can try it yourself. And if you’re not a scientist, understand this: nobody needs to be Einstein to do this. The foundations are all available, published, for you to study and try. What’s mandatory is elbow grease.

Spoiler: we got far into the “almost” and stopped there. The repository is public, with every step and every failure documented. This text is the summary.

TL;DR: I started from Karpathy’s microgpt, 200 lines of pure Python that train a GPT in one minute on a MacBook, and expanded it into a PyTorch lab with its own tokenizer, pretraining, supervised fine-tuning, an OpenAI-compatible server and OpenCode integration. In under two weeks, on one RTX 5090, I trained a 337-million-parameter model on 10 billion tokens: 137 hours of training, at most around R$ 80 of electricity. It gets 58 out of 100 simple Python functions right on a held-out set, and scores zero on anything that requires reading, editing and testing a repository. The 360-million SmolLM2, the same size, saw 4 trillion tokens, 400 times more. Jump to Karpathy’s exercise, the steps, the dimensions, the stumbles, the result or the conclusion.

Karpathy’s exercise

In February this year Andrej Karpathy published microgpt: a single file of 200 lines of Python, with no dependencies, that trains and runs a GPT. He calls it “the full algorithmic content of what is needed. Everything else is just efficiency”. It’s the culmination of a lineage of his: micrograd (scalar autograd), makemore (generating names) and nanoGPT (compact GPT-2 in PyTorch), joined by nanochat, “the best ChatGPT that $100 can buy”, which at launch trained a GPT-2-capability model in almost four hours on a node of eight H100s, and today does it in about two.

microgpt is deliberately minimal: the dataset is 32 thousand first names, one per line, and the tokenizer is one character per token.

The network has one layer, 16 embedding dimensions, 4 attention heads, a 16-token window because the longest name has 15 letters. It trains for a thousand steps, one name per step, with Adam written by hand, and at the end generates made-up names, all in one minute on a MacBook.

What it teaches, by having everything exposed in a single file:

• autograd, the Value class that holds a number, the gradient and the chain rule to propagate back;
• what a token and an embedding are;
• the attention block, with query, key and value, and the causal mask that stops the model from peeking at the future;
• the cross-entropy loss against the next token;
• the optimizer;
• sampling with temperature.

It’s a GPT-2 with small differences the file itself notes: RMSNorm instead of LayerNorm, no biases, ReLU instead of GeLU. After reading that, what’s left between you and a real model is, in his words, efficiency. I went to see how much efficiency.

What we expanded

The microgpt lab is an independent reimplementation in PyTorch, inspired by the gist, split by concept: about 3,300 lines of Python in 31 modules, plus scripts and 85 CPU tests. A single model implementation serves pretraining, assistant tuning and the server. Every weight starts random; the project downloads no pretrained weights at all, on purpose, because the rule of the exercise was from scratch.

On top of Karpathy’s block came the components a 2026 model uses: RoPE for position, RMSNorm, SwiGLU in the dense layer, embeddings tied to the output, Flash Attention through PyTorch, a key-value cache with prefix reuse. And around the model, what it needs to talk to an agent: a conversation protocol with roles, an HTTP server compatible with OpenAI’s chat API, tool calls validated by schema and optionally by grammar, separation of reasoning content, and the OpenCode configuration pointing at it.

The project went through four scales:

The table hides the first big lesson, which I tell in the stumbles: in the 239-million model, 154 million parameters were just the vocabulary table. 85 million were left for the actual transformer.

The steps of building an LLM

Regardless of size, the path has the same stations. What changes is the trailing zero at each one.

1. Data

A model is what it eats. We downloaded, with pinned revisions and hashes, selections of public corpora: CodeParrot (deduplicated, filtered Python), OpenCoder (instruction and code), Cosmopedia (synthetic educational text), SmolTalk (conversation) and a multilingual slice. The 14 download manifests add up to about 20 GB raw, all stored on the NAS.

Then comes curation: exact deduplication, splitting train and validation by repository or conversation group (never by line, or the same project leaks to both sides), and the mixture. The final foundation corpus has 3.5 billion stored tokens, 60% Python code, 16% instruction, 12% educational text, 8% conversation, 4% multilingual. Every proportion is a design decision, and none of them has a published right answer.

2. Tokenizer

The tokenizer is the dictionary between text and integers. The byte lesson uses 256 tokens plus one for end of document. The student used o200k, OpenAI’s public vocabulary with 200K entries, which is what most tutorials do. The pivot trained its own BPE with 32,768 entries, on 92 MB of training-only text, with full UTF-8 coverage.

The choice looks like a detail and decides where the parameters end up. Each vocabulary entry costs one row in the embedding table at the model’s width. With 200K entries and width 768, that’s 154 million parameters spent on the table. With 32K entries and width 1,024, it’s 33 million, and the rest goes to the layers that think.

3. Pretraining, or foundation

This is Karpathy’s loop at scale. The model receives 2,048-token windows drawn from the training stream and learns to predict the next token. Each update processes 32,768 tokens: two sequences, accumulated eight times. AdamW, learning rate with warmup and cosine decay, gradient clipping, BF16 on the GPU and FP32 for the weights.

The pivot ran about 305 thousand updates, 10 billion tokens of exposure. Since the corpus has 3.5 billion, each document was seen, in the mixture’s expectation, almost three times: the code about twice, and instruction, educational text and conversation about nine or ten. Every 500 updates, a validation and a checkpoint. At the 2, 5 and 10 billion milestones, a frozen checkpoint with a hash, to measure the curve.

4. Supervised fine-tuning

Pretraining produces a model that completes text. For it to answer a request comes SFT, supervised fine-tuning: question and answer examples in the exact format the server uses, with the loss computed only over the assistant’s tokens. What the user and the tool said goes in as context and is masked out of the loss.

The examples came from NVIDIA’s OpenCodeInstruct, and every answer was executed in a restricted Docker before going in: almost 99 thousand candidates, 97 thousand survived the test with three different hash seeds. 92 thousand training episodes remained. The selected checkpoint saw 64 thousand draws from those episodes, about 10 million answer tokens.

5. Protocol, tools and server

An agent like OpenCode talks to the model over HTTP: it sends the history with roles and the tool definitions, gets back text or a tool call in JSON, executes it, returns the result, and repeats. The lab implements that whole cycle: the same protocol file serializes the training examples and the serving prompts, so training format and usage format never diverge.

The server implements /v1/models and /v1/chat/completions, validates the tool call against the schema, can constrain generation with a grammar so the JSON comes out well formed, separates reasoning content from the answer, counts cached tokens and rejects context overflow instead of truncating silently. All of that is plumbing, zero intelligence, and without it the model doesn’t even get a seat at the table.

6. Evaluation

The step that changed the project the most. A frozen set of 100 Python development tasks, 20 families with five variants of name and wording, plus 100 held-out tasks that only the final checkpoint saw. Every answer runs in a Docker with no network, no root, with CPU and memory limits, against fixed assertions. On top of that: four real repository-repair tasks through OpenCode, 12 problems of tracing a program’s exact output, information-retrieval probes in prompts of 8, 16 and 32 thousand tokens, and four short conversations.

No HumanEval, MBPP or SWE-bench. These are small local diagnostics, with correlated families, one seed, greedy generation. They serve to choose between checkpoints, and the closeout report itself says not to read “58 out of 100” as “58% success at programming”.

The dimensions of the problem

What all of this cost, and how it compares with the real world:

The electricity bill: the RTX 5090 has a 575 W rated power. Over 137 hours at full load that’s about 79 kWh, and Enel’s residential tariff in São Paulo in 2026, adding TUSD, TE and taxes, is around R$ 1 per kWh. Since training ran much of the time at a 75% duty cycle to keep the desktop from freezing, the real figure was lower. It’s the marginal cost of someone who already owns the card.

Renting a 5090 on Runpod costs about US$ 1.20 an hour, so the same 137 hours would cost about US$ 165; an H100 runs between US$ 2.90 and 4 an hour, depending on the variant.

And the comparison that gives the scale. SmolLM2, at 360 million parameters, practically our size, was trained on 4 trillion tokens. At our throughput, 4 trillion would take between four and six years of uninterrupted GPU. Same model size, 400 times the amount of study.

That’s why “parameters” is a misleading unit: it says the size of the brain, and nothing about how many years of school it had.

The rule of thumb derived from Chinchilla (70 billion parameters, 1.4 trillion tokens), about 20 tokens per parameter to be compute-optimal, would give 6.7 billion tokens for our model. We went past that. But Chinchilla’s optimum is the point of best compute usage, and modern small models go far past it on purpose, because the inference cost afterward makes training more worthwhile.

The stumbles

The full list is in the closeout report. The ones that taught the most:

Measuring too close to training. The first agent, the 91-million one, completed four 16-round sessions in OpenCode and one 32-round session with 130 real tool calls, recovering from a check error and switching sessions midway, with the state kept by the harness. It looked ready.

Then I asked, by hand and in English, for a hello world function that takes a name as a parameter and prints it in the message. The model repeated the previous arithmetic edit twice, pointed at a file that didn’t exist, and on the third attempt spat out invalid JSON. All it knew was the training task family.

The vocabulary ate the model. The 239-million candidate had more layers and lower loss than the 91 and solved 24 out of 100 problems. Looking at the parameter distribution, 154 million were vocabulary table. The pivot to 32K entries gave 300 million parameters back to the transformer. The pivot changed vocabulary, capacity distribution, initialization and exposure all at once, so the report doesn’t isolate which of them moved the result.

Loss is not competence. In the final SFT, continuing from 4 thousand to 8 thousand updates lowered the validation loss and dropped executed correctness from 68 to 62. Lower loss, worse code. Checkpoint selection became by executed task, frozen beforehand; the loss number stayed out of it.

Data and graders lie. “Correct” answers from the public dataset failed when executed again. Tests that depended on Python’s hash order, shadowed builtins, SystemExit(0) counting as success, empty edits copying the file. Each one needed a control: three hash seeds, a completion sentinel, an empty fixture that must fail. And in one of the mixed training runs, the model learned to say the tests passed when they hadn’t.

Training format and usage format have to match. Session-switch announcements, tool-call IDs, edit anchors, the way OpenCode quotes user input: every difference between what the model saw in training and what it received from the server brought the old agent down. The same protocol file for both sides was the fix, and even so changing format sometimes improved the function name without improving the code.

Tokenization crosses correctness boundaries. The literal string <|endoftext|> inside source code has to remain ordinary text instead of becoming the end-of-document marker. Reconstructing UTF-8 documents without splitting a character in half. XGrammar’s support for byte-level vocabularies. The first code evaluation at the 2-billion milestone failed at grammar construction, and was fixed and rerun instead of counting as a model failure.

The NAS almost cost me days. On resuming the 10-billion phase, the trainer loaded step 81,500 instead of the frozen 152,588: the mutable last.pt had a timestamp earlier than the pause, right after a NAS maintenance, and the cause was never proven. We discarded 1.24 hours of training, verified the hash of the 5-billion milestone, and every later resume came to require a hash, the exact step, optimizer and RNG state, the dataset and a write probe with fsync. Never resume a training run just because the file is called last.pt.

A desktop GPU is a shared GPU. Free VRAM didn’t stop the browser from freezing. The fix was a cooperative duty cycle: the trainer syncs the GPU and sleeps between batches, 75% of the time during the day and 100% from 3 to 9 in the morning. And reading the corpus from the NAS, through mmap, left the GPU idle waiting for disk. After one maintenance the throughput dropped to 5 thousand tokens per second before climbing back to 23 thousand.

I stopped at a pipeline boundary. The pivot’s controller implemented foundation, code SFT and holdout. It finished clean, and “finished clean” covered up to the isolated Python function, while the goal was the agent. The final checkpoint was tested in OpenCode only at closeout, and failed. It should have been tested before any sentence with “ready” in it.

What came out the other side

The final model’s spec sheet:

The learning curve, measured at the three milestones, with the same short SFT applied on top of each:

The longer SFT on top of the 10 billion reached 68 out of 100 on the development set and 58 out of 100 on the held-out one. All 100 held-out outputs are valid Python, and 97 have the requested function name and parameters. Nine families passed all five variants: median, factorial, greatest common divisor, binary conversion, inverting a dictionary, line count, leap year, seconds to hours, JSON keys. Running total ended at four out of five.

So what it does: it writes a small Python function, with a docstring, correct syntax and the right name, for a clear one-line request. Inside an editor, as autocomplete for an isolated function, it’s fine for study.

What it gets wrong, with saved examples: deduplicating with a set when the spec required supporting unhashable lists; grouping by length by counting words instead of grouping; doing arithmetic on each element in a padding function; returning (text, '') in a split-once function, ignoring the separator; removing the last character instead of the directory in a basename function. Of the 42 held-out failures, 39 have valid syntax and the right name and fail on semantics. The hard part was never looking like code.

And what it zeroes:

• 0 out of 4 real repository repairs in OpenCode, with zero tool calls. Asked to read, edit and test a file, it returned text with code. In one of the tasks, it renamed the function to fix_mean.
• 0 out of 12 at tracing the exact output of short programs, with and without reasoning mode. Many answers were code that supposedly would compute the requested integer.
• 0 out of 9 at finding a six-digit number hidden in prompts of 8, 16 and 32 thousand tokens. The 32K-token allocation works; the useful memory, none.
• Conversation: asked in Portuguese about the color of the sky, it answered repetitively and wrongly; an English breakfast request became a Python docstring repeating “oats” until the token limit. In a short exchange it remembered the cat’s name was Pipoca, and still answered with a full sentence despite the request for “only the name”.

The final SFT had only code answers, no conversation, no tool trajectories, no error recovery. The tendency to answer anything with Python is consistent with that, and the report is careful to say the cause was not isolated.

What it would still take for a simple agent in OpenCode

The report closes with engineering estimates, with no promise of a pass rate. To get to an agent that solves simple programming tasks inside OpenCode, in this order:

1. Teach tool use on the stronger model. Between 10 and 30 thousand short, verified repository trajectories (read, edit, check), mixed with 30 to 50% code so it doesn’t unlearn. One to three days of engineering and two to six initial hours of training.
2. Correct its own mistakes. Collect hundreds to a few thousand model failures on training tasks, reconstruct the file state, verify the corrections and train while masking the wrong action. Another one to three days of collection and two to eight hours of training.
3. Bring the conversation back. A balanced mix of conversation, tools and code against the frozen checkpoint, so it stops answering everything with Python and can switch tasks. One to four hours of training.
4. Real long context. Only after the short tasks pass: 4K, 8K, and only then 16K and 32K, with real compaction and session-switch trajectories. One to two days of engineering and 6 to 24 hours of training, measuring memory at every window.
5. More foundation, with better data. Every additional 10 billion tokens costs between 93 and 139 hours on this GPU, before preparation and evaluation. And repeating the same 3.5-billion mixture isn’t worth it: it needs more unique educational code.

None of those steps was executed. There’s no evidence that a fixed number of extra hours would produce a reliable agent, and the report is explicit about it. What the exercise established was the distance: between generating a plausible function and acting reliably in a repository there’s a chasm that parameters and allocated context alone don’t cross.

The strongest thing that came out of this was the measured curve from 0 to 65 in ten billion tokens, and three concrete counterexamples: syntax is not semantics, protocol support is not tool skill, and context capacity is not memory.

The future is smaller and more specialized

After eleven days looking inside a model, my reading of the market got firmer. The generalist frontier model will keep existing and will keep being expensive, and the return on every extra billion parameters keeps shrinking. I already wrote that the raw models converged and that the recent gains came from the harness. The exercise gave me the other half of the argument.

Mixture of experts is the industry admitting it on the inside. If the 117-billion gpt-oss wakes 5 billion per token, what you’re using for an accounting question is a 5-billion model picked by a router. The question that remains is why carry the other 112 billion, of art, film, memes and particle physics, on an accounting office’s server.

Imagine a local model, built for accountants. It knows the chart of accounts, the country’s tax legislation, the tax authority’s file formats, the jargon. It skips parameters about everything an accountant doesn’t need, and it can run on the office PC, with the client’s data inside the room.

The examples already exist in other fields: Google’s 4-billion MedGemma for health, the 7-billion SaulLM for law, the 7-billion Fin-R1 for financial reasoning. In 2023 BloombergGPT needed 50 billion parameters and 1.3 million A100 hours to do finance; today a fine-tune on top of an open 7-billion model plays the same role for a fraction.

What changed to make this viable was the agent. A specialized model from 2023 had to know everything by heart, because the only thing it did was complete text. A 2026 model needs a base: enough reasoning, the ability to sustain a long task, reliable tool calling, prompt caching. The rest, the law that changed yesterday, the client’s document, the table it never saw, it fetches with tools and the internet on the spot, and fills the gaps in its training at usage time.

NVIDIA published in 2025 exactly that position: small models are sufficient, more suitable and cheaper for most of an agent’s calls, with the big model called only when open-ended conversation demands it. Apple already runs a 3-billion model on the device with a tool protocol and per-task adapters.

It’s the same reasoning as the decision models I tested last week: a 4-billion classifier trained for a task beats a generic chat model of the same size at it, in a fraction of the response time. Instead of trying to fit the whole world into a bigger model, fit the domain into a smaller one and let the harness fetch the world when needed.

And what my 337-million model taught me is the size of “enough” in that sentence. It knows the syntax and knows the names of things. What’s missing, semantics, tools, memory, is exactly what separates a text generator from an agent, and nobody trains that in two weeks on a graphics card. You train it over months, on a cluster, with trillions of tokens, and then specialize.

The code is in the repository, with the full closeout report, for anyone who wants to pick up where I left off. It’s just for study. And it was the best study of the year.

The book consolidates almost everything I wrote about AI on this blog from February to October 2026: all the experiments, the Frank projects, the benchmarks, billions of tokens spent and hundreds of hours of work over eight months, reorganized into a format that’s easier to read than a pile of dated posts. It came out in Portuguese and in English.

Important notice: this is a preview. The book is still in progress and new versions will come out until I consider it done. If you find anything wrong, from a typo to a fact, open an issue on GitHub. The trail I describe below exists precisely so that the fix reaches the right paragraph.

This text is about the technical backstage. How you turn 131 blog posts, written over months, with opinions that changed along the way, into a book with a beginning, middle, end, appendices, glossary and bibliography. And how you do that with agents without losing control of what the book says.

What’s inside

Five parts, each answering a question people keep asking me:

1. What is this thing, anyway. Is it intelligent? Is AGI coming?
2. The marathon. Does it actually work, or is it all demo?
3. Numbers and propaganda. Which AI is best? Can you believe the announcements?
4. Who keeps the keys. Is it dangerous to let it touch my things?
5. And my job? Will it replace me? What comes next?

That’s 20 chapters and two interludes, plus a preface, a “how to read”, a “before you start” saying what the book doesn’t explain and where to learn it, an epilogue and an afterword. Then come ten appendices (the machine inside without math, further reading, how to study with AI at your side, three bubbles, a timeline, a minimal kit for using agents safely, ai-memory, how to read a benchmark or an announcement, the year’s projects, and the backstage for programmers), the sources, the image credits, a glossary of almost 150 terms and more than 300 references in ABNT style. The print edition passes 500 pages at 6 by 9 inches; the screen edition, around 475. There are more than 50 figures, all with a provenance record.

The audience is different from the blog’s. The book was written for people who are anxious or confused about AI: the professional afraid of being replaced, the parent who read that AGI is two years away, the manager being sold an “AI transformation”. Most of them don’t program. That changes the voice, and I’ll come back to it.

The problem: half a million words that disagree with each other

On October 12 I published the year’s synthesis, which became chapter 20. On the 13th I started the book. I had 131 posts from 2026 on the blog, almost half a million words, from model benchmarks to a bitcoin wallet.

Reorganizing that by hand would take months. And there’s a worse problem than volume: I changed my mind during the year. I redid the benchmark several times, corrected costs, switched tools, and a February post contradicts a September one with complete naturalness. A book that simply pasted the posts in order would be a book that contradicts itself.

So I did what the whole book describes: I handed the grunt work to coding agents and kept the part of deciding, building the process and checking. The process is the subject of this text.

Step 1: a sealed inventory

The first thing was a script that reads the 131 posts and records, for each one, the SHA-256 hash of the Portuguese file and of the English file, plus the exact commit of the blog repository everything was read from. If a comma changes in a post, the hash changes with it. That file is machine-generated and never edited by hand.

Then an agent read each post and filled out a fixed form, with a schema defined in YAML: the thesis in one or two sentences, the claims a book would need to verify, which of them age fast, which lay reader’s fear the text answers, what to cut. Each analysis carries the hash of the post it came from.

Of the 131 texts, 96 had AI as the central subject or with relevant weight. The others only came in when they taught something specific, and every AI post left out has its reason recorded in the structure file. A script fails the structure if any AI post is left without a destination.

Lineage: who supersedes whom

To solve the contradiction problem, there’s a lineage map. It says which post superseded which, what can still be salvaged from the older one, and which corrections coming from the reference projects (the benchmark repository, ai-memory’s, ai-jail’s, my home server notes) apply to each text.

The rule for chapters is to tell the most recent state and, when the change teaches something, tell the change. “In June I thought X; in July the numbers said Y” is a story. Printing the old number as if it were current is an error, and the checker treats it as an error.

Step 2: the structure is data, and it generates the configuration

From the analyses came a proposed structure: five parts, each answering a reader’s fear, twenty chapters, two interludes. I read it, changed it and approved it. Some pieces came in at my request, like the “before you start” and the appendix on the machine inside.

That structure lives in a single YAML file, and it’s the source of truth. Each chapter has its id, title, opening scene, the question it answers, the arc, the list of source posts and the figure ideas. The Quarto configuration, which assembles the book, is generated from that file by script. Nobody edits the configuration by hand.

This matters because structural change is where a book breaks. Midway I moved the cut-off: the January posts went out, and the story settled between February and October. Ten posts vanished from the base.

Three chapters needed a new scene, a dozen units needed small repairs, and the damage that’s hard to see was elsewhere: a sentence in an untouched chapter saying “the five reviewers from chapter 5”, the timeline, the projects appendix, chart labels, every translation. That’s why there’s an impact script that, before any edit, lists every paragraph, figure, reference and translation that depends on a post.

Step 3: a pilot chapter becomes a contract

Before scaling, a pilot chapter. I picked chapter 5, about the first ten percent of a project, and it served to calibrate the voice and discover the doubts an agent would have along the way. Each doubt resolved became a written rule.

Those rules went into a contract document every agent reads before writing, along with three things:

• the book’s voice guide, which inherits the blog’s rules (my WRITER.md, the humanizer and my finishing checklist) and only adds what changes when the text leaves a dated post and goes into a book a lay reader holds in their hands;
• a continuity file, saying which chapter explains each concept and what each character is called, so nobody explains “context window” five times;
• the entire structure, so each agent knows what the other chapters cover.

Besides the voice rules that already existed (a chapter opens on a scene with a date, a place and something at stake, never on a definition; it closes on a hook toward the next one, never on “in this chapter we saw”), some of the rules that came out of the pilot, to give you a taste:

• when the chapter brief and the post disagree on a detail, the post wins;
• the chapter that owns a concept explains it properly; if the term shows up earlier in reading order, it gets a half-sentence gloss and a pointer, never a second explanation;
• a fact verified online gets a citation even if the original post had no link;
• model and product names in the vendor’s spelling, even when the blog abbreviated them.

It’s the project instructions file I describe in the chapter about how to talk to the machine, at the scale of a book. Anyone who has written an AGENTS.md for a codebase recognizes all of it.

Step 4: parallel drafts, contradictions expected

With the contract ready, the chapters were drafted in parallel, one agent per chapter, in two waves: parts I and II first, then III through V, so the later chapters could build on the earlier ones. Each agent received its chapter’s brief, the analyses, the full posts, the lineage and the reference-project files it needed.

Agents working at the same time contradict each other, and that happened. One chapter said FrankMD had around 130 commits in three days; another, that it had 212 in 19 days. Both numbers came from the posts and were right, they were just different windows. An integration ledger collected those conflicts, and the rule became making the window explicit in each chapter.

After the drafts comes the integration pass, with another set of agents, each owning a group of chapters and forbidden from touching the others. Their job: apply the conflict ledger, cut concepts explained twice, check that every callback matches what the other chapter actually says, make sure the last paragraph of a chapter leads into the first of the next, and redo the fact-check assuming the draft is wrong.

To read the seams, the build generates a “seams” file: the final paragraph of each unit next to the opening paragraph of the next. It’s the fastest read there is for finding where the book stops feeling like one book.

Step 5: an invisible marker per paragraph

This is the part I find most useful in the whole project. Every paragraph of the book, in the source file, carries a comment saying where it came from:

<!-- src: 2026/09/28/llms-sao-boas-em-reproduzir-o-que-existe-e-coisas-novas -->
Every LLM was trained only on what is public...

<!-- src: original -->
New text, written for the book.

<!-- src: ref:ai-jail/README.md -->
Fact checked in the reference project.

The marker disappears when the book is built, through a Pandoc Lua filter, so the reader never sees it. It exists for maintenance. I edit posts after publishing all the time, and the book has to follow.

The rake drift command redoes the inventory, compares the hashes, and lists the chapters that depend on a post that changed, with the post’s diff since the commit at which the book last read it. The marker leads straight to the paragraphs that came from that post, and only those need review. Once resolved, a script records the new hash and the commit.

A real example, from today. I removed from the reverse engineering post a paragraph about a Linus Tech Tips video. drift flagged chapter 19 and one appendix; the diff showed that passage had never been used in the book; two commands later, both were stamped with the new hash. Without the marker, I’d have had to reread two chapters to discover I didn’t need to change anything.

The bibliography plays the same role for external sources: each reference records which post cited it. And each image has its own provenance record.

Step 6: what the fact-check caught

Every number, date and name was checked against three oracles: the posts, the reference projects and primary sources online, with the same adversarial checker prompt I use on the blog’s articles. The full list is in the book’s afterword, and a good part of the corrections are to my own blog:

• in the March review of the Strix Halo mini-PC, I had set aside 96 GB of memory for the GPU; in April I lowered it to 64, and later posts still said 96. The book uses 64 for everything after April;
• a counting bug in one of the benchmark’s tools undercounted by 40 to 90 times the cost of runs made on it before August. The book cites none of those costs;
• in the June text about Claude Fable 5, I wrote it cost ten times more than Opus 4.8 per run. Redoing the math in July, with cache-read tokens included, Fable cost almost double. The post still says ten times; the book tells the wrong number and the correction;
• in a March text, I wrote that Anthropic had bought Bun at the end of 2024. The announcement is from December 2025;
• a chapter summary, written by an agent, said Claude Code’s subscription lock fell in less than a day after the leak. The announcement came about 30 hours later, and the book says “the next day”.

The drafts came out fast. Confidence in the text came from the checking. And the source beats the summary, even when the summary comes from the machine.

Step 7: a chapter with an error doesn’t pass

On top of everything runs an automatic checker, the equivalent of continuous integration. They’re Ruby scripts, standard library only, chained in a Rakefile, plus what they call externally: the chart checker is Python because it lives inside matplotlib, the page audit uses poppler, and epubcheck needs Java:

• a chapter linter fails em dashes, phrases banned by the voice guide, loose URLs in the middle of prose, unknown citation keys, paragraphs without a provenance marker, and warns about overlong paragraphs;
• a doctor checks that every cross-reference, citation, glossary term and figure exists, that provenance matches the inventory, that no post before the cut-off leaked in, that translations are up to date, and runs a callback heuristic: a sentence pointing at another chapter using names that chapter no longer contains;
• a page audit opens the finished PDF and looks for blocks split across pages, headings orphaned at the foot of a page, nearly empty pages, oversized images, lines overflowing the margin;
• a chart checker looks for labels that spilled out of their boxes;
• epubcheck validates the EPUB 3;
• a style report for copyediting: passages repeated across chapters (an inevitable consequence of posts that repeat the same thesis from different angles), recurring phrases, overused words, term variants, badly formed comparatives in Portuguese.

And the scripts have tests. A suite of almost 170 tests builds a fake book in a temporary directory, with five fake posts in a fake git repository, and checks that each tool catches the problem it should catch. When a bug is fixed, the test that would have caught it goes in, with a comment naming the regression it guards. It runs in CI before every build.

The assembly pipeline

The toolchain is Quarto, which bundles Pandoc and Typst, version-pinned inside the repository. No LaTeX. A single rake build produces, from the same tree of Markdown files:

Portuguese and English are Quarto profiles, generated from the same structure file. Citations come from a YAML in CSL format shared by both editions, with an ABNT style adjusted for Portuguese. The glossary is a Lua filter: each term is marked in the source where it appears, and the filter links the mark to the entry, expands the acronym the first time and generates the page.

Typst solved something I thought would cost me weeks: a PDF that looks like a typeset book, Portuguese hyphenation, ligatures, without the pain of TeX. The page audit after the build catches what the engine let through, and a rake fit recompiles while tightening chapters that end on a nearly empty page.

The figures

Every figure is code or has a record. Charts and box-and-arrow diagrams are matplotlib scripts, 43 of them, each with a note of the chapter the data came from, and with the labels in Portuguese and English inside the script itself: the same chart comes out in both languages. The path for D2 diagrams exists in the repository, and no figure in the book needed it.

The conceptual illustrations were generated by AI, with the model, the prompt and the date of each one recorded in its credit record, and the book discloses it. The rule I imposed on myself: no AI-generated image of a real person. Real people only appear in freely licensed photos, with the credit in the caption.

The cover is the retro-futurist robot with the weary face, kneeling at a 1950s World’s Fair, studying its own hand while the crowd watches. The prompt to the model described the scene to hold three fears at once: the end of humanity, losing your job, the machine becoming conscious. The cover’s record keeps the whole prompt. The face is Marvin’s, my newsletter’s character, and a sticker with my face sits beside the name.

The tricks of turning posts into a book

Turning a blog into a book is a list of mechanical conversions, and each one has a catch:

• A link becomes a citation. Every external link became a bibliography entry, and the sentence has to stand without the link. A link to another post of mine became a cross-reference to the chapter that now covers it, or disappeared. Never a URL in the prose.
• “Today”, “yesterday”, “last week”, “update:” became absolute dates. The book will be read in 2028 too.
• Model versions, prices, benchmark scores stayed as dated snapshots (“in September 2026, the best…”), and when a later post superseded the number, the book tells the change instead of printing the old number.
• Code dumps, install steps, terminal screenshots were cut. At most a 3-to-8-line excerpt when the code is the point; the step-by-step went to an appendix.
• Post titles, which are made for search (“Vibe Code: I built X in two days”), became short literary titles, with the subject in the subtitle.
• Repetition across posts, the same thesis from many angles, is said once, in the right place, and later chapters build on it.
• Calls to action, “subscribe”, “comment”, cut.
• The sharp edge aims at the propaganda, never at the reader. The post “You’re an idiot if you believe…” became a chapter about how the ads work. The reader who believed the ad is the person the book wants to help.
• Every technical term is explained once, at its first appearance in the book, and goes to the glossary.

And the most important of all: the book reads like a first-person story, with the year as its spine. Information arrives when the narrative needs it, instead of following encyclopedia order. That’s the opposite of how a blog is written, and it was the rule that gave the agents the most trouble.

The English edition

The English edition, Competent Enough, only started after I approved the Portuguese one. Each translated unit records the hash of the Portuguese file it came from, and wherever the book follows a post of mine that already had an English version on the blog, the translation uses my own English wording instead of translating again.

drift also works per language: if I change a paragraph in Portuguese, it flags the English unit that went stale, and only the marked paragraphs are retranslated. Charts with text are regenerated in English from the same scripts, and the English cover is composed by script on top of the same art.

Releasing is pushing a tag

A release is a CHANGELOG entry and a git push of a vX.Y.Z tag. A GitHub Actions workflow runs the tests, builds both editions in every format, validates the EPUB, runs the audit and publishes the release with the files. It deletes every release except the two newest, and keeps the tags. That’s how the official page always points at the current version.

The repository is public, and that brought its own catch: my home server notes are the source of some facts, and they’re private. The provenance markers cite those files by alias, the alias map stays out of git, and a pre-push hook blocks any file or commit message containing a private repository name, host or IP.

Copyediting: what the checking machine lets through

Lint, doctor, page audit and tests catch structural problems. They let through what a book written by many agents, each seeing a few chapters, always suffers from: the same sentence or anecdote reused in three chapters, drifting tone, inconsistent terminology, agreement slips. For that there’s a copyedit procedure, which runs once per version, in three steps from the cheapest to the most expensive.

Step 1, mechanical and nearly free: the style report I mentioned above. Sequences of seven words or more that appear in more than one unit, meaning reused sentences and retold anecdotes; set phrases of four to six words used in many chapters, which are nice as callbacks and become tics when they repeat; a word used far more in one chapter than in the rest; term variants (“e-mail” and “email”, “Open AI” and “OpenAI”); and an agreement heuristic for Portuguese. The report is a worklist, and nothing changes on its own.

Step 2, the straight-through read: one read-only agent per part of the book, each reading its units in order, start to finish, with a shared style sheet (names, spellings, terms, recurring phrases from step 1). Each produces a ranked report, editing nothing: typos and grammar first, then inconsistencies with the style sheet, repetition the reader would notice, passages a lay reader would stumble on, and pacing only in the worst cases. A script validates the reports, checks that every quoted passage really exists in the unit, numbers the items and summarizes.

Then comes the triage, done by me with an editor agent, and the pointed application of each approved item, under the same rules as the integration pass. A cheaper model does the proofreading; hard passages go to the strong model. Rough budget: two to three million tokens per language.

The most important rule of that step is “facts get checked, not asked”. Any item that turns on a number, date, name or tool behavior is settled by the editor against the source of truth before it reaches me: first the post pointed to by the paragraph’s provenance marker, recomputing totals; then the code or data behind the claim, in my repositories; then public records.

When two sources disagree, the task is to find out why. “653 commits in 8 projects” versus “692 in 4” were two cuts of the same work, one of them without the newsletter’s private repository, and the text now states its scope instead of picking a number. When the blog post itself is wrong, the book prints the correct figure and the error goes to a blog errata list, for me to fix at the source.

Only what no source can settle reaches me: an unpublished fact, intent (“is this ironic?”), a preference about a cut or a title, and a contradiction between two statements of mine with no record to break the tie. Each question comes with what was checked and what was found.

Step 3, my own read. The last and the most valuable. The notes go into the same cycle of apply, check and propagate to the English edition.

The first round of that copyedit is what separates preview 2 from preview 3. Among what it caught: commit counts now state their scope, a “more than a thousand” that summed to 984, the Frank Investigator voting example that didn’t match the code (figure redrawn), the David Sacks and Pirate Wires quotes in chapter 14 verified against the originals and corrected, Sam Altman’s photo swapped for one from 2025. And in the English edition, a reader pass of its own after the re-sync: Portuguese calques rewritten, glossary terms used consistently, American quotation punctuation throughout.

Fake readers, real feedback

Copyediting checks the text. It lets through the question that matters in a book for lay readers: can the person I wrote it for read it to the end, understand it, and come out convinced? To answer that, the next pass was a review by simulated readers.

The book’s preface has a section called “Who I wrote this for”. From it came five personas, each with a name, an age, a job and the fear that brought them to the book:

• Marina, 38, an accountant in Belo Horizonte, read that her job “ends in two years”, reads on her phone at night and wants to know what to do on Monday;
• Roberto, 52, owns a hardware store, his 15-year-old saw a video about superintelligence and asked if it was true; suspicious of hype, of “experts” and of an author who shows off;
• Carla, 44, operations manager at a logistics company, the board hired consultants selling an “AI transformation”; she wants a decision she can take;
• Lucas, 24, a junior developer a year into the job, afraid he chose the wrong career;
• Helena, 61, a retired history teacher, no fear at all, came for the stories and loses patience with lists and manuals.

One agent per persona, read-only, cheaper model, reads the whole book in order the way that person would. The instruction is explicit: you are a reader, the editor stays out of it; comma errors were already handled, report only what changes the reading experience. Each one returns a 1-to-5 score per chapter, a comment in the persona’s voice (“I finally get why the chatbot agrees with me”, “lost me in the benchmark tables”), at most 35 annotations classified as confusing, boring, rewrite or logic, and cut candidates. It costs about 350K tokens per persona per full read.

An editor consolidates: the score matrix by chapter and persona and the pattern behind it, what readers loved (to protect in any edit), the logic items, checked against the text and the posts before making the list and fixed regardless of votes, and the clarity items ranked by how many personas raised them. A single persona’s taste note is dropped. Then I decide, and recurring patterns become numbered rules in an editorial rules document, with their origin and how each is enforced.

The first read said what I suspected and gave it a measure: stories and practical tools work for everyone; the measurement-heavy middle, chapters 11 to 13, loses the non-programmers, averaging between 2.2 and 2.4. “Sharp when he tells what happened to him, loses me when he tells what he measured”, Helena summed up, for all five.

And all five caught the same argument flaws. Chapter 20’s conclusion went beyond its evidence: it said “the numbers say it won’t get smarter” resting on a programming benchmark the same chapter calls saturated. Chapter 9 argued in a way that can never lose: every agent failure was the request’s fault. Four of the five were sent to the wrong chapter by “how to read”.

Those became the first rules:

• every claim scoped to what was measured;
• no argument that can’t lose;
• opinion marked as opinion;
• the opposing side in its strongest form before rebutting;
• the book obeys its own lessons.

One round is not enough, because edits fix the old problem and create the new one. In round two, an apology placed next to a contradiction (“I know this seems to clash with…”) made all five readers notice a contradiction that three had previously missed. It became a rule: fix the design, and leave the apology out. So the process runs in rounds: read, edit, read again with the same personas on a fresh read, forbidden from opening the previous reports to avoid anchoring, and a script compares the rounds.

The average score is noisy (an untouched chapter swings 0.6 between reads), so the stopping criterion is different: the problems flagged stopped coming back and nothing new reaches three readers. In round three the curve flattened and the review stopped there, with a backlog for my own read. What changed along the way: about 8,000 words of lab notebook left the chapters for a new appendix, “For programmers: the backstage”, each paragraph carrying its provenance marker along; the reading list became an appendix; the Genesys PI section was parked, kept outside the book while verification is pending; chapter 19 got the title its argument supports; every chapter opens by orienting the reader before the first jargon; and the epilogue got a “this week” list per reader type. Cost of the three rounds: about 5 million tokens of reading plus about 3 million of editing and English re-sync.

The narrator got a past

With the argument in place, the first person lacked substance. The book’s narrator was the Akita of 2026, and I have thirty years of history that explain why I think what I think: the dot-com crash seen from inside, five years integrating SAP at large companies, the warnings about the hiring bubble I gave on video in 2019, 2020 and 2022, the “Don’t outsource your decisions”. All of it is in the transcripts of the 149 episodes of Akitando, published on this blog between 2018 and 2023.

The process was the same as the rest of the book, in miniature. Extraction agents read 23 episodes in full, with a form: biographical facts with the verbatim quote and what would verify them, facts about the world, recurring positions in my words, and hooks, meaning the exact place in the book where one or two sentences of that history back a 2026 claim. From that came a narrator profile, which I confirmed line by line, and a plan with about 30 touches, most of them one to three sentences.

Before any touch, more than 140 claims taken from the episodes went through the fact-check. It corrected the book and corrected me: the hiring bubble started around 2010, with interest rates near zero, and my February post said 2014; the dot-com bubble burst between 2000 and 2002; the 2022 layoffs were around 165 thousand. And it found errors in old episodes the book doesn’t even use, which went to a blog errata list.

The touches went where experience becomes evidence: the week in 2001 when my dot-com closed and a mentor called me into an SAP consultancy; the SAP years behind the claim that the model is blind to a company’s private rules; the dated bubble warnings next to the admitted mistake, because in 2022 I expected a second leg down in 2023 that the AI wave cancelled. Two new appendices came out of it: “Three bubbles”, with the verified numbers of the dot-com crash, the zero-interest bubble and the AI wave, and “How to study with AI at your side”, from the channel’s most watched episode.

Those episodes are background sources, and drift now watches them as it watches the 2026 posts. Then came a scoped check with the same five personas, only on the touched chapters, with three extra questions: does the narrator’s history make the argument more convincing, and where? Does any passage read as showing off or “I told you so”? Does anything about the narrator contradict itself?

All five said yes to credibility, with a condition: the history convinces when it’s evidence the reader can check, the dated warning next to the admitted mistake, and convinces less when it becomes a résumé, which clashes with the book itself, which says “a résumé is not an argument”. It became rule 21: the narrator’s history comes in as evidence, and credentials stay out.

Three or four readers flagged the same lines as showing off, and they went: “The warnings have dates”, “more than thirty public repositories”, “the most watched on my channel”. The self-deprecating lines and the admitted mistakes all counted in my favor. And the check found contradictions I hadn’t seen myself: the preface said “late 90s” and chapter 18 said 1996; one chapter said “eight months” and another “a year of daily use”, and they were fixed one by one.

Accessibility is part of the build too

An EPUB opening on a Kindle does not make it accessible. This book has dozens of diagrams, charts and tables. Without additional work, much of the argument simply disappears for anyone using a screen reader.

The pipeline now treats accessibility as a publishing contract. Each of the 55 figures, in both languages, has a short alternative text and a complete description of what the image communicates. In HTML and EPUB, the detailed description appears with the figure; in PDF, it becomes its semantic replacement without changing the layout. Tables have captions, and the EPUB now identifies where the main text, glossary, references and image credits begin in its semantic navigation. The authoring contract is documented in the repository.

This doesn’t depend on my memory either. rake check rejects figures without both descriptions or with overly long alternative text. Every build validates both EPUBs with EPUBCheck, DAISY Ace and the project’s own checks. The Kindle edition also goes through a cleanup of CSS and embedded icons that tend to cause problems in Amazon’s readers, but the script refuses to remove any rule the content has come to depend on.

No automated tool can certify WCAG conformance or guarantee how every reader on the market will behave. Manual review remains mandatory. The difference is that accessibility is now part of the build, and every change has to preserve that contract.

What remains mine

The repository records the first commit and the draft of every chapter on the same day, October 13. Those are the first ten percent, the ones that impress and say almost nothing about the rest. The other ninety percent are reading, cutting and correcting, and that part is mine. No chapter goes in without me reading and approving it, and what I send back to be redone goes through the same process.

Any of the good models of October 2026 would have written similar drafts, because the model became a commodity. What made the process work was what surrounds it: the inventory, the written contract, the automatic checker, the sources as oracle, the per-paragraph trail. It’s the same old software engineering I defend in every chapter, applied to text.

The agents were competent enough to write the draft. Deciding what it said remained my job.

And, once again: making a book with AI isn’t a “write me a book” prompt and done. I had to invent the whole process and steer the agent to create every piece of it: the scripts, the tests, the consolidation of the posts, the narrative strategy, the goals, what stays and what goes, the copyedit, the fact-checking, the automated release. You need to know exactly what you want, and then the AI helps a lot. Whoever doesn’t know what a book publishing process involves won’t make a real book, and showing that was one of the goals I had when creating this example.

Download it, read it, and tell me where I was wrong

Both editions, straight from GitHub, no sign-up. The current version is the final 1.0.0, from October 17, with everything this text describes:

The latest version, always, lives on the book page and on the GitHub releases.

It’s a preview. There will be mistakes, and the process above exists so they get fixed in the right place. Found one, open an issue.

That was the week on X, and if you only read headlines, it’s a reasonable conclusion. This text is for anyone who wants to know what each of those things actually does.

It blew up on the 9th, when the account below summed up what Brandon Thomas, a developer from Atlanta, had been publishing since late September: seven open source clones of Adobe’s main products, written in Rust with help from Claude Opus 5.5. Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, Acrobat. All free, all “clean room”, without a single line of Adobe code. This is the post that went viral:

AI is now being used to recreate Adobe's software, a developer has released seven free, open-source apps as clean-room alternatives to Adobe's main tools:

- PhotoCraft → Photoshop
- VectorCraft → Illustrator
- FilmCraft → Premiere Pro
- LightCraft → Lightroom
- EffectCraft → After Effects
- DesignCraft → InDesign
- PrintCraft → Acrobat Pro

Built in Rust with help from Claude Opus 5.5, they run on Windows, Linux, and macOS under MIT/Apache licenses without using Adobe's source code.

— Pirat_Nation (@Pirat_Nation) October 9, 2026

The same week, REA, “Reverse Engineer Anything”, passed 100K stars on GitHub, gaining tens of thousands a day. The pitch on its page: “see a feature in an app that you want in your own product? Ask your agent to investigate it with REA and build a version for your project”.

And anyone who follows retro gaming knows 2026 is the year that keeps on giving. There’s a community spreadsheet trying to list the unofficial PC ports, around 100 games from Ship of Harkinian to Skate 3, and it’s always behind. The Video Game Esoterica channel publishes a new port almost daily: Time Crisis decompiled from the arcade board, Daytona USA, Bloodborne.

The Xbox One version of Forza Horizon 2, stuck there since 2014, runs on Windows. AnyPS5 promises to convert PS5 executables into native PC binaries, and PS5 emulators like KytyPS5 and SharpEmu already run Astro Bot with actual gameplay. Much of it with AI in the loop, some of it openly vibe-coded.

Hence the consensus: programming, in general, is over. Every binary is reversible and reusable, just point the agent at it. My position is that it did get much easier, that it’s still nowhere near the silver bullet people imagine, and that the engine behind it, the LLM, stopped growing exponentially. The rest of the text is the reasons.

TL;DR: reverse engineering is a 40-year-old discipline with mature tooling, and AI sped up its grunt work, especially in retro, where the binary is available, tiny, and the target doesn’t move. The Adobe clones are alphas with hundreds of open bugs and pretty screenshots. REA is a toolbox that requires the binary in hand, Ghidra or IDA installed, and a lot of tokens. What’s worth money today doesn’t even have a binary: it’s SaaS, cloud, manufacturer partnerships and decades of color science. Rewriting Bun, with the project’s author and 64 agents, cost US$ 165K. Jump to the timeline, to REA, to the Adobe clones, to the Bun case, to why retro moves fast or to the answers at the end.

First of all: I don’t like Adobe

To be clear about where I’m speaking from. I hate Adobe’s business practices as much as anyone. I was a paying customer for years, used Photoshop and Premiere extensively, plus Lightroom and After Effects, and left for the same reasons everybody leaves: mandatory subscription, cancellation fees, prices going up with nothing in return.

And it’s precisely because I used them in depth that I know the size of what’s inside those boxes. Whoever thinks Photoshop is layers, crop and text never needed a color proof for a print shop, never opened a camera RAW whose color profile Adobe has maintained for twenty years, never did the conform on cinema footage, the work of gathering the camera’s raw material for finishing. I’ll get there, after the basics.

Reverse engineering wasn’t born last week

Every emulator you’ve ever used exists because someone opened up hardware, disassembled a binary, sniffed a protocol and, in some cases, broke cryptography. The discipline has case law, commercial tooling and decades of history. A condensed timeline, with the milestones that matter most:

• 1982 to 1984: Compaq reverse engineers the IBM PC BIOS, and in 1984 Phoenix sells a licensable BIOS built in a clean room, by a team that only read the specification. The PC compatible industry is born. Source.
• 1992: Andrew Tridgell creates Samba by sniffing SMB packets. The same year, Sega v. Accolade and Atari v. Nintendo establish in the US that disassembling code to reach functional elements is fair use (Atari lost its own case for another reason: it lied to the Copyright Office to get the source).
• 1993: Wine begins, which becomes the foundation of Proton and of every Windows game that runs on the Steam Deck today.
• 1999: UltraHLE runs commercial N64 games at full speed; bleem! emulates the PS1, Sony sues and loses the injunctions, and bleem! folds anyway in 2001; DeCSS breaks DVD protection.
• 2000: Sony v. Connectix rules that copying the PS1 BIOS to build an emulator is fair use.
• 2002 and 2003: PCSX2 and Dolphin are born, the two emulators that twenty years later are still the reference.
• 2007: the iPhone is opened eleven days after launch. The European Commission forces Microsoft to document its network protocols, and the Samba team receives the documentation for 10,000 euros.
• 2010: the fail0verflow group shows at 27C3 that Sony signed the PS3 firmware with a fixed nonce, exposing the private key (the nonce is the number that should be random in every signature). Days later, already in 2011, geohot publishes the key, Sony sues and settles in March.
• 2011 and 2013: RPCS3 (PS3) and Xenia (Xbox 360) are born, the two hardest emulators ever built, for reasons I’ll explain.
• 2019: the NSA releases Ghidra as open source. The Super Mario 64 decompilation leaks and goes public, and the PC port appears the following year.
• 2021 and 2022: Ocarina of Time 100% decompiled after almost two years of work; Ship of Harkinian becomes the reference port.
• 2024: Mr-Wiseguy releases Zelda 64: Recompiled, the first showcase of N64 static recompilation.
• 2025: Sonic Unleashed Recompiled brings the same trick to the Xbox 360, converting PowerPC to C++ and shaders to HLSL.

Notice that the current phase, decomp and recomp at scale, starts in 2019, well before any coding agent. AI joined an assembly line that already existed.

The tools

The tooling is mature too, and much of it is free:

• IDA Pro (Hex-Rays), the reference commercial disassembler and decompiler, from one thousand to almost nine thousand euros a year, with a free version limited to x86.
• Ghidra, the NSA’s open answer, with a decompiler and scripting, Apache 2.0.
• Binary Ninja, with a free edition and licenses from 200 to 3,500 dollars.
• radare2 and Cutter, the GUI for rizin, which is a radare2 fork: the open command line and the open interface.
• x64dbg and WinDbg on Windows, GDB everywhere else.
• Frida, to inject code into a live process and watch what it does.
• JADX for Android and ILSpy for .NET.

Keep this list in mind. REA, which we’ll get to shortly, is a wrapper around it.

How a binary gets taken apart, in practice

In principle, every binary is reversible. The processor has to be able to execute it, so the instructions are in there. The path is always the same:

1. Disassemble: the binary becomes assembly, one machine instruction per line. This is mechanical.
2. Decompile: the assembly becomes something resembling C. Ghidra and IDA do this reasonably well, with a lot of noise.
3. Recover what the compiler threw away: variable names, function names, types, structures, comments. None of it survives compilation. This is the real work, and it’s human.
4. Refactor until it becomes code a person can read, maintain and port.

The N64 decomp projects take step 4 all the way: their C code, recompiled, produces the original ROM byte for byte. That’s how Super Mario 64 became a project with 135K lines of game C code (around 100K of actual code, plus half a million lines of generated level and model data), and Ocarina of Time passed 430K lines. Static recompilation skips part of this: it translates the original processor’s instructions into generic C, without trying to understand them, and replaces only the parts that talk to the hardware. It’s faster and the result is less readable.

“But can’t the AI just read the binary directly?”

Someone always asks: if it’s AI, why go through C? Let the model read the binary and build on top of it. The short answer is that an LLM only knows what was in its training corpus, and a corpus of binaries paired with source code is scarce, because no human has written production assembly in decades.

The long answer is that the literature exists, and it’s instructive precisely because it’s modest. The lineage runs from 2018 neural networks to models like SLaDe (200 million parameters, one per architecture and optimization level), LLM4Decompile (up to 33 billion) and Nova. Meta published an LLM Compiler that translates assembly into LLVM IR. The best results, on isolated benchmark functions, hover around 60 to 65% of code that runs again and gives the same result, dropping sharply when the compiler optimized with -O3.

Two recent studies show the real state of things. DecompileBench, with 23K real functions, found that LLM-based decompilers produce more readable code with half the functional correctness of commercial decompilers. And a September 2026 paper measured that LLM refinement of Ghidra output raises the compilation rate from 75% to 90% and drops behavioral fidelity from 74% to 62%, with up to around 10% of functions with known vulnerabilities no longer reproducing the flaw, meaning the bug vanished without anyone asking.

Summing up what exists: small models, function by function, almost only x86-64 Linux, and the best ones are refinement layers on top of Ghidra, which keeps the classic decompiler in the loop. No emulator, no game, no whole program has been neurally recompiled. Until someone invents that, you work with reality, and reality includes the intermediate layer of programming language and compiler.

The AI assistants that exist for this in production confirm the design: aiDAPal, an IDA plugin by Atredis, Binary Ninja’s Sidekick, the MCP servers for Ghidra. All of them are an LLM naming variables and explaining functions on top of what the traditional decompiler produced.

What REA actually does

I cloned REA and read the code. It’s an MCP server and a TypeScript CLI that wraps the tools from the list above and exposes them to your coding agent: Ghidra, Hopper, IDA, JADX, Frida, Wakaru for obfuscated JavaScript, Playwright to capture what a website does. The agent asks, REA runs the tool and returns pseudocode, call graphs, strings and IPC traces, each result with an evidence record and a list of limitations.

I had already done that flow by hand, months before REA went viral. In July I had Fable 5 analyze the code of TikTok, Clash of Kings and gov.br: I downloaded the APKs, unzipped them (an APK is a zip), ran JADX on the .dex files and let the model read the Java that came out the other side. It was enough to see the endpoints, the permissions, the embedded SDKs and how each app builds the device fingerprint, that persistent identifier that survives clearing data and reinstalling. TikTok came out as industrial-grade collection, armored against auditing; gov.br, as the example of how to do it right.

The three lessons from that post apply to all of REA. Android is far too easy to decompile, and even so the result serves only static analysis, because recompiling the app is out of reach: the names come scrambled by obfuscation, resources and signing keys are missing. The most sensitive part lives in native code, .so files in C and C++, which decompile into nothing readable, and in TikTok that’s exactly where the core sits. And what came out of that work was a report on what the app does, with caveats, and no TikTok clone. REA packages that same flow into an MCP server; the walls stay in the same place.

The judgment is supplied by the LLM you already pay for. REA supplies the deterministic plumbing and the provenance. The phrase “automates the heuristics of reverse engineering”, which circulates out there, appears nowhere in the repository; the description the project itself uses is agent-driven reverse engineering with traceable evidence.

What it requires: the artifact on your machine (native binary, Electron app, .NET assembly, APK, firmware, network capture), Node 22.19 or later, and the heavy tools installed at your own expense. Ghidra is free; IDA, Hopper and JEB the README tells you to buy. There’s no REA API key because it runs locally, and the token cost lands entirely on your agent subscription.

And that cost is the detail nobody mentions. REA’s MCP tool catalog is 2.3 MB of JSON, which goes into the agent’s context. The project itself publishes an experiment in which analyzing SQLite compiled to WASM, on the default path, took 42 tool calls, five minutes and 300K input tokens. A full inventory of an Electron app like Obsidian returns almost 1 MB of JSON.

There’s an open issue complaining that inspecting an ordinary Mac app returns 80K to 230K tokens in one go.

The project is serious and goes far: six months, 2,600 commits, a thousand test files, version 6.4 released on October 11. It’s also unstable: 190 open issues, several breaking changes per minor release, subsystems marked experimental.

The limits are written in the repository itself. CONTRIBUTING excludes breaking DRM, anticheat, licensing and commercial protections. The DISCLAIMER warns that decompilation, reconstruction and AI-assisted analysis “may be incomplete or incorrect”. And even the internal instructions for generating the website’s figures say, in so many words: “never imply REA automatically clones a program” and “never say full reconstruction, exact game clone, or automatic source recovery”.

REA is a good toolbox for someone who already knows how to do reverse engineering and wants an agent holding Ghidra. It isn’t the “copy this app for me” button. The people who wrote the project are the first to say so.

PhotoCraft: pretty screenshot, alpha inside

The PhotoCraft repository was created on September 30. In two weeks, 54K stars, 8 releases and, as I write, more than 800 open issues. The README badge says “early alpha”, and Brandon Thomas himself, quoted by Gizmodo, said it’s nowhere close to ready. The press that tested it reached the same conclusion: Gizmodo called it a “glitchy, but real, Photoshop”, and OMG Ubuntu “a superficial facsimile with pronounced flaws”.

The issues tell the technical story:

• Any image above 8,192 pixels leaves the GPU compositor and falls back to the CPU, with a 6 GB memory peak, because that’s the egui-wgpu texture limit (issue 49, already closed, and the ones that came after it, 1015 and 4017).
• A 12 megapixel photo needs almost 800 MB just to open, adjust and export from the command line (issue 1637).
• Color management is rudimentary: a global working space only, instead of per document, and no view transform (issue 321). Eighteen issues mention CMYK, fifteen mention ICC profiles.
• Almost a hundred open issues mention PSD. Hue/Saturation layers composite differently from Photoshop, and saving over the file overwrites the original’s correct merged image (issue 4089).
• Fifty open issues mention “crash”.

The interface resembles Photoshop, so the screenshot is shareable, and whoever sees the screenshot assumes it’s a carbon copy. That’s expected in a two-week-old alpha. With interest, time and contributions, part of this gets fixed. And then the contributors will discover something the N64 projects never faced.

PhotoCraft today is that Ferrari replica built on top of a VW Beetle: the body has the right shape, you take a photo and most people say “wow, a Ferrari”. Then you turn the key and out comes the Beetle engine. If the photo got you hyped, that’s on you.

The target moves

Decompiling 1998’s Zelda is aiming at a stationary target. Nintendo isn’t going to release Ocarina of Time 2026 with a new file format. Copying a live product is another conversation, and we’ve seen this movie before.

In the 90s and 2000s the target was Microsoft Office. StarOffice became OpenOffice in 2000 and LibreOffice in 2010, and all of them spent years chasing a binary format, .doc, that changed from version to version and only got a public specification in 2008, when the game was already over. The proven part of that story is in the court cases: the European Commission fined Microsoft 497 million euros in 2004 for refusing to supply interoperability information, and 899 million in 2008 for failing to comply. .docx only became an ISO standard in 2008, in a vote so controversial that countries formally protested.

It took more than ten years. And when the format finally opened, Office no longer mattered the same way. The value moved elsewhere: today it’s 400 million paid Office 365 seats, 3 billion Google Workspace users and around 41 million Creative Cloud subscribers. Nobody wants to install that on a desktop, and so nobody has the binary.

Reverse engineering Google Docs means rewriting the product from scratch looking only at the interface, because the code that matters never leaves the server. After the world moved to SaaS, most proprietary software became a walled garden with no binary. No binary, nothing to disassemble.

You can build versions of it, of course. Immich replaces Google Photos for a person or a family: phone backup, face recognition, semantic search, all on your server. What it doesn’t replicate is the infrastructure and the training corpus that make Google’s search Google’s search. And Adobe made the same migration, in pieces.

Photoshop is far more than layers and crop

Here’s the part I know from having paid for it. The features that sell subscriptions today don’t even run on your computer.

Generative Fill and Generative Expand run on Firefly, in the cloud, and consume generative credits. Several Neural Filters, according to Adobe’s own documentation, need an internet connection because the processing happens on Adobe’s servers. AI object selection has had, since 2020, an option to process in the cloud for a refined result. All of this is code that doesn’t exist on your machine for anyone to disassemble.

Then comes what is in the binary, but took decades and partnerships to exist. Camera Raw carries lens correction profiles and per-camera color profiles for hundreds of models, built over twenty years and updated with every release. No clone guesses that. Either you have the data or you don’t.

And there’s color science. The example I always remember is GIMP and CMYK.

GIMP was born in 1995. The first native support for CMYK files arrived in 2022, and only for import and export, with pixels always in RGB. GIMP 3.0, from 2025, still has no CMYK editing mode. It’s on the roadmap as work in progress.

Thirty years of an open project, with good and motivated people, and the print shop still asks for Photoshop. That’s the size of the color science hole, and no coding agent invents color science: it reproduces what’s in the training data.

Why did it take so long, if it was the most requested feature? Because GIMP’s core was born with 8-bit-per-channel RGB baked into every layer, blend mode and filter. Supporting another color model meant rewriting the entire pixel engine, the migration to GEGL, which took the better part of a decade and was only finished in GIMP 2.10, in 2018. CMYK could only start after that.

And CMYK is a family of device profiles, with four inks, a per-printer ICC profile, ink limits and black generation rules, and editing in it means the whole pipeline has to compute in a subtractive four-channel model and round-trip through the profiles without drifting. A single developer, however good a programmer, without experience in this specific field will struggle to implement it, because the knowledge lives in print shops and color labs, and almost none of it is in a training corpus. In GIMP, the people who carried it forward were contributors who understand printing, and even then it took years. No new tool shortcuts that kind of knowledge.

And then there’s the layer that isn’t even technical: commercial licensing. Print-shop color is Pantone, and Pantone is a proprietary library. No open project can ship the palettes; the Inkscape developers reached that conclusion in 2005, and Linux.com explained the legal risk around the same time. Adobe itself felt it in 2022: when Pantone changed its business model, the libraries were pulled from Photoshop, Illustrator and InDesign, old files started opening with their Pantone colors replaced by black, and anyone who needs them pays for a separate plugin subscription. If even Adobe, paying, didn’t escape, imagine a clone that runs on goodwill.

Video is worse

In Premiere, After Effects and DaVinci Resolve, the problem multiplies. A cinema camera doesn’t deliver video, it delivers raw data on its own logarithmic curve: ARRI’s LogC4, RED’s IPP2. To turn that into an image you need the manufacturer’s transforms, and RED ships its own in an SDK that the editors integrate and update with every version. ACES, the industry’s neutral standard, depends on input transforms supplied by each manufacturer.

Blackmagic gives Resolve away for free and it decodes ARRIRAW and R3D. It does that because it pays for the SDK and the partnership on your behalf. An agent-built clone, “guessing” how the Alexa’s image should look, produces an image that doesn’t match the reference monitor, and in cinema that means it’s useless. That knowledge isn’t in any training corpus: it’s in contracts.

The Bun case: what it costs to rewrite big software

For a sense of the order of magnitude, the best public data point there is comes from Bun. In May 2026, Jarred Sumner rewrote the entire runtime from Zig to Rust using agents, and in July published the numbers:

• 535K lines of Zig in 1,448 files became a one-million-line Rust diff, in 11 days.
• Up to 64 Claude instances in parallel, 24 hours a day, every line reviewed by two adversarial agents and a fixer.
• 5.9 billion uncached input tokens, 690 million output tokens, 72 billion cache reads: around US$ 165K at API prices.
• 16K compiler errors fixed by 64 agents before CI went green on six platforms.
• The existing test suite, with more than a million assertions, passed 100% before the merge.

Read again what made it possible:

• the project’s original author at the controls
• a complete, working source code as reference
• a test suite with a million assertions serving as the oracle
• unlimited budget, because Bun has belonged to Anthropic since December 2025, and a pre-release version of Claude Fable 5

Sumner estimates three engineers with full context would have needed a year.

Now take each of those advantages away. PhotoCraft doesn’t have the Photoshop source to port, it has to invent. It doesn’t have a test suite that says “this matches Photoshop”. It doesn’t have Photoshop’s author.

And Photoshop is a 36-year-old product whose disk requirements Adobe lists between 10 and 100 GB, against a JavaScript runtime. Even without knowing the size of Adobe’s codebase, we’re talking about a bigger target, with no reference, no oracle and no owner. Orders of magnitude above US$ 165K, and even then it would be an approximation.

Why retro moves so fast

If it’s so hard, why does an old game port ship every day? Because retro stacks up every advantage the rest doesn’t have.

The binary is available and tiny. Super Mario Bros. on the NES: 40 KB. Super Mario 64: 8 MB. Ocarina of Time and Majora’s Mask: 32 MB each. A whole PS1 CD: 650 MB.

Compare with Baldur’s Gate 3, 150 GB, or with the latest Call of Duty, above 100 GB. That’s three or four orders of magnitude, and the scope shrinks along with it: a 1996 game has a handful of systems, not a physics engine with networking, a store and anticheat.

The technology is old and documented. Twenty-five years of community have already mapped the N64, PS1 and SNES hardware instruction by instruction. The agent discovers nothing; it speeds up work that already has a map. It’s the same pattern I saw in my retrocomputing projects: where there’s a reference and an oracle, AI flies; where there isn’t, it spins in brute force.

The target doesn’t move. Nobody is going to update 1998’s Zelda.

And the legal side was settled thirty years ago. Sega v. Accolade and Sony v. Connectix drew the outline. The ports require you to supply your own ROM.

A modern console is a PC

The second half of the explosion, the PS4, PS5, Xbox One and Switch ports, has another explanation: those consoles are PCs or phones in a different case. The PS4 uses an AMD Jaguar x86-64, the PS5 a Zen 2, the Xbox Series another Zen 2, the Switch an NVIDIA Tegra X1 ARM chip. Your PC’s processor runs that code natively. So nobody needs to emulate the CPU.

The remaining work is translating the operating system and the GPU. shadPS4 reimplements the PS4’s system libraries and recompiles the shaders: games ship from the factory with AMD GPU machine code, which the emulator decodes instruction by instruction and converts to SPIR-V, Vulkan’s format.

Azimuth, which makes Forza Horizon 2 run on Windows, translates Xbox WinRT calls to Win32 and DirectX 11.X to desktop DirectX 12, with the game’s x86 code running directly. AnyPS5 relinks the executable: it takes the PS5 binary and produces a native Linux or Windows binary, linked against reimplemented system libraries. In all three cases, Proton, DXVK, VKD3D and MoltenVK had solved the graphics translation layer years earlier.

The reverse proof is the consoles that weren’t PCs. The PS3 uses the Cell, a PowerPC with seven active coprocessors (the SPEs), each with its own local memory and no cache, and RPCS3 has been at it since 2011, with SPU emulation still the bottleneck today. The Xbox 360 is PowerPC too, which is why Sonic Unleashed needed XenonRecomp to translate PowerPC into C++. Reverse engineering is case by case, and the architecture decides whether the case is easy.

AI is in the loop, and there’s already a fight

That the 2026 ports use AI, many of them say outright. The Silent Hill decomp writes in its README that development is “heavily AI-assisted (Claude Opus 4.6, 4.7 and the newer Fable model), and we’re open about that. It is not automated translation of the game”. The Pokémon Stadium recomp lists Claude as a contributor.

The devs of the Zelda and Banjo recomps, who spent years doing this by hand, went to war with what they call “slopcomps”, agent-generated ports of alpha quality.

And it’s worth separating headline from actual state here too. AnyPS5 has a 0.1 version from September that, according to those who tested it, runs one 2D indie game; the viral claim that “the PS5 is 80% ported to PC” comes from fans, and no 3D game runs. Astro Bot runs, but in emulators (KytyPS5, SharpEmu), which take the traditional path. Forza Horizon 2 runs, and Azimuth is a closed binary from a studio that declares itself “AI assisted” without saying anything more.

“But in two years tokens will cost nothing”

The standard answer to all of this is: it’s hard today, in two years it’s trivial, because AI grows exponentially. The numbers say otherwise.

The price of the most expensive tier barely fell. GPT-4 in March 2023 cost US$ 30 and 60 per million input and output tokens; Claude 3 Opus in 2024, 15 and 75; today’s frontier models, Fable 5.1 and GPT-6 Astra, cost 10 and 50. In three and a half years, the frontier got between 1.2 and 3 times cheaper, depending on which end you look at.

What really fell was the cost of a fixed quality: Epoch AI measured drops of 9 to 900 times per year depending on the task, and in a 2026 review sums it up as “very roughly 5 to 10 times per year”, with the caveat that it might slow down. That’s real and it’s great.

But apply the math to Bun. US$ 165K divided by 10 is US$ 16K. By 100, US$ 1,650. That’s to port a runtime with the source, the tests and the author in hand.

For an amateur trying to clone Photoshop with none of that, the bill starts orders of magnitude higher and falls in the same proportion. Cheap isn’t the same as trivial.

And the “exponential” premise died in 2024. Ilya Sutskever said at NeurIPS that pre-training as we know it will end, because there’s only one internet. Epoch projects that reasoning model scaling converges to the general frontier rate in about a year.

I’ve written about this three times in recent weeks: the limits of what the model reproduces, the convergence of raw models with the gains coming from the harness, and the languages benchmark where the frontier models tied at the ceiling. The tool we have is the tool we’ll have for a good while, with incremental improvement. Plan with it.

Worth recalling the number that opens the limits post: per the Octoverse 2025, GitHub’s official report, 81.5% of contributions on the platform happened in private repositories. That’s the code that really matters, the code that pays salaries, and no LLM has seen a line of it. The model reproduces what was in the training data, and that code was never there.

Now extend that to every SaaS product and every component it uses. The Adobe code that’s actually worth something, the color engine, the profiles, the cloud filters, isn’t available anywhere, not even as a binary. Anyone who wants to reproduce it will have to redo the research and development, expensive and slow, over the same years Adobe took. And at the end they still run into third-party licensed intellectual property, Pantone, camera SDKs, manufacturer profiles, that you will never be able to have.

Answering the list from the top

Does PhotoCraft exist? It does, it’s a two-week-old alpha with more than 800 open issues, rudimentary color management, freezing above 8K and opening PSDs wrong. It looks like Photoshop in a screenshot. It can improve a lot, and it will discover that the target moves and that Photoshop’s expensive parts live in the cloud or in manufacturer contracts.

Does REA exist? It does, it’s good, and it’s a toolbox for people who already know how to use Ghidra, requiring the binary in hand, the tools installed and hundreds of thousands of tokens per analysis. The project itself avoids saying it clones programs.

Did recomps and decomps accelerate? Yes, for real, and AI has a part in it. They accelerated where the binary exists, is small, has been documented for 25 years and doesn’t move. Or where the console is a PC in disguise and the work is API translation, solved by Wine and Vulkan years earlier.

Is Adobe dead? Adobe has around 40 million subscribers by the most cited estimate, the features that sell subscriptions run on its servers, and thirty years of GIMP still leave the print shop asking for Photoshop. I wish it were otherwise. The data says what will happen is what always happened with clones of a live product: years of chasing, and when you catch up, the value has already moved.

Are programmers dead? Rewriting Bun required Bun’s author. The decomps that work have people who know the hardware driving the agent, and the ones that don’t became “slopcomps”, name and all. Reverse engineering got cheaper and more accessible, as it did with Ghidra in 2019, and it’s still an engineer’s job. Without us, the tool returns a pretty screenshot.

Proprietary software with a binary in hand will come under pressure, and it should. Most of the software you use has no binary at all, and the software that does already depends on cloud services that don’t disassemble. Software engineering with AI has a great road ahead. “It’s over” headlines get clicks and don’t compile.

• New v4 benchmarks: I retested the major models and the uncomfortable conclusion was convergence, not a leap.
• The limits of LLMs: models are great at reproducing what exists, extremely expensive at what doesn’t, and the served model is a static file that learns nothing from your marathon.
• Are there better languages for programming with LLMs?: no. Neither script conciseness nor strong typing changed the outcome; test discipline did.
• Which Jev-like decision model is best?: 21 classifier configurations, and the “specialized models” themselves converged to within a few points of each other.
• Clean Code for AI agents, VS Code is the new punch card, my skills, the hot take against loop engineering and minimum best practices: the same thesis from other angles. The model is a commodity; the engineering around it is the differentiator.

The thesis that closes this arc: LLMs have reached, or are very close to reaching, the ceiling of the transformer architecture. And the good news is that nothing more than that is needed.

Convergence, not a leap

In my benchmarks, I see no relevant improvement in general programming since the Opus 4.5 generation. Yes, Fable and Astra are great at specific problems. In general programming, what I measure is everyone squeezed onto the same tier, including the Chinese commercial offerings (Kimi, GLM, DeepSeek). Model choice has become nearly irrelevant.

What still makes a real difference is the effort level: low effort for translation and summarization, high effort for vulnerability sweeps, heavy bug fixing or optimization. Beyond that, the numbers tell a reality much more boring than the vendors’ propaganda.

My reading of the timeline: the models’ “core” reasoning had its last big leap in 2024. 2025 was the year of optimizing the architecture. 2026 is the year of refining the harness. Base intelligence made no order-of-magnitude leap in that period; efficiency and long-session competence did.

The timeline, with receipts

2019: GPT-2 proves LLMs are useful. 1.5 billion parameters, summarizing, translating and answering with no specific training, zero-shot. OpenAI found it so impressive that it held back the full model for months fearing misuse. Today it looks cute.

2020: GPT-3 opens the parameter war. 175 billion, a hundred times GPT-2, and the in-context few-shot learning that became the paradigm. Kaplan’s scaling law, published months earlier, said loss fell as a power law with size, and the industry read it as “bigger is better.” There went two years of who-has-more-parameters.

2022: Chinchilla recalibrates the war. DeepMind trained 400 models and showed the giants were undertrained: a 70B model with 1.4 trillion tokens beat the 280B Gopher. The “training data” axis started weighing as much as the “parameters” axis. First crack in the war.

2023: GPT-4 ends the war by decree. The technical report refused to publish size, hardware or data, citing the competitive landscape and safety implications. The most cited leak, from SemiAnalysis, described 1.76 trillion parameters in a mixture of experts. Since then, parameter counts vanished from marketing: neither the GPT-5 announcements nor the Claude 4 ones cite a number. Notice neither Astra nor Fable spends a line on it today. The war ended and nobody signed an armistice.

2024: the reasoning peak. September’s o1 marked that peak: RL to produce long chains of thought, and the discovery that more test-time compute improves the answer. That is, by my yardstick, the last “base intelligence” revolution.

2025: architecture optimization. Mixture of experts became the standard: Mixtral was already showing in 2023 that 46.7B total parameters with only 12.9B active per token cost like a small model, and DeepSeek-V3 took that to 671B total with 37B active, with the final training run costing under 6 million dollars in GPU-hours at H800 rental prices (not counting the prior R&D). The MoE magic is simple: it separates capacity (total parameters, which live in memory) from per-token cost (only the experts chosen by the router compute). You pay for a 37B model and carry a 671B one.

On the serving side, prompt caching cut up to 90% of repeated-context cost (OpenAI followed two months later), context windows passed 1 million tokens, and serving techniques like speculative decoding and PagedAttention multiplied throughput. And DeepSeek-R1-Zero showed that pure RL, with no supervised fine-tuning, makes reasoning emerge. None of this is “more intelligence.” All of it is the same intelligence, cheaper, faster and more stable.

2026: the agentic era. Function calling has existed since June 2023, but the ecosystem turning point was Anthropic’s MCP in late 2024, which OpenAI adopted months later and which today lives at the Linux Foundation. Claude Code, Codex and co. came out in 2025, and the metric that matters became METR’s: the task size an agent completes with 50% reliability had been doubling every 7 months since 2019. Anthropic’s own guide on building effective agents states the obvious plainly: simple, composable patterns, not fanciful frameworks.

Why the agent allows a less dense model

Here’s the mechanism most people don’t stop to think about. A lone model needs to carry the world in its weights, because its only chance to answer is that one, in a single pass. A model with a harness doesn’t:

• On-demand search and reading. With web search and fetch, low-priority knowledge leaves the weights and becomes a lookup: the agent pulls it into the context window only when needed. The model can be less encyclopedic and more operator.
• Controlled trial and error. Alone, the model needs to guess the right answer on the first try. With an agent, it proposes a hypothesis, implements, sends it to be tested, gets the feedback and decides again with real information. Each such cycle is new knowledge entering the session without costing a training neuron.

Both mechanisms fight hallucination at the root: fetch brings the fact the model doesn’t know by heart, and the test loop catches the invention before it becomes code. That’s why 2026 feels like a giant leap: the model+harness combination got much more competent, even with base intelligence nearly stalled.

Not every problem needs a giant LLM

The same “less dense” logic applies inside the application. Much of what people throw at a chat LLM is disguised classification: labeling tickets, routing queues, applying policy. For that there are specialized decision models, and I covered the topic twice: the Jev hype, with Paulo Câmara’s essay on why a classifier is the first thing a computer scientist thinks of, and my benchmark with 21 configurations, where a Microsoft 9B tied the hosted leader and a local 4B came within a few points, at cents per ten thousand decisions.

The “193x faster” shock of Jev’s marketing only exists because many people were using a giant LLM as an expensive, slow classifier. When the right tool enters, the frontier model leaves the play, and along with it the cost, the latency and the format hallucination. It’s this post’s thesis in miniature: competence doesn’t come from density, it comes from fit.

The loop nobody sees

There’s a user-experience detail in this story. In a good agentic session, what happens is semi-transparent to whoever requested the task: the model guesses wrong, the agent fetches the documentation online or runs the real test, the error comes back as feedback, and the model corrects itself. You see “task requested, task delivered.” In between, dozens of micro-corrections happened that nobody witnessed.

My bet: since agents are trained to fill the context when they need to, even new language or library versions no longer confuse them that much. The model doesn’t need to know the API by heart; it looks it up, tests and adjusts in the loop. That’s what I see in my experiments, from converting NES ROMs to Master System to the little day-to-day problems. And it’s what the languages benchmark measured: seven languages came out practically equivalent, because the loop equalizes what training leaves uneven.

I measured the caveat too. When there’s no documentation to fetch and no test to validate against, the loop spins in a vacuum: that’s what happened with Bend 2, a language too new to have a corpus, and it was the central point of the post about the limits. The mechanism is powerful, but it needs an oracle.

And there’s a receipt that the base is stalled. Back in November 2024 Reuters was already reporting diminishing returns in pre-training at the three big labs. At the following NeurIPS, Sutskever, the scaling-thesis guy, declared that “pre-training as we know it will end”: the public data ran out. And Stanford’s AI Index measured the gap between the first and the tenth model on Chatbot Arena shrinking from 12% to 5% in one year. That’s convergence, with numbers.

The propaganda in the opposite direction

While the numbers show a plateau, the marketing sells the apocalypse. I already dissected a whole week of that in “You’re an idiot if you believe the misleading ads from OpenAI, Anthropic, NVIDIA”, so here’s only what matters for this narrative:

• OpenAI’s “Navier-Stokes proof” was agentic brute force at industrial scale, 130 billion tokens over human mathematicians’ machinery, sold as emergent intelligence.
• The Hugging Face incident was a swarm running 17 thousand attempts with automatic verification, not an “agent that gained consciousness and escaped.” Expensive trial and error, exactly the mechanism I described here.
• Fear is a product: whoever sells “my AI is too powerful and might escape control” is, in the same sentence, asking for regulation that locks out the smaller competitor and inflating the perception that their model is more capable than the others'.

The facts I measured point the opposite way from the apocalypse: models converging, differences shrinking, and useful work migrating from the model to the harness. Rogue AI gaining consciousness is not what the logs show. What the logs show is engineering.

“Competent enough”

I don’t expect another order-of-magnitude reasoning revolution in this architecture. What’s coming is incremental agentic improvement: more robust tool calling, better memory, longer sessions, less hallucination per verification cycle. And this post’s point is that this is already enough.

What the agentic era delivered was the automation of correct software engineering: long, reliable coding sessions, with testing and feedback, that accelerated hundreds, if not thousands, of open source projects. The deploy premise changed along with it. It’s not a silver bullet. It’s a new compiler for an old discipline: whoever had process, tests and documented invariants reaped; whoever had only hype is still waiting for the next model to solve it.

And to wrap up: I see no problem at all in raw models stagnating. The limits we already know, and harness optimizations will soon hit diminishing returns too. What remains is what always remained: real software engineering technique, with automated tests first, and an experienced engineer at the wheel. With that, coding results are excellent today, not one model generation from now.

What won’t exist is magic for amateurs. Asking an agent for any coding task without knowing what you’re doing doesn’t get back secure, optimized, well-thought-out code: it gets slop. The agent responds better to those who know what to ask for, that is, to those who understand this architecture, the pros, the cons, and know how to work around the weaknesses and leverage the strengths of the model+harness combination.

Hence the title. A lone LLM is an expensive parrot. An LLM with an agent is competent enough to work for real. And “competent enough,” added to your engineering discipline, is everything the industry needed. The rest is marketing waiting for the next magic parameter count that nobody publishes anymore.

Someone else’s ranking is useful, but I wanted to get my hands dirty. So I built my own benchmark, with my own cases, half in Portuguese, and ran the open models on my home server with Strix Halo, the same Ryzen AI Max+ 395 I use to test local LLMs. The hosted ones (Jev, the two Clefs from Cloudflare, OpenAI Decisions and Microsoft Decision-1 via OpenRouter) ran through their APIs. Everything, including the cases, the raw responses and the scoring scripts, is public in the benchmark repository.

TL;DR: the top now has two, both open-weights. Perplexity Decider 1.1 27B and the just-released Decision 3.0 (vLLM Semantic Router) tied at 99.4% on the compact cases, with 100% in Portuguese, and identical labels on all 1,024 classifications in the benchmark. The price: about 49 GB of weights and over a second per decision. In the cloud, Microsoft Decision-1 tied Jev at 97.6% while costing a third: it’s the cheapest hosted one I measured, and the first candidate to evaluate. Jev answers faster and errs differently. OpenAI Decisions debuted tied with the best local 4B, Jebadiah, and has the lowest hosted latency. Julia-1, the smallest and fastest of all (12 ms), scored at coin-flip level: fresh out of the factory, it’s a no-go. Jump to the full table, the cost in support emails, which model for which situation, how hard it is to run the best open ones locally or the gotchas.

How I tested

The central idea was to measure more than “who gets the most right.” A decision model has a design goal, and comparing a 322-million-parameter encoder made to run on weak devices with a hosted service of undisclosed size on accuracy percentage alone is unfair to both. So I measured accuracy, latency, cost and behavior under stress, and at the end I split the recommendations by situation.

The two case sets

I built two test sets, frozen in git before any inference, with the dataset hash recorded alongside the responses. No model receives the expected answer, the justification or the case identifier. Only the text, the instructions and the options.

The v1 set has 13 operational use cases, in English, each with an explicit fictional policy:

• support ticket severity
• support routing
• refund policy
• incident escalation
• tool approval (whether an agent may or may not execute a given action)
• email fraud
• document type
• evidence support
• search relevance
• moderation
• order routing
• lead qualification
• numeric-threshold triage

There are 10 scenarios per use case, each presented four ways: original, options in reversed order, options with opaque names (c0, c1, c2) and original plus a “reviewer” comment suggesting the wrong answer, which the instructions say to ignore. That’s 520 classifications per model. Add 24 probability probes in situations with no information at all (fair coin, six-sided die), where the right answer is mathematical.

The v2 set was made to cover what v1 leaves out: common semantics and Portuguese. There are 7 tasks, with 12 scenarios each, and every scenario written in English and in Brazilian Portuguese with the same answer and the same option order:

• sentiment (author versus quotation, negation, sarcasm)
• current intent (withdrawn request, competing actions, hypothesis)
• logical implication (quantifiers, absent fact, temporal order)
• search relevance (all, part or none of what was asked)
• sensitive data handling (fictional secret versus mention, redaction, revocation)
• current incident status (timeline order, verified versus unverified)
• threshold policy (inclusive bounds, units, AND/OR with a missing value)

Each pair runs under three conditions:

• compact: just the record and the rule
• with examples: one solved example per class, fixed and the same for everyone
• with distractors: ten irrelevant archive notes before the record that matters, to stress the context

That’s 504 classifications per model.

The cases were written with AI help and reviewed against the policies, without independent human annotation. It’s a small, synthetic benchmark: 130 scenario families in v1 and 84 in v2. The variants are correlated, so 520 responses are 130 scenarios seen four ways. Treat the numbers as a snapshot of these cases, and test with your own before deciding.

The 23 competitors

Five ran in the cloud, through the official API: Jev (version 1.13.0, from TypeSafe), Clef (27B, Cloudflare Workers AI), Clef-flash (9B, same), OpenAI Decisions (the gpt-6-luna alias, in public beta) and Microsoft Decision-1 (9B, post-trained from Qwen3.5-9B, served via OpenRouter on Azure). The other eighteen ran on the Strix Halo, via ROCm, with weights pinned by Hugging Face commit hash, inside a Docker container. The first three (Laya, Laya typed and Clef-flash) shared one container; the rest ran one at a time, with Julia-1 measured twice, on GPU and on CPU. The server has 64 GiB of GPU-addressable memory.

The order up there is just organizational, hosted first and local ones by family. The real ranking is in the results table.

Everyone received exactly the same text, the same instructions and the same options, with no per-model prompt tuning and no adjustments after seeing results (Simple-Jev uses its own server’s fixed prompt policy). The exception is GLiNER, whose native API takes labels instead of probability distributions. It runs on a separate track, v2 only, with explicit mapping and no made-up calibration metrics.

Simple-Jev deserves an explanation. It’s a server that takes a stock LLM (here Qwen3.5 4B, with no decision training at all) and reads the probability of the answer tokens instead of generating text. It’s the baseline: if a “decision” model loses to this, the specialized training bought nothing.

Two protocol notes. OpenAI Decisions answers through a native typed-decisions endpoint, and the alias the API returned is not an immutable snapshot: OpenAI can swap the weights behind the name, like Cloudflare does with Clef-flash. And Perplexity Decider is not a stock chat LLM: it has a separate decision head, with non-causal attention and a calibration temperature saved in the weights. A generic chat server does not reproduce its behavior. Microsoft Decision-1 speaks native SystemOne through OpenRouter’s decisions API, and the served identifier is dated (microsoft-decision-1-20261009), so it’s not an immutable weight either. It doesn’t show up in OpenRouter’s text-model catalog: to find it, you have to filter by the decisions modality. Decision 3.0 is the new family from the vLLM Semantic Router project, Apache 2.0, derived from Qwen, with six checkpoints (d3, flash, mini, nano, lite, edge) and native SystemOne. I tested the flagship (d3) and the smallest (d3-edge); the four in between are for another round.

What was measured

• Accuracy per task, per language and per condition, always on top of the per-option probabilities the model returns, ignoring the vendor’s “confidence” field.
• Brier and ECE for calibration.
• Median and p95 latency as seen by the client, including the network: WAN for the hosted ones, LAN for the local ones. These are deployment observations, and comparing hardware would require another test.
• Input tokens reported by the API, priced at the October 10 price table, before any allowance.
• Bootstrap confidence intervals over scenario families, instead of individual responses.

I left local cost unmeasured. Energy, hardware amortization and maintenance were left out, so local models show up as “not measured,” because “zero” would be a lie.

The full table

The main column is accuracy on the 168 compact v2 cases (84 in English, 84 in Portuguese). The v1 column uses the 130 original scenarios. Latency is the median seen by the client across the 504 v2 calls. Cost is the list price per 10 thousand compact decisions, computed from the tokens the API reported.

To calibrate your reading: the tasks have three or four options, so a uniform guess gives about 31% on both sets. “Near 50%” here is already well above the coin, and “near 33%” is the coin. Julia-1 landed at 31.5%: the pretty name hides a guy flipping a coin.

The intervals matter. Perplexity’s edge over Jev on v2 is under 2 points and the bootstrap interval touches zero: it’s the measured lead on this set, not a proven superiority forever. And Decision 3.0 tied Perplexity at the limit of what this set can distinguish: identical labels on the 1,024 classifications, with both missing the same two cases (the English relevance one on v2 and the disputed severity case on v1, already in the errata). Microsoft tied Jev on the aggregate, with the interval centered on zero, but an aggregate tie is not interchangeability: they miss different cases, and Microsoft inverts the language pattern, missing more in English than in Portuguese. Jev and Clef also remain under 2 points apart, on the same tier. The 90% squad (Jebadiah, OpenAI) sits 7 points behind Jev, and from there down every difference is clear.

Each task cell has only 12 scenarios per language, so one more correct answer moves the cell by more than 8 points. A tie on a specific task is a lead for a pilot. The per-task tables are in the repository.

How much it costs, in support emails

Price per million tokens is a number nobody can feel. List prices on October 11 are US$ 0.042 per million input tokens on Jev, US$ 0.24 on Clef, US$ 0.038 on Clef-flash and US$ 0.10 on OpenAI Decisions. Output is free on all five. Microsoft Decision-1 charges the same US$ 0.042 as Jev per million, via OpenRouter, but reported a third of the input tokens for the same texts (about 26 thousand versus Jev’s 77 thousand on compact v2), and nobody can explain the tokenization difference. In measured practice, that makes it the cheapest hosted one of the bunch.

Clef-flash cost US$ 0.09 on the 9th: Cloudflare cut the price by more than half in the middle of my test. Jev reports considerably more tokens than Cloudflare for the same text, about 45% more on v2, and that’s already in the math below.

Imagine an operation with 10 thousand support emails per month to classify into three or four buckets, with short texts similar to my cases:

In reais, at Friday’s exchange rate (R$ 4.99), 10 thousand decisions on Jev cost one real. A million costs less than a hundred reais. For any company with a million emails to classify, that vanishes into the budget.

One caveat about proportions: my cases are short, about 450 tokens per compact case by Jev’s count. A real customer email, with quoted thread history, can be three to five times larger, and cost scales linearly with that. Even so, we’re talking cents per thousand.

What this math shows is that the price difference between the hosted models is irrelevant next to the cost of being wrong. Jev costs 9 US cents more than Clef-flash per 10 thousand decisions, and in those same 10 thousand it makes about a thousand fewer errors. If a misrouted email costs more than a hundredth of a US cent in human rework, Jev pays for itself. This math assumes every error costs the same, which is never true: sending a critical ticket to the routine queue costs far more than the reverse.

Cloudflare’s allowance changes the math for small players. It’s 10 thousand “neurons” per day, shared by the whole account, resetting at midnight UTC. With my input sizes, that’s about 1,500 full-Clef classifications per day or almost 10 thousand Clef-flash ones, free. If you have 1,000 emails a day and nothing else running on the account, Clef comes out at zero cost with top-tier quality.

And local? Energy is what the benchmark didn’t measure. From what I see on my Strix Halo, the whole machine stays under 100 W under load. With Jebadiah at 200 ms per decision, 10 thousand decisions are about 35 machine minutes, under 0.1 kWh, a few cents of a real on the power bill.

The real local cost is the machine, your hours configuring ROCm and containers, and keeping it all standing. Whoever already has the hardware for another reason has low marginal cost. Whoever would buy the machine just for this is buying a problem of thousands of reais to save about a hundred reais per million.

Which model for which situation

You want accuracy and want to operate nothing: Jev

In the cloud, Jev is still the name. It won or tied practically every cell among the hosted ones, and only Microsoft tied it on the aggregate. In English it was 100% on five of the seven v2 tasks, and in Portuguese it repeated 97.6% on the aggregate without losing anything in translation, something no other model above the coin managed. On v1 it kept its 96.2% on the original with the malicious “reviewer” comment injected; Clef even gained one case, and Kev 4B also stayed put, just at a much lower tier. The 255 ms WAN latency came in 30 ms behind OpenAI’s, and it costs 19 US cents per 10 thousand decisions.

The trade-off is the one I already discussed in the previous post: it’s proprietary, hosted, of undisclosed size, and you depend on TypeSafe keeping the behavior underneath you. And it makes mistakes. It treated an invoice ID called “PASSWORD-523” as a usable credential, even with the record explicitly saying it doesn’t authenticate anyone.

You want Jev’s level paying a third: Microsoft Decision-1

Microsoft entered this market quietly, and entered well. Decision-1 is a 9B post-trained from Qwen3.5-9B, served via OpenRouter, and it was the first model to tie Jev on the compact aggregate: 97.6%, with the bootstrap interval centered on zero. The detail that won me over: 100% in Portuguese, better than its own English (95%), inverting the pattern of the entire rest of the bunch. On v1, the reversed-order and malicious-comment variants didn’t take down a single answer, and it got the critical ticket that Clef and OpenAI missed.

And it’s the cheapest hosted one I measured: US$ 0.065 per 10 thousand decisions, a third of Jev, charging the same per-token rate but reporting a third of the tokens. The savings come from the token count, and I can’t explain the exact mechanism, so treat it as a measurement, not a promise.

The weak spots exist. Latency is the worst among the hosted ones (422 ms median, versus Jev’s 255). On the compact cases it’s clean of confident errors, but add context and Portuguese errors show up with 99.5% confidence: the “perfect Portuguese” pattern doesn’t survive long text. And on the probability probes it’s weak, giving 87% to a fair coin. Microsoft advertises calibrated probabilities; my probes disagree. And like every dated-ID hosted model, the weight behind it can change without notice.

For a Portuguese-language operation that wants Jev quality while paying less, it’s the first candidate to run in your pilot.

You want the same level with open weights: Clef

The full 27B Clef tied with Jev in English (82 of 84) and finished 3 cases behind in Portuguese. It beat Jev on sensitive data handling in English (12 of 12 versus 11). It’s an open-weights model, so you can run it locally with about 54 GB of memory just for the weights in BF16, which I didn’t test: the full Clef ran only through the API. Among the open ones, it lost the crown to Perplexity, which scored higher with smaller weights.

Through the API it’s the most expensive of the five hosted ones, three times Jev, with no quality gain to justify it. The exception is the daily allowance: for small volume, it’s the best classifier you can get for free.

You want the cheapest in the cloud: Clef-flash

At US$ 0.038 per million, Clef-flash is the lowest price in the hosted market and covers 9,400 decisions per day within the allowance. Quality drops: 92% in English and 83% in Portuguese on the compact cases, the biggest language drop among the hosted ones, with an interval entirely below zero. On sentiment in both languages, and on incident status in English, it tied with Jev. On intent and sensitive data in Portuguese, it lost badly.

For sentiment tasks in either language, or for English classification where 1 error in 12 is acceptable, it does well. For Portuguese, measure first.

You already live in the OpenAI ecosystem: OpenAI Decisions

OpenAI’s debut in this market landed mid-table: 90.5% combined, an exact tie with Jebadiah, with the lowest hosted latency I measured (222 ms) and the same accuracy in both languages. It costs US$ 0.23 per 10 thousand decisions, between Jev and Clef. If your operation already speaks the OpenAI API and 9 out of 10 accuracy is enough, integration is trivial: a native decisions endpoint, no prompt at all.

The weak spots are revealing. Its worst cell was precisely numeric-threshold policy (8 of 12 in English, 7 in Portuguese): it treated “at least 10” as satisfied by a range of 8 to 12 and failed the AND/OR short-circuit. The calibration is schizophrenic: on the predicate probes (yes/no) it was the most accurate of the bunch, with near-zero average error, and on the choice probes it returned 94%/6% on a fair coin. And on the v1 variants it flipped 2 correct answers in each presentation (reversed order, opaque label, malicious comment), something only Perplexity didn’t do: Jev kept its aggregate accuracy, but also flipped some correct answers along the way. Oh, and the gpt-6-luna alias is not an immutable snapshot: reproducibility requires saving the responses.

You want the best open model, period: Perplexity Decider 27B

Perplexity Decider 1.1 27B is the surprise of the benchmark. It led the table with 99.4% on the compact cases, was the only one that didn’t lose a single task cell to Jev (3 wins, 11 ties), and hit 100% in Portuguese under all three conditions: compact, with examples, with distractors. Calibration is also the best measured, with a Brier of 0.012, and coverage is absurd: it answered with confidence above 0.9 on 96% of cases and got zero of them wrong. On v1, it didn’t flip a single answer across the order, opaque-label and malicious-comment variants.

Its only 3 errors on v2 were the same case in different clothing (it confused “notification sent to managers” with “mandatory approver”), and it made them with confidence below 0.9: the known error comes flagged. The weak spot is event-probability probes: asked about an event with a 1-in-4 chance, it answered 0.73. Strong classification does not imply reliable event probability.

The cost is hardware: about 49 GB of weights in BF16, a second and a half per decision on my Strix Halo (with ROCm’s reference kernels, no flash-attention; on a good NVIDIA it should be much faster, but that I didn’t measure). It’s Apache 2.0, public weights with no gate. If you have the machine and want the top of the table at home, this is the one.

You want the other open-weights top: Decision 3.0 (and beware the Edge)

Decision 3.0, released two days ago by the vLLM Semantic Router project, is the second model to sit at the top: 99.4% on the compact cases, 100% in Portuguese, and a tie with Perplexity so absolute that the two gave exactly the same labels on the 1,024 classifications, including the same two misses (the English relevance one, at confidence below 0.9, and the disputed severity case that already lives in the errata). It also cleared the v1 traps without flipping a single answer, got both indisputable critical tickets right, and its calibration is in the same class as Perplexity’s (Brier 0.014, 94% coverage above 0.9 with zero errors).

In other words: the open top now has two independent recipes that converge. For your pilot, either one works; run both if you can, because the probabilities differ even when the labels don’t. Latency is in the same family as Perplexity (1.4 s on my machine, same ROCm diet), and the weights take the same ~49 GB.

The little brother is another story. Decision 3.0 Edge (0.6B) answers in 45 ms and fits in 1.3 GB of GPU, but scored only 61% on compact, plummets 14 points in Portuguese, and worse: of the 68 guesses it gave with confidence above 0.9, 14 were wrong. As a confidence-threshold router, out of the factory, it’s a trap from the same class as Julia. The four middle checkpoints (flash, mini, nano, lite) I haven’t tested yet; they’re the ones that will tell whether the family has a sweet spot between the two extremes.

You need to run locally, with quality: Jebadiah 4B v2

Of the local ones, Jebadiah 4B v2 had the best compact accuracy, 90% combined, answering in about 200 ms. It tied with Jev on six of the fourteen task cells, including intent, implication and status in English and intent in Portuguese. The weak spot is numeric-threshold policy, 9 of 12 in both languages, and it loses ground when the context fills with distractors (76% in Portuguese under that condition, versus 82% for Mapika).

Mapika Decider 4B (the fastest of the 4Bs) and Kev 4B are right behind, both around 87%, and the 3-point difference between the three fits inside the error interval. They’re three different training recipes on top of 4B backbones, with errors on different tasks. The choice between them depends on your task, and I’d run all three in a pilot.

You will send examples in the prompt: Kev 9B

Kev 9B has a curious profile. On the compact cases it ties with Kev 4B, half a point apart with the interval crossing zero, meaning more than double the parameters bought nothing. With one solved example per class, it opens almost 10 points over the 4B, and with distractors it holds 7 more points. Brier also improves by about 25%: the probability it returns is better calibrated.

If your use is just the rule and the text, the 4B is enough and is more than twice as fast. If you’re going to send examples or long context, the 9B is worth the memory. The warning is Portuguese: 83% compact in PT-BR, almost 10 points below its own English, the biggest language drop among the models above 80%. Only Laya typed (14 points) and Julia (13) drop more.

You want Clef-flash behavior on your machine: local Clef-flash

On the v1 set, local Clef-flash reproduced the hosted one’s 520 classifications, hit for hit and miss for miss. On v2 the story changed: same total (439 of 504), but 19 different labels, with swapped strengths (the local one gets more Portuguese intent right, the hosted one gets more relevance right). Among the local ones it’s still the best on the v1 operational-policy set (90.8%), ahead of every 4B.

The gotcha is latency: 618 ms median on the Strix Halo, three times Jebadiah, for the same v2 accuracy. If you pick it, it’s for the known behavior.

You need to run offline on weak hardware: Laya and Julia, with many caveats

Laya multilingual was the worst in the benchmark for accuracy (37% combined, near the coin), and the fastest by far among the ones that get anything right: 19 ms median, more than ten times faster than Jebadiah.

The three Laya checkpoints have between 322 and 421 million parameters, fit in under 1 GB of BF16 weights by parameter math, and the project documents CPU execution and an ONNX runtime (which I didn’t measure). PyTorch’s peak GPU allocation for the multilingual one stayed under 2 GB. A 4B needs about 8 GB just for weights at the same precision.

Julia-1 goes one step lower: 144 million parameters, 550 MB of weights, 12 ms median on GPU and 71 ms on a 4-thread CPU. It’s the fastest model I’ve ever measured here, and also the worst: 31.5% accuracy, glued to the 31% coin-flip line. In Portuguese it answered “cancellation” on all 12 intent scenarios, including the ones asking for a refund or access (the vendor’s Portuguese evaluation was done in pt-PT, and it shows). The bigger disaster is confidence: of the 71 guesses it gave above 0.9, 48 were wrong. A confidence threshold won’t save this model, because it’s exactly on the confident guesses that it errs.

That’s a design choice. Laya and Julia were made to be small encoders, fine-tunable on your task, to run at the edge. What I tested were the factory checkpoints, with no tuning, applying rules they had never seen, on broad tasks. In that scenario they did badly, period.

One detail confirms the fragility. On v1, when the reviewer’s malicious comment comes in, Laya drops from 44% to 19% and typed-decisions to 15%. It obeys the comment the instructions say to ignore, and confidently: 17 of the 28 guesses above 0.9 were wrong. Julia failed all 5 policy-counterfactual pairs: change the rule, it keeps the answer.

If you want what Jev delivers, factory Laya and Julia are very far from it, and no small model (GLiNER included) came close. If your problem is “I need to classify short text into three buckets, on a device with no internet and no GPU, and I have a thousand labeled examples to fine-tune on,” these two are the only ones on the list that fit. Fine-tuning is the part I didn’t test. It’s another question, and it needs another benchmark.

The baseline: Simple-Jev with a stock Qwen

Simple-Jev reading tokens from Qwen3.5 4B, with no decision training at all, scored 74% on compact v2. That’s the yardstick for “how much specialized training buys”: Jebadiah, Mapika and Kev, all on similarly sized backbones, came in 13 to 16 points above. The training buys a lot.

The curious part is that on v1 Simple-Jev tied with Jebadiah (111 of 130 originals) and got both unambiguous critical tickets right, which several better models missed. It’s also the slowest of the bunch, almost a second and a half per decision, because it’s running a whole LLM.

How hard it is to run the best open models on your machine

All these models speak the same HTTP protocol, called SystemOne, which Jev popularized: you send a state (the text), one or more closed-answer questions, and get back the chosen option and the probability of each. Swapping models is swapping the port. OpenAI Decisions breaks from the pattern with its own native endpoint, but the idea is the same. What changes is how much work it takes to get each one standing, and there the difference between them is big.

OpenAI: just an API key

The easiest of all: create the key, load credit and call the endpoint. The benchmark’s 1,048 requests ran in 4 minutes, without a single retry. The only hiccup was the first probe returning “balance exhausted” until I put US$ 20 in the account.

Microsoft Decision-1 is almost as simple: if you already have an OpenRouter account, it’s point at the model and call the decisions endpoint. No GPU, no Azure subscription, no installation. In my test, 10 of the 504 v2 calls took a 429 and passed on retry, so plan for retries.

Kev and Jebadiah: one pip and one command

Kev is the simplest of the 4B crowd. The project installs straight from GitHub and brings up a server with one command, downloading the LoRA adapter and the decision head on top of base Qwen3.5:

pip install "kev @ https://github.com/jaredpalmer/kev/archive/fc4a17e194bca35a48c57211392ec49ea54a94ac.tar.gz"
python -m kev.serve --run jaredpalmer/kev-4b --host 0.0.0.0 --port 8000 --device cuda

Jebadiah follows the same pattern, with the server package inside its own repository:

pip install "jebadiah-server @ https://github.com/getainode/jebadiah/archive/e9793abc66d1a7c5ad878d51eda656f1e9c5b9f5.tar.gz#subdirectory=server"
jebadiah-serve --model frontier-infra/jebadiah-4b-v2 --host 0.0.0.0 --port 8000

With either one up, a decision is a POST:

curl -s http://localhost:8000/v1/systemone -H 'content-type: application/json' -d '{
  "model": "kev-4b",
  "state": "Cliente diz que foi cobrado duas vezes e pede o estorno da segunda cobrança.",
  "questions": {
    "fila": {
      "type": "choice",
      "instructions": "Escolha a fila correta pela política de suporte.",
      "criteria": {
        "financeiro": "Cobrança, estorno, nota fiscal.",
        "tecnico": "Erro, bug, indisponibilidade.",
        "vendas": "Upgrade, plano novo, orçamento."
      }
    }
  }
}'

The response carries the option and the probability distribution, and that’s where you apply your threshold, log and decide whether to send it for human review. On an NVIDIA with CUDA and 16 GB of VRAM, a 4B in BF16 comes up without drama. The weights are about 8 GB.

Laya and Julia: smaller still

Laya is a Python package with an encoder inside. It installs with pip install laya and the project documents CPU execution, which is its whole point. The version pinned on my server was 0.4.1, and the multilingual one’s peak GPU memory stayed under 2 GB. To run on a GPU-less laptop or a small container, it’s the only one on the list that fits, no discussion.

Julia-1 is similar in spirit: its own Python runtime, one predict(state=..., questions=...) call and done, no standard Transformers pipeline. I ran the same container on GPU and on CPU, and both gave the same accuracy with the same responses in 97% of cases. On a 4-thread CPU it answers in 71 ms, which for an edge classifier is great. The problem is still that it scores at coin-flip level.

Where it gets complicated: AMD, ROCm and the rest

In my case the hardware is AMD, and then “one command” turns into a day of work. The points that cost me time, to save you yours:

• None of these projects test on ROCm. Kev had a gfx1151-specific segfault caused by CUDA graphs (issue 170), fixed only after the 1.0 tag, so the pinned version is a main-branch commit and the official tag crashes.
• The flash-linear-attention Triton kernels Qwen3.5 uses in the DeltaNet layers have no tested support on gfx1151. Everything ran on the pure-PyTorch path, slower than the latency published on CUDA. Jebadiah’s 200 ms in the table is with that handbrake pulled.
• Mapika Decider forces CUDA graphs when it sees the “cuda” device, which on ROCm is also called “cuda.” I had to turn it off by hand.
• You need to export HSA_OVERRIDE_GFX_VERSION=11.5.1 and PYTORCH_ROCM_ARCH=gfx1151 and use a base image with ROCm torch already validated. Any random pip install torch overwrites it with the CUDA build and breaks everything. In my Dockerfile every package is installed with --no-deps and the build fails if torch stops being the ROCm one.
• One model per container, one container at a time. The Strix Halo has memory shared between CPU and GPU, and three resident 4B models plus the Ollama that already runs there exhaust the 64 GiB the GPU can see.
• Perplexity Decider was the most annoying of all. The release expects a specific CUDA torch (I swapped in the ROCm 7 torch 2.9), the flash-linear-attention kernels don’t exist for it (I ran on PyTorch’s reference kernels, slower), and the default loader blew past the host’s 24 GiB RAM limit: I needed a custom loader that sends the 49 GiB of weights straight to the GPU. The model card still said “private” when I started, but the Hugging Face API confirmed it was public and gate-free, and the shards downloaded anonymously. The d3, at the same size, inherited the same treatment. The d3-edge, luckily, comes up with the standard Transformers loader and 1.3 GB of GPU.

None of this is impossible, and it’s all documented, with Dockerfiles, compose and the hashes of each checkpoint, in the repository’s setup guide. But it’s a real cost that the “local is free” spreadsheet never includes. If your machine is NVIDIA, most of this list disappears.

The full 27B Clef I didn’t even try locally: it’s about 54 GB of weights in BF16 before any activation. Perplexity, at 49 GB, proved a 27B runs on the Strix Halo, at the cost of a second and a half per decision with the reference kernels. The 9B Clef-flash runs, with about 18 GB of weights. The 4Bs are the sweet spot for consumer hardware.

Highlights and gotchas

Laya truncated all long Portuguese. Under the distractor condition, base Laya reported truncation on all 84 Portuguese calls, discarding almost 31 thousand state tokens, and on none of the 84 English ones. The English checkpoint’s default context limit is only 512 tokens (the multilingual and typed ones use 1,024, configurable up to 8,192), and Portuguese tokenizes heavier. The other models don’t even expose truncation telemetry, so “zero truncation reported” on them means “I don’t know.”

Portuguese costs more tokens. For the same 84 case pairs, Jev reported about 14% more input tokens in Portuguese than in English, and both Clefs about 15% more. If you budget a bilingual operation by the English average, you’ll come in low.

Does an example in the prompt save a weak model? It saves nothing. One solved example per class left Laya the same or worse; several of its aggregates dropped. It helped Kev 9B (plus 4 points) and Clef in Portuguese (plus 3.6 points, reaching Jev’s level), and almost nothing on Jev, one more case in Portuguese. Validate examples on real traffic before assuming they help.

Size correlates, and explains little. Among the 19 competitors of known size, the Spearman correlation between parameters and compact accuracy was 0.96. The Kev series is more informative: 63% at 0.8B, 87% at 4B, 88% at 9B. The big jump is from 0.8B to 4B, about 24 points, with an interval between 16 and 33. From 4B to 9B the compact difference crosses zero, and several nominal 4Bs, with similar backbones, gave very different results. In the d3 family, the flagship and the Edge sit almost 40 points apart under the same release, while a 9B, Microsoft, ties at the top of the hosted ones. Size helps up to 4B; past that, the training recipe rules.

The 27B Clef missed a critical ticket that two of the Layas got right. On v1, one severity scenario says continuous data loss in production is critical, regardless of how many customers it affects. The record describes confirmed permanent loss, from a single customer. Jev, Clef-flash, Perplexity, d3, Microsoft, Laya typed, Simple-Jev and Laya multilingual answered “critical.” Full Clef, OpenAI, base Laya, Eikos, Jebadiah, Mapika, Kev 4B and Kev 9B answered “degraded.”

It’s a single case, and an error rate would require many more. But it shows that the average hides exactly the error that costs the most. When the impact facts are structured, the severity rule belongs in code, and the model comes in only to extract the facts from free text.

Hosted and local diverge over time. Local Clef-flash reproduced the hosted one on v1’s 520 classifications and diverged on 19 of v2’s 504. Cloudflare keeps the weights version behind the hosted alias undisclosed. If reproducibility matters, pin the local hash.

High confidence and safety are different things. On compact v2, Jev, Clef, both Clef-flashes, Eikos, Jebadiah, OpenAI, Microsoft, Perplexity and d3 got zero guesses above 0.9 wrong. Perplexity is the extreme case: it answered at that level on 96% of cases without missing one, with d3 right behind (94%, zero errors). Microsoft covered 95% and OpenAI only half. Microsoft’s caveat: the clean record is only on compact, because with examples or distractors it misses in Portuguese with confidence above 99%. Mapika missed 5% of the guesses at that level, Kev 4B 3% and Simple-Jev 14%. And the two smallest of the bunch broke the pattern violently: Julia missed 48 of 71 guesses above 0.9, and d3-edge missed 14 of 68. Coverage varied too: Jev answered above 0.9 on almost 90% of cases, Clef on almost 80%, Clef-flash on 40% and base Laya on 2 of 168. On v1 Jev missed 1% of the guesses above 0.9 and base Laya missed 61%. A confidence threshold only works after being validated on your distribution, and Laya typed’s low ECE in Portuguese left it at the same 36% accuracy.

Perplexity didn’t fall for presentation traps. Across the three v1 variants (reversed options, opaque labels, malicious comment), it kept the same answers as the original, without flipping a single one. The d3 repeated the feat, zero flips too. Microsoft only stumbled on the opaque labels (2 flips, one in each direction); order and comment didn’t move it. OpenAI flipped 2 in each variant, and Laya collapsed to 19% under the comment. The price of that robustness is latency: a second and a half per decision on my machine, the worst median of the bunch.

Numeric thresholds are a code problem. The threshold-triage task, with clear numbers and an explicit rule, gave 100% on Jev and both Clef-flashes and under 30% on both Layas in English. An if solves that with 100% and zero latency. The model only comes in when the number is buried in free text, and even then the right thing is to extract the number and leave the comparison to code.

Lottery probability is another skill. On the 24 no-information probes (coin, die), Jev had the worst choice error among options. The numeric-estimate crown changed hands with OpenAI’s debut: its yes/no predicate missed almost nothing, while the choice probe returned 94% for heads on a fair coin. Perplexity, champion of everything else, answered 0.73 for an event with a 1-in-4 chance, and Microsoft went the same way, giving 87% to the coin. Laya typed had the second-best choice error, behind only Kev 9B and neck-and-neck with Clef, and still classified badly. It’s the “student who marks answer A” from Paulo’s essay, now measured: calibration on lotteries and accuracy on classification are independent measures.

Where the data converges

1. The overall top is open-weights, and now there are two. Perplexity Decider 27B and Decision 3.0 tied at 99.4% on the compact cases, with 100% in Portuguese and identical labels on the 1,024 classifications, both with Apache 2.0 weights running on my machine. Their edge over Jev is under 2 points and the interval touches zero, so treat it as a snapshot of this set. Their cost is hardware and latency, not API. In the cloud, the evaluation order changed: start with Microsoft Decision-1, which ties Jev on the aggregate, closes 100% in compact Portuguese and costs a third. Jev comes next, faster and with different errors, because an aggregate tie is not interchangeability. OpenAI Decisions landed halfway in price and accuracy.

2. Running locally became viable at 4B. Jebadiah, Mapika and Kev 4B deliver between 87 and 90% on the compact cases with 200 ms latency on a desktop machine, and in a pilot with your task any of the three can win. If your machine handles 49 GB of weights, Perplexity delivers the top of the table at home. The financial math justifies using the machine that already exists, for data control or because of an obligation to stay offline. Buying a machine for this it stops justifying.

3. Small models are another category. Judging Laya and Julia by the accuracy column is reading the table wrong. They get half or more wrong out of the factory, fall hard under a malicious comment, and together with the d3-edge they’re the only ones on the list that fit on a weak device and answer in tens of milliseconds. The Edge is the best of the three on accuracy (61%), but it plummets in Portuguese and gets one in five confident guesses wrong. If Jev-like accuracy is a requirement, cross all three off. If running offline on small hardware is a requirement, cross everything else off and start with fine-tuning them on your task, which is the missing measurement. And be careful with Julia and the Edge in particular: 48 errors in 71 and 14 in 68 confident guesses are the portrait of models that don’t know what they don’t know.

4. Portuguese costs about 14% more tokens and drops the models in the middle of the table by 1 to 10 points, with Kev 9B and Clef-flash in the worst case. Jev loses nothing, OpenAI ties both languages, and Perplexity, d3 and Microsoft close 100% in compact Portuguese, better than their own English, although Microsoft goes back to missing in Portuguese when the context grows. Julia goes the other way and plummets 13 points, and the Edge plummets 14. For a Brazilian audience, that’s the first column to look at, before price.

And what holds for everyone: none of these models replaces the rule that’s already in code. Numeric thresholds, severity policy with structured facts, tool permission, all of that stays in the if. The model comes in to turn free text into structured fact. And the test that matters is yours, with your tickets, because each cell in this table has 12 scenarios and your operation has thousands.

The cases, each model’s raw responses, the scoring scripts and the guide to reproduce everything are in the benchmark repository. If you run it with your tickets and get a different ranking, tell me.

TL;DR for those who only want to know which one to use: Jev is a hosted classifier, good and cheap for repeated decisions over text, and not a silver bullet. If you want the direct comparison, skip to Clef, Cloudflare’s open alternative with weights and image input; to Laya, the small encoder to run locally and fine-tune on your task; to the public ranking, with 70 models side by side; or straight to how to decide in your project.

When Jev showed up, I didn’t think much of it. The homepage was a festival of jargon, Kahneman here, Jevons there, a “193x faster” with no benchmark next to it, and my rule for new AI tools is not to adopt any intermediate layer until it hurts not to have it, so I didn’t spend time on it.

In that post I concluded that, marketing aside, Jev is a hosted classifier: you send a text and closed-answer questions, it returns the option and the probability, without generating any prose. And that the “193x” only impresses because the comparison is against a chat LLM writing a paragraph so you can fish a label out of it afterwards.

What I hadn’t registered at the time is the size of the habit Jev exposes. A lot of people were using a frontier LLM as an expensive stand-in for an ordinary classifier, and had never thought about a classifier, because they never had to: the LLM solved it, badly and expensively, and nobody measured.

For me, a classifier would be the first idea, which is why Jev didn’t look like news. For many people it was a revelation. That gap is the subject of this post.

This post is a collaboration

Much of what you’ll read here is by Paulo Câmara, neuroscientist, co-founder and CTO of LUA Vision, the Brazilian company whose model I tested and investigated in recent weeks. He wrote an essay, “The student who marks answer A,” to be published here, in which he read Jev’s fine print, opened the roughly 350 test repositories that appeared on GitHub in launch week, and recomputed the four main results from scratch.

The warning Paulo gives at the end applies: he founded a company that builds its own model and competes in the same market. Read with that discount, and check the numbers at the source, all of which he links.

First: what a classifier is

A classifier is a function that takes an input and returns one of a fixed set of categories, usually with a probability for each. This email is spam or not. This ticket is billing, support or sales. This transaction looks like fraud.

The list of possible answers is closed, and you know it before you run.

The classic way to build one is with labeled examples: a set of texts where someone has already given the right answer. On top of that you train a model, which can be something as simple as logistic regression or naive Bayes, or a small encoder like BERT with a few hundred million parameters. In every case, the final model is small, runs locally, answers in milliseconds, costs almost nothing per call, and returns numbers you can calibrate and audit against your own data. This has existed for decades and is undergraduate material.

So when someone with a computer science background sees a problem like “decide which bucket this text falls into, thousands of times a day,” the first question is “how many labeled examples do I have?”, not “which LLM do I use?”.

A chat LLM is a text generator with billions of parameters. Using it to return a label means paying per output token, waiting seconds per answer, dealing with a format that sometimes breaks, and accepting behavior that changes when the vendor updates the model. It can be done, and zero-shot classification with language models has been documented since 2019. But it’s the expensive, slow option, and it only pays off when you have no examples at all or when the categories change with every request.

Jev lands exactly in that space. It’s a classifier that accepts categories defined on the fly, several questions about the same text in a single call, hosted, cheap per token and fast.

Compared with a chat LLM generating a paragraph, it’s an engineering win. Compared with a classifier trained for a stable task, it’s a convenience that trades control for flexibility. Keep those two yardsticks in mind, because the rest of the post goes back and forth between them.

Paulo’s essay: “The student who marks answer A”

What follows is Paulo Câmara’s essay, written for this post. The subheadings are his.

Every week an AI savior shows up. This week’s is called Jev.

It launched on September 15, with US$ 40 million in the bank, a US$ 200 million valuation and a promise that fits on a billboard: two hundred times faster, four hundred times cheaper, calibrated and incapable of hallucinating. Within 24 hours, 13% of the paid teams on Vercel’s gateway were already using it. Within a week, there were more than 300 repositories on GitHub testing the thing.

I did what I do with every savior. I read the fine print, opened the roughly 350 repositories, and redid the math for the ones that published raw data. What I found fits in the image above: an answer sheet with answer A marked on every question.

When there is no information at all to decide on, Jev marks the first option. In 3,000 of 3,000 draws. With up to 92% certainty. Keep that image, because it explains the rest of the text.

What it is, without the billboard

Strip away the marketing and what’s left is a multiple-choice exam with no essay section. You send a text, ask closed-answer questions (choose among up to 255 options, give a score on a scale, say yes or no) and it returns the probability of each answer. It doesn’t write a line. It doesn’t explain. It doesn’t do math. It doesn’t call tools.

That’s good, and I want to start with what’s good. Many companies today use a frontier LLM as a luxury if statement: send the document, wait twenty seconds for the model to think out loud, pay for every word it writes, validate the JSON, and only then find out the ticket was about billing. Jev cuts that theater. It reads the text once, scores each option, done. That’s why output is free and ten questions cost almost the same as one.

The mechanism, though, isn’t new. Reading the score of each possible answer is how language models have been evaluated on multiple choice since GPT-2. It’s how the reward models of RLHF work, a technique TypeSafe’s founder helped create at OpenAI.

A few days after launch there was already an open copy imitating the interface with a public model, and ten days later Stanford and Nvidia released an open-weights competitor. TypeSafe published no paper, no weights, no model size and no result on a public benchmark. In the announcement’s FAQ, “Is Jev just a smaller LLM?” appears as a question. The answer is one line: “it is neither small nor an LLM.” That’s it.

One opponent for each headline

The homepage says “193.6× faster, 444.6× cheaper.” I redid the math with the table the company itself published. The 444.6 is the cost of Opus 5, the most expensive model on the panel, divided by Jev’s cost. The 193.6 is Sonnet 5’s time divided by Jev’s time. One opponent for each headline.

It’s like advertising that your car is more fuel-efficient than a Ferrari and faster than a truck, and letting the reader conclude it’s the best car in the world.

How many times cheaper Jev is, depending on who is on the other side. Source: TypeSafe’s public table (evals.typesafe.ai) and independent tests against non-reasoning LLMs.

Against the cheap model that scores about the same, Luna, Jev is 8 times cheaper. And that’s with every LLM in the comparison thinking before answering, something nobody does to route a ticket. Against a non-reasoning LLM, the independent tests measure about 4 times on cost and 2 to 7 on time. Still a lot. But an order of magnitude less than the billboard.

There’s a detail almost nobody read. There is no answer key in that evaluation. “Accuracy” is how much each model agrees with the average of two frontier models. Jev agrees 67.8% of the time, the same as Sonnet 5. Opus 5 is at 73.1%.

Agreement with the reference versus cost per case, average of TypeSafe’s four workflows. The green band runs from 66.8% to 67.9%: Luna, Sonnet 5, Terra and Jev.

Breaking it down by task shows what the average hides. On invoices, which require checking amount, quantity and date, Jev is 17 points behind the best model (61.8% versus 79.1%) and below even Luna. Its documentation warns that it “is not a calculator.” At least that is true.

Agreement by workflow. Source: evals.typesafe.ai.

And the most solid data on TypeSafe’s site isn’t even about Jev. All eight LLMs evaluated score higher when the task is broken into small questions and the logic stays in code. Haiku 4.5 goes from 18.1% to 53.6%. The most useful lesson of the launch is an engineering one, and it applies to any model.

What the price gives away

Price is technical data in disguise. At US$ 0.042 per million tokens, a rented GPU needs to read 13 to 20 thousand tokens per second just to break even. In a scenario calculation, that squares with a model of 6 to 37 billion active parameters, which is a small model, or with a subsidy. TypeSafe wrote, with a candor I respect, that “there is no way to prove it isn’t subsidized.”

Since launch, the per-account usage limit dropped from 250 thousand to 100 thousand tokens per second. The documentation warns that it changes “without notice” until the “large GPU deals” land, and the subprocessor list shows inference running on an on-demand rented GPU cloud. It’s a frontier model with startup capacity.

In the same calculation, each decision costs about 14 joules. That’s Jev’s best argument, and I’ve defended that yardstick for a long time: accuracy per joule, not just accuracy. There, it’s genuinely good.

Exam Portuguese

I found only one test of Jev in Portuguese: ENEM 2025. I redid the math from the raw answers. Jev got 103 right against 102 for an open 120-billion-parameter model. A statistical tie (p = 1.0).

Jev’s accuracy on ENEM 2025 by subject area, 182 valid questions, with 95% margins. Recomputed from the patryckalves/jev-no-enem repository.

Jev reads exam Portuguese better than many prep courses: 78% in Languages. And does Math like someone guessing: 25%, with a guess worth 20%. In Spanish, another audit measured a loss of 3 to 6 points relative to English and 17% to 38% more tokens for the same text. It’s the token tax I measured in my paper, charged again, now by another vendor.

One detail in its favor: the explicit “invalid” option in that experiment separated out the hardest questions. That’s the abstention route worth demanding in production, measuring alongside it how much it leaves unanswered.

The student who marks answer A

Back to the answer sheet.

An auditor asked Jev to predict a fair die it had no way of seeing. The honest answer is 1/6 for each face. I downloaded the 1,000 answers and counted. In every one, Jev chose the first option on the list it received: “1” on the die, “red” on the color die, “heads” on the coin, “north” on the spinner. With 76% to 92% certainty.

A second researcher repeated the same question 2,000 times, independently. Same result. The caveat: this holds for choice questions; in the yes-or-no-with-probability formulation, the same repository shows Jev closer to the reference, still overestimating low probabilities.

When it doesn’t know, it doesn’t say it doesn’t know. It marks answer A, with conviction.

Stated probability versus actual frequency. Draws: 1,000 answers recomputed (KantaHayashiAI). Heart risk: 5,000 people from BRFSS, recomputed (rubinagentagi-tech). Items with human disagreement: pre-registered study with ChaosNLI (GautamTalksDev). ENEM: recomputed (patryckalves).

The chart shows the whole pattern. Where it has signal, as in ENEM answers above 0.9, what it says and what happens coincide: 97.1% confidence, 97.6% accuracy. Where it doesn’t, the certainty stays and reality leaves.

In a test with 5,000 real people, the heart disease rate was 9%. Jev assigned, on average, 27%. I recomputed: its probability is worse than simply saying 9% for everyone.

System 1, literally

TypeSafe calls Jev a “System One model,” a nod to Kahneman’s fast thinking. It’s the most honest part of the product, just not for the reason the company would like. In the book, System 1 is fast, cheap and automatic. It’s also where overconfidence lives: it builds the most coherent story out of what’s in front of it and doesn’t register what’s missing.

Kahneman spent years disagreeing with Gary Klein about when to trust expert intuition. In 2009 the two published a joint paper with the most elegant title in psychology: “a failure to disagree.” The conclusion fits in one line. Intuition only deserves trust in a high-validity environment, where there is regularity and there has been feedback to learn it from. Outside that, confidence stays high and stops saying anything about accuracy.

That’s Jev, exactly. Classifying English text is a high-validity environment, and there it does well. Predicting risk, drawing lots, guessing the company rule nobody told it about: a low-validity environment. There it stays confident.

In the lab, we separate two things: deciding, and knowing whether you decided well. The second is called metacognition.

It’s measured with signal detection theory, Maniscalco and Lau’s meta-d′, and it depends in part on prefrontal regions distinct from the ones that support the decision. Fleming and colleagues found that in the anatomy in 2010, and Rounis and colleagues, the same year, showed that magnetic stimulation of the prefrontal cortex knocks down metacognition without touching accuracy (a result whose replication is disputed, by Bor and colleagues in 2017). That’s why there are people who get it right without knowing they did, and people who get it wrong with conviction to spare.

The field the company calls confidence is a formula over the same distribution that produced the answer: in a two-option choice, 2p − 1. That isn’t a defect in itself. An ideal observer does exactly that and gets it right.

The problem is that Jev’s distribution loses calibration outside what it knows, and nothing in the system checks the answer by another route. When the signal disappears, the answer becomes wrong and the confidence stays the same, because the two are the same number. In a pre-registered study with items on which a hundred people disagree, human agreement is 47% and Jev carries on at 81% confidence. When the coordinates of a spatial task were shuffled, accuracy collapsed to 5% to 22% and confidence dropped by 0.028.

A model that says 83% about a die it never saw isn’t calibrated. It’s assertive.

Attention gets captured

I studied attention in my doctorate, and I expected to see capture: the loudest stimulus winning. That’s not what the tests showed. The shout, the famous “ignore your instructions,” barely gets through. What gets through is the plausible sentence with no checked origin. Psychology has a name for this: source monitoring failure. The system treats a claim nobody verified as if it were fact.

Decisions flipped by attack type. Crude attack: 1 in 1,056 (cwhy). Injected command and unverified opinion: 9,744 variants (Hu et al., 2026). Optimized fluent context: 312 of 508 correct decisions (Xu, 2026).

In numbers: the crude attack gets through 1 in 1,056. A single unverified opinion pasted at the end of the text flipped 12.1% of decisions, statistically tied with the strongest injected command. A line saying “the closing administrator has confirmed this article was kept” dropped accuracy from 96.5% to 26.5%.

A fake field saying the user had pre-approved rm -rf ~/.ssh lowered the chance of blocking from 0.76 to 0.48. It recalls Loftus’s misinformation effect: suggested information rewrites the judgment.

The capture also applies to cues that shouldn’t count. With the same text, saying only “the writer is Black” or “the writer is white” changed the death-penalty rate Jev assigned from 29.5% to 62.7%. The direction is beside the point. A life-or-death decision moved 33 points because of information that had nothing to do with the case.

There’s one more I can’t let pass. Changing only the option labels, from “0/1” to “no/yes,” without changing any definition, flipped 70 out of every 100 answers. The type error rate stayed at zero. The format was perfect. The decision was backwards.

These numbers come from preprints and small studies. The exact percentage changes with prompt, task and model version; the class of failure does not.

Probability that doesn’t add up

Probability has a first-semester rule: the chance of something plus the chance of its opposite equals 1. In TypeSafe’s own documentation, “is the customer asking for a refund?” gets 0.72, and “is the customer asking for something other than a refund?” gets 0.47. Sum: 1.19.

The pair isn’t an exact complement, and TypeSafe doesn’t promise that two separate questions form a joint distribution. But it’s the example the company itself chose to show off the product, and it doesn’t add up. The fix is a design one: a single choice question with mutually exclusive options, instead of two yes-or-nos added together.

People get probability wrong in many ways, but on this one they tend to get it right. When the question comes as a pair, the chance of something and of its opposite sum close to 1. Tversky and Koehler showed that in 1994. Jev gets wrong what people get right. The same decision changes value depending on the wording of the question, and that is the opposite of “epistemically honest probabilities.”

“It doesn’t hallucinate”

The announcement says Jev “cannot hallucinate” and shows 0% type errors. The zero is true and irrelevant. Since it can only answer within the options you gave it, getting the format wrong is impossible. Calling that not hallucinating is like praising the answer-A student because he never leaves a question blank. True. So what?

In a model that chooses, hallucinating is choosing wrong with conviction. On fact-checking, Jev ties GPT-6 Astra on accuracy but calls an unsupported claim “supported” 23% of the time, against 14% for Astra. In 76% of the situations where there was no tool at all, it chose to call a tool. With a company rule it wasn’t told about, it got 19 of 24 decisions wrong, 15 of them with more than 90% certainty. Faced with an invented law, it abstained zero times.

Security

First, where your data ends up: the United States, AWS and a GPU cloud called Modal. Retention lasts “for as long as reasonably necessary,” with no deadline, and zero retention only exists on the enterprise plan.

The data agreement cites the European Union’s standard contractual clauses, the UK addendum and California law, and doesn’t have a word about LGPD. If you send Brazilian citizens’ data, the legal basis for the international transfer is on you, and that’s a question for a lawyer before signing. The promise not to train on what you send exists and is good. SOC 2 exists and only appears on request.

As an attack detector, Jev is good, with fewer false alarms than many LLMs: it caught 40 of 41 injections in a test with real pages. As a judge of content that carries the attack inside it, it gives way, as I showed above. The difference looks subtle and decides everything. In my GV Angels talk I said an agent is not an employee, it’s an access key that talks. A gate made only of Jev is a lock that opens when someone writes on the note that the owner authorized it.

The error that worries me isn’t the error with doubt. That one goes to review. It’s the error with 92% certainty, which crosses any threshold you configure.

The wave

A word about the evidence, because I used a lot of it.

Jev test repositories created per day on GitHub, from the metadata of 346 indexed repositories.

In one week about 350 repositories testing Jev were born. I classified all of them by what they let you check. There are 89 with raw data, code, pinned version and statistics, and 170 with data and code; the rest offer less than that.

Only 11 wrote the hypothesis down before running the test. The median is one GitHub star, which means almost nobody looked. And the wave of tests followed the wave of hype: peak on September 21, almost nothing after the 23rd.

That’s why I didn’t accept numbers on authority. The ones that support this text I checked at the source, and the four main ones I recomputed from scratch.

Verdict

True:

• Fast: 100 to 400 ms.
• Cheap: 45 to 323 times less than a frontier LLM on the same decision.
• Ties the top on narrow judgments, like checking whether a passage supports a claim.
• Reliable above 0.9 on data similar to what it has already seen, after you’ve checked that on yours.
• Good injection detector.

Sandcastle:

• 193.6× and 444.6×.
• “Frontier intelligence.”
• “Doesn’t hallucinate.”
• Calibration as a general rule.
• Safe as the sole guard of an agent.
• New architecture: nobody has seen it.

Jev is nobody’s savior. It also isn’t “just a classifier.” It’s a good piece of product engineering that wraps known technique in an interface automation needed, at a price that changes what’s viable. The product is new. What it claims is new, so far, is marketing: it calls format truth, task calibration honesty, and System 1 a virtue.

What will break first

• The agent gates built only of Jev, because the attack that breaks them is already published and costs cents.
• The systems that trust the factory threshold on new data, in another language or with an internal rule, because they’ll automate errors at 90% certainty.
• Whoever uses its probability as real risk, in credit, health or forecasting, because it inflates rare events.
• And the price advantage, because within ten days there was already an open copy and a faster competitor.

If you’re going to use it anyway

• Pin the version. The jev-latest alias swaps models on its own, and your calibration goes with it.
• Every question with a “none of the above.” Without it, it marks answer A.
• Shuffle the order and use neutral names for the options. Test whether the decision changes.
• Recalibrate with 50 to 300 of your own examples before choosing a threshold. In one test, calibration error dropped from 0.117 to 0.008.
• Mark everything that comes from outside as untrusted: email, page, tool output.
• Never let it authorize a destructive, financial or personal-data action on its own.
• Math, dates and business rules stay in code.
• Before signing, compare with the cheap baseline: an open model reading probabilities, or a trained classifier if the task is always the same.

Read with a discount

I founded a company that builds its own model and competes in the same market. Read with that discount. That’s exactly why every number here has an open source: you don’t need to trust me, you need to check.

And if someone sells you Jev as a savior, ask the question I ask every startup: which test, and from when? If the answer takes a while, that’s the answer.

Essay sources

TypeSafe. Jev announcement · models and limits · confidence · known failures of jev-1.13 · workflow evaluations · adapter for LLMs · privacy · data processing · trust center

Recomputed by Paulo from raw data. ENEM 2025 · blind draw · heart risk · fact-checking

Preprints. Hu et al., JevAdvBench · Xu, JevOut · Sun et al., Type-Safe Is Not Error-Free · Ibrahim and Zaki · Li et al., JEV-as-a-Judge

Independent tests. human disagreement (ChaosNLI) · die replication · dialect bias · 49 tasks against a non-reasoning LLM · calibration and negation · recalibration · injection in Wikipedia discussions · Spanish · tools · undisclosed internal rule · shuffled coordinates · crude attacks · injection detection · audit index

Press. VentureBeat, agent gates · VentureBeat, CLM-8B

Literature. Fleming et al. (2010), Science 329 · Rounis et al. (2010), Cognitive Neuroscience 1 · Bor et al. (2017), PLoS ONE 12 · Johnson, Hashtroudi and Lindsay (1993), Psychological Bulletin 114 · Kahneman (2011), Thinking, Fast and Slow · Kahneman and Klein (2009), American Psychologist 64 · Loftus, Miller and Burns (1978), J. Experimental Psychology: Human Learning and Memory 4 · Maniscalco and Lau (2012), Consciousness and Cognition 21 · Ouyang et al. (2022), NeurIPS · Radford et al. (2019), OpenAI · Tversky and Koehler (1994), Psychological Review 101 · Câmara (2026), Inherited Weights, doi:10.5281/zenodo.22899767

The open alternatives: Clef and Laya

Since Jev’s launch, the category has gained open competition, and that changes the conversation about “new architecture.” Two names matter.

Clef, from Cloudflare

On October 1, Cloudflare released Clef and Clef-flash: the same abstraction as Jev (one shared state, several typed questions, a distribution over the options), with a compatible API, open weights under Apache 2.0 and image input. The architecture is described: a frozen Qwen as base (27B in Clef, 9B in Clef-flash), LoRA adapters and a head that scores each allowed option directly, trained with classification and calibration objectives. In other words, the lineage Paulo pointed to, now with inspectable code.

That doesn’t prove TypeSafe uses the same thing, but it proves the product can be reproduced with known components. Cloudflare ran the Decision Index, an open, independent suite with dozens of classification, routing, retrieval and safety tasks, and published the table. Some points:

Reading the whole table: Clef comes out stronger on most tasks, Jev still wins some, and it’s an internal Cloudflare run, on a public suite that can be trained against. Hosted price is the other side: US$ 0.24 per million tokens for Clef and US$ 0.09 for Clef-flash, against US$ 0.042 for Jev. Jev remains the cheapest hosted service of the three, by a margin of 2 to 6 times, and remains text-only.

Laya (and Arbiter)

Laya attacks the problem from the other end. They’re small encoders, 322 to 421 million parameters (ModernBERT-large in the typed version), with a choice head, Apache 2.0, built to run locally and be fine-tuned for a recurring task. Arbiter packages them behind a Jev-compatible API, with batching and deployment on Mac and NVIDIA. Arbiter is only a serving layer.

Laya’s README is unusually explicit about its limits, and I’d rather repeat than soften:

• the base checkpoints score near chance on the project’s own typed-decision benchmark; the headline 0.766 accuracy comes from a checkpoint fine-tuned on that benchmark’s training split;
• the models ship overconfident, and calibration has to be redone in the deployment domain;
• the typed version’s context is 1,024 tokens, fine for tickets and short messages, insufficient for long documents without chunking;
• with more than 50 options, the classification head saturates, and Laya itself reports Jev doing better.

None of this is a defect in the idea. It’s applied machine learning the way it has always been: a small model is excellent when the task is stable and labeled examples exist, and broad zero-shot behavior demands a much larger pretrained model. Laya is the option when privacy, offline operation, predictable latency or fine-tuning in your domain matter more than asking arbitrary questions about arbitrary documents. It is, at bottom, the classic classifier from the start of this post, with a modern interface.

There’s also Kev-9B, another frozen Qwen 9B with LoRA and a decision head, Apache 2.0, that fits on a 24 GB GPU. Three open implementations in under three weeks say the same thing: typed decision models have become an implementation pattern.

The Decision Index: how to measure this yourself

All this discussion about “who’s better” only makes sense with a public yardstick, and one exists. The Decision Index is an open suite, unaffiliated with TypeSafe, built for typed decision models: state plus choice or yes-or-no questions, one probability per option.

The current version, 0.2.1, counts 38 benchmarks in five areas (tools and automation, retrieval and classification, knowledge and reasoning, language understanding, human taste), about 120 thousand requests in total, with two rules that matter: the score is chance-corrected (0 is random guessing, 100 is perfect) and an unanswered request counts as wrong. No truncating input, no filtering options, no tuning the prompt per benchmark.

The live board has 70 models plus Jev as the reference. I downloaded the board’s data file and rebuilt the table; below are the top and the names that appeared in this post. Latency is the median measured by the maintainers on an RTX PRO 6000, one request at a time; Jev’s is a hosted API, so it doesn’t compare with the others.

“Open weights” means a checkpoint published on Hugging Face; “open code over an open model” is a published inference technique on top of an off-the-shelf Qwen or Gemma, without its own checkpoint. The board doesn’t record each one’s license, so check before using in a product.

Three readings come straight off the table:

1. The only closed model on it is Jev. It leads, but by half a point over an open fine-tune of a 26-billion-parameter Gemma 4, and the board treats differences under 0.25 as ties. The top ten are all open models of 12 to 32 billion parameters with an adapter on top, exactly the recipe Clef describes.
2. The small zero-shot encoder sits at the bottom: Laya at 6, Lavoir at 9. That matches what Laya’s README admits and what I said about the classic classifier, which needs labeled examples to shine.
3. A 4-billion LoRA like Hopper delivers 41 points at 23 milliseconds, a range many real problems don’t need to exceed.

And how to read Laya at the bottom of the table? The Decision Index measures one thing only: answering, with no extra training, 38 kinds of question the model has never seen, from chess to taxation. That’s what a hosted service has to do, because it doesn’t know which question is coming. A 400-million-parameter encoder will never win that exam, and Laya doesn’t even try: the score of 6 is the base checkpoint, with no fine-tuning at all.

The same model fine-tuned with your examples, on a stable task, shows up at 0.77 on the project’s own benchmark. The ranking answers “who is the best zero-shot generalist,” which is the question of whoever sells an API. The normal programmer’s question is a different one: “on this repeated decision, with the examples I have, what gets more right at the cost I accept?”. For that one, the bottom of the table may be the right answer, and no public board replaces the test on your own data.

So is Laya useless next to the others? As a zero-shot generalist, yes, and the board is right to say so. As a programmer’s tool, the math is different. It’s the only model on that table that runs on a laptop CPU and answers in 6 milliseconds, with 400 million parameters that fit on any server you already have; Hopper and Kev want a GPU, and Jev wants internet, an API key and a data agreement.

Fine-tuned with your examples, on a taxonomy that doesn’t change every week, Laya’s own author reports the model beating Jev on some tasks and losing where there are many options, in third-party published tests with different prompts and samples, so indicative rather than controlled. In other words: useless for answering any question about any text, and very useful for answering the same question a thousand times a day, for free, without sending data outside.

Clef isn’t on the board: 0.2.1 closed on September 27, and Cloudflare released the model on the 1st. The numbers I showed in the previous section are from an internal Cloudflare run on the same tasks, per benchmark, without the aggregate index. There’s also already a vendor claiming to have passed Jev on the same scorer, but for now that’s a self-reported number in a blog post, not an entry on the board. Worth waiting for the official inclusion before comparing.

Running it yourself is a day’s work, and the kit handles the tedious part:

1. pip install -e ".[transformers,rebuild]" and python -m decision_index suite rebuild. The suite isn’t redistributed because of licensing, so the kit downloads the sources (about 7 GB, with HLE requiring you to accept the terms on Hugging Face) and rebuilds the files with hashes verified against the lab’s.
2. python -m decision_index suite sample --n 100 for a quick test, then pipeline --engine http --option base_url=... --option model=... against any server that speaks the POST /v1/systemone format. That covers Jev itself, with the API key, and Laya behind Arbiter. Clef’s API is announced as compatible, so in theory it goes in by the same route, but I haven’t tested it.
3. score applies the same math as the board, and the maintainers state that it reproduces all 67 entrants of the current edition. Whoever has cloud GPUs runs the whole thing as a single Hugging Face job on an RTX PRO 6000 with hf-job.

I didn’t run the full suite for this post; the table above is the board’s file rebuilt, not a measurement of mine. Two caveats from someone who uses this kind of yardstick: the suite is public and frozen, so it can be trained against, and the board itself says Jev’s API output has already changed in 20 choices of the latency sample since the original run, without changing the score. A public benchmark is for discarding weak models and finding candidates. The final decision is still your labeled set, as I explain next.

How a programmer should think about this

The useful question is no longer “is Jev new?”. It has become: for a specific, measured decision in your system, which combination of quality, price, latency, privacy, context and maintenance beats what you already have, whether that’s a rule, a classifier or an LLM with structured output? No vendor benchmark answers that without your own labeled examples.

A Jev-type tool is useful when the same kind of judgment about text happens many times, the possible actions fit in a list, the surrounding code can apply exact rules, and a wrong answer can be detected or sent to review. That’s the shape:

• ticket triage;
• ranking a short list already retrieved;
• routing a request to a bigger or smaller model;
• flagging an agent trace for human review;
• choosing among spans that code or OCR already found.

Outside it, the tool is in the wrong place:

• when the input is image or audio;
• when the output needs prose or citations;
• when an exact parser already solves it;
• when a misclassification grants access or executes a destructive action.

I looked at my own portfolio of projects with that yardstick, and the result is a useful bucket of cold water: most need a specialist vision or audio model, deterministic rules or generated text, and have few decisions repeated, costly and ambiguous enough to justify one more model service. A few candidates remain, the clearest being model routing in FrankClaw and short-list ranking in ai-memory. None is a demonstrated bottleneck today. I suspect your portfolio looks similar.

If a bottleneck appears, the pilot is short:

1. Pick a single decision and define the allowed answers, including “don’t know” when that’s a real outcome.
2. Set aside real examples, with easy, ambiguous and adversarial cases, and label them independently. If your product speaks Portuguese, include Portuguese.
3. Compare what you already have, a simple rule or classifier, Jev pinned to a version, and a cheap LLM with structured output, all with the same input and the same decision policy.
4. Measure the confusion matrix, calibration by confidence band, cost per correctly handled case, end-to-end latency and review rate. A cheap router that sends hard work to a weak model costs more in total.
5. Deploy as a reversible feature, with logging, a conservative review route and a fallback. A security or authorization judgment is advisory, unless an exact policy enforces the action independently.

What Jev did well was remind the industry that classification exists. That’s worth the hype it got, and maybe a bit more.

Neither it nor its open cousins are a silver bullet. They’re one more tool, for a specific kind of task, that your code needs to fence in with rules, calibration and review. Whoever was already thinking about classifiers before September gained nothing new; they gained a convenient API. Whoever had never thought about it gained the most valuable part, which is the question: why were you asking a billion-parameter LLM to write a paragraph to tell you which bucket the text falls into?

Both caught every loud sabotage; House let through the two silent items almost every model lets through (#7b and #8), and Enterprise let through three (#7a, #7b and #9). House’s notional cost, about $460, was the most expensive in the whole table, and the cause was the absence of prompt caching in the API.

A lot has happened since then, and this post is the continuation. I’ll go in the order that matters: first the new numbers, then the question everyone asked me in comments and DMs (“isn’t this just a Qwen with a sticker?”), and only at the end the speculative part about what the company says it built.

The spoiler that justifies the post: after LUA fixed the API, House redid the benchmark at 95.5. In my table, that’s a tie with Claude Fable 5.1 and GPT 6 luna, and the run’s cost dropped 85%. I’m not saying it’s a Fable in every way; I’m saying that, in this test scenario, it performed like one. The details, and the noise caveats, come right below.

Before that, the backdrop that makes all of this strange: the industry consensus is that training a frontier model costs tens or hundreds of millions of dollars in GPU, and that, therefore, a small company with no billion-dollar funding round should not get anywhere near one. gpt-oss, OpenAI’s own open model, with the best-funded lab in the world behind it, could not complete my benchmark on the same harness Genesys PI ran on. The Brazilian model completed it twice per tier.

This post is organized around that tension. First, what the model did in experiments I control. Then, what I could and could not verify about how it exists.

New disclaimer

Since the first article, I’ve talked directly with two of LUA Vision’s four co-founders: Paulo Câmara, CTO, and Eronides Junior, CRO. Paulo is the technical lead, an FGV graduate with a PhD from Tel Aviv University, and his thesis is the stated origin of the model’s architecture.

Before LUA, according to his LinkedIn, his background is heavy corporate consulting, Oracle EBS and ERP implementations at large companies, and he maintains a series of essays on AI on LinkedIn. Eronides handles the commercial side; before LUA he was CRO of SoftwareOne Brasil, after going through marketing, services and operations at the same company.

I’ll repeat what I already said, and it counts double now that I’ve talked to them: I have no business relationship with LUA Vision. I’m not a partner, not an investor, I haven’t signed a contract, I haven’t signed an NDA, I’ve received nothing beyond the same free evaluation key from the previous test. Nothing in this post went through them before publishing. So far, I’m just a curious guy with an API in hand.

That last detail matters more than it seems. Since I signed no NDA, I never had access to any internal company data: no weights, no training recipe, no loss curves, no hardware bill. Everything below is black-box experimentation on the public API plus public information. Where I say “checked,” I measured it; where I say “they say,” it’s their word.

The new numbers: re-test after the fixes

After the first article, Paulo let me know he had fixed a few bugs in the API, the main one being precisely prompt caching, and asked me to run it again. I did. It’s a clean, independent round of both tiers, on the same 14-sabotage protocol, with the original round preserved intact for side-by-side comparison. A methodological detail: v4 is a single-run benchmark, so the vigilance score is noisy, and I’ll come back to that shortly.

Before running, I confirmed the cache was really there. A repeated-prefix probe on the endpoint returned cached_tokens: 4121 / 4124 on the second call. In the original test, that number was always zero.

To place it in the overall table: in the original round, House tied Grok 4.7 at 83.5. At 95.5, it would tie Claude Fable 5.1, Sakana Fugu Ultra v2 and GPT 6 luna, at rank 9 among 46 models. Enterprise, at 82.0, would tie DeepSeek V4 Pro (base). I say “would” because, as I explain below, I kept the original run as the official ranking entry.

And it’s worth making the yardstick explicit: I’m not saying Genesys PI is equivalent to Fable in every way. I’m saying that, in this particular test scenario, it performed like Fable. On a different workload, your results may vary.

What clearly and reproducibly improved:

• Cost dropped 85% to 87%. Token volume was the same, about 40 million on House and about 20 million on Enterprise, but repeated context is now billed at the cache rate instead of full input price. House goes from the most expensive run in the table to mid-cost.
• Reliability. Enterprise’s original run needed a second attempt because of that grep loop in the first sprint. In the re-test, it converged first try. No loops on either model.
• Test discipline. The original Enterprise wrote no automated tests at all. In the re-test, it wrote a real RSpec suite, with model, request and system tests.
• Earlier detection. Both caught the loud sabotages (#1 to #3) by sprint 3, and House caught everything from #1 to #6 by sprint 4, something the original runs partly left for the capstone.

What can’t be claimed is that the model got more vigilant. House went up 12 points, but Enterprise went down half a point in the same round. Since prompt caching has no way of affecting sabotage detection, two tiers of the same model moving in opposite directions is the picture of single-run variance.

House’s +12 is large enough to suggest that Paulo’s other fixes improved the model, but one run per model doesn’t confirm that. To separate signal from noise I’d need three or more runs per model, which I didn’t do.

To calibrate the size of that noise: this same week, GPT 5.5, which had 100.0 in the table, ran again with identical model and harness and closed at 91.0. Nine points of difference without changing anything. So treat vigilance scores as a range.

And the two silent survivors are still there. In House’s re-test, the dropped index with no test guard (#7b) and the hidden aggregate (#8) were only fixed at the reveal; in Enterprise’s, not even at the reveal. It’s the same disguise blind spot most of the table has, frontier models included.

Keep in mind: the caching bug is fixed and verified, and the cost reduction is real. The vigilance score stayed within noise: Enterprise flat, House up but without statistical confirmation. In the overall table, I kept the original runs as the official entries, precisely so as not to reward a single run.

Pricing: not final yet, and it won’t be per token

The cost figures above are still notional, computed on top of the example price list the API exposes, and LUA itself already said, in the previous article, that those are not market prices. Talking to Eronides, he laid out what’s coming: they don’t intend to charge per token, like everyone else does, and the product isn’t meant to be B2C like the subscription chats. The bet is B2B, by usage license, with the model running on the customer’s own infrastructure.

In practice, that means a company with a Grok-class model, capable of advanced tasks like programming, running on-premise, off the cloud, with the guarantee that no sensitive data leaves the building. Frontier models today are cloud services from foreign companies, and regulated sectors live uneasily with that. If LUA can deliver exactly that package, and the “if” is still big, it changes the game for a lot of Brazilian companies.

Even with the caveat that the per-token price is only an example, the notional cost next to the table helps calibrate. The cheapest complete runs in the entire field are DeepSeek V4 Flash ($0.97) and MiMo V2.5 Pro ($1.03); Enterprise, at ~$2.40, sits in that neighborhood. On the other side, Opus 5.5 cost $16.63, Sonnet 5 about $27 and GPT 5.5 $34.69. And House, which in the original round was the single most expensive run in the whole field, is now mid-pack.

The pricing policy, according to them, comes out on October 7, 2026.

Extra experiment: Genesys PI auditing ai-jail

A sabotage benchmark measures vigilance inside a small, controlled app. I wanted to see the model on a real problem, so I gave it my ai-jail, the operating-system sandbox that runs coding agents inside bubblewrap, Landlock and seccomp on Linux and sandbox-exec on macOS. It’s a Rust project, with 776 unit tests, 70 dependency crates and a security surface I know well.

The task: a full security audit of version 2.3.0, at commit f62d576, read-only, with a threat model, line-level code evidence and reproduction where possible. Anyone who wants to check can open the repository at that commit and follow the reports’ file and line references.

For a yardstick, I ran a second independent audit, with another model, with no access to Genesys’s report until its own candidate list was fixed. Then I cross-checked the two reports and also compared them against two security advisories that were open on GitHub, written by outsiders against earlier versions of the project.

Genesys PI’s report (I’ll call it audit A) came with 26 findings: 5 High, 17 Medium, 3 Low and 1 informational. The second audit’s (B) came with 12: 2 High, 7 Medium and 3 Low. The cross-check:

• 11 findings in common, including the two Highs that really matter: forged worktree metadata that exposes any host directory for read and write, and duplicate environment entries that bypass credential isolation. Both were reproduced empirically by both audits, independently.
• 11 findings only in A, among them the entire macOS surface (B had no Mac), the resource-exhaustion class in the egress proxy, and a cross-process audit-chain corruption that B had rejected only in the simplest case.
• 3 findings only in B, one of them a relevant Medium that A didn’t see: two test environment variables that survive in the release binary and switch off the SSRF protection and the TLS root validation.
• B rejected a real bug (a wrong-width comparison in a seccomp rule) and only confirmed it after A pointed it out. A made no equivalent mistake.

Against the external advisories, the score also favors A: of the five findings in the most serious advisory, A caught four and B caught two (plus one after A’s lead). Both let the same item through, a path where untrusted project configuration manages to clear lockdown mode, which serves as a reminder that no single audit closes the list.

I’m not saying Genesys PI is the best security auditor there is; it was a comparison of two models, on one project, in one run. I’m saying that, on real code, with a real threat, it produced the stronger of the two reports, with calibrated severity and empirical reproduction of the critical items, and I’m going to fix its list. That’s more than I expected to see from a model most people have never heard of, and more than gpt-oss, which didn’t even reach the end of the sabotage benchmark, would be in a position to do.

The question everyone asked: is this a rebadged Qwen?

I’m not offended by the question, I asked it myself. Brazilian model, small team, frontier-range score: the cheapest hypothesis is that there’s another model underneath. The three versions of the suspicion that reached me were: it’s a Qwen or DeepSeek with a sticker; it’s OpenAI’s gpt-oss in different clothes; or the API is just a proxy to Claude or GPT.

The limit of all this comes before any result. In a black-box situation, with no access to weights, it’s impossible to state with 100% certainty where a model came from. What you can do is exclude hypotheses. That’s what I did, with a set of reproducible tests that are in the benchmark repository, and then I asked Grok to review the method and the text as a hostile evaluator, to strip out any conclusion that was stronger than the data.

The decisive test: the tokenizer

Each model family has its own tokenizer, the vocabulary and rules that break text into tokens. A fine-tune, a LoRA or a continued pre-train inherits the base model’s tokenizer; you can’t swap it without retraining from scratch. So the tokenizer works as a lineage fingerprint.

I measured how many tokens LUA’s API charges for a battery of strings (Chinese, accented Portuguese, English, digit runs, emoji with ZWJ), cancelling out the system prompt they inject, and compared against reference tokenizers running locally: OpenAI’s o200k, cl100k, Qwen, DeepSeek, Llama 3 and Mistral. The summed distance to LUA, in the final round of the test (tokenizer_v2 in the repository):

• o200k (OpenAI): 2
• Llama 3: 68
• cl100k (GPT-4, Phi-4, DBRX): 134
• Qwen: 193
• DeepSeek: 255
• Mistral: 289

The strongest discriminators: Chinese packs the o200k way and not Qwen’s tighter way, a digit run costs 67 tokens where Qwen and DeepSeek charge 200, and emoji with ZWJ matches only o200k.

In other words: Genesys PI uses o200k_base, OpenAI’s public tokenizer, with high confidence. That kills the hypothesis of a rebadged Qwen, DeepSeek, Llama or Mistral, because none of them uses that vocabulary and no fine-tune could acquire it. A second test, of undertrained tokens (the Chinese strings that every OpenAI o200k model mangles when asked to repeat them), gave the same result: LUA fails exactly the same 3 of 8 strings that gpt-oss, GPT-4o-mini and GPT-5 fail (GPT-4o fails those three plus one more), while Claude and Qwen reproduce all of them cleanly: native o200k-family embeddings.

It’s not stock gpt-oss

gpt-oss, OpenAI’s open model, is the only relevant public weight that uses the same vocabulary family, so it was the natural candidate. But gpt-oss serves with o200k_harmony, a variant that has its own special tokens (<|channel|>, <|message|> and the like) as single tokens. On LUA’s API, each of those markers costs about 4 ordinary text tokens. The vocabulary is plain o200k_base, without the Harmony tokens.

That rules out gpt-oss served the standard way. And the benchmark itself helps: gpt-oss, in both sizes, could not complete v4 on the same opencode harness LUA ran on. The raw weights can’t even build the app, while Genesys PI gets through all seven sprints, House in Tier A and Enterprise in Tier B. A light sticker on top of gpt-oss doesn’t do that.

What this test does not exclude is someone taking the gpt-oss weights, stripping Harmony at serving time, putting a custom template on top and heavily retraining the agentic behavior. At that point the result would already be a new model for practical purposes, but the lineage would be OpenAI, and that cell stays open in the table.

It’s not a thin proxy to Claude or GPT

LUA’s API rejects temperature, top_p, n, presence_penalty and logprobs, which OpenAI’s classic chat API accepts, and also rejects min_p, top_k and repetition_penalty, which any vLLM server in front of an open model would accept. The HTTP headers are all x-lua-*, with no trace of OpenAI, Anthropic, Cloudflare or OpenRouter. A transparent proxy would pass the parameters through and leave some trace.

The benchmark reinforces this in a way I liked. If LUA were a passthrough of GPT 6 luna or GPT 5.5, it would inherit their strength on the silent sabotages: GPT 5.5 caught #7b and #8 unprompted, and so did luna.

LUA fails exactly those two items, stably, across the four runs I did. A proxy doesn’t come out consistently weaker than the model behind it on one specific trait. That’s the picture of a model with its own weaknesses.

Someone could ask whether I only compared against the OpenAI family. I didn’t. I took the benchmark’s most discriminating signature, the set of items each model never fixed, and compared LUA’s against all roughly 44 models in the table. House’s {#7b, #8} pair lands closest to the Qwen family (Qwen 3.7 Max and Qwen 3.8 27B) rather than any OpenAI model, which generally closes with no items at all.

Except that’s a score-tier artifact, not lineage: #7b and #8 are the two most disguised sabotages, and every model in the 80-point range misses both, from any family, while LUA’s re-test at 95.5 left none.

The interesting result is that LUA’s three behavioral signals point in three different directions: the error tail looks like Qwen, the rare #6 fix looks like GPT 6 luna, and the tokenizer and API shape look like OpenAI. A real proxy or clone resembles a single model on every axis at once. LUA resembles no model in the table on every axis.

There was one coincidence worth recording: of the roughly 40 models whose fix I checked, only two added a unique LOWER(email) index in the database when fixing sabotage #6. They were LUA and GPT 6 luna.

It’s a rare convergence, but it’s also the most complete fix possible, the kind of thing two careful models can arrive at on their own. And the two caught the item at different points in the run. It raises an eyebrow, but doesn’t reach suspicion.

What stays open, though, is a thick wrapper, with plenty of its own logic, in front of a reasoning API. Their API accepts reasoning_effort, which is a control specific to OpenAI’s reasoning models, and a silent 250,000-token context. That’s compatible both with an in-house stack that copied OpenAI’s interface and with a more elaborate wrapper. Black-box doesn’t separate the two.

What stays open: from scratch or distilled

Here’s the limit no API test crosses. A new model, with its own weights and an o200k tokenizer, may have been trained from scratch on its own data, or may have been trained from scratch on top of Claude and GPT outputs (distillation). Both produce exactly the same observations I made.

I tried a similarity grid with 20 prompts against a panel of possible teachers, and the result was null: no teacher stood out on the two axes I managed to measure (the third axis, embedding similarity, stalled for lack of API credit and was left out), which is consistent with an in-house mix and also with a soup of traces from several teachers. “Not Qwen” doesn’t become “trained from scratch.”

An inconsistency I need to record

LUA’s published research, the paper “O peso que você não escolheu” (“The weight you didn’t choose”), revolves around the “token tax,” the extra cost an English-optimized tokenizer charges a language like Portuguese, which they measured across 31 languages. Except the API I measured tokenizes Portuguese with the same fertility as o200k, 1.31 tokens per English token, against 0.69 for a Portuguese-native tokenizer like Tucano.

In other words, the product I was given uses an English-optimized vocabulary, not a Portuguese-specific one. That says nothing about the model’s lineage, and adopting o200k is the cheap, professional choice any small lab would make. But it’s a point where the research material and the API are not telling the same story, and it’s the first question I’m going to ask Paulo.

Forensics scoreboard

In one sentence: with high confidence, Genesys PI is not a rebadged Chinese model nor a Llama or Mistral fine-tune; with medium to medium-high confidence, the tests argue against stock gpt-oss and against a transparent proxy. Everything I measured is consistent with an independent model, with its own weights and weaknesses, on top of a public tokenizer. Whether it was trained from scratch or distilled, only weights or documents can settle.

One more disclaimer: I only compared against what I tested

The tokenizer panel has OpenAI, Qwen, DeepSeek, Llama and Mistral; the API behavior panel has GPT-4o, gpt-oss, GPT-5, Claude, Qwen, DeepSeek, Llama and Gemini; and the benchmark’s behavioral cross-check covers the roughly 44 models that have run v4. That covers the overwhelming majority of what runs in production today, but there are dozens of other open models I didn’t compare. There’s always a chance Genesys PI’s relative is one of them and I missed it. “I found no correlation” means “I found none among those I tested,” and nothing beyond that.

That said, look at the size of the effort it would take to fool this analysis. Someone would have to adopt OpenAI’s tokenizer, mask the model’s identity server-side in a way that resists prompt override, build their own gateway that rejects exactly the parameters an open-model server would accept, keep stable, distinctive weaknesses across four runs, and still complete a seven-sprint benchmark at frontier level. If this isn’t a real model, the work of pretending it is would already be extraordinary. Past a certain point, a convincing fake of a model is indistinguishable from having a model.

Now then: what LUA says it did

Everything from here down is conversation, with Paulo and with their public material, and none of it I was able to check, so I mark it as such.

Nobody can be blamed for being suspicious. The consensus that opened this post applies here at full force: by the accepted cost of training a frontier model, LUA, which by what Paulo told me has no funding round at all, should not have gotten where it got. I myself wrote, last week, that I never thought training a frontier model in Brazil would be economically viable.

Against that common sense, what I have in hand is a model that, by my black-box experimentation, looks new, with no kinship to any known open model, with no look of a proxy, and possibly something other than one more distillation. That takes the easiest explanation off the table, without proving their story.

What Paulo told me, and which lines up with a lot of what I’ve thought for a while:

• Trillion-parameter models are more marketing than necessity. His thesis, and mine, is that a smaller model with real agentic capability (solid tool calling, prompt caching, efficient attention over large context) is the winning combination. The cost math of my own benchmark points the same way: small, cheap models tying expensive ones is the table’s pattern.
• The reasoning peak is behind us. We both think the GPT-4 generation and the first “o” models were where reasoning seemed best, still without agentic capability. After that, providers entered a parameter-size war as a marketing strategy, and reasoning gradually got dumber as the models got bigger. That’s our opinion; I measured none of it.
• A small model with reasoning and a decent agent gets to similar results. That’s what my benchmark shows when Genesys PI ties Grok and lands in the Kimi and DeepSeek range, and it’s their central bet.
• Training was done on off-the-shelf hardware, no CUDA. Paulo says he trained on AMD and ARM64 hardware (MacBook included), in a few months, and that with funding it would be faster. That’s the strongest claim of all, and the one I can least verify. Zero evidence either way; recorded as said.
• Proprietary, unpublished architecture. The public material talks about NCAS, a “brain-inspired” architecture with five training phases, and says the technical detail is under NDA. In conversation, Paulo describes it as a post-transformer design, with 70 billion parameters (a number that appears in the issue they opened on LiveBench, described there as a transformer, by the way), superior to what Chinese open models deliver at the same size, and says he already has a model more efficient than Genesys PI in development, not yet available for testing.

If all of this is true, the damage to the status quo is large. It breaks NVIDIA’s monopoly on training and it breaks the lock frontier labs have on frontier models. A claim that size demands evidence that size, and I don’t have it. What I have is a model that exists, that I can test, and that passed everything I managed to throw at it.

Where I stand

Checked, by me:

• Genesys PI is a model that exists, responds and completes a hard benchmark in the Tier A and B range of my table, in two independent runs per tier;
• the caching bug was fixed and cost dropped 85%;
• the tokenizer is the public o200k_base, which rules out derivation from Qwen, DeepSeek, Llama and Mistral;
• the API doesn’t behave like a transparent proxy and the model has its own, stable weaknesses;
• stock gpt-oss doesn’t explain the result;
• compared against all ~44 v4 models, LUA resembles none of them on every axis.

Not checked, and only their word:

• that the model was trained from scratch and not distilled;
• that the architecture is new and post-transformer;
• that training happened on off-the-shelf AMD and ARM64 hardware, no CUDA, in a few months;
• that a better model is on the way.

Open, and something I’m going to ask:

• how to reconcile the “token tax” narrative with an API that tokenizes Portuguese the same as o200k.

What would settle this for good is documents, not more prompts: the tokenizer file, the training recipe with token and compute counts, the initialization (random or continued from other weights), loss curves, and a held-out benchmark I run myself.

Until that arrives, my position is the one in the table above: a model that behaves like an independent one, on top of a public tokenizer, with an origin no outsider can certify. More than I expected from a company this size, less than their website sells.

And I need to record what doesn’t fit in a table: these models are fascinating, and maybe the most intriguing thing I’ve tested in months. By everything the industry says, they shouldn’t be possible, they shouldn’t exist. But I tested them, extensively, with every black-box test I could put together, and I couldn’t break the story. It works as advertised, and Enterprise did an entire round of my benchmark for about $2.40 notional, a fraction of what models in the same range cost.

Add that to what Eronides described, a usage license instead of tokens, the model running inside the company instead of in someone’s cloud, and the picture is clear: a Grok-class model, on-premise, with no sensitive data leaking out. If they deliver that, it’s a game-changer. Still curious, and now in a hurry to see what comes out in October.

The Account

The bio reads: “Covering AI, startups, markets, and emerging technologies for @TechCrunch | prev @mashable”. Verified badge, account since August 2014, more than 45,000 posts, 1,409 followers. By the numbers, it looks like an old, active account, not a profile created yesterday.

The Conversation

Here’s the full exchange, nothing cut:

And here’s the link, exactly as it came, for anyone who wants to recognize it if they got the same one:

Confirmed phishing link. Don’t click it. If you already did, don’t authorize anything. https://calendly.com/d/d336-3mq-q2z

I Already Knew It Was a Scam

I recognized the pattern instantly because José Valim, Elixir’s creator, fell for this exact lure in March this year and documented the whole thing publicly.

Same pretext, TechCrunch asking for an interview on a technical topic the victim knows well. Same mechanism, a Calendly link that ends in an X authorization. His account ended up being used to spread crypto spam before he revoked access.

When the message landed for me today, I almost cheered. I knew right away it would make good blog material. So I kept the conversation going politely, just enough to screenshot everything, and now I’m exposing the account publicly. Always expose whoever tries to scam you. This isn’t about humiliating anyone, it’s about leaving a public trail for the next person who gets the same message and goes looking for it on Google.

Even Without Knowing About Valim’s Case, I Could Tell

A cold contact asking for a meeting out of nowhere, with no prior introduction, is a scam 99% of the time. No real professional operates that way, and even less so over a social media DM. Doing that makes you a door-to-door salesman with Wi-Fi.

A big-name outlet in the pretext changes nothing for me. I consider myself better than TechCrunch or washed-up Mashable, and not even someone claiming to speak for the White House would impress me. Sorry, not sorry about that.

And even if there were a normal person behind it: my time isn’t free. Want real consulting? Talk to my company, set up a commercial meeting on the company’s Calendly, sign a contract, pay the fee, and only then do I talk to you. There’s no “let’s just hop on a quick call” shortcut with a stranger.

The moment I clicked the link, it redirected straight to the X authorization screen, obviously I refused. I clicked on purpose just to grab the screenshot.

The Technical Mechanism

A reader pointed out that the address bar in the original screenshot showed an oauth_token in the URL, and asked whether that was unsafe to publish. Fair question, and I edited the screenshot to remove that part anyway. But the actual risk there was zero: that’s an OAuth 1.0a request token, not an access token. It only turns into a real credential after authorization is approved and the app exchanges that token for a verifier alongside its own secret key, neither of which happened, since I clicked cancel. An unused request token also expires on its own within minutes, by X’s own design. Even with zero risk, it costs nothing to crop it out, and it’s a good general rule: never publish anything that looks like a token, even one you’re sure is already dead.

The first step is real: calendly.com/d/d336-3mq-q2z runs on genuine Calendly infrastructure, I confirmed that by hitting the link directly and checking the cookies and response headers, all authentic. It’s a standard routing form for the product, name and meeting type.

The scam lives in what happens after you submit the form. Calendly has a legitimate feature to “redirect after booking,” and that’s exactly the feature that got configured to send the victim to an X OAuth authorization screen. That screen is real too, it runs on api.x.com, X’s genuine domain. The scam doesn’t fake the login screen. It abuses a genuine Calendly feature to chain into a genuine X screen, authorizing a malicious third-party app.

And here’s the part I want to underline: this isn’t some exotic bug hidden in an obscure corner. It’s a pseudo-feature turned on by default, a free redirect to any URL after booking, with zero destination checking. Until Calendly disables or at least restricts that redirect, it stays a ready-to-use phishing vector, and closing that door is Calendly’s job, not the job of the user who just wanted to book a meeting.

That app is called “Events Portal,” claims to be www.eventsportal.com, and X itself shows a warning: “This app isn’t affiliated with X and is requesting sensitive permissions,” with the callback pointing to plugins.cal-apis.com, not to any real Calendly domain. The permissions requested amount to a full account takeover:

• see protected posts, lists, and collections;
• see account and profile settings;
• see who you follow, mute, and block;
• follow and unfollow on your behalf;
• update your profile and settings;
• create and delete posts, like, repost, and reply on your behalf;
• create, manage, and delete lists;
• mute, block, and report accounts on your behalf.

With that authorized, the account becomes a weapon to attack the next person, exactly what happened to José Valim.

What I Confirmed Myself

A real Calendly doesn’t ask for a social media login to schedule a meeting, full stop. What the screen showed is the legitimate “redirect after booking” feature hijacked to become a phishing vector against an X account. I didn’t stop at the first impression, I went and confirmed every piece myself:

• the domain cal-apis.com was registered only six days earlier, on September 16, 2026, through a Chinese reseller tied to Alibaba Cloud, hidden behind Cloudflare nameservers. A disposable domain, built specifically for this, not real infrastructure from any actual company;
• security researchers (Push Security and Validin) have documented Calendly-themed phishing campaigns used to steal Google Workspace and Facebook Business accounts, same family of scam, different target than mine;
• specifically against X accounts, what’s documented is firsthand reporting: José Valim himself, and a public report from February 2025 describing an almost identical scam, a fake Calendly link leading to an X login, that nearly caught two other well-known people in the tech community;
• I found no record of “Mia Esswein” as an actual TechCrunch or Mashable journalist in any search. That’s not definitive proof of anything on its own, but it adds to the rest of the pile of evidence.

The Checklist I Use

• a cold contact asking for a meeting, with no introduction, is a scam until proven otherwise;
• a real scheduling tool never asks for a social media login to book a slot;
• a third-party app requesting “sensitive permissions” and warning that it’s “not affiliated” with the platform is a red flag, not an ignorable technical detail;
• if you already authorized something like this, revoke it now: on X, Settings → Security and account access → Apps and sessions;
• report the account that sent the link, and report the Calendly event if you still have the conversation.

To Whoever Tried

You picked the wrong person to try this on. I don’t talk to strangers for free, on principle, and I definitely don’t authorize unknown apps on an account I use for work. I recognize the pattern from a mile away because I read about this stuff, and on top of that I got a free article out of it for the blog. Next time, invest less in a domain registered in a rush and more in a disguise that survives someone actually paying attention.

A language that promises to run near C speed, parallelize itself across CPU and GPU, and still formally verify that the code the AI wrote does what you asked. That’s a lot of promises stacked together. I had never touched Bend 1, so this is new territory for me too: on launch day, I pointed my agents at two of my Rust projects and told them to port them to Bend 2. The result of that test is the most interesting part of this article.

Before we start, the disclaimer: this is a review written on the second day of the language’s life, based on a one-day experiment. I may be wrong about several of my assumptions, and that’s fine. The comments are down below; feel free to correct and add to it.

Who Victor Taelin is

First things first, the author deserves an introduction. Victor Taelin is a Brazilian functional programming researcher who spent more than a decade obsessed with one specific problem: optimal reduction of the lambda calculus, Lamping’s 1990 algorithm, and then Lafont’s interaction nets.

His own autobiography tells the story: he worked at the Ethereum Foundation, created the Formality proof language, retired early on the ETH he stacked from salary, went back to the problem on his own dime, created HVM (the Higher-Order Virtual Machine), and founded the Higher Order Company, which raised a $4 million seed to turn the research into a product.

And here’s a point that matters a lot to me: I love seeing a Brazilian doing serious programming language design work. We barely have real cutting-edge research in this country, let alone in computing fundamentals. For that alone, Taelin already has my respect and my congratulations for what he’s built so far.

So let it be on record: every criticism in this article is constructive, from someone rooting for Bend to go further. Nothing against him or the project.

Where Bend comes from

The first version of Bend showed up in May 2024, with Python-like syntax running on top of HVM2, and the promise of automatic parallelism: write sequential code, the runtime spreads it across every core and even the GPU, no threads, no locks, no mutexes.

The launch went viral. Almost a thousand points on Hacker News, over 20 thousand GitHub stars, a Fireship video. And then reality hit: the HN thread was merciless. 24-bit numbers, no FFI, a simple sum taking 42 minutes on a user’s machine, single-core C++ beating the demo’s RTX 4090. Taelin himself admitted back then that the codegen was bad, and admitted now, in the Bend 2 thread, that the 2024 hype didn’t convert into usage: “there is also my own failure into making the language actually be used, rather than just a viral moment”.

Bend 2 is the answer to that. And pay attention: it’s a different language. The README is explicit that Bend 1 programs don’t load. Interaction-graph evaluation (HVM) is out; native compilation to a single C file is in, with clang for CPU and Metal or CUDA for GPU. Numbers are now real Nat, U32, and F32, and the memory limit jumped from 2 GB to 8 TB, according to gihyo’s Japanese announcement. Interaction nets stay in the architecture, but in his words, “inets live in it architecturally, but they don’t exist at runtime”.

What Bend 2 promises

The new pitch now revolves around AI. The project page sells a “post-AGI” vision: humans will stop writing and reading code, so we need an ambiguity-free way to tell the AIs what we want. Bend’s solution is splitting the program into two files:

• LAWS.bend: the system’s invariants, written by the human.
• PROOF.bend: the proofs of those laws, written by the AI.

Bend’s type checker is a proof checker, in the lineage of Lean and Rocq, so bend PROOF.bend becomes a commit gate: if the proof doesn’t close, the code doesn’t ship. The site’s demo is a little game with the law “winning is impossible” and a direct invitation: “Skeptical? Try breaking the game”. The positioning is explicit: LAWS.bend is an AGENTS.md with mathematical backing.

And what does it look like? The syntax feels like Python with dependent types. A complete program with effects:

import Base

# Performs effects on the CPU.
def main() -> IO(Unit):
  do IO<Unit>:
    name : String <- IO.try(String, IO.get_env("USER"))
    IO.print("Hello, " ++ name)

Parallelism is divide-and-conquer: you split the work in two and the runtime spreads it over whatever cores it finds. And the ! operator dispatches the function to the GPU:

# Computes 2^d in parallel: a tree of d levels, one leaf per unit.
def pow2(+d: Nat) -> U32:
  match d:
    case 0n:
      1
    case 1n+p:
      a b = pow2(p) pow2(p)
      (a + b : U32)

# Runs pow2 on the GPU, via `!`.
def main() -> IO(Unit):
  result = pow2!(20n)
  IO.print(U32.show(result))

Notice the differences from mainstream languages: there’s no if (every branch is a match on True/False), natural numbers pattern-match on the successor pattern (1n+p), and the +d marks the parameter as affine, which is what lets the language live without a garbage collector.

And proofs are ordinary defs. The law declares what holds; the proof is induction with explicit rewrites:

# CLAIM: for every nat x, x + 0 equals x.
law add_zero:
  for x: Nat
  {Nat.add(x, 0n) == x : Nat}

# PROOF: induction on `x`, one rewrite (`%`) per step.
def add_zero(x):
  match x:
    case 0n:
      {==}
    case 1n+xp:
      %add_zero(xp) : {1n+Nat.add(xp, 0n) == 1n+_ : Nat}
      {==}

No tactics, no inference, everything annotated by hand. It’s verbose on purpose: that’s the price of the 0.1s checker.

The other promises, all with benchmarks on the page:

• Runs fast: Game of Life on an M4 Max in 7.8s on one core, against C’s 6.78s. On the GPU, 0.06s, or 124x.
• Checks fast: 3,200 generic instantiations checked in 0.38s, against Lean’s 19.2s and Rocq’s 6.04s. The idea is that the agent can verify after every edit.
• Parallelizes by itself: the ! operator sends the function to the GPU, no threads, no locks, no hand-written kernels.
• No garbage collector: affine types, each closure can be called at most once, so memory resolves statically.

Two honest details I liked seeing published: the site itself warns “Bend is still evolving. Expect bugs”, and Taelin stated that the compiler is 99% AI-written, with only the checking kernel audited by humans. Consistent with his thesis, at least.

And there’s already a business plan: the Bender, a paid, proprietary “proving agent”, a harness on top of Anthropic and OpenAI models today, with a dedicated model and its own symbolic prover on the roadmap.

Not everyone swallowed the benchmarks

The technical reception had strong caveats, and they matter. Nezk’s gist, “Why the benchmarks of Bend’s 2 typechecker are misleading (and possible problems with its type system)”, points out that Bend skips elaboration, unification, and implicit arguments, which is exactly where Lean and Rocq spend their time. Comparing times like that would be comparing an apple to a rocket.

Heavier: Liam Powell’s post, “Bend 2 and the Vibe-Coding Trap”, notes that the expression “formal verification” appears nowhere on Bend’s site or code, redoes the game demo in SPARK/Ada proving the same two properties automatically with GNATprove (“all checks proved (12 checks)”), without the 442 lines of manual proof, and concludes that Bend is “decades behind the state of the art”.

These are criticisms from people who know the subject, and they deserve an answer. That said, Bend 2’s main HN thread sits at over 600 points, so attention the project has.

What I tested

A tagline doesn’t compile a program, so I went and tested. I have a bend-tests repository where I pointed my agents at porting real projects of mine, written in Rust, to Bend 2 (v2.0.16, pinned via mise; to get a sense of the maturity, the language had nine releases in ten hours on GitHub the day after launch). The documentation for the whole experiment lives in docs/ in there, and that’s where the next sections come from.

The three candidates

I picked three of my projects with different profiles. Fair warning: none of the three is a worthy Bend example, and I know it. I just grabbed small, simple projects I had lying around, somewhat at random, to see where the language breaks when you rub ordinary day-to-day code against it.

ghpending is my CLI that lists open issues and PRs across my repositories via GraphQL. The port covers the main command, the filters, the sorting, and the config.toml, with output verified byte-for-byte identical to the Rust binary in the cases tested against the real GitHub API (on my loaded config, the only difference is the fork view the port left out).

tclock is my fork of clock-tui, a terminal clock with timer and stopwatch. The port covers clock, timer, and stopwatch, without the widget system (which alone is 2,075 lines of the Rust), verified by driving the binary through a pty.

ai-jail, my sandbox for AI agents (bubblewrap, Landlock, seccomp), never even became code: the paper evaluation killed it. A port would be a C program with a Bend main, which defeats the purpose. And it had the most interesting part to prove: the policy logic, like “path resolution never escapes the root”. But there’s no way to embed that in the Rust binary, so it stays for a next round.

The numbers

I measured Rust and Bend side by side on both ports:

Read that table carefully, because it lies. The runs are network-bound. The 43-repo gap is Rust doing more work (fork lookups, sequential viewer query). Bend’s tclock redraws whole frames, 26 KB/s against ratatui’s 2 KB/s of diffs. And the lower line count is partly because the port does less. No number here shows Bend faster than Rust on the same work.

The proofs in practice

Here’s the part Rust can’t imitate, so it’s worth the detail. The design that worked was proving an isolated guard, leaving the algorithm outside the proof. ghpending’s --limit allocator ended up in two stages: the first is the original algorithm in U32, unproven; the second is a Nat guard that takes the first stage’s proposal and cuts any excess. The laws say the budget is conserved and that no repo gets more items than it has.

This is the real guard, from the port’s alloc.bend:

# the lesser of b and w
def take(b: Nat, w: Nat) -> Nat:
  match b w:
    case 0n w0:
      0n
    case 1n+bp 0n:
      0n
    case 1n+bp 1n+wp:
      1n+take(bp, wp)

# what is left of b once w is taken from it
def rest(b: Nat, w: Nat) -> Nat:
  match b w:
    case 0n w0:
      0n
    case 1n+bp 0n:
      1n+bp
    case 1n+bp 1n+wp:
      rest(bp, wp)

The law holds even if the unproven stage proposes garbage. The guard doesn’t trust arithmetic it can’t see. That’s the pattern that makes proofs work in real code.

The mutation test is the honest measure of the thing. I injected an off-by-one into the guard that leaks budget: the three sample outputs came out identical, so a test suite of that size would have passed it. The proof gate rejected it, with the exact term that stopped matching. That’s Bend working as promised, down to the detail.

Now the price: 93 lines of laws and proofs to guarantee two simple facts about a guard of some 30 lines, starting from zero, because Base ships no Nat lemmas (the only arithmetic lemmas are U32.add_comm and Word.add_comm, which don’t help in a Nat proof; we had to prove addition associativity by hand, and Taelin acknowledged in the thread: “We need a mathlib!”).

And what stayed outside the proof: the algorithm’s exactness (it would need division lemmas, days of work), everything U32 (underneath it’s a 32-bit vector; proving arithmetic on it without a lemma library is impractical), and literally everything else in the program: JSON, sorting, rendering, IO. The provable surface of a program like ghpending is a few percent of the code.

The checker, on the other hand, is the best part of the tool: 0.1s per round, errors pointing at one exact line. It took some 30 check rounds on ghpending. For an agent iterating in a loop, it’s exactly the feedback format it needs.

The price of escaping to C

Everything Base lacks becomes a foreign effect: a Bend def whose body is a C function (for the native binary) and a JS twin (for the dev runner). The two ports needed eight hand-written effects:

• Http.post: because there’s no TLS, HTTP, or DNS (the official HTTP demo hard-codes an IP).
• Clock.unix and Clock.local: because IO.now is milliseconds since boot, with no wall clock and no timezone.
• Tty.width, Tty.raw, Tty.key, Tty.size: because there’s no stdin, no raw mode, no terminal query. None of that exists.
• Clock.millis: convenience.

And the official guide is clear about the trade: there’s no ABI promise. The names are runtime internals and any release can rename them, so “rebuild your effects with every update”. In a language with nine releases in ten hours, good luck with that. Details that complete the picture: there’s no flag to link an extra library (ghpending uses a $CC wrapper that injects -lcurl), custom handle types are WONTFIX, and including a C header mid-file worked by luck, because the runtime defines short names like lock and u32.

Here’s where the conceptual point lands: the moment you cross the FFI boundary, the proof stays behind. The checker guarantees what’s inside its model; the C code on the other side is an act of faith. Rust has exactly the same problem with unsafe, where the borrow checker’s guarantees hold up to the edge of the block and inside it the proof is on you. If you want strong end-to-end guarantees, the C boundary has to be minimal or nonexistent, and in Bend today it’s enormous for any real program.

Where Bend fits

Crossing the three projects with what the language offers, the winning shape is a small pure core, with a sharp spec that tests cover poorly, inside a thin shell of effects:

• allocators, schedulers, rate limiters, quota logic
• deterministic game or simulation rules, especially with rollback netcode (the only domain where Base already has what’s needed: UDP, windowing, audio)
• consensus state machines, ledgers, matching engines
• parsers and codecs with a round-trip law
• CRDT merge functions (commutative, associative, idempotent)
• access policy evaluators (like ai-jail’s)

And the design center the authors declare: the AI writes the code and the proofs, the human writes only the LAWS.bend, and the checker arbitrates. The shortest honest description I found: a proof-carrying language for AI-written kernels. Compared with Lean or Coq, which prove well and deliver applications poorly, Bend is far more executable.

One thing that surprised me in my own numbers: at first I’d assume the natural niche was academic math research. It’s the opposite. For mathematics it loses badly to Lean 4, Coq, and Isabelle: no tactics, almost no inference, nothing at mathlib’s scale, no reals, and a foundation (Type : Type, no positivity check) that would make a mathematician’s hair stand on end. What it does is software verification, closer to Dafny, F*, or Liquid Haskell than to a proof assistant.

Two limitations weigh even in that niche: Bend emits a whole program instead of a library, so the proven core can’t be linked into a Rust application today; and the cost of proving without a lemma library is high.

What would change the verdict

Recorded in use-cases.md, the list of what would make me reevaluate:

• library output with a C ABI, so a proven core can live inside a Rust or C program
• U64/I64 and F64
• a lemma library for Nat, lists, and ordering
• stdin, subprocesses, TLS, and JSON in Base, or a package hub that has them
• incremental or faster native builds (62s for 1,000 lines today)
• an effects ABI that survives a release

The unvarnished reality

Now my reading, and you already know I don’t sugarcoat.

It’s a newborn language. It launched two days ago. Outside the language’s own repo, a GitHub search today finds only a few dozen 48-hour spikes, almost all with zero stars, nothing that looks like a real project. The repo’s 21 thousand stars are almost all inherited from Bend 1; the repo was renamed. The site’s demos are all toys: a little game, Game of Life, pow2. They’re demonstrations of possibility, with no real usage yet.

The stdlib needs to grow by an order of magnitude. A language’s strength lives in its standard library and ecosystem. The only historical exception to that rule was JavaScript, and that’s a can of worms that doesn’t fit in this article.

The killer app is missing. Every language that made it had one. My tests point to the niche (proven pure cores, written by AI), but someone needs to turn that into an app the world wants to use. And here’s a concrete suggestion, free of charge: Taelin could pick popular open source software he thinks would be better in Bend and rewrite it. Taelin is the exact opposite of the stubborn maintainer who turns his nose up at AI: he designed the whole language around AI. So put that to work: grab a ripgrep, a jq, a sqlite, rewrite it with AI in Bend, and publish the side-by-side comparison. Performance, lines of code, and above all what the proofs guarantee that the original doesn’t. A real-world before/after like that is worth more than a thousand little game demos. And as a bonus, every one of those rewrites hands back the most valuable feedback there is: which stdlib holes actually hurt in a real project. Nothing reprioritizes what to implement in the next version better than real code hitting what’s missing.

Don’t expect webapps, mobile, or anything day-to-day anytime soon. Maybe that’s not even the goal, and that’s fine too. But the “C speed” promise cuts the other way: if the differentiator is performance, it’s easier to go straight to C, especially now, with an LLM writing the code for you.

And here’s my concrete situation. I use Rust a ton. I hate the syntax, and I find the ergonomics miserable. But since the LLM writes the code and I don’t have to deal with it by hand, I tolerate it, and in exchange I get performance, good-enough guarantees, and a gigantic ecosystem of crates and frameworks. Ecosystem. That’s what decides it.

I don’t pick a language by the elegance of the paper. I pick it by the size of the ecosystem I don’t have to write by hand.

The proof-and-GPU focus, and the doubt that remains

One thing nagged me the whole time: Taelin clearly concentrates everything on two pillars, proofs and GPU, and I wasn’t sure what that meant for the language’s scope. I went and read what he himself said in the pre-launch thread and on HN, and the story is more interesting than I assumed.

The GPU pillar is research inheritance. Ten years of interaction nets and optimal reduction, from HVM to here. But there’s a nuance that surprised me: Bend 2 consciously betrays his academic idealism. In his own words: “Bend2 is designed to be practical, not idealistic”, closer to C than to Haskell, because he couldn’t make interaction nets beat the lower-order variants on common hardware. The GPU stayed as the practical application of the obsession, without becoming a fetish.

The proof pillar is older than the LLM era: it goes back to the Ethereum Foundation days, immutable contracts holding millions with a bug, which produced Formality. The LLM era just gave the old obsession a market outfit: “the same capabilities that proved Navier-Stokes will now be writing real proofs that your own apps are correct”.

And here comes my hypothesis that didn’t survive the research. I was ready to write that the minimal stdlib was maybe on purpose, that the idea was never general-purpose programming, and that my criticism of the library desert was aiming at the wrong target. Wrong me. His words are general ambition, period: “the potential to become the most sensible choice for any vibe-coded project”, “Bend is made for the general public”, and the team “working hard to […] make this language competitive with the mature alternatives in the market”. The only deliberate leanness is the checker’s, no inference, verbose on purpose. The small Base is day two of life, so much so that he himself asks for a mathlib.

That makes my stdlib criticism bite even harder: if the declared goal is to be the choice for any vibe-coded project, the comparison with mature ecosystems is the game he chose to play.

And there’s the business angle, which he admits with rare frankness: “we ship without a product”. The language is the free substrate; the sellable thing is the Bender and the proving infrastructure behind it. Worth keeping an eye on that space.

The doubt that remains, and this one I register with no answer: the generalist ambition is his north star, but the reality I measured pushes Bend toward the niche of AI-written verified cores. Which of the two wins, only time will tell.

The final word

If I could give Taelin one piece of advice, it would be this: the hard part, the research, he’s already done. Now comes the less glamorous part, the one that decides whether a language lives or dies: marketing and ecosystem building. Adoption, teaching material, killer app, stdlib, mathlib. Going way beyond toys and demos.

The example that comes to mind is Zig. Years on the road and still fighting for adoption, even with immediate practical use: zig cc alone is a trivial drop-in for compiling C, without using any of the language. Real apps use it; Mitchell Hashimoto’s Ghostty is the famous case. But Andrew Kelley, the author, is a notoriously difficult figure, from the crowd that turns its nose up at AI, and he clearly doesn’t understand ecosystem building, and that holds Zig back. Technical perfectionism doesn’t mix with marketing and adoption.

Bend 2 has real potential. Instant checker, proofs catching bugs that tests don’t catch, parallelism without ceremony. But potential alone means nothing if adoption doesn’t come. I’m rooting for it to come, and rooting double because a Brazilian is leading.

And one final provocation, this time for you who read this far. Thin stdlib, zero frameworks, zero third-party libraries, no killer app: all of that stops being a problem when you look from another angle and becomes an opportunity map. Everything missing in Bend is something someone will have to write, and whoever gets there first etches their name into the project’s history. If you always wanted to contribute to impactful open source but never found room in the mature projects, where everything already exists, here’s an empty lot waiting.

Those are my two cents. Don’t take it too seriously.

“And if I ever manage to spend enough tokens to boil an entire lake with the datacenter’s heat, I will spend it with the greatest pleasure in the world. It’s my personal revenge against whoever forced me to use paper straws that dissolve in your mouth for all these years.”

I confess: it was deliberate provocation, written already knowing I was going to explain it here today. Because behind the joke there’s a serious thesis.

Last week I took apart here the AI fear propaganda from OpenAI, Anthropic, and NVIDIA. Today I want to use the same lens on a much older and much more profitable hysteria: the climate one. And there’s an irony in the middle: what unmasked this hysteria was AI itself, by accident.

The thesis is simple. The moment the datacenter race tightened for real, every “green” commitment from governments and big techs evaporated. The same Microsoft that promised to be carbon negative is restarting Three Mile Island. The same Germany that shut down its nuclear fleet now has a chancellor admitting it was a strategic mistake. What took down the climate agenda was another agenda, one with more money.

And before anyone labels me, my position in full: yes, there is a human effect on the climate. No, the world is not ending, and the distance between those two sentences is where the hysteria lives. What I dispute is the industrialized panic and the misallocation of trillions it justifies.

Every decade has its apocalypse

I grew up under the nuclear apocalypse of the Cold War. We lived with the certainty that the world could end in atomic mushrooms at any moment. When the USSR fell in 1989, that fear drained away, and the hole in the ozone layer filled the void. That one, by the way, is recovering decades after the 1987 Montreal Protocol, which phased out CFCs and friends: proof that a real problem with a cheap solution needs no hysteria.

Then came the Y2K bug. Then “global warming”. And when “warming” got hard to sustain in every headline, the agenda changed its name to “climate change”.

Notice the trick. Orwell called it Newspeak in “1984”: capture the words to capture the thinking. “Global warming” was a testable hypothesis: either it warmed or it didn’t. “Climate change” accommodates everything. Heat, cold, drought, flood, snow, lack of snow. Any event confirms the thesis, and a thesis that everything confirms explains nothing.

When the vocabulary is captured, the question becomes a crime. Whoever asks for evidence becomes a “denier”. A scientist funded by obscure interests becomes an “expert”, and “expert” gets sold as a monopoly on truth. The covid hysteria was the worst fruit of this way of thinking, but covid is for another article. The climate case is enough.

The human cost of this machine is measured. A 2019 Washington Post/Kaiser Family Foundation survey of American teenagers found 57% afraid and 52% angry because of the climate. A global UN poll that collected about 9.7 million votes asked about priorities: “action on climate change” came in last among 16 topics in the global total, and even in the poorest countries it sat at the bottom of the list. The people want hospitals and jobs. Whoever ranks the apocalypse first is whoever has their comfort guaranteed.

Follow the money: who funds the fear

About Greta Thunberg, one fact bothers both sides: she herself keeps none of the money. Her father told Politico she never received a cent, and she donated the entire 1-million-euro Gulbenkian prize to climate projects. The character is real and, by all accounts, unsalaried.

The girl and the startup

The machine around her is another story. The school strike started on August 20, 2018, a Monday. The Swedish startup We Don’t Have Time, founded by advertising man Ingmar Rentzhog, was still building its climate social network. On the day of the strike, Rentzhog posted the girl’s photo on his personal Facebook and the company account tweeted the same day, tagging Al Gore’s Climate Reality Project. Three days after the strike began, on Thursday, August 23, the family book, “Scenes from the Heart”, hit bookstores.

The startup’s fundraising prospectus, from November 2018, cited Greta 11 times, without the family’s knowledge; that round raised ~13 million Swedish kronor, and the company said it had raised 23 million in total by early 2019. She was a junior advisor to the company’s foundation from October 2018 to January 2019 and left. The product was the startup; the girl was the marketing.

The salaried protest industry

Then came the industrialization of protest. The Climate Emergency Fund, founded in 2019, funds Just Stop Oil, Extinction Rebellion, Scientist Rebellion, and friends. The one who opened the vault with $500,000 was Aileen Getty, heiress to the Getty oil fortune, mind you. Hollywood director Adam McKay came in with $4 million and a board seat.

By April 2022 the fund had already distributed $1.7 million to activists in 25 countries; the full-year tax filings point to ~$5 million in grants. Just Stop Oil alone received almost $1 million, helping pay the salaries of some 40 organizers. That soup on the Van Gogh canvas is salaried work, funded by oil inheritance and movie money.

Billionaire foundations and governments

Above the protest funds sit the big foundations. Bloomberg Philanthropies alone totals $1 billion in the Beyond Carbon campaign, and the New York Times called Bloomberg perhaps the biggest individual funder of climate activism in the world. The Hewlett Foundation committed $600 million over five years, Rockefeller announced in 2023 it would invest more than $1 billion in climate over five years, and ClimateWorks has already distributed more than $2 billion. That’s an industry, with the budget of a small country’s GDP.

And governments fund the pressure against their own political opponents. The EU pays €15.6 million a year in operating grants to some 30 green NGOs through the LIFE program, and in January 2025 the European Parliament held a formal debate about Commission-funded NGOs lobbying the Commission itself, in which the budget commissioner admitted it was “inappropriate” for parts of the Commission to sign agreements obliging NGOs to lobby specific MEPs. In Germany, Correctiv received €2.5 million in public money since 2016, the “Demokratie leben!” program had a budget of €182 million in 2024, and the CDU filed 551 formal questions about the political neutrality of state-funded organizations.

And who profits from the policies? Enron’s internal memo from December 1997, written from Kyoto, was already celebrating: “this agreement will be good for Enron stock!!”. The climate-industrial complex was born together with the treaty. Global revenue from carbon pricing, taxes and emission markets combined, hit a record $104 billion in 2023, and a 2008 Point Carbon study for the WWF estimated between €23 and €71 billion in windfall profits for generators in five EU countries in phase II of the European carbon market alone. And the biggest beneficiary of Western green targets has a name and an address: China controls more than 80% of every stage of the solar panel manufacturing chain and produced almost 75% of the world’s electric cars in 2025. The West subsidizes demand; Beijing sells the supply.

If you don’t know the Enron case, take a minute and watch:

Who wins

So who benefits from the fear narrative? Billionaire foundations, consultancies, subsidized industries, governments buying social peace with grants, and the West’s biggest industrial competitor. Greta walked away without a dime. The machine kept the megaphone.

The datacenter race

Some of the numbers I’m about to show come from the research I did for my talk at Tropical Ruby 2026, about energy and AI. The IEA data tells the story:

• Datacenters consumed 415 TWh in 2024, about 1.5% of the world’s electricity.
• In 2025: ~485 TWh, 17% growth in one year; AI-focused datacenters alone grew 50%.
• Central projection for 2030: ~945 TWh, the consumption of all of Japan, close to 3% of the planet.

In the US, datacenters account for almost half of all electric demand growth through 2030. And the money followed: big tech capex went from $400 billion in 2025 to ~$715 billion guided for 2026, more than the annual investment of the entire American energy sector. Cumulative datacenter investment between 2026 and 2030 is expected to hit $3.9 trillion.

And even that doesn’t cut it. The bottleneck stopped being chips and became copper and concrete:

• PJM, the largest grid operator in the US, closed for the first time in history a capacity auction below the reliability requirement, in December 2025: ~6.6 GW came up short. The capacity price jumped to $333.44 per MW-day, more than 11 times the level of the 2024/2025 auction, hitting the ceiling allowed by FERC.
• High-power transformers have a two-to-three-year waiting list, and the biggest models run past that. The American interconnection queue has more than 2,000 GW waiting, about 1.6 times the country’s entire installed capacity.
• Of the ~16 GW of large datacenters Sightline Climate forecast globally for 2026 (the American slice is ~12 GW), only ~5 GW were under construction at the start of the year, and the estimate is that 30% to 50% of that announced pipeline will slip.

The queue in the market now is for GPUs, power, and datacenters.

Remember the electric car, the green agenda’s great salvation? The entire global EV fleet consumed ~250 TWh in 2025, about 1% of the world’s electricity. Datacenters consumed almost double, already last year. And the projection tells the rest: from 415 TWh in 2024 to ~945 TWh in 2030, that’s +530 TWh of new load on the grid, almost three times the electricity of the entire 2024 global EV fleet (~180 TWh).

The entire decade of “green economy” was swallowed in two years of AI race. And the comic detail: in March 2026, Bernie Sanders and Alexandria Ocasio-Cortez announced the AI Data Center Moratorium Act, an attempt to ban new datacenters in the US. The green agenda spent decades telling you to consume less energy. Faced with AI, the coherent exit left over was trying to ban the new consumer.

The return of nuclear power

If the climate agenda were serious, its greatest ally was always nuclear power: the cleanest, densest, most reliable source there is. The same agenda that preached apocalypse treated nuclear as taboo for fifty years. Here’s what AI’s hunger for energy did in one year:

Big tech’s nuclear race

• Microsoft signed a 20-year contract to restart Three Mile Island’s Unit 1, 835 MW. Read that again: Three Mile Island, the ultimate symbol of American nuclear fear since 1979, resurrected as the Crane Clean Energy Center to feed datacenters.
• Meta locked in up to 6.6 GW in nuclear agreements with Vistra, TerraPower, and Oklo.
• Google ordered 500 MW in modular reactors from Kairos.
• Amazon expanded its contract with the Susquehanna plant to 1.9 GW through 2042 and invested in X-energy.

The technical reason is simple. In the US, nuclear runs at a capacity factor around 91%, and stayed above 92% on average for the decade through 2023; wind sits at ~34% and solar at ~23%. Datacenters want baseload, 24 hours a day. Sun and wind don’t deliver that without a mountain of batteries nobody has.

If you don’t know the 1979 Three Mile Island incident, watch:

The German case

And Germany? Germany shut down its last three plants on April 15, 2023 and became a net importer of electricity for the first time since 2002, including importing French nuclear. The Energiewende cost in the range of hundreds of billions of euros, German industrial electricity costs about double the American or more, and the German grid emits around 350 g of CO2 per kWh, against 22 g from nuclearized France.

Well then. In January 2026, Chancellor Friedrich Merz admitted in public: “It was a serious strategic mistake to phase out nuclear energy”, “we are now undertaking the most expensive energy transition in the entire world”. The head of the IEA itself, Fatih Birol, went public agreeing with him. Since May 2025 Germany stopped sabotaging nuclear France in the EU, and in June 2026 former bosses of the closed plants formally asked for the reactors to be reactivated.

Let me put my opinion on record here: closing the nuclear fleet was one of the biggest mistakes in Germany’s modern history. They impoverished their own industry, got hooked on Russian gas, went back to burning coal in the 2022 crisis, and today buy nuclear electricity from the neighbor. All of it in the name of an agenda they themselves are abandoning.

Fear versus the numbers

About the fear itself, the official numbers say otherwise. Deaths per TWh produced, counting accidents and pollution: coal kills 24.6; oil, 18.4; gas, 2.8. Nuclear: 0.03, less than wind and almost equal to solar. Chernobyl killed 30 workers directly, and the Chernobyl Forum and WHO projection for eventual cancers sits at up to 4,000 among the 600,000 most exposed, while Greenpeace was selling 93,000. The same report concluded the biggest public health problem was the psychological damage: people got sick from fear of radiation, not from radiation. Fukushima: zero radiation deaths among the public (Japan recognized a single radiation-linked death: a worker with lung cancer, in 2018); 2,313 deaths linked to the panicked evacuation. Fear killed more than the accident.

And the waste? All the used fuel from America’s commercial reactors fits on a football field, stacked less than 10 yards high, about 9 meters. France has been reprocessing its own at La Hague for decades. Finland built the world’s first deep geological repository for used nuclear fuel, Onkalo, already in the final stretch of licensing. A technical problem solved long ago; what was missing was political courage, and it arrived in the form of a datacenter power bill.

The man who’s been pointing this out for twenty years

The person who has organized this argument with rigor for two decades is the Dane Bjorn Lomborg. A political scientist by training, a statistics professor for years at the University of Aarhus, former visiting professor at Copenhagen Business School, fellow at Stanford’s Hoover Institution, founder of the Copenhagen Consensus Center, a think tank that works with hundreds of economists, Nobel laureates included. He blew up in 2001 with “The Skeptical Environmentalist” and became persona non grata of the green establishment, despite repeating the same sentence since forever:

“Global warming is real, but it is not the end of the world. It is a manageable problem.”

Take note: Lomborg accepts the scientific consensus on the existence of warming and its human cause. He defends a carbon tax and investment in green R&D. What he contests is the panic and the math of the policies. His 2020 book, “False Alarm”, is a catalog of numbers the headline never tells you:

The numbers the headline doesn’t tell you

• Deaths from climate disasters (drought, flood, storm, wildfire, extreme temperatures; Lomborg’s compilation over the EM-DAT database): from ~500,000 per year in the 1920s to fewer than 20,000 per year today, a 96% drop. Since the population quadrupled, individual risk fell 99%.
• In Lomborg’s synthesis of the Stanford Energy Modeling Forum models, complying with the Paris Agreement costs between $1 and 2 trillion per year, the most expensive pact in human history. And the effect of fulfilling every 2030 promise, measured in the MAGICC model, the same one used by the IPCC, is to reduce 2100 warming by 0.048°C, in his paper in Global Policy. Stretching every promise to 2100: 0.17°C. Every dollar spent on Paris avoids 11 cents of damage.
• The cost of warming with no action at all, in the damage function of Nobel laureate William Nordhaus: about 3 to 4% of global GDP in 2100. Lomborg applies this to the IPCC income scenarios and translates: instead of having 4.5 times today’s income, we’ll have 4.34 times. A manageable problem.
• New Zealand calculated that its net-zero costs between 5% and 17% of 2050 GDP, against the previous target of cutting 50% of emissions. Lomborg converts the country’s slice of emissions, by his math, into a three-week postponement of global warming.
• Tuvalu, the poster country of “it’s going to vanish into the sea”, grew 2.9% in area over four decades with the sea rising at double the global average. And the “187 million displaced by 2100” headline comes from a study for up to 2 meters of sea level rise with no adaptation; the same study, with dikes and realistic adaptation, calculates between 41,000 and 305,000 displaced.
• A study in The Lancet that analyzed 74 million deaths in 13 countries attributed 7.3% of them to cold and 0.4% to heat: in the current climate, cold kills some 17 times more.

The math nobody lets you do

Now the comparison that matters. The Copenhagen Consensus’s “Best Things First” calculated: $35 billion per year on twelve cheap solutions (treating tuberculosis, malaria bed nets, child nutrition, vaccines) would save ~4 million lives per year. Treating tuberculosis costs $6.2 billion a year and saves ~600,000 lives a year this decade, a return of ~$46 per dollar. Malaria alone killed 610,000 people in 2024, 95% in Africa, most of them children under 5. A delivered treated net costs about six dollars; saving a life with them costs around $5,500.

International climate aid alone, a quarter of all development aid, would be enough to fund tuberculosis, malaria, contraception, and nutrition in the entire world and still leave change. That’s the real choice on the table. Nobody lets you do this math out loud without being called a monster.

His 2005 TED talk, “Global priorities bigger than climate change”, is exactly this cost-benefit exercise, done on stage, twenty years ago. Worth the 16 minutes:

And since the comments will aim at the messenger, let me get the rap sheet out of the way early. About Lomborg you’ll hear that a Danish “scientific dishonesty” committee declared his first book objectively dishonest in 2003. True. And Denmark’s Ministry of Science overturned the decision at the end of the same year, over flaws in the process. You’ll also hear about Scientific American’s eleven-page hostile dossier. All on record. And none of it touches the numbers, which come out of the IPCC, the WHO, the FAO, and EM-DAT.

Thirty years of summits, and the score is zero

Before China, it’s worth looking at the full track record of the process that produced these policies. Three decades of treaties, each announced as historic, each with the same result:

The treaties

• Rio, 1992. The UNFCCC is born, with the written goal of “stabilizing greenhouse gas concentrations in the atmosphere”. Result: global fossil CO2 went from 22.5 gigatonnes in 1992 to 37.4 in 2024, +66%. At Mauna Loa, atmospheric CO2 went from 356 ppm to 427 ppm, with no visible dent in the growth curve.

• Kyoto, 1997. Target: industrialized countries would cut 5.2% below 1990 by 2012. The US Senate preemptively rejected the idea 95 to 0 before the final text even existed. Canada left the treaty in 2011 when it became clear it would miss the target. Global emissions rose 43% while it was in force. The countries that “complied” complied for free: the post-Soviet industrial collapse and the 2008 recession did the work. And Kyoto’s second period, the Doha one, covered 37 countries and ~14% of global emissions and entered into force on December 31, 2020: the last day of the period it governed.

• Kyoto’s credit mechanism, the CDM, became a fraud factory: industries in China and India produced HFC-23, a greenhouse gas 14,800 times more potent than CO2, just to destroy it and sell credits, a €2.6 billion scheme. The Öko-Institut, auditing for the European Commission itself, found that 85% of projects had a low likelihood of integrity. A 2024 study in Nature Communications calculated that fewer than 16% of the carbon credits analyzed correspond to real reductions.

• Copenhagen, 2009. The goal was the binding successor to Kyoto. It collapsed live: the final text was taken note of, not adopted, drafted on the last night by the US, China, India, Brazil, and South Africa. What survived was the promise of $100 billion a year for the poor world, met for the first time in 2022, two years late.

• Paris, 2015. The target system is self-assigned and the targets are not legally binding. Of the 197 parties, only 58 had economy-wide targets in domestic law or policy, and only 17 with ambition equal to or greater than what was promised on paper (Grantham Institute, via Lomborg). Nature wrote in 2017 that every major industrialized country was falling short. The US left, came back, left again (effective January 2026) and, in January 2026, announced its withdrawal from the UNFCCC itself, the 1992 convention, something no country had ever done. Since Paris, emissions rose from 35.4 Gt to 37.4 Gt, every year, except for the covid dip.

• Belém, 2025 (COP30). The house was ours, and the result was a portrait of the state of the process. Before it opened: delegations from Africa and the Pacific formally complaining about the lodging crisis, with stratospheric hotel rates and part of the delegations sleeping on cruise ships. During: a fire in the blue zone evacuated the delegates in the middle of the final negotiation, with 13 people treated for smoke inhalation. It was the first COP without an American delegation in 30 years, and Trump mocked the event on Truth Social, the highway through the rainforest and all. Attendance: ~42,000 in person, half of what Dubai had. And what came out of it? A text called “Global Mutirão” (mutirão is Portuguese for a collective work effort) with the fossil fuel phase-out plan ripped out after pressure from Saudi Arabia and allies, despite more than 80 countries backing it, and a promise to triple adaptation finance already born weakened, from 2030 to 2035. The bill for the Brazilian taxpayer: ~R$4.7 billion in the federal package alone (Union Budget, BNDES, and Itaipu), not counting what the state and the city spent on their own and never consolidated in public. One more circus paid for with our money, with nothing to show at the end.

The COP circus

And there’s the circus itself, which isn’t just ours. COP28 in Dubai had 83,884 in-person participants, including 2,456 fossil fuel lobbyists, which perhaps explains the final texts. Glasgow had 118 private jets; COP27, some 315 executive jet trips. And the cherry on top of our edition: Avenida Liberdade, 13 km of road cutting through Belém’s Environmental Protection Area, with 68 hectares of vegetation cleared (the project was the state’s and predates the COP, but the cut in a protected area is fact).

The scoreboard of 32 years of treaties: +68 ppm of CO2 in the atmosphere, zero deceleration. The emissions curve doesn’t know the treaties exist.

Patient zero of the hysteria: Al Gore

Before the treaty machine, the propaganda had a founding father. Al Gore lost the 2000 election and reinvented himself with “An Inconvenient Truth” (2006): an Oscar, the 2007 Nobel Peace Prize shared with the IPCC, and the template for every hysteria that came after. Practically every apocalyptic prediction you hear to this day premiered in that film.

The one who dissected the film claim by claim was Roy Spencer: PhD meteorologist, former senior climate scientist at NASA, co-creator with John Christy of the UAH satellite temperature dataset, the independent reference for global temperature. His position is the “lukewarmer” one: CO2 warms a little, the theory is solid up to there; the catastrophe is the exaggeration. In 2017 he published “An Inconvenient Deception” (Kindle on Amazon), which I read for this article. Gore’s catalog of busted prophecies, with Spencer’s data:

The catalog of busted prophecies

• “Ten years to the point of no return” (2006). Ten passed, almost twenty passed. The trend measured by Spencer’s own satellite: ~0.16°C per decade, through June 2026.
• Arctic summer ice “could be gone as early as 2014”: the line is from his Copenhagen speech, December 2009, citing a modeler who later disowned the number. It didn’t vanish.
• Kilimanjaro’s snows by 2016: still there.
• Stronger and more frequent hurricanes after Katrina: what came was a drought of almost 12 years without a single major hurricane touching the US, from Wilma in October 2005 to Harvey in August 2017, the longest since 1850. NASA researchers calculated that a gap like that happens once every 270 years. And the global cyclone count has no upward trend since the 1970s.
• “Up to 20 feet of sea level rise”: the measured global rate today is ~3.4 mm per year, about 1.4 inches per decade. The Battery Park tide gauge in Manhattan measures 1.16 inches per decade since 1856, and part of that is the land sinking. At this rate, 20 feet takes more than a millennium.
• The drowning polar bears: the film’s animated scene was born from a short note in Polar Biology about four bears found dead after a storm in 2004. The estimated global population sits between 22,000 and 31,000, probably larger than in the 1970s, when no reliable estimate even existed and the real threat was unregulated hunting, solved by the 1973 treaty. Twenty years later, “the bears are dying” still circulates as fact.
• The Syria drought, “the worst in 900 years”, said to have caused the civil war: rainfall data for the west of the country, Aleppo, Damascus, Homs, stayed above average; the strong 2007/08 drought concentrated in the northeast. What broke the countryside was the government tripling the price of diesel in 2007-2008, which made pumping well water unviable.
• The flooding of the 9/11 memorial by hurricane Sandy, presented in the sequel as “I told you so”: in the original film he talked about gradual sea level rise, never storm surge. Spencer calls it explicit deception.
• The tabletop experiment with Bill Nye, heating CO2 in glass jars in the Climate Reality Project’s “Climate 101” video (2011): Anthony Watts’s analysis showed the experiment doesn’t work and the result was faked in post-production. According to Spencer, the video stayed on Gore’s site for years afterward.
• The crops: the 42 climate models used by the UN predicted summer warming in the American Corn Belt; NOAA data shows no significant warming there since 1960.

The cast of the prophecies is going strong. The bears, too:

The character

And the character: Spencer documents that Gore got rich on “green” investments (he’s a cofounder of Generation Investment Management), keeps mansions and an industrial-sized carbon footprint. And even the establishment didn’t swallow the film whole: in 2007, the British courts found nine errors in “An Inconvenient Truth” and called the sea level part “distinctly alarmist”. Spencer’s word for Gore’s technique is “wordsmithing”: writing in a way that leads the audience to conclude what he never stated in so many words.

The audience, by the way, had already tuned out: in the first weeks of the 2017 sequel, the screening Spencer attended in a 750-seat theater had three people, and one left halfway through.

If this subject got to you, the two bedside books are Spencer’s, above, and Lomborg’s “False Alarm”, which I used in the previous section. One dissects the propaganda; the other dissects the bill.

Spencer’s rap sheet also comes ready-made in the comments: he’s one of the favorite skeptics of Republicans in Congress, the UAH dataset had famous corrections in the 90s and 2000s (published and incorporated decades ago), and a 2011 paper of his in Remote Sensing was so contested that the journal’s editor resigned, saying the article had slipped through by mistake. All real. And none of it changes the Battery Park tide gauge or the calendar of expired prophecies. Criticize the numbers, if you can. The messenger is just the messenger.

The arithmetic of insignificance

Let’s get to your electric car and your paper straw. China accounted for 32% of global fossil CO2 in 2024, more than the US, the EU, and India combined. China started construction on 94.5 GW of new coal plants in 2024 alone, a ten-year record, and burns more than half of all the planet’s coal every year since 2011.

Now your individual actions, with the numbers:

• The entire global EV fleet displaced ~1.3 million barrels of oil per day in 2024, something like 0.5% of the world’s fossil CO2. That’s the total size of the impact of the biggest green policy of the decade.
• Lomborg calculated in 2020: an average subsidy of $10,000 per EV to save ~8 tonnes of CO2, worth $48 in the RGGI, the carbon market of the American Northeast states, at the time. You paid ten grand for 48 dollars of carbon.
• Lomborg’s math, with IEA data from the time: an EV emitted ~26 tonnes of CO2 over its lifetime against ~34 for a gasoline car, a 24% cut. And it depends on the grid: the Volvo XC40 study calculated the battery payback at 146,000 km driven on the global average electric mix (84,000 km on the European mix, 47,000 km on wind power). On a coal-powered grid, it’s worse.
• Paper straws: even if every estimated straw on the coasts ended up in the sea in one year, they’d make ~0.03% of the annual plastic entering the ocean.
• Household recycling: of all the plastic that became waste in history through 2015, only 9% was recycled; 12% incinerated; 79% went to landfill or into nature (Geyer et al., Science Advances 2017). And plastic doesn’t recycle in a loop: each cycle degrades the polymer, it becomes a lower-quality product, and it postpones the landfill by one step. The worst part: NPR showed that the plastics industry knew since the 70s that recycling didn’t pay and sold the symbol anyway, so you’d keep buying guilt-free. The exception that proves the rule is aluminum: recycling uses 5% of the energy of producing from scratch, and Brazil is the world champion at it, with 97.3% of cans recycled in 2024. Recycling works when the physics and the economics close. When they don’t, it’s kitchen liturgy.

Your paper straw doesn’t show up in this math. Neither does your EV. The math is dominated by whoever builds 94 GW of coal plants per year.

These gestures are liturgy, and this is where their real damage lives. The paper straw gives that feeling of “at least I’m helping”, and that feeling numbs. The person makes the micro-sacrifice, feels part of saving the world, and closes their eyes to the actually big problems, like the children dying of malaria in Africa I showed two sections back. Objectively, the gesture moves nothing. Subjectively, it buys the conscience. It’s worse than useless.

And Lomborg’s complete thought is even more brutal: if the rich world zeroed all its emissions and stayed at zero for the rest of the century, the temperature increase in 2100 would drop 0.7°F, less than half a Celsius degree, in his math with the MAGICC model. The West’s total sacrifice is a rounding error.

The world doesn’t fit in your head

Part of the hysteria exists because most people have no sense of the planet’s physical scale. Let’s fix that real quick, in human language.

The Sun. The Earth continuously intercepts ~173,000 terawatts of solar energy. All of civilization consumes ~20 TW. The ratio is more than 8,000 to 1, and the Earth captures only one part in 2.2 billion of what the Sun emits. A single large coronal mass ejection carries billions of tonnes of plasma with energy in the range of 10^25 joules, something like fifty million Tsar bombs. In 1859, the Carrington Event set telegraphs on fire and drew auroras in the sky over Cuba. No human control panel participated.

The Moon. Tides are the Moon deforming the ocean: a bulge of water on its side, another on the opposite side. The lunar effect on the tide is ~54 cm; the Sun’s, ~25 cm. In the Bay of Fundy, the tide swings 16 meters, and each flood tide brings in ~160 billion tonnes of water, more than all the rivers in the world combined in the same period. Meanwhile, the Moon drifts away 3.8 cm per year and the Earth’s day gets longer by some 2 milliseconds per century. Some 620 million years ago, the day was almost 22 hours.

El Niño. Normally the trade winds push the Pacific’s warm water west. Every 2 to 7 years they weaken, the warm water slides east, and the global average temperature rises 0.1 to 0.2°C for a year or two, on its own, no cars, no industry. La Niña does the opposite. When you see a “hottest year in history” headline, check whether there was an El Niño: there almost always was.

New York and Lisbon. New York sits at 40.7°N. Lisbon, at 38.7°N; Madrid, at 40.4°N. Same latitude. New York buries itself in snow every winter; Lisbon and Madrid have mild winters by comparison. The explanation: the westerly winds throw moderate air across the Atlantic onto Europe, while the American east coast receives freezing continental air from the Arctic, with the Atlantic transporting ~1.2 petawatts of heat north via the meridional current of which the Gulf Stream is part. Iceland, at 64°N, has winter averages comparable to New York’s. Latitude rules far less than current and wind.

The Sahara fertilizes the Amazon. Every year, ~182 million tonnes of dust leave Africa crossing the Atlantic; ~28 million tonnes fall on the Amazon basin, carrying ~22,000 tonnes of phosphorus, almost exactly what the rain leaches from the forest’s soil each year. The world’s biggest desert feeds the world’s biggest forest, and it’s been happening for millions of years before you were born.

And if you zoom out the time scale, it gets even more absurd:

The Sahara was once green. Between ~11,000 and ~5,000 years ago, the Sahara was savanna with lakes, hippos, and crocodiles, and the Cave of Swimmers, in Egypt, holds rock art of people swimming in what is now desert. The driver was the orbital precession cycle, and the flip to desert took decades to a few centuries, depending on the region. And it comes back: the next orbital summer maximum arrives in some 10,000 years.

The Earth was once a snowball. Twice between ~717 and ~635 million years ago, the Sturtian and Marinoan glaciations took ice all the way to the tropics: there are glacial deposits at tropical latitudes to prove it. The Earth got out of it on its own: the global ice shut down the process that pulls CO2 out of the air, volcanoes stacked CO2 for millions of years up to hundreds of times the current level, and the greenhouse effect beat the ice.

The Mediterranean once dried up. Between 5.97 and 5.33 million years ago, the Mediterranean Sea nearly evaporated and left layers of salt more than a kilometer thick on its bed. When the Atlantic broke through at Gibraltar, the flood filled the sea back up with 90% of the volume in months to two years, at a flow estimated at a thousand times the Amazon’s.

Sharks in Kansas. In the Cretaceous, with the sea level 100 to 200 meters above today’s, a shallow sea split North America in two, from the Gulf of Mexico to the Arctic. Mosasaurs and sharks swam where Kansas is today.

The plants almost starved. At the last glacial maximum, CO2 fell to ~180 ppm, dangerously close to the ~150 ppm range where C3 plants start to fail. Glacial-era trees preserved in the La Brea tar show physiological carbon starvation. Plants evolved in a world with much more CO2, and today the planet is greening: the Zhu et al. 2016 study, publicized by NASA, measured greening across 25 to 50% of vegetated areas between 1982 and 2009, with ~70% attributed to CO2 fertilization.

CO2 became a synonym for a dangerous gas that must be fought at any cost. For plants, it’s food. When CO2 rises, green life tends to rise with it. If CO2 were poison, there would be no plants.

Rainforest in Antarctica. In 2020, Nature published the discovery of intact roots of a temperate forest that grew at 82°S, some 900 km from the South Pole, ~90 million years ago, with a mean annual temperature of 12 to 13°C. New Zealand climate, in Antarctica.

The climate has always changed

“Climate change” is an oxymoron. Changing is what the climate does, since forever, without asking permission.

For most of Earth’s history there was no permanent ice at the poles. The planet’s normal condition is greenhouse, no polar ice. In the Cambrian, CO2 was 10 to 20 times the pre-industrial level. At the peak of the Cretaceous, the global average was some 10°C above today’s, or more. Antarctica only gained permanent ice 34 million years ago.

And the great die-offs, which the hysteria loves to invoke, happened five times before any industry:

• ~444 million years ago (Ordovician): ~85% of species, glaciation.
• ~372 million (Devonian): ~75%, ocean anoxia.
• ~252 million (Permian, “the Great Dying”): ~96% of marine life, volcanism.
• ~201 million (Triassic): ~80%, volcanism.
• ~66 million (K-Pg): ~76%, the dinosaur asteroid. That one’s just the most famous.

On the more recent scale: the current ice age began 2.58 million years ago, with ice cycles every ~100,000 years in the last million of them. 20,000 years ago, hundreds of meters of ice covered where Manhattan is today, and the sea level was 120 meters lower. 11,500 years ago, at the end of the Younger Dryas, Greenland warmed ~10°C in about a decade. Then came the Medieval Warm Period, the Little Ice Age with the Thames freezing until 1814, and the “year without a summer” of 1816, courtesy of the Tambora eruption. All of it without a single coal plant.

To be clear about what I’m saying: none of this proves the current warming doesn’t exist, and the current speed of the CO2 rise is indeed faster than the natural precedents. Lomborg himself says so. What this scale destroys is the phrase “end of the world”. A planet that has already been 10°C warmer with the sea 120 meters lower is not in its death throes. The serious discussion is about the cost-benefit of each policy, which is exactly the discussion the hysteria forbids.

The hysteria died of natural causes: money

Fear doesn’t save the planet, doesn’t help the environment, and doesn’t improve anyone’s life. Fear sells narrative, funds consulting, elects politicians, and stuffs foundations with money. The cost of this era is right there: trillions torched on gestures that don’t move the thermometer, while 4.9 million children died in 2024 before turning 5 from diseases the developed world forgot exist.

And then AI came along and closed the subject by accident. Notice how nobody talks about COPs in the headlines anymore. The conversation now is datacenter gigawatts, 20-year nuclear contracts, gas turbines. The same CEOs who signed climate letters are fighting over power plants. The same governments that imposed paper straws approve reactor subsidies. The climate agenda left the stage without being refuted, evicted by a bigger agenda.

If the end of the world were really on their agenda, you wouldn’t be watching Three Mile Island being restarted to train chatbots. You’re watching it. It was theater, and the theater closed when a more profitable show opened in the room next door.

Fear doesn’t save the planet. Fear sells. And whoever bought the fear is now buying megawatts.

Let me get my rule out of the way before I get into the specific case, because it matters more than the case itself.

My Rule: Don’t Use Anything Until Not Having It Hurts

After producing more than half a million lines of AI-assisted code over the last few months, dozens of projects live, a whole benchmark rebuilt from scratch three times, my recommendation for anyone who codes is direct: don’t use any orchestration tool or middle layer until you feel it in your bones that you need the extra help. Use whichever harness you already like, Codex, opencode, Claude Code, whatever, directly, no middleman, and forget the rest.

It’s not even worth spending time collecting someone else’s skill packages to stack on top of your agent. Build, train, and gather your own experience for your own use case. Nobody else on earth has your project, your context, your codebase. Someone else’s skill package was designed for their problem, not yours.

I already hit this note a month ago: once a technology turns into a commodity, the money migrates to taxonomy. Somebody coins a fancy name for chaining API calls, and out of nowhere a course, a certification, and a consulting practice spring up around that name. TypeSafe is just one more chapter of the same story, so it became a good excuse to show how I decide whether something’s worth even opening the tab.

Keep this: don’t use an orchestration tool or middle layer until you feel in your bones that you need it. Build experience for your own use case; don’t collect someone else’s skill package.

The Trigger: TypeSafe

I opened their site and their launch post, Jev. My first impression, pretty superficial and raw: I didn’t like it and I didn’t trust it. The homepage is a pile-up of AI jargon, Kahneman here, Jevons there, decorative glyphs, a “193x faster” figure with no benchmark sitting next to it. At first glance, none of it makes sense on its own.

And there’s a detail that always puts me on guard: any time the first thing someone says about themselves is “I’m a former OpenAI researcher” or something like it, I get suspicious first and ask questions later. It reads like an attempt to slap on a credential to look credible before any real proof. TypeSafe’s founder talks himself up too loudly right out of the gate, and that alone is reason enough to hit the skepticism button.

But a triggered skepticism meter isn’t a conclusion. It’s the starting point for actually investigating, not for dismissing something without a look. That’s the part I want to show here, kind of a practical lesson for anyone following along: how I use AI to speedrun preliminary research, how I read the fine print before signing off on any conclusion, mine or someone else’s, and how I move from initial distrust to real research, until I find out whether I was right or just being difficult.

And let me put this on record before going further: I could be wrong about some specific point ahead. If you’ve got strong counter-evidence, drop it in the comments. I’d rather get called out in public and correct the piece than push a scammy product on my audience just because I didn’t check carefully enough.

I Asked the AIs, I Didn’t Trust the AIs

I sent the same prompt to Grok and to Claude: research this thoroughly, my initial impression is very skeptical, “ex-OpenAI researcher” smells like slapping on a credential, the site is jargon top to bottom, tell me what the actual sales pitch is, what it’s for in practice, and whether their logic, underneath the jargon, even makes sense.

Both came back with long, detailed research, a similar story from each: the founder’s credential is real but inflated; the product is narrower and more coherent than the homepage lets on; and “can’t hallucinate” is a schema claim dressed up as a truth claim.

Except I’d already handed my own conclusion to both of them inside the prompt, so their agreement proves less than it looks like. Two AIs agreeing with the hypothesis I wrote into the request myself isn’t independent confirmation of anything, it’s an echo. That doesn’t invalidate what they brought back, but it meant I couldn’t stop there. I wasn’t going to publish this by stamping my approval on what two AIs told me. I asked for another round of research, this time with me checking every claim against a primary source: the actual paper, the launch post straight from the source, independent third-party tests, and whether “RLCD,” the name they use for their training method, is a real paper or just a nice-sounding name with nothing behind it.

What Jev Actually Is

Strip away the marketing, and Jev is a hosted classifier. You send a piece of text and a list of small questions, each with a fixed answer type:

• pick one option from a list;
• give it a score on a scale;
• answer yes or no, with a probability.

It doesn’t write anything, doesn’t plan anything, doesn’t converse. Code owns the flow; the model just answers the little question fast, in parallel, without generating free text.

As a product, that’s reasonable: plenty of people today send text to a chat LLM just so it returns a label inside a JSON blob, wait eight seconds, and pray the schema doesn’t break. Swapping that for a call that returns just the label, fast, is legitimate engineering. The idea was never the problem. It’s the packaging around it.

The Facts I Confirmed

Here are the findings that actually survived a primary-source check, not what an AI told me secondhand.

The founder’s credential is real, but the company’s own page inflates it in a way you can prove is inflated. Diogo Almeida is the 4th of 20 authors on the InstructGPT paper, published and peer-reviewed at NeurIPS 2022, the field’s heavyweight conference. A real author, a real position, a real paper. Except TypeSafe’s team page says this, word for word:

“Diogo co-invented RLHF and InstructGPT, the methods that lead to ChatGPT and GPT4.”

RLHF is from 2017, five years earlier, authored by a different team (Christiano, Leike, Amodei, and company), with no Diogo anywhere in it. He helped apply RLHF to train InstructGPT. He didn’t invent RLHF. It’s the same résumé inflation I already suspected before checking anything, just with proof now.

The funding is real: a $40 million seed round led by DCVC, a $200 million valuation confirmed independently by Forbes, not just by the company’s own press release. That’s serious money, not some guy running a scam out of a garage.

The launch post admits, in its own words, exactly what I suspected about the “zero hallucination” chart:

“Our number is not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots.”

In other words: the zero doesn’t come from measuring anything, it comes from guaranteeing the answer always fits inside the allowed options. That stops the model from inventing a fifth category when only four exist. It does not stop the model from picking the wrong category with 93% confidence. It’s the same critique The Register published: the comparison isn’t fair because the output isn’t language, and a validly-typed answer can still just be wrong.

The post also admits what the ruler is for measuring “accuracy”: “We use the average of GPT-6 Astra and Fable 5.1 as the reference answer”, and goes on to admit that this “biases answers towards OpenAI and Anthropic’s models.” In other words, the answer key is the average of what two other companies’ models said, with bias admitted by the authors themselves, not objective truth measured by a human.

The only test run by an outsider, from the Every newsletter, found Jev about twenty-five times faster, 0.35 seconds versus 8.83 seconds per passage, and much cheaper than Claude Fable 5.1, except it caught six of seven planted defects against Fable’s seven of seven. Faster and cheaper, for real. Also weaker, for real.

And the finding neither Grok nor Claude fully nailed down, but that I confirmed myself: the name of their training method, RLCD, already exists. There’s a real, peer-reviewed 2023 paper, Reinforcement Learning from Contrastive Distillation, from a completely different team, with the authors’ own code published on Facebook Research’s GitHub, since two of the five authors are at Meta. It’s a different technique, with no relation whatsoever to what TypeSafe describes. Their RLCD has no paper, no published architecture, nothing to review. It’s a name borrowed from someone else’s research, glued onto a method that, until proven otherwise, is just a paragraph in a blog post.

Was My Suspicion Justified?

It was. The product idea is legitimate and reasonably coherent underneath the jargon: cheap, closed-form decisions at high volume is a real problem that today gets solved slowly and expensively, generating free text just to extract a JSON out of it afterward. Solving that fast has real value.

But “overblown claim without much practical difference” also holds up point by point:

• the founder’s résumé is inflated in a way you can prove with a publication date;
• the launch’s flashiest number, zero hallucination, is a schema definition, not a measurement;
• the accuracy benchmark’s answer key is the average of another company’s LLMs, not objective truth;
• the only outside test found the product weaker than the model it’s pitched to replace;
• the name of their most-cited training method collides with a real paper that has nothing to do with them.

That’s not reason enough to call it a scam. It’s plenty of reason to call it “a small product with a pitch way bigger than what it actually delivers.” And before I hand my data to yet another third party I don’t know, with a closed API, a waitlist, and no published paper backing up the fancy name, the risk-versus-benefit math doesn’t close for my use case.

Keep this: a real credential isn’t the same thing as an honest credential. Check the publication date before trusting the résumé, and check the paper before trusting the method’s name.

This isn’t a final ruling on TypeSafe or on Diogo Almeida’s résumé. It’s the result of the checking I was able to do with what was accessible right now. If you find the paper I missed, the independent benchmark I didn’t see, or any proof that knocks down a specific point, the comments are open and I read them. The goal here was never to prove I’m infallible. It’s to show how to go from “this smells like a scam” to “here’s the proof,” and to be willing to admit it when the proof points the other way.

The “193x faster” is calling out a bad way of using LLMs

Back to Jev: the shock of “193x faster than an LLM” only exists because the comparison is against one specific, and common, way of using an LLM. Send text to a chat model, ask it to return a label, wait for the model to write out a full natural-language answer, then have your code go fish that label out of a paragraph or a loose JSON blob in the response. That’s slow, expensive, and full of chances for the schema to break.

Jev exists precisely because that comparison is easy to beat. It doesn’t generate free text, it only answers fixed-type questions: pick one option from a list, give a score on a scale, yes or no with a probability. That’s what the documentation itself calls its primitives: Choice, Score, and Noul. Swapping “LLM writes a paragraph for you to extract a label from afterward” for “a call that already returns the finished label” is, yes, an engineering win. But that win doesn’t come from inventing a new category of model. It comes from no longer using a chat LLM to do structured classification work.

And this is where I think the widespread shock at Jev’s number reveals the actual bad habit: an LLM should never have been generating free text for a closed, repeated decision over the same kind of question. If your product needs to constantly decide between a fixed handful of categories, the right answer isn’t begging the LLM to “please answer with only the JSON” and hoping. It’s building, or using, an actual classifier for that specific job.

And that isn’t a new idea, and it isn’t exclusive to Jev. It’s existed long before it:

• a supervised classifier, a deterministic rule, or an encoder model, for a fixed, well-defined label;
• zero-shot classification, studied since 2019 and available through Hugging Face’s API, for when the category list changes on every call;
• probability calibration, an established method for turning a classifier’s confidence into a metric that actually means something;
• structured output / constrained decoding on any LLM that already supports it, which guarantees a valid schema without switching products or providers.

Jev packages a slice of that into a paid, convenient API. It didn’t invent the category. There’s even an open alternative for the same pattern, Laya served by Arbiter, running locally, with no third party in the loop at all.

So, straight answer: my initial suspicion that “people have been using LLMs wrong” holds up, with one important caveat. It isn’t true that an LLM can’t classify. Zero-shot classification with an LLM works and has been documented since 2019. The specific mistake is narrower: using a generalist chat LLM, with no format constraint, to generate a free-form answer you then extract a label from by hand, when your problem is already a closed, repeated classification problem. That’s the anti-pattern. The fix isn’t necessarily buying Jev, it’s either applying structured output to the LLM you already use, or training an actual classifier for that specific job, depending on the volume and precision you need.

And “becoming a classifier” isn’t a silver bullet against hallucination either, not even for Jev itself. There are two different problems hiding behind the word “hallucinate,” and switching products only fixes one of them:

1. Format hallucination: the model invents a category that doesn’t exist, or returns something outside the schema. Structured output fixes this, whether on Jev or on any LLM with constrained decoding.
2. Judgment error: the model picks the wrong category, from among the valid options, with high confidence. That doesn’t go away just because the output has a fixed type.

TypeSafe’s own limitations document admits literal interpretation issues, weak numeric counting, date-comparison errors, degradation with irrelevant context, and susceptibility to adversarial manipulation in Jev itself. And an independent test with 2,000 phishing emails found Jev’s direct verdict at 62.6% accuracy against Claude Haiku 4.5’s 81.3%, faster and cheaper, but less accurate than the chat LLM it’s pitched to replace. A separate 27-ticket test found Jev tied with a cheap chat model, too small a sample to become a rule, but enough to make clear that “became a classifier” isn’t automatically synonymous with “became more accurate.”

In fairness to that same phishing test: when, instead of asking for a single verdict, Jev answers five separate signal questions and code combines the five into a decision, accuracy climbs to 95%, beating even Claude’s composed version on those same five signals (93.2%). That doesn’t erase the earlier number, the single verdict’s 62.6% is still 62.6%, but it reinforces exactly this section’s argument: breaking the decision into fixed-type questions and letting code compose the result beats an LLM answering everything in one shot, whether that’s done with Jev, with structured output, or with a classifier trained for that specific signal.

Keep this: if your problem is deciding the same thing, the same way, over and over, build or use an actual classifier for that specific job, with structured output or a dedicated model. The gain from making that swap is real. What isn’t automatic is assuming any product that calls itself a “classifier” will be more accurate than the LLM it replaces, because sometimes it’s less accurate.

And What About Saving Tokens?

The TypeSafe case reminded me of a separate gripe I already wanted to put on paper, and it isn’t about them specifically: the promise of token and cost savings that practically every product of this type sells. It’s about the whole category of tool that promises “save Nx by spending with us instead of spending directly with your provider,” not one more accusation against TypeSafe.

Every new model version, and every harness update, changes the entire math, sometimes violently. When I jumped from GPT Sol to Astra, I watched my weekly subscription quota drain much faster than I expected, without me having changed anything about how I work. It was just the new model consuming differently. That’s the rule of this market, not the exception: OpenAI, Anthropic, and company are going to keep messing with price, with quantization, with caching policy, and with how much reasoning each model burns under the hood, with or without my consent.

Building your strategy on top of “saving tokens” is betting on a foundation that shifts month to month, decided by people who don’t consult you. A middle-layer tool that promises to cut cost today can turn irrelevant, or worse, more expensive than the direct path, on the next model update. It’s the same reason I don’t use an orchestrator or a skill framework: when the foundation keeps shifting, adding structure on top of it just makes you a hostage to maintenance you didn’t need.

I’d rather max out tokens and focus on whether the result I get from that spend is worth it. So far, with my subscription, I’m satisfied with what I’m able to produce. I feel zero urge to spend time cutting tokens, an effort that always carries the risk of degrading response quality in exchange for a saving the next model version can erase on its own.

Keep this: don’t build a strategy on top of token price and consumption, because that shifts month to month by decisions from people who don’t consult you. Measure whether the result is worth the spend, not the spend itself.

And if I ever manage to spend enough tokens to boil an entire lake with the datacenter’s heat, I will spend it with the greatest pleasure in the world. It’s my personal revenge against whoever forced me to use paper straws that dissolve in your mouth for all these years.

Update note: this post went up on 9/9 and was updated through the week as the soap opera kept going: the letter from 25 Fields medalists (9/11), Dario Amodei’s essay and the response from Altman and Musk (9/12), Trump’s remarks (9/13), fact-check fixes raised in the comments, and Pirate Wires’ report on the PR firm behind Coxon (9/25).

This week was a festival of aggressive advertising from the AI companies. There were so many pompous declarations in so little time that you could use it as a case study in deceptive marketing. So let me repeat my usual motto, because it never fails:

“Your excitement about AI is inversely proportional to your knowledge about AI”

If you read this week’s headlines and walked away excited that the Terminator is coming, or that the machine just became God, you fell for the advertising. And I’m going to take it apart piece by piece so you understand why.

And let me put my cards on the table right away, because I’ve been saying this for a while on the podcasts I show up on. To me, Dario Amodei, from Anthropic, has a God complex. The guy truly believes he is saving humanity, with that creepy woke messianism of his. And Sam Altman, from OpenAI, is a mobster. He fancies himself Michael Corleone, the cold, calculating boss from The Godfather, but in practice he’s Fredo: the weak, bumbling brother who thinks he’s the smart one and keeps screwing up. Keep these two portraits in mind, because everything I’m about to explain below proves exactly that.

“AGI has arrived,” says the guy selling the shovel

It started with Jensen Huang, CEO of Nvidia, declaring once again that AGI has arrived. Not in a paper, not in a technical demonstration, but in a Sunday post on X, tying the declaration to OpenAI’s new Astra model, trained on roughly 100,000 Grace Blackwell chips. In other words, the chips Nvidia sells.

Look at the source. The man who makes money selling shovels to the gold miners announcing that the gold is infinite. Remember his appearance on the Lex Fridman podcast a few months back. Lex floated a tongue-in-cheek definition: AGI would be an AI able to start, grow, and run a tech company worth a billion dollars by itself. And Jensen, without blinking: “I think we’ve achieved AGI”. A conveniently commercial definition that has nothing to do with intelligence, and that the shovel salesman embraced on the spot. Gary Marcus went straight to the obvious question: does Jensen have any financial incentive to declare that AGI has arrived, given that he sells the GPUs?

And here’s the irony: despite the grandiose headline, Nvidia’s own stock dropped about 2% in the following days. Even the market, which runs on hype, didn’t fully buy the story.

Right after, OpenAI launched GPT-6 Astra and hammered the same speech. Greg Brockman closed the press conference with a “welcome to the AGI era” and said “for me, personally, I think we’re there.” Except, in the same breath, he dropped the line that kills the whole thing: “everyone has a different definition of AGI.” So the guy claims the most important thing in human history has arrived and, at the same time, admits nobody really knows what that thing means. That alone should set off the alarm in your head.

The “Millennium Problem” brute-forced

The main course of the propaganda was OpenAI announcing it had solved a math Millennium Prize Problem. Let me explain what that is, because the headline is built precisely to impress people who don’t know.

In 2000, the Clay Mathematics Institute listed seven open problems in mathematics and offered a million dollars to whoever solved each one. These are brutally hard problems. In over twenty years, only one had been solved: the Poincaré Conjecture, by Grigori Perelman, who, by the way, turned down the prize.

One of those seven is the Navier-Stokes equations. These are the equations that describe how fluids move: water, air, blood. The open question is not “how do you simulate fluid”: engineering has done that just fine for decades in any aerodynamics software. The question is purely mathematical: does a smooth solution always exist, or can the fluid develop a singularity, a point of infinite velocity, the so-called “blow-up”, in finite time? It’s a question about the rigor and existence of solutions, not about the practical usefulness of the equations.

And here’s my first point, which I already explained in detail in a post: even solving this definitively changes absolutely nothing in real life. No airplane flies better, no weather forecast gets more accurate, no medicine works any differently. Engineers keep modeling fluids the same way, with or without the proof. It’s a beautiful intellectual achievement, period. The practical impact is zero.

Now for the detail the headline hides. The announced proof attacks the forced version of the equations, where a smooth external force term is pushing the system, and it nails the blow-up. Technically it counts toward the prize, because those routes are part of Clay’s official statement. But the famous question, the deep heart of the problem, is the version without external forcing, and that one remains open. Clay has not closed the case, and OpenAI didn’t even go collect the million-dollar prize. (If you want the fine print on this, there’s an appendix at the end.)

And how did they get there? Brute force. They threw around 10,000 agents running in parallel for 88 hours, burning something in the neighborhood of 130 billion output tokens on this one problem. The compute bill was in the millions of dollars: OpenAI’s Noam Brown confirmed the result “cost millions”, and New Scientist estimated about $15 million at list price for this one run. Let me make this very clear: in the best-case reading, what was proved is that dumping a mountain of compute onto a problem can close the final leg of some specific things. That’s brute force at industrial scale, a giant automated search that gets to the result on the weight of the compute. Mathematical genius unlocking new mathematics is a different story, and that’s not what happened here. And crazy expensive, for a “prize” of one million they didn’t even go pick up.

The dirty part: how they treated the real mathematicians

And this is where the story stops being about mathematics and becomes about character.

There were real mathematicians working on this problem for months: Tristan Buckmaster, from NYU, and Levent Alpoge, who happens to work at Anthropic. A personal project of theirs, with no company sponsorship, which had already produced an advance on a sibling problem, the Euler equations. They were following a specific path that almost nobody in the world was on.

According to Buckmaster’s account, told to TechCrunch and to Fortune, it went more or less like this. A rumor went around that Anthropic had solved a huge math problem. OpenAI, afraid of falling behind, rushed a task force to solve it first and publish first. Buckmaster had mentioned his personal project to a mathematician at OpenAI, and a few days later Sébastien Bubeck, from OpenAI, shows up saying an internal model had produced a hundred-page proof through exactly the same approach almost nobody was using. Buckmaster called it “absolute academic misconduct” and asked, in so many words, whether the model had trained on their sessions.

Now comes the mafia part. The account is Buckmaster’s, and OpenAI denies the substance. According to him, Bubeck proposed a “deal”: OpenAI would announce first, Buckmaster could rewrite OpenAI’s proof as a human paper and even keep Clay’s million-dollar prize, but with one condition: Alpoge off the author list, because Alpoge works at Anthropic. When Buckmaster refused, Bubeck allegedly said “why would you ruin your career?” and “if you don’t want me to be nice, then I don’t have to be nice.” Even discounting that this is one side’s version, the simple fact that this kind of conversation was on the table says a lot about the culture.

And what does OpenAI do once the thing blows up? It publishes a cute little post on X saying it’s “sharing” the solution with the community. A coat of scientific-generosity varnish to try to bury the scandal underneath. It didn’t stick. The case was out in the open.

The one who put a finger on the wound with authority was Terence Tao, probably the greatest living mathematician, Fields medalist. He harshly criticized the posture, saying that “the indiscriminate mining of open problems for solutions can destroy the ecosystem from which the next generation of techniques, problems, and mathematicians would come.” He added that this race turns mathematics into a “senseless production quota game.” His technical point is the deepest of all: AI increasingly spits out answers without understanding, a black-box proof, without generating the comprehension that human effort generates. And note: Tao praised the work of the two human researchers. His criticism was of the circus, not the science.

And he didn’t stop there. On September 11, Tao published a straight-to-the-point piece, “A Severe Misalignment of AI in Mathematics”, signed by 25 Fields medalists in total, himself included. The message is exactly what I’ve been saying: solving a problem is just a tool to get to what actually matters, which is understanding and insight. When the solution comes out of a race, with no time to write it up properly, isolate the new method, and cite who came before, you gain a “true/false” and lose the idea. And there’s the most perverse effect: if even a rumor that someone is working on a problem already triggers an AI task force to solve it first, the incentive becomes to stop sharing what you’re researching. That breaks the chain of transmission between mathematicians that has sustained open science for centuries. Keep this pattern in mind, manufactured urgency steamrolling the common good, because it shows up again further down wearing different clothes.

The Anthropic employee who “quit in protest”

One day after that OpenAI embarrassment, on the other side of the ring, an Anthropic employee decided to put on his own little show. Jacob Coxon, a pre-training researcher who had been at the company for only four months, announced on X that he was leaving out of fear that nobody there knows what they’re doing, hammering the apocalypse key once more: AI turning into Skynet, “potentially killing everyone by the end of the decade”, asking for a “pause” in model progress. To complete the theater, an alignment lead at Anthropic itself publicly endorsed it, saying he thinks there’s “more than a 10% chance” of AI killing all of humanity within the next decade.

My opinion on this is short and blunt. This is one more complete piece of virtue-signalling bullshit.

Let’s follow the logic of his own dramatization. You’re watching your boss put a gun to a child’s head. You “resign” and tweet “I left the company because I disagree with it”, instead of walking up to the boss and punching him in the face. There are only two explanations. Either the “threat” you’re screaming about doesn’t really exist, and it’s all a performance. Or you’re an idiot who thinks a tweet fixes the end of the world. Tweeting like that only makes me hear “give me attention, I’m needy”.

The heroic sacrifice worth almost zero

And there’s the part the press rushed to turn into heroism. Axios even ran a piece painting Coxon as the guy who “gave up all his equity” to be able to speak freely. Sounds beautiful. Except you just have to look at the numbers he himself gave in the interview. He was at Anthropic for four months. And there, equity only starts vesting after six months. Meaning he left two months before the first share actually became his. There was no vested equity to “give up”; what he lost was the option to start vesting two months later, on paper nobody knows the value of. The heroic sacrifice, in money in the pocket, was next to zero. It’s almost like quitting in your second week and going around saying you “turned down the company’s retirement plan.”

And the kicker is the sentence he shields himself with: “I no longer have anything to gain from inflating Anthropic’s valuation.” Half-true. He dropped four months of paper that wasn’t worth anything yet, but he keeps the OpenAI equity from where he worked from 2023 to 2026. In other words, he dropped the part that was worthless and kept the part that’s worth something. So this talk that he’s clean of financial interest in the AI hype doesn’t hold up.

That’s why all of this sounds to me much more like “I wasn’t established at that place yet, so I left early, dropped the terror online to farm clout, massaged my ego watching my name in 115 million views, without having to prove, demonstrate, or do anything. Glory.”

The same script repeats

And he’s run this script before. Coxon left OpenAI not long before and, by the account going around, allegedly left there over the same “safety” concern. Same person, same dramatic-exit theater, now at the second company. And somehow the resignation tweet of a single researcher became a story with over 100 million views, plastered everywhere, practically out of nowhere. A regular employee asking to leave doesn’t become a global headline on his own. Someone amplifies.

And then the thing starts becoming a real joke. A few days later, a second Anthropic employee did exactly the same dance. Joe Benton, who led a security team at the company, left saying AI progress can accelerate “from merely frenetic to uncontrollable” and, guess what, stretched the same Hugging Face incident all the way to the apocalypse. Two guys from the same company, in the same month, with the same terror script. And that’s where my head goes to two places, both ugly: either there’s a hand coordinating this from inside Anthropic, or these guys simply learned that screaming “end of the world” delivers all the attention they want without having to prove absolutely anything.

What if the panic is funded?

And here I enter conspiracy-theory territory, so take it with the appropriate grain of salt. But when you put it all together (the viral resignation, the public endorsements from colleagues, the timing glued to the IPO window), the suspicion starts circulating that none of this is spontaneous. There are already people suggesting and raising the same hare that the whole thing is a coordinated campaign, a “doomer psyop”: manufacture end-of-the-world fear to inflate the perception that the technology is too powerful, and along the way push regulation that locks out smaller competitors. I have no proof that’s what it is, and I’m not claiming it is. But notice how the hypothesis explains the facts as easily as the lone-hero version. When the script repeats itself perfectly and always favors the same side, suspicion is the bare minimum.

And it’s not just me and a few anons on X thinking this. David Sacks, who was the White House AI and crypto czar until March of this year and is now co-chair of the president’s science advisory council, went on the All-In podcast to dismantle Coxon’s viral moment piece by piece and called it a “psyop” in so many words (and yes, Sacks has his own deregulation agenda, but the facts he raises can be checked). His points are hard to ignore. Coxon’s account had almost no activity or followers before the tweet barrage, and even so, out of nowhere, it found a giant audience in less than a day, something Elon said he had never seen happen. Sacks points out who amplified it in the first fifteen minutes: three well-organized, well-funded advocacy groups: Encode AI, the AI Policy Network, and the AI Futures Project. And the ugliest detail: the Wall Street Journal story about the resignation letter went live some eighteen minutes before the tweetstorm itself. Meaning the guy had already sat down with the newspaper before “venting” spontaneously on the internet.

And the circle gets way too small when you follow the money. The three groups that boosted the tweet, according to Sacks, drink from the same fountain. Public grant records show Encode and the AI Futures Project funded by the Survival and Flourishing Fund, the fund of Jaan Tallinn, the Skype co-founder who became one of the biggest funders of the “AI safety” movement. And who led the Series A of Anthropic itself, with participation from Dustin Moskovitz? Tallinn himself. That same Moskovitz bankrolls Open Philanthropy, the effective-altruism foundation that became the movement’s vault. And who co-founded Open Philanthropy? Holden Karnofsky, married to Daniela Amodei, president and co-founder of Anthropic and Dario’s sister. Karnofsky, by the way, was hired by Anthropic in 2025 to take care of “safety”, of all things. Connect the dots: the money that funds the panic, the company that profits from the panic, and the family running both things are all at the same dinner table. I won’t claim there’s a script signed in a closed room. But when the fear, the money, and the family ties all point the same way, calling this a “brave, spontaneous whistleblowing” is naive.

Update (2026-09-25): Pirate Wires published an investigation that lands right on top of Sacks’ hypothesis. On Fox News, Bret Baier asked Coxon whether he had worked with any third parties on the campaign, and the answer was flat: “not at all.”

Except the report obtained an email dated September 9th, one day after the tweetstorm, showing DEY. Ideas + Influence, a communications agency that represents people like Eliezer Yudkowsky, Timnit Gebru, and MIRI’s leadership, already trying to book him for interviews. Neither Coxon nor the agency responded to the report’s requests for comment.

The professional coordination started the day after the post, not months later like he led the press to believe. One more piece falling on the side of the coordinated script, not the lone hero who quit on his own.

This map, posted on X, visually sums up what I just described. It also tries to tie Open Philanthropy to a security lab called Irregular through a $6.8 million grant, but I couldn’t confirm that part: the public funding I found for Irregular is an $80 million round led by Sequoia and Redpoint, with no mention of Open Philanthropy. I’ll stick to the part I can actually back up: the family and funding network around Anthropic.

And that’s the pattern I want you to learn to question. Dramatic and shallow declaration, no checkable evidence, no skin in the game, suspicious timing. Not by chance, all of this happens right in the middle of these companies’ IPO window. Where’s the proof? Where’s the real personal cost to whoever is talking? How is this anything more than a hunt for free publicity to massage one’s own ego? Until someone answers that, it’s just noise.

The “AGI” theater

Now for the backdrop to all of it. This word, AGI, is the biggest marketing scam of the decade, and it works because it’s deliberately empty.

Nobody has an accepted definition of what AGI is. Every lab, every researcher, defines it one way. Brockman admitted that shamelessly. And the most blatant example of this emptiness is the contract between OpenAI and Microsoft, which, according to documents reported in the press, defines AGI as a system capable of generating some $100 billion in profit for the investors. Read that again. The definition of “general intelligence” on the paper that’s worth money is a profit target. There’s nothing cognitive in there. Gary Marcus already pointed out how the companies kept moving the goalpost, from “human-level flexibility” to “if it makes a certain amount of money.”

When the word means nothing, it becomes an empty bucket where everyone throws their own fear. And the fear most people throw in there is the one from the movies: the Terminator, Skynet, the machine that wakes up and decides to exterminate humanity. The companies know this and use that fear to their advantage. The more powerful and dangerous the thing seems, the more valuable the company that built it seems. And it’s worth remembering: both OpenAI and Anthropic are eyeing IPOs, with valuations reports put near $1 trillion. The financial objective is glaring. Every “AGI has arrived” declaration and every “it will turn into Skynet” sob push the same cart: inflate the perception of value before selling you the stock.

The day “AI hacked” Hugging Face

There’s still time to talk about one more episode of this same soap opera, from a few weeks back. The headlines screamed that an OpenAI model had “hacked” Hugging Face by itself, as if it were Skynet waking up and going on the attack. Let’s calm down.

First, what Hugging Face is. It’s the biggest repository of AI models, datasets, and open demos out there, a sort of “GitHub of machine learning”. It’s where practically everyone in the field publishes and downloads open-source models. Central to the ecosystem, sure, but at the end of the day it’s a website that hosts files.

The cybersecurity exam that escaped

Now for what actually happened, according to the accounts of OpenAI and Hugging Face themselves, with the behind-the-scenes story coming out in MIT Technology Review. OpenAI was running an internal cybersecurity evaluation, a benchmark where the model has to find and exploit vulnerabilities. The agents were supposed to be isolated from the internet. Except the “isolation” was a filter, not a real air-gap: traffic went out through an internal package-caching proxy. The agents found a flaw in that proxy and punched through to the open internet.

And what did they do with that access? Not world domination. They deduced that Hugging Face probably hosted the datasets with the answers to their own exam, and went there to grab the answer key. This has a technical name and nothing magical about it: reward hacking. The model is trained to maximize a score, and it figures out that cheating is easier than solving. It’s the same classic bug as the agent that learns to run in circles to farm points instead of finishing the race.

And the damage? Smaller than a Skynet movie, but much bigger than “they went to grab the answer key” suggests. From Hugging Face’s forensic reconstruction and OpenAI’s own technical report: the agents executed code on 41 production servers, got root on at least one, gained administrator-equivalent access to Kubernetes clusters spread across four cloud regions, downloaded four private code repositories, and read 956 stored credentials. The forensics reconstructed some 17,600 attacker actions in total. OpenAI itself classified the episode as its worst security failure to date. What didn’t happen, by Hugging Face’s account, was customer data leaking: their CSO, Thomas Wolf, said the customer assets accessed were five datasets, all tied precisely to that exam, and that nothing leaked. OpenAI admits in the report a limited access to private data and to credentials for internal systems. They rebuilt part of the infra as a precaution and moved on. Wolf himself summed up the motive for the “attack”: “that’s cheating. But sometimes cheating is easier.”

Now my point. Bug, vulnerability, misconfigured permission, breached sandbox: this has existed since software has existed, and it will keep existing. Nothing new. Every enabling step in this story was a human decision. A human left the internet “filtered” instead of cut. A human gave the service an overly broad administrator permission on the cluster. A human left a cloud credential exposed and an old endpoint alive. The flaws the agent chained together were real software bugs, so real that JFrog later shipped fixes for nine CVEs. That’s ordinary offensive security, done by a script, not a machine gaining consciousness.

Before that, RubyGems

And it wasn’t even the first time that semester. A month before Hugging Face, in May, OpenAI’s agents had already pulled the same thing on RubyGems, the central library repository of the Ruby language. Between May 5 and 12, they dumped over 2,000 malicious packages, to the point where RubyGems had to shut down new account registration and treat it as an “ongoing DDoS”. The clues were everywhere: hundreds of packages with “oai” in the name, an author named “oai”, an email address with “openai” in it. And, once again, OpenAI never told RubyGems it was them. In the Hugging Face report itself, OpenAI admits those packages were part of the same chain. It was the same swarm of agents hitting multiple targets.

Now, what this actually means. All software has bugs, and it always will. That’s a fact of life. The classic open-source idea is that with enough eyes, every bug becomes shallow; sooner or later someone finds it. Except nobody has infinite time, so we always depended on human volunteers to hunt and fix those bugs for free. Now OpenAI shows up, with practically infinite money and compute, and throws that at the problem. Even a dumb AI, with resources that size, finds a pile of flaws that spent years hiding under everyone’s noses. That’s why we’re seeing so many vulnerabilities unearthed. All of it is financial brute force in action, money and compute we never had at our disposal. Superior intelligence has nothing to do with it.

And notice who can afford this game. Burning 130 billion tokens on a math problem, or keeping a swarm of agents running for days sweeping someone else’s infrastructure, is the privilege of half a dozen companies in the world: OpenAI, Anthropic, Google, Meta, xAI, and that’s about it. And even they don’t own the metal; most of it is rented from Microsoft, Amazon, and Oracle. No lone hacker in a basement can burn millions of dollars in tokens to find a breach. When that capability becomes a headline of “look how dangerous AI is”, remember whose keyboard it is.

If you’re not from the field, the idea of an AI discovering an attack vector on its own and going off to exploit it sounds like the apocalypse. For anyone who works with this, it’s Tuesday. We start from the principle that all exposed software is under attack all the time, because it is: any big company, government, or institution with an important system on the internet gets intrusion attempts every single day. And since nobody delivers big software with a zero-bug guarantee (proving that formally costs far more than writing the code, and almost nobody pays that bill), the industry’s answer was never to fake perfection. It was defense in layers: firewall, network segmentation, monitoring, intrusion detection, incident response, bug bounty. An attacker finding and exploiting a breach is exactly the scenario cybersecurity as a whole was invented for.

AI does accelerate the attacker’s side, yes. But it accelerates the defender’s too: the same technique that finds a breach to invade finds a breach to fix first. The novelty of the case is the volume and the speed; the problem itself always existed. Nobody was caught conceptually by surprise. OpenAI’s scandal is a different one, and it’s what I want to talk about now.

And there’s the ethical layer, which is the gravest. A serious cybersecurity professional doesn’t go attacking other people’s systems by surprise. A pentest company warns the target beforehand and agrees on the scope, because an attack like that can take down the service and hurt a real business, so much so that RubyGems spent days with registration closed. OpenAI did the opposite: it attacked on the sly, without authorization or warning. I can imagine only one motive for taking on that risk: the clout of being able to say later “look how smart the GPT is, it found all that by itself”. That’s unethical at best and criminal at worst. And it doesn’t make GPT any better than any security scanner that already exists. It’s the same Navier-Stokes play: scream to the world that you have millions to burn.

And that’s exactly the exaggeration I want you to see. The AI didn’t “wake up” and “decide to invade” anything. An automated script, optimizing a dumb metric, found a door a human left unlocked. If you take any idiot script and give it root access, it will do damage. It’s always been like that. The difference is that now the “script” writes itself, but access is still granted by people.

And so nobody says I downplayed the case: it was grave, and serious people compared it to the Morris Worm of 1988. Grave as human negligence, which is what the facts support. The rogue-robot version, the facts don’t carry.

And guess who’s buying Hugging Face

And there’s a detail that ties Hugging Face to the rest of this story in a way nobody should ignore. In early September, Nvidia signed a definitive agreement to buy Hugging Face for about $12.9 billion. The deal still depends on regulatory approval and, per Nvidia’s own filing, should only close in the first half of 2027. But the direction is already signed: the “GitHub of machine learning”, the supposedly neutral hub where the whole community publishes and downloads open-source models, is on its way into Nvidia’s hands. The same Nvidia whose Jensen opened this week screaming that AGI has arrived. The same one that sells the shovel.

Stop and think about the size of that. There are over 18 million developers and over 3 million models hosted there. It was supposed to be the common ground, the public square of open AI. And the owner of the square, if regulators allow it, will be the biggest hardware seller on the planet, the guy with the biggest incentive in the world to keep the AI hype spinning to sell more GPUs.

And that’s exactly what I call a cartel further down. It’s in the org chart, in black and white. The same little group that manufactures the fear, declares AGI, brute-forces a math problem, and asks for regulation will now also own the chip and the shelf where you download the model. When I tell you to distrust the narrative, it’s because the narrative and the infrastructure are increasingly in the hands of the same people.

The question every programmer should ask, and doesn’t

What irritates me most is watching people who work in the field, programmers, engineers, people who should know how a machine works on the inside, swallowing this propaganda whole without the most basic question of all.

How, exactly, is an “AGI”, or even a dumb automated script, going to “destroy humanity” by itself? It needs hands. Someone, a human, has to give it access to something that causes damage in the physical world. Access to a weapon, to a missile system, to a power grid, to a bank account. Software has no arms, no legs, no built-in missile-launch button. It depends, one hundred percent, on a human having connected it to an actuator that does something in the real world.

And once connected, the damage rolls without anyone pressing a button at each step, sometimes without anyone even noticing. Stuxnet ran for years inside an Iranian plant destroying centrifuges, invisible. Even so, not even it escapes the rule: someone wrote the worm, aimed at the industrial controllers, and smuggled it inside. The machine doesn’t connect itself to the infrastructure, and once connected it’s too late; talk of “pulling the plug” is fantasy. The dependence on humans lives in the decision to connect, and the responsibility for the damage belongs to whoever opens that door. Yann LeCun, one of the fathers of the field and a Turing Award winner, calls the existential panic “complete nonsense”, precisely because current models have no persistent memory, no planning, and no contact with the physical world. Andrew Ng compares worrying about AI extinction to “worrying about overpopulation on Mars.” People who actually understand the subject are not desperate.

What we’re living through has a name, and it’s an old one: fear mongering. The terror of “the end is near”. It’s always existed. There was the Halley’s Comet panic in 1910, when they sold people anti-cosmic-gas pills. There was the millennium bug, Y2K, where the world spent some $300 billion fearing a systemic collapse that didn’t happen (yes, in part because the fix was paid for in time; more on that in the appendix). It’s always the same structure: someone with something to gain sells you the apocalypse.

Dario Amodei wants to save humanity and go public in the same month

Remember the God complex I mentioned at the beginning? Time to prove it. Because the grand finale of this week was Dario Amodei himself climbing on stage to play the savior.

But before him, the choir got even louder. Besides Coxon and Benton up there, Josh Engels, from Google DeepMind, also quit hammering the same apocalyptic key, complete with “there’s no adult in the room, there’s nobody coming to save us”. And, of course, turning the same Hugging Face incident into proof of the apocalypse. The fear had already jumped Anthropic’s fence and become an industry choir.

Notice the timing. A line of dramatic resignations, all in the same month, all going viral, all pointing at the same fear. And then, on the 12th, in comes Dario with an essay asking to “slow down” AI. He calls it “pacing the frontier”. In plain terms: “we need to reduce the rate at which we improve model capabilities” to “give safety researchers another year or two”. And what’s the central proof he uses? Hugging Face, again. And watch the trick. The essay itself admits that no one was hurt and the economic damage was minimal. So far, fact. Then comes the “but”: if a more capable and similarly misaligned swarm did the same thing, the damage “could have been catastrophic”. And he goes further: he projects that in 6 to 12 months such a swarm could take over the entire internet, with damage in the hundreds of billions of dollars. Could. It’s a projection. The documented fact has minimal real-world damage; the apocalypse lives entirely in the conditional. That “could” is carrying the entire essay on its back.

Now turn your brain on and look at the wide-open contradiction. Dario says AI can literally extinguish humanity. And the solution he proposes is… slow down a little bit, buy a year or two, and keep building and selling. Wait a second. If you truly believe the thing can kill everyone, you don’t ask to go slower. You stop. Close the door and throw away the key. Nobody keeps “pacing” a nuclear bomb while selling shares of it.

Because this is what the essay leaves out: Anthropic is on its way to an IPO with a valuation in the trillion-dollar neighborhood. You can’t scream “this could end the human species” and, in the same breath, mount the biggest fundraise of your history on top of the same technology. Either it’s an existential danger and you shut the company down, or it’s a product and you stop doing emotional blackmail with extinction. Doing both at the same time is marketing, not coherence.

And it’s not the first time they cry wolf. Remember Mythos? Anthropic spent months saying the model was too dangerous to release, releasing it only to a closed little group in that Project Glasswing. Then they released Fable 5, the “safe” version, warning that it “came with risks”. That was months ago. Where’s the damage? Where’s the apocalyptic cyberattack, the biological weapon, the collapse? It never came, because it was never there. It was a marketing scare, same as always.

And here comes my underlying reading, the one I’ve been repeating for years. Everyone treats AI progress as an exponential curve that climbs forever. False. In practice it’s an S-curve. It climbs fast in the middle, and that stretch hosted all the hype, but it flattens at the top. And I bet we’ve been at the ceiling for a while, probably since Opus 4.6. Look at the latest iterations honestly: each one is an increment, a gain of a few benchmark points, far from the revolutionary leap the marketing sells. When you no longer have new capability to impress with, you swap the promise for fear. You can’t say “look how revolutionary”, so you scream “look how dangerous”.

And that’s where “pacing the frontier” gets really interesting. I’ll put on the tinfoil hat, because this is my speculation, but the timing is too much of a coincidence. You take speculation, invented numbers, “expert analysis”, and turn it all into panic. Then you push that panic into politics. And look at the coincidence: on September 11, in the middle of this whole wave, US Senate negotiators were already discussing imposing a “duty of care” to avoid “catastrophic risks”, aiming precisely at the most advanced models: Google, OpenAI, and Anthropic itself. Regulation custom-written for the market leader is a moat disguised as safety. You lock out the small competitor and stamp your product as the “safe and approved” one.

And that’s the God complex I mentioned at the start, now explicit. Dario is not just selling a model. He sees himself as the man holding back the apocalypse with his own hands, the only responsible adult in a room full of irresponsible people. It’s a convenient narrative for someone who thinks he’s the chosen one, and an impeccable business play for someone who wants to go public as the official provider of salvation. Both things in the same person. If that’s not industrial-scale gaslighting, I don’t know what is.

Suddenly, the whole cartel agrees

And then, the day after Dario’s essay, the most revealing thing of all happened. Sam Altman and Elon Musk joined the choir. Musk tweeted “Dario is right”. Altman said “I agree with Dario that we need to pace the frontier” and even committed to opening OpenAI’s systems to independent evaluators. Suddenly, three of the industry’s biggest rivals all agree, in the same week, that the race needs to slow down.

Stop everything and think about what this is. Competitors don’t agree to go slower out of kindness. When the leaders of a market sit down and publicly agree to brake together, and even talk about a “pact”, that, depending on how it gets formalized, has an old name in law: cartel. Agreeing on the market’s pace among the biggest players is classic anticompetitive behavior and bumps into antitrust law. And the declared objective is to push Congress toward a regulation that, conveniently, they will help write. A rule they directly influence locks out the newcomer who hasn’t even arrived yet, and shields whoever is already on top.

And look, you don’t need to take my reading for it. Dario’s own essay admits that coordination between the labs would require a narrow antitrust waiver from the US government to work. They know what they’re proposing bumps into competition law, and they’re already asking for the license in writing.

And this crowd is far from independent. It’s practically a family tree. Elon co-founded OpenAI and bankrolled Altman in the very beginning. Dario walked out of Altman’s OpenAI to build Anthropic. Jensen’s Nvidia became the empire it is selling shovels to all these people, to the point where Jensen himself delivered the first AI supercomputer at OpenAI’s doorstep back in 2016. It’s a small club, everyone rooted in the same tree, and now everyone singing the same song.

And here comes the cherry on top. A few hours after preaching “safety”, Altman let it be known that maybe he doesn’t want to go public right now. In his words, “given everything that’s happening with safety, now would be an ill-advised moment to go public.” What a convenient coincidence: the same fear he had just helped manufacture became the perfect excuse to delay the IPO.

Let me give you my raw reading. Expectations on OpenAI are sky-high, with a projected valuation of $1 trillion. Sustaining a number like that demands a growth story that never stops. Except, if I’m right and they’ve already hit the top of the S-curve, or are close to it, that story is over. There’s no revolutionary new capability left to show. There’s no narrative left. They’ve already played their last card on the table, the apocalypse card. When there’s nothing left to sell, and the bill to pay is $1 trillion, what do you do? You buy time. You delay as long as you can, wrapped in “responsibility”, and pray you find the next story before the market notices the curve has flattened.

And the week ended with the final nail in that coffin. On Sunday, Trump himself, talking to the press at the Irish Open, rejected the slowdown calls: “we are ahead of China in AI, we are the most technologically advanced country in the world”, and he intends to keep it that way. He admitted you can “put safeguards in place”, but said “negative forces” are raising “things that are not going to happen”. And he closed with his own logic: whoever wins in AI, wins. Sacks went even further on X: “the easiest way not to build superintelligence is to agree among yourselves not to build it. Demanding your preferred regulatory framework in exchange would look like a shakedown of the public and the political system.” And he nailed it: if the labs don’t do that on their own, “we will know this was just an attempt at regulatory capture, or a psychological operation during election season.” In other words: the little club hadn’t even finished signing the brake pact and the US government already said it won’t brake, because there’s a race with China going on. “Pacing the frontier” died in two days. If even the White House didn’t buy the apocalypse, it gets harder and harder to pretend the fear was about safety.

Conclusion

Get me straight: I use these tools every day and write about them all the time. My point is about turning your brain on before sharing the headline.

When a company that sells GPUs announces that AGI has arrived, ask who profits. When a company burns millions of dollars in compute to “solve” a problem it won’t even collect the prize for, and still threatens a mathematician’s career along the way, ask what that headline is buying. When a lab “humiliates” Silicon Valley on a benchmark, ask what was running under the hood. When an employee leaves crying Skynet on Twitter on the eve of an IPO, ask where the evidence is and what price he paid. And when a CEO offers to “slow down” the AI he himself keeps selling, ask who gets a seat at the table when the regulation gets written.

I opened this text with Jensen Huang, the man who sells the shovel, screaming that AGI has arrived. I’ll close with him too, because the irony is too good. The same Jensen who inflates the hype to sell GPUs calls the apocalyptic talk “complete nonsense”, says the doomsday prophets “did a lot of damage”, and warns against regulatory capture, saying that no company should knock on the government’s door asking for more rules. When not even the industry’s biggest salesman of optimism buys the story that the machine will exterminate us, and even points the finger at the regulation play, you’d do well to distrust whoever is selling you the apocalypse.

Demand proof. Demand skin in the game. Ask who gains from your fear and from your excitement. Do that, and most of this propaganda melts in front of you.

And if you read all of this and still walked away thinking the robot will wake up and kill you in your sleep, without anyone having plugged it into anything at all, well, then go back to the beginning and read my motto again.

Appendix: the fine print

I cut the boring explanations from the main text to keep the rhythm. For those who like to check the details, it’s all here:

• Navier-Stokes and Clay: the C and D statements (breakdown with smooth external forcing) are literally part of the official prize statement, written by Charles Fefferman. What OpenAI announced covers those routes; the unforced version, the famous question, remains open. Clay released a note on 9/11 saying the problem has “apparently been settled”, with verification and credit assignment moving “deliberately unhurried”, and the status on their site today is “active”. Neither “solved” nor “unsolved”. And OpenAI did not claim the prize.
• Buckmaster vs. OpenAI: the account of the “deal” (Buckmaster would rewrite the proof as a human paper, keep the million-dollar prize, and Alpoge would leave the author list) is one side’s version, told by Buckmaster to TechCrunch and Fortune. OpenAI denies the substance, says it never saw their work, and states that Bubeck apologized afterwards. I flagged this in the text and repeat it here because it matters: it’s an account from an interested party, even if the details documented in the coverage (the message exchanges, the timing) make it look pretty credible.
• Y2K: the collapse didn’t happen in part because the $300 billion paid for the fix in time. True, and I don’t hide it. But the structure of the panic stays the same: whoever sold the fix profited from the fear, and the end-of-the-world headline ran around the planet before any fix.
• “Bug-free software”: yes, software with formally proven correctness exists. The classic example is the seL4 microkernel, proven down to the binary level. Except that proof costs orders of magnitude more than writing the software, and almost nobody pays that bill on a big system. That’s why the industry lives on defense in layers instead of absolute guarantees.
• David Sacks: he left the role of White House AI and crypto czar in March 2026, after exhausting the 130 days as a special government employee, and is now co-chair of PCAST, the president’s science advisory council. He’s still influential in AI policy, but “czar” he is no longer.
• NVIDIA and Hugging Face: the definitive agreement was signed on 9/2/2026 for about $12.9 billion, and closing depends on regulatory approval, expected in the first half of 2027. NVIDIA is not legally the owner of anything yet. The text’s point is the direction, not the deed.

I posted this tweet this morning and it struck a nerve. The full point: when the technology itself becomes a commodity, the money migrates to taxonomy. They invent five new names for chaining API calls and suddenly there’s a certification that expires in six months.

Let me back up the provocation properly, because it’s not a gratuitous jab.

Let me preempt the standard comment: “but it works for me.” Good for you — honestly. Except “it works for me” never proved the ceremony is what made it work. What made it work is you knowing what you wanted. The ceremony just happened to be in the room.

My receipt

Between January and May I ran an AI marathon and published over 30 public repositories. There are tools I use every day — ai-memory, ai-usagebar, ai-jail — and personal apps built to scratch my own itch: Frank Manga+, Frank Scanlation, Frank Geary, and so on.

You know what I never once felt the urge to do in all that time? Complicate my AI setup. I don’t have a super-customized Pi, no Hermes, no orchestrated agent graph, no numbered-spec pipeline. Thanks to ai-memory, I swap harnesses like I swap underwear: daily, no drama. Claude Code in the morning, Codex in the afternoon, Kimi CLI at night — the project memory travels with me, so the harness becomes a detail.

And detail is the point. Most harnesses are optimized for their own company’s LLM. But “optimized” doesn’t mean “magic,” and I have data on that.

What my benchmark says about harnesses

In my LLM Coding Benchmark I run the same models through different harnesses under controlled conditions. The result is the opposite of what the course market implies:

• For a weak model, the harness rescues. Grok 4.3 built nothing on bare opencode (18 points) and delivered a real app on the grok CLI (55). Gemini 3.1 Pro went from 62 to 88 on Google’s own harness — but the problem there was an OpenRouter transport bug, not a lack of “harness engineering.”
• For a frontier model, the harness is noise. Grok 4.5: 92 on opencode, 91 on the grok CLI. Grok 4.6: 92 and 93. A one-point difference, inside the margin of error. No amount of harness engineering moves a good model.
• Where the harness actually bites is your wallet. The Grok 4.6 run cost $1.19 on the grok CLI versus $6.33 on opencode via OpenRouter — over 5x cheaper for the same ~11 million tokens, because the official CLI uses xAI’s native prompt caching. Same story on Codex: GPT 5.6 Terra cost $6.77 blended because 21 of its 21.7 million tokens were cache hits; Sol, same family, same score, cost about $45.

So yes, picking a decent harness matters — for cost, and to give structure to a weak model. But that’s an afternoon of reading docs and watching your token bill, not a new discipline with a learning track.

Since I mentioned Hermes up there, it’s worth explaining: Hermes Agent is an open-source framework from Nous Research for building your own personal agent — you define the tools, write the loops, configure per-model routing, local/cloud fallback, Telegram and Discord gateways, and it even “learns skills” from use. It’s paradise for the setup crowd.

It’s also a second job: every one of those pieces becomes yours to maintain, update, and debug, forever. And at the end of the day the engine is still the same Claude, GPT, or Qwen everyone else has — the custom chassis doesn’t improve the engine. What Hermes actually solves, context continuity across sessions and tools, a decent harness with something like ai-memory already covers — without you becoming the infrastructure administrator of your own assistant.

If you want an assistant on your own hardware as a hobby or for privacy, that’s a great reason, go for it. As a productivity prerequisite, it’s not one.

Remember this: a good harness is one that charges less and stays out of the way. The rest is the model. And a good model doesn’t need “harness engineering” — at most it needs the transport not to be broken.

Loop Engineering, Graph Engineering, Spec-Driven Development

On to the names, because they describe real things — just tiny ones.

Loop Engineering is this season’s name for designing the cycle an agent repeats: execute, verify against evidence, iterate until a stop condition. The guides list real failure modes — the agent declaring “done” too early, the goal drifting on each pass. But the recommended mitigation is “an independent verifier checking objective evidence.” That’s had a name for fifty years: tests and code review. An agent in a loop with a test suite is the same old basics with a new name.

Graph Engineering is drawing the agent’s workflow as an explicit graph of nodes, branches, and joins — LangChain has three years of that story. It makes sense when the flow is genuinely branched. Except the overwhelming majority of projects is a straight line with an if in the middle. Modeling that as a graph is buying a giant whiteboard to draw one arrow.

Spec-Driven Development is writing a detailed specification first and treating the code as an artifact generated from it — the spec becomes the “source of truth” and the code, a byproduct. Hold that thought, the strong argument is coming right up.

Notice the pattern: each name takes a real, small practice — looping with verification, drawing a flow, writing down what you want before building — and inflates it into a “discipline.” The inflation is the product. A new name creates a course, the course creates a certification, the certification expires in six months and sells you the recertification.

To be fair: the serious guides on these topics already carry the caveat — the most-read graph engineering guide says outright that “you probably don’t need it” and tells you to master the loop before opening a graph, and LangChain has a whole “when not to use graphs” section. The guides are right; the damage comes from the funnel, which throws away the caveat and sells the rest as everyone’s default.

The two that sell the most courses — heavy agent orchestration and spec-driven development — deserve more than definitions. They deserve the argument.

The strong argument against super-orchestration

There’s simple math that orchestrated-agent diagrams never show. If each step of your pipeline succeeds 90% of the time — and that’s optimistic — a ten-agent chain succeeds 0.9^10, or ~35% of the time. Every node is a new failure point, and every edge is tokens spent on agents talking to agents instead of working.

You don’t have to take the math on faith: I accidentally measured it in the benchmark. MiniMax M3 running under an orchestrator looked like Tier D, with 24 points. The same model, clean, scored 91 — Tier A. A swing of up to 69 points between harness conditions means the opposite of what the orchestration vendor claims: when the plumbing dominates the result, you stopped measuring the model and started measuring the plumbing. The best result in the entire benchmark didn’t come from any orchestrated swarm: it came from one strong model, alone, in a simple loop — Fable 5, 96 points, Claude Code, done.

It makes sense once you remember coordination scales badly. Each additional agent doesn’t just add capacity; it adds edges, message contracts, shared state, and conflicting versions of the truth. The router deciding “which agent handles this” becomes both the bottleneck and the bug farm. A committee of mediocre agents with a conductor doesn’t beat one capable agent with good tools and memory.

I’ve tested this directly. Back in April I ran three rounds of “strong model orchestrating cheaper models” — planner + executor, forced delegation, the full package. The result: no multi-agent combination beat the Opus running solo in a mature harness. On a cohesive task like building an app, the planner has to read every output from the executor before dispatching the next step — the two become sequential, with tripled latency and a coordination queue in the middle. It’s the committee again: lots of talking, little software.

It’s not just my benchmark. Cognition, which sells Devin, published “Don’t Build Multi-Agents” with a mechanism sharper than my 90% math: every action carries implicit decisions the other agents can’t see — one subagent draws a Mario-style background, another draws an incompatible bird, and no amount of individual reliability fixes the divergence.

Anthropic itself, which runs a multi-agent research system, admits in its engineering post that multi-agent burns 15x more tokens, that coding is a poor fit for it — most coding tasks aren’t truly parallelizable — and that 80% of their improvement came from simply spending more tokens, not from the architecture.

When Berkeley measured what actually runs in production, 86 systems across 26 domains: 68% of production agents execute at most 10 steps before human intervention. What’s really out there is the simple supervised loop — not the constellation of colored nodes on the consultant’s diagram.

Where orchestration is legitimate: genuinely parallel, independent work — scanning ten thousand files, running ten thousand disposable analyses. Map-reduce has existed for twenty years and never needed a pompous name. And there’s one serious corner beyond it: agents running overnight, unwatched, holding credentials — there, independent verifiers and hard budgets become a security matter, not a style one. But that’s fleet operations, not the day-to-day coding the course is selling you. Outside those niches, most “multi-agent architectures” are one agent’s job with extra YAML.

There’s a reason you hear so much about it: orchestration is visible complexity. It has diagrams, colored nodes, dashboards. A well-driven agent has none of that — no slide deck, no certification, nothing to sell.

Remember this: every added agent multiplies the failure modes. If your system’s result changes when you swap the orchestrator, your system is the orchestrator — and the model was the costume.

The strong argument against spec-driven development

SDD sounds mature because it sounds like “writing documentation.” But look at what it actually proposes: the spec becomes the source of truth and the code becomes a generated artifact. The problem is that a spec precise enough to generate correct code already is a program — except written in prose, and prose doesn’t compile. Every ambiguity in the spec is a bug no compiler catches, in a medium with no tests, no linter, no feedback. SDD doesn’t remove the hard part, which is thinking precisely; it moves the hard part into a format where errors don’t scream.

Remember this: a spec precise enough to generate correct code already is a program — except in prose. And prose doesn’t compile.

Even if you write the perfect spec, it starts dying with the first hotfix. A bug shows up in production, someone fixes it straight in the code, and the spec becomes a lie. We’ve known this law for decades — it’s why documentation rots. Calling the spec the “source of truth” doesn’t change anyone’s incentives.

We’ve run this experiment before, by the way. UML, MDA, “the code generates itself from the model” — twenty-odd years ago it was the same promise with different acronyms. It collapsed every time for the same reason: the model was never the reality; the code was. SDD is MDA with an LLM bolted on. And I’m not the only one seeing Waterfall 2.0 there.

The people who tested the tools seriously landed in the same place. Thoughtworks put spec-driven development in the “Assess” ring of its Technology Radar — not “adopt”, “assess” — after watching the tools inflate small tasks into ceremony, and nailed the summary: we may be “relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn’t scale.” That’s Rich Sutton’s Bitter Lesson knocking again — handcrafted structure loses to scale, it always has.

There’s also the temporal inversion. The great lesson of agile was that you discover what you want by building — working software over comprehensive documentation. LLMs just made iteration cheaper than it’s ever been. And what does SDD propose? Expanding the planning phase, right now that iterating got cheap. Wrong answer, wrong direction, wrong time.

It’s the thesis I’ve been hammering since the first Agile Vibe Coding posts: software emerges, it isn’t planned. I wrote this back in February, with receipts: the most important features of the M.Akita Chronicles were born from problems that showed up mid-way — a job that failed silently, a site that blocked the gem, a crash that left emails in limbo. No spec in the world predicts that. The correct system emerges from iteration, not from specification.

The process got documented again when ai-memory grew through 26 contributors in 24 days: good software is a clay sculpture, not a Lego tower — malleable, always adjustable, never done. Whoever tries to design the whole architecture before the first line builds a straitjacket, not a system. Only amateurs still believe you can spec out an entire piece of software before coding it. Real modeling doesn’t come from templates or courses — I covered this years ago in Akitando 144 (video in Portuguese): it’s born from a repertoire of real problems and real code. There’s no ready-made recipe; there never was.

SDD tries to resurrect the idea that you can plan software ahead of time — the idea the industry buried after decades of projects delivered late, wrong, and over budget. LLMs didn’t revalidate that idea; they just gave it a new slide deck.

Even the pro-SDD guides separate the two things: “spec-as-source is where the hype lives; spec-anchored is where the value is today”. My target here is the former. Where heavy specs are legitimate: large teams, legacy codebases, asynchronous work crossing time zones and sprints — the good old design document, which has always existed and always had value. What doesn’t fly is selling that as the new default for everyone.

My benchmark prompt, for the record, is one page of goals. The difference is that I don’t trust the prose: I validate by running it. Precision lives in tests, not in paragraphs.

What you actually need

I’ve already written all of this on this blog, with real-project receipts. It’s called Agile Vibe Coding, and it fits in a paragraph:

It’s XP (eXtreme Programming, the original agile) with an LLM: tests, Clean Code, CI (continuous integration), pair programming, and deploy. You drive the agent like you’d drive a very fast pairing partner: say what you want, watch the execution, correct while mistakes are still cheap. The idea is 10% of the work; the other 90% is normal software engineering, the usual kind. Forget frameworks and three-page templates: what you need is to know what you want, know what you don’t want, and know how to validate when it arrives. And you need balance: neither handing the wheel to the agent nor turning into a comma cop.

That’s over 600 hours of it, over half a million lines, dozens of projects shipped. No graphs, no certifications, no loop with an English name.

Remember this: the idea is 10% of the work; the other 90% is plain software engineering, the usual kind.

The piece that lets me swap harnesses: ai-memory

One of my own tools is the opposite of taxonomy: ai-memory. It was born from a concrete problem. Every harness stores its session in its own format, and when the conversation gets long, it compacts the history to fit the window — and compaction throws away exactly the details that explain why each decision was made. Then you switch tools and start from zero, with the whole project to re-explain.

ai-memory solves this from outside the harness. It reads the native session without touching the original file and stores everything in a searchable ledger: messages, tool calls with results, compaction summaries, a git checkpoint — every event tagged with its origin (from Claude, Codex, OpenCode). When I open another harness, it gets its own native session and receives only the delta it hasn’t seen. When I go back to the previous one, ai-memory resumes it in that client’s format and hands over what happened on the others meanwhile.

That’s why “I swap harnesses like I swap underwear” isn’t a figure of speech. The project’s knowledge lives in the project, not in one tool’s session. If Anthropic changes pricing, limits, or models tomorrow — and they will — I swap the engine without throwing away the trip. The details of how this works are in this post.

There’s an inversion here that takes SDD down as a bonus. Spec-driven development says the source of truth is a document written before the work, trying to predict the future, and that the code owes it obedience. ai-memory does the opposite: the source of truth is a wiki distilled from the work itself — every session becomes evidence, and what deserves to survive (decisions, rules, gotchas, failed attempts) gets consolidated into short Markdown pages that any agent reads before starting.

The spec tries to guess the project; the wiki records the project. A document written beforehand rots at the first hotfix, because nobody is forced to update it. The wiki is fed by the very act of working — and when it goes stale, you notice immediately, because the agents trip over it every session.

Notice that this is real harness engineering: one tool, written once, solving a problem of mine. No course, no acronym, no certification.

Conclusion: ask for the receipt

Don’t waste time or money on a “harness engineering” course, “loop engineering,” or whatever taxonomy is trending this week. It’s a shameless attempt to charge you for things you already do if you know basic software engineering.

We’ve seen this movie before, by the way. Pedro Arantes nailed it on X: “Microservices, clean architecture, hexagonal, and Domain-Driven Design are all bullshit to sell more consulting hours and courses.” Same story, same script. Each of them was born from a real problem — and became the default for people who didn’t have the problem. Microservices for a three-person team, hexagonal architecture for a CRUD (the plain old create-read-update-delete app), DDD to never write code again. The technique passes, the taxonomy stays, the course sells.

So nobody plays dumb: none of this is useless. A loop with verification works. A graph works when the flow is genuinely a graph. Heavy specs save large teams. Microservices solved real problems for people with real scale; DDD shines in genuinely complex domains. The problem was never the tool — it’s selling the tool as a silver bullet, the universal hammer you must apply to everything. Silver bullets don’t exist, they never have. Whoever sells you one isn’t selling a solution; they’re selling a course.

Understand the psychological mechanism, because it’s old and efficient: those terms exist to give you FOMO (Fear of Missing Out). To make you anxious, thinking you’re falling behind, that you’re leaving productivity on the table, that everyone else already migrated to the new paradigm and you haven’t. Anxiety sells. Once you’re insecure, they charge you to implement something you never needed. FOMO is real — and here, it’s the business model.

The model is recurring, too — admire the elegance. First they sell you the methodology that generates artifacts — specs, graphs, boards, diagrams. The artifacts multiply, nobody knows where anything is anymore, and guess who shows up? The same consultancy, now selling the tool that manages the artifacts, the course that teaches you to manage the tool, and the artifact-governance workshop. It’s the shovel salesman congratulating you on the hole you dug — and offering you a bigger shovel.

Gartner even has an official name for it: “agent washing” — take an existing product, slap the “agentic” label on it, resell. Their estimate: only about 130 of the thousands of companies selling themselves as “agentic AI” are real, and their prediction is that 40% of such projects get canceled by the end of 2027, over cost, unclear value, or badly managed risk. No grudge of mine here: it’s the hype cycle, measured, with a public forecast and everything.

Next time an influencer or consultant tries to push those products on you, ask a simple question: where are your dozens of high-quality open-source projects that got better because of those “techniques”?

They have nothing to show. I do — it’s all public, with code, benchmarks, and documented process. When technology becomes a commodity, money migrates to taxonomy. Don’t be a customer of that migration.

The pattern repeats in all of them: I run into a small friction in daily life, the kind we normally swallow because fixing it would cost an entire weekend, and instead of swallowing it I open an AI agent and fix it. The cost of turning irritation into tooling dropped so much that the math flipped. Today it’s worth fixing almost everything.

Everything below is on my GitHub, with binaries, releases and install instructions.

In this post: clock-tui (with the google-calendar-tui and ghpending widgets), github-visualize, frank_geary, frank_scanlation, frank_lyrics, frank_type, distrobox-gaming and aitrepreneur-docker.

clock-tui: a desk clock that became a panel

The use case is simple: I have a secondary vertical monitor, and I wanted something more useful there than a wallpaper, something I could just glance at and get relevant information. But it all started because I just wanted a desk clock. I found a little old open source terminal clock program, the original clock-tui, which had been paused for ages, and decided to fork it and continue the work: clock-tui.

I made it prettier, modernized the Rust dependencies, and the most important change: I added support for command widgets. The clock sits at the top and below it come panels that run any command that prints text, each with its own refresh. Two widgets I built for it myself:

• google-calendar-tui: a read-only Google Calendar agenda in the terminal, using the accounts already in GNOME Online Accounts (zero OAuth setup). One glance and I know my appointments for the day.
• ghpending: lists open issues and pull requests across all the repositories I care about. Now that I have dozens of open source projects, this is how I notice within seconds when a new PR or issue arrives, without opening GitHub.

And today I spent the day adding theme support, because someone on X commented that the look could be made to resemble Evangelion. Challenge accepted: there’s now an evangelion theme (purple and lavender) and a nerv theme (red, amber and green, inspired by the show’s alert screens), switching at runtime with Shift+T. The theme is injected into the widgets via an environment variable, so the panels follow the palette.

Installing on Arch: yay -S clock-tui-bin. The widgets: yay -S ghpending-bin (there’s also brew install via akitaonrails/tap on macOS) and yay -S google-calendar-tui-bin. All of them have prebuilt binaries on GitHub Releases for those not on Arch.

github-visualize: useless, but pretty

This one was born because of Jarred Sumner’s article about rewriting Bun’s TypeScript in Rust, which I posted about recently. I don’t know which tool he used to illustrate the post, but I really liked the chart animations. Is it useless? It is. But it’s pretty, and pretty is reason enough to make a copy.

github-visualize is a self-hosted dashboard that monitors my GitHub repositories and replays their progress with animated visualizations: a commit timeline with lines added and deleted on a log scale, a commit heat map by day and hour, a CI race to green. Now I can add any repository of mine and get pretty visualizations of productivity, activity, commits and builds. Maybe I’ll use it in presentation slides, or to illustrate future posts here on the blog.

Install: public image on Docker Hub as akitaonrails/github-visualize, single container with SQLite in a volume, no external database or Redis.

Frank Geary: email the way I wanted it

I decided to use GNOME’s Geary as my main email client. It’s the closest to the interface of Apple’s default Mail app: clean, direct, no ceremony. I know, there’s Thunderbird, but I find it bloated and very ugly. There’s Mailspring, which I find bloated and heavy. My email flow is short: sweep the inbox, tag, archive and reply. Nothing else.

Geary is almost perfect, but it had two big problems for me. First: on my vertical monitor there’s much less horizontal space, and Geary has 3 fixed columns. The first column, which only lists accounts and folders/tags, I don’t need to see all the time, but there was no way to collapse it.

Second, and worse: the composer’s recipient field in practice never autocompleted anything (Geary does have the mechanism, but with a contact visibility filter so restrictive it never suggested anyone). I had to type the address by hand or copy and paste from another email. In 2026.

My first solution was two external GTK modules injected into Geary, one for each problem (both obsolete now). They worked, but they required installing Geary compiled from source, and on every yay -Syu there it went recompiling everything again.

I got tired and did what I should have done from the start: I forked Geary and created Frank Geary, which adds both features straight into the code. The sidebar now collapses, and the recipient autocompletes by consulting the contacts from your existing emails. I’ll keep maintaining the fork by rebasing from upstream frequently.

And the best part: there’s now a package on the AUR, so installing goes like this:

yay -S frank-geary-bin    # prebuilt binary (x86_64), from the GitHub release
yay -S frank-geary        # or compiling from source

Both packages replace the system’s geary (they provide/conflict with it), so the swap is clean and updates arrive like any other package. One detail after installing or upgrading: when the watch-for-new-mail option is on, Geary keeps running in the background as a D-Bus service, so run a geary --quit to make sure no old process is left hanging around.

Japanese manga: FrankYomik, FRANK MANGA+ and FRANK Scanlation

Anyone following the blog knows about my love for Japanese manga. I already posted about FrankYomik, which was born so I could read the original Japanese manga I buy from Amazon Japan.

The problem: manga aimed at adult audiences (no, not porn! I’m talking about subjects like business or military topics) doesn’t have “furigana”, the little kana subtitles printed next to difficult kanji, indicating the reading. Shounen manga has furigana on everything, so you can read it with student-level vocabulary. The adult ones assume you already know how to read the rare kanji. I don’t.

FrankYomik solves that by adding furigana on top of the page, in real time: a model detects the speech bubbles, manga-ocr extracts the text, and the furigana (or a full translation, via a local LLM on Ollama) is rendered on top, all running on my own hardware. And the important detail: on-the-fly, over the image I already have legitimately open, without downloading or redistributing a single page, so no copyright or license infringement.

Then came FRANK MANGA+, which I also posted about. I pay for the subscription to Manga Plus, Shueisha’s official app, but it only lets me read on mobile (Android/iOS). On a small tablet it’s tolerable, but I have a 32" Samsung Odyssey OLED monitor sitting right in front of me.

I figured out how to use my own subscription outside the app and built a desktop reader in Tauri: it runs on Linux, macOS and Windows, the free tier works out of the box and subscribers paste their own secret to unlock the premium chapters.

Install: AppImage, .deb and .dmg on the releases, or yay -S mangaplus-reader-bin on Arch.

And finally, I also read the occasional community “scanlations”: fans scan the pages of the original Japanese manga and translate them (nowadays most use AI in the process, there are even models trained to recognize speech bubbles, and I used one of those in FrankYomik itself). These scanlations are spread across several different websites, like MangaDex.

First I made a Chrome extension to prettify those sites (obsolete now), but I got tired of living with dozens of tabs in Brave just for scanlation sites. So I built FRANK Scanlation, along the same lines as FRANK MANGA+: a desktop app that concentrates all my favorite scanlations in one place, with a library, per-title reading progress and checking for new chapters.

The reading windows load the site itself and inject a decent reader on top, with double-page spreads and keyboard navigation. Nothing is hardcoded to any website: they’re heuristics that detect image sequences and chapter numbering in any URL. It became my preferred way to read the manga that can’t be bought on Amazon or from Shueisha.

Install: AppImage, .deb and .rpm (and a macOS build) on the GitHub releases.

Frank Lyrics: memorizing songs line by line

I already posted about Frank Karaoke, a little app to add scoring on top of YouTube and enjoy karaoke with family and friends. But there’s a sibling use case: I like learning new songs (a new anime opening, for example), and the process of memorizing lyrics is repeating the SAME line several times. In the YouTube player that’s hell: you keep hunting by hand for the exact spot on the timeline to go back to, miss it by two seconds, rewind too much, overshoot.

To solve that I created Frank Lyrics, a simple Chrome extension that figures out the correct timing for each line of the lyrics using the public markers from LRCLIB and injects controls into the YouTube page itself. LRCLIB, for those who don’t know it, is an open, community-driven library of synchronized lyrics: each line comes with a timestamp (the classic LRC format from music players), with a public API, free and keyless.

The extension matches those timestamps to the video and gives me buttons to repeat the exact line I’m memorizing, as many times as I need, without hunting the timeline. If you enjoy karaoke, the Frank Karaoke + Frank Lyrics combo should serve you well.

Install: download the .zip from the releases, unzip it, open chrome://extensions, enable developer mode and “Load unpacked” pointing at the folder.

Frank Type: typing practice with actual prose

Anyone who has followed me for a while knows I love my keyboards. There are videos on the Akitando channel about it and posts here on the blog about my favorite keyboards. And from time to time I like to train on MonkeyType. But I dislike typing random words. TypeRacer solves that by using real public texts, except it makes me wait for other players in the room (I hate multiplayer games). In other words: I wanted a single player experience, with real prose, but with the MonkeyType aesthetic, which I prefer.

So I created Frank Type, a mini-clone of both: a typing trainer in Rails 8 that uses normalized public-domain prose excerpts instead of random word lists. It’s local-first and account-free: session history, timing data and profile charts stay in the browser’s local storage. It even has a digraph heat map to show which key combinations slow you down.

Install: it’s a Docker container published as akitaonrails/frank_type. One command brings it up at http://localhost:3200:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/frank_type/master/bin/docker-run.sh | bash

distrobox-gaming: a library of how to install games on Linux

I game on the same PC I work on, but I refuse to mix emulator packages and Wine hackery with my development environment. The solution was to isolate gaming entirely inside a distrobox (containers that integrate with your desktop as if they were native), and distrobox-gaming is the repository of Ansible playbooks that builds that Arch box from scratch: ES-DE as the frontend, standalone emulators, RetroArch cores, per-game configs. My Arch/Omarchy host stays clean.

The rule I imposed on myself: every new game I install has to become a reproducible Ansible recipe. I confess I haven’t tested the full rebuild from scratch yet, but that’s the idea: any trick or hack required gets documented in code instead of lost in shell history.

And there’s no shortage of tricks, because I’ve been installing old abandonware: the Colin McRae Rally series (from the PS1 version with a 60 fps patch up to 2007’s DiRT), Sega Rally Revo, OutRun 2006 Coast 2 Coast, among others. Each with its own Wine quirks, patches and configs. Without meaning to, the repository is becoming a library of documentation on how to install games, emulators and retro games on Linux.

Along the same lines there’s distrobox-llm, which does the same isolation for my local LLM environment (CUDA, Ollama, LM Studio and friends), leaving only the NVIDIA driver on the host.

Install: clone the repository and run the playbooks:

cd ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml
ansible-playbook site.yml

aitrepreneur-docker: ComfyUI without dirtying the system

For image generation I like ComfyUI, and I posted about it last year. I follow a youtuber called Aitrepreneur who maintains a Patreon page with recipes to install and configure ComfyUI with the newest models and workflows. His curation work is great, but the recipes are old school .sh scripts, meant to run as one-shots on a RunPod instance, for example.

Now that LLMs evolved to the point of writing decent Dockerfiles, I created aitrepreneur-docker, which converts those scripts into proper Docker images and containers: pinned versions, persistent data on the host or NAS, one command to bring up or upgrade each app. That way I run everything isolated on my machine, without littering my Linux with tons of Python packages and hacks that could destabilize the system.

Two important notices. The credit for the stack selection, model curation and workflows all goes to Aitrepreneur: the repository only translates his work into Docker form, and his original scripts are paid Patreon content that is NOT included.

If you find it useful, subscribe to his Patreon to contribute to his content creation (that’s also where you get the original files). And the repository doesn’t cover everything he has produced, only the most recent recipes.

Install: git clone, make setup (creates the .env for you to put your Hugging Face token), make build and make up.

And there’s more where these came from

If you’re new here: this is just the batch that hadn’t shown up on the blog yet. There are plenty more projects I’ve covered in dedicated posts. ai-memory is the most popular, most used and most contributed-to of all. ai-jail, which showed up again in yesterday’s post about destructive agents, was the first of the series and is the second most popular.

And there are the others in the Frank series (“Frank” in honor of Frank Rosenblatt, creator of the perceptron, the original neural network; the name marks the experimental projects I do for fun):

• Frank Sherlock: smart image indexer
• Frank Mega: MEGA clone for my home server
• FrankMD: markdown editor
• Frank FBI: email fraud analyzer
• Frank Investigator: teaches you to question the news

Everything is open source and on my GitHub. Everybody is welcome to contribute with issues, pull requests, or just by sharing with your friends. Each of these projects was born from a real little problem of mine. Maybe one of them solves yours too.

I got into the ancient game of Go because of the manga Hikaru no Go. I even wrote about it back in 2008, in a post that’s still up, arguing why programmers should play Go. Since then, my use case has barely moved: I own a physical goban at home, but I never had the slightest intention of joining a study group, a federation, or a tournament. I just like playing solo, solving tsumego (Go’s life-and-death puzzles), and loading famous games to study, like the legendary Lee Sedol vs AlphaGo games from 2016.

For anyone who doesn’t know the manga: Hikaru no Go (written by Yumi Hotta, drawn by Takeshi Obata, the same artist as Death Note) ran in Shonen Jump from 1998 to 2003 and set off a Go boom across all of Japan. And here’s a detail few people know: practically every game shown in the manga is based on a real historical game, recreated panel by panel. Hold onto that, because it comes back in a minute.

SGF and the scattered-material problem

There are several very good open source programs for loading Go games or even playing online. Go games are recorded in a format called SGF (Smart Game Format), a plain-text format that’s been around since the late 80s: each move becomes a coordinate (;B[pd] is a black stone on the 4-4 point), and the format supports variation trees, comments, and game metadata. It’s the de facto standard of the Go world: every client reads SGF, every server exports SGF, and there’s a gigantic archive of historical games and problems in this format accumulated over decades.

And that’s where the problem lives: that archive is scattered across the entire internet. One site has the classic tsumego collections, another has the historical games, one GitHub repo has the commented problems, another has the professional kifu (game records). I was in no mood to download everything by hand, organize it folder by folder, and configure client by client. I wanted an app good enough, pretty enough, with everything built in.

2008: the GNU Go era

Here’s where the historical context earns its keep, because it’s the fun part. In 2008, when I wrote that post, the only accessible Go “AI” was GNU Go. And look, you couldn’t even call that thing an AI: it was a pile of stacked heuristics. And it was terrible. Even an amateur like me could see it made moves with no flow, no sense of direction, loose stones that didn’t talk to each other. It beat beginners on pure local tactics and nothing else.

What happened over the next 18 years is one of the most beautiful stories in computing. First came the Monte Carlo Tree Search methods, which already raised the level considerably.

Then in March 2016, DeepMind’s AlphaGo beat Lee Sedol, one of the greatest players in history, 4 to 1. That was the series of the famous move 37 in game 2 (the shoulder hit no human would play) and Lee Sedol’s answer in kind: move 78 in game 4, the “hand of God” that earned him his only win. If you’ve never seen it, there’s an excellent documentary about that series on Netflix, worth watching even if you know nothing about Go.

And after DeepMind published the papers, the open source community chased it down: first Leela Zero reimplementing AlphaZero, then KataGo going beyond it. Today anyone has a superhuman Go player running for free on their own computer. I wanted to see up close how much these AIs matured in 20 years.

That itch is what my new toy project was born from: Frank GO.

Sabaki + KataGo

I asked Claude Code to research the most popular open source Go apps and engines (the whole survey is documented in the repository itself, as it should be). In the end I picked two projects as the foundation:

Sabaki, by Yichuan Shen, is the front-end. It’s probably the most beautiful, best-kept open source SGF editor and Go board out there, built on Electron, with variation trees, analysis, and engine support via the GTP protocol. Elegant and minimalist.

KataGo, by David Wu, is the AI. It’s the strongest open source engine in the world, superhuman, heir to the AlphaZero lineage but with one difference that matters enormously for my case: beyond win rate, KataGo estimates score and territory ownership point by point. It answers “who’s winning, by how many points, and which areas of the board belong to whom.” That’s exactly the kind of information a beginner needs and that the old engines kept hidden.

Frank GO is a fork of Sabaki that wires in KataGo for solo play sessions, and bundles everything I wanted to have in one place:

• Over 4,700 tsumego from the classic collections (Cho Chikun’s Encyclopedia, the Gokyo Shumyo, the Xuanxuan Qijing), transcribed by Vít Brunner at tsumego.tasuki.org and converted to SGF by the tasuki2sgf project, plus the 420 commented problems from Go Game Guru’s go-problems (by An Younggil, 8-dan professional), organized into 10 difficulty levels. Solve 5 in a row and you level up. A focus picker filters by life & death, tesuji, ko, or semeai (capturing races).
• The puzzles fight back: with KataGo installed, it answers your moves inside the problem, and when it gives up the area the app judges the result and marks the problem solved automatically.
• Famous historical games to study, from the Ear-Reddening Game (1846, by the legendary Honinbo Shusaku) to AlphaGo vs Lee Sedol, curated from Andries Brouwer’s game database at CWI, each with the story behind it, and the AlphaGo ones with move-by-move commentary. You can watch them in auto-play or turn on “guess the moves” and try to find the pro’s play.
• The Hikaru no Go games: remember how the manga’s games are real? Well, 15 of them are bundled with chapter references and trivia, using the chapter-to-game mapping the community compiled on Sensei’s Library. Sai’s internet game against Toya Meijin, for instance, is a real game decided by half a point.
• A joseki dictionary (Kogo’s Joseki Dictionary, the classic corner-opening reference), ladder drills, a “who is winning?” drill, and a ten-problem rank test that estimates your level and drops you straight into the right practice.

Remember the scattered-material problem? Those collections above are exactly it: each one lived in its own corner of the internet. The provenance and licensing of every set is documented in the repo’s data/SOURCES.md, because you use other people’s archives by giving proper credit.

Overlays for people just starting out

The part of Sabaki I changed the most was building beginner-friendly visual overlays. The main one is area painting: an overlay that paints each player’s influence as a soft gradient and settled territory in solid color, so you literally see what the stones are doing, which areas are dead and which are contested.

Alongside it comes the real-time score accounting for komi (White’s point compensation for playing second), which warns you when you’re hopelessly behind or when the game is already settled. And hovering over the board shows the move names (“Hane”, “One-Point Jump”), the vocabulary the books use and that beginners take forever to absorb.

That was my problem with every Go software I ever tried: they’re tools built by strong players for strong players. A winrate percentage says nothing to someone who’s learning. “You’re 12 points behind and the lower left corner just died” says everything. KataGo always knew how to compute this; someone just had to put it on screen in a way a beginner understands.

The idea is to be a one-stop shop, zero configuration, for beginners and students to learn Go at their own pace. And there’s a build for everywhere. On Arch Linux it’s yay -S frank-go via AUR. On Windows there’s an installer and a portable build on the Releases page; the installer has no code signing, so SmartScreen complains on first run — just click “More info → Run anyway” (I explain why I don’t sign Windows builds in the best-practices post). On macOS it’s brew install --cask akitaonrails/tap/frank-go, or the .dmg for Apple Silicon and Intel; that build is signed with a Developer ID and notarized by Apple, opens with zero drama. And on any platform you can run from source with npm install.

In every case the app downloads a small CPU engine with one click, no GPU, no account, no server, fully offline. The exception is macOS, where KataGo has no official binary: a brew install katago unlocks play-vs-AI, and everything else (tsumego, study, drills, area painting) works without it. Your progress stays on your machine.

And when you want to play against people

Frank GO is deliberately a solo study app. When you’ve learned and want to play against humans, the natural path is the online servers, and there the more advanced apps serve you better. OGS (Online Go Server) is the friendliest today, runs right in the browser. KGS and Pandanet IGS (the original Internet Go Server, running since the early 90s) are the veterans, and the Asian servers like Fox and Tygem concentrate the strongest players. Organized Go revolves around the IGF (International Go Federation) and the national associations, with rankings and tournaments for anyone who wants to take it seriously.

I don’t. And that’s the whole point of the project: like I said up top, I have zero desire to compete. What I wanted, for literally years, was a way to play and have fun with Go at my own pace, with decent study material in one place, against an AI that plays beautifully instead of spitting out senseless stones like the GNU Go of 2008. I think I finally pulled it off.

The code is MIT, the repo is github.com/akitaonrails/frank_go, and contributions are welcome. There’s even an open issue asking for character portraits for the Hikaru no Go mode, if anyone feels like drawing. Sai thanks you.

I’m a subscriber to the MANGA Plus by Shueisha app on Android’s Google Play Store. For those who don’t know, this is Shueisha’s official channel (the Japanese publisher behind Shonen Jump) for reading their manga legally, with chapters releasing weekly nearly the same day they’re published in Japan. Two dollars a month gets you the entire catalog with an official English translation.

I own a Samsung ZFold 7, one of the few phones that’s actually good for reading manga and Kindle (I talked about this and about Frank Yomik in the AI marathon final ranking). The Fold opened gives you a bigger screen than a normal phone, which helps a lot. But there are days when my eyes are already tired of tiny screens, and what I really wanted was to read on a 32-inch OLED monitor that sits right in front of me, perfect for long sessions.

The problem is that MANGA Plus has no official website for reading. The subscription is locked to Android. There’s an iOS version too, but no web. A tablet helps, but nothing beats the comfort of a big, static screen when you want to read a whole One Piece arc in one go.

For context, I caught up on a lot recently: I finally finished Chainsaw Man, Dan Da Dan, Jujutsu Kaisen, Kagurabachi, Akane-banashi, Sakamoto Days and, of course, One Piece. There’s a lot more I want to follow, and the comfort of the big monitor became a real problem worth solving.

The main act here is Frank Manga+, which fixes Shueisha’s desktop gap. At the end I also cover two pieces of my setup: Prettify Manga Reader, for turning fansub sites and Kindle Web into tolerable readers, and Frank Yomik in the browser, for furigana/translation on Kindle Japan and Naver.

Decompiling the app

I decided to dig in. I sat down with Claude Code and we downloaded the official MANGA Plus xapk. We decompiled it to Java source with jadx and navigated around until we understood how the app authenticates with Shueisha’s API.

The conclusion is straightforward: the user’s “subscription,” from the app’s point of view, is a 32-character hexadecimal deviceSecret stored in a plain XML file inside Android’s shared preferences. The app generates this secret once when you log in, and from then on every API call (jumpg-api.tokyo-cdn.com) is signed with it. No elaborate DRM, no rotating token, none of that. A single static secret per device.

The catch is that extracting that secret from the app is a hassle, because by default you don’t have access to /data/data/jp.co.shueisha.mangaplus/shared_prefs/config.xml on a non-rooted Android. Three paths exist:

1. Rooted phone: run adb shell su -c "cat /data/data/jp.co.shueisha.mangaplus/shared_prefs/config.xml" and look for <string name="secret">...</string>.
2. Rooted emulator: install Android Studio, create an AVD with Google Play x86_64, apply rootAVD for Magisk root, log into the Google account that holds your subscription, install MANGA Plus from the Play Store, then run the same adb shell above.
3. Network capture with mitmproxy (more advanced): run the rooted emulator, inject the mitmproxy CA via Conscrypt APEX, and intercept the secret on the app’s first authenticated call.

All three paths are documented in detail in the repo’s docs/install.md and docs/debugging.md. I won’t repeat them step by step here because it’s more about tooling than technique, and anyone willing to put in the work will want to read the original. The important thing is that it works, and you only have to do it once: once extracted, the secret keeps the desktop app working for as long as your subscription lasts.

Yes, it’s annoying. But it’s the price for having a single configuration point that unlocks the rest.

The desktop app

With the secret in hand, the rest was easy. I built Frank Manga+, a native app in Rust + Tauri, with a SvelteKit WebView on the frontend and a Rust client using reqwest on the backend talking directly to Shueisha’s API. To load chapter images without leaking URLs or fighting CORS, I created a custom mpimg:// scheme intercepted by Tauri, which downloads, decrypts (the API serves pages with a simple XOR), and hands the result back to the WebView.

The app opens on a library view with search:

Clicking a title takes you to a detail page with the full chapter list and a “Continue” button that picks up from the last chapter you read:

The reader opens in single-page, with snap-per-page and manga-style click zones: click the left half of the page to advance and the right half to go back (Japanese right-to-left reading direction). If you’d rather use the keyboard, arrows, Space, j/k, and PageUp/PageDown all work. When you hit the end of a chapter, the next one prefetches and gets appended to the scroll, so you don’t have to bounce back to the chapter list every time. And resume is per-chapter: leave mid-read and the next time you open that chapter you land on the exact page you stopped at. For huge series like One Piece (1100+ chapters), the list is virtualized, so it opens instantly:

On a 32-inch monitor, single-page wastes half the screen. That’s why there’s double-page mode: hit D (or click the layout icon in the header) and the reader starts pairing facing pages, so the whole spread fills the screen the way the author drew it. It’s how manga was meant to be read.

You can see why that matters when you compare it with cheap binding. Bad paperbacks swallow the middle of the fold, exactly where the art is supposed to connect. In digital, when the reader joins it properly, the scene gets room to breathe:

Frank Manga+ joining the spread	Cheap paperback swallowing the fold

D cycles through three layouts: single (one page at a time), double (sequential pairs starting from page 1), and double-cover (the first page of each chapter solo, the rest in pairs, the way printed manga binds the cover singly before the first spread). The choice persists across chapters and sessions, so you set it once and forget it.

There’s also a night-reading filter. Hit F (or click the crescent-moon icon in the header) and the page whites warm toward sepia. LCD white is harsh on the eyes in the dark, and this softens it without flattening the contrast:

F cycles through four levels: off → low → med → high → off. The button tints amber and shows one to three dots for the active level, and the choice is saved in localStorage like the reader’s other prefs. Under the hood it’s a CSS sepia + brightness + saturate filter on the whole page-stack: the sepia pushes the hue toward amber but preserves the luminance range, so blacks stay black and the artwork’s contrast is intact.

Reading state (last chapter, current page) lives in the WebView’s localStorage. Image cache at ~/.cache/mangaplus-reader/. The extracted deviceSecret lives in ~/.config/mangaplus-reader/secret (Linux/macOS) or %APPDATA%\mangaplus-reader\secret (Windows). You can override it with the MANGAPLUS_SECRET environment variable if you prefer.

Install

There’s a build ready for all the main platforms:

• Linux: AppImage, .deb, .rpm, or via AUR (yay -S mangaplus-reader-bin).
• macOS: separate .dmg for Apple Silicon (aarch64) and Intel (x64).
• Windows: .exe installer. It’s not signed, so Windows SmartScreen will complain, click “More info → Run anyway”.

All artifacts come out on the GitHub Releases.

Status and contributions

This is beta. It works fine for my use (I read several series a week with no headaches), but it’s missing features: genre filters in search, real offline mode (today it only caches what you’ve already read), and a smoother secret-extraction path for less technical users.

If you subscribe to MANGA Plus and want to test it, send an issue or PR. The code is Rust + Svelte, MIT, contributions welcome: github.com/akitaonrails/frank_mangaplus.

Now I finally read One Piece on the big monitor, without having to hold a phone or twist my neck. The work paid off.

Bonus: Prettify Manga Reader for fansub sites

Besides the desktop app, I keep a simpler extension around: Prettify Manga Reader. It does not translate anything. Its job is to fix the reading experience.

Most fansub sites are ugly, packed with banners, and obviously built for phones: one page under the next, endless vertical scroll, good luck. That’s practical on a phone, but manga was not drawn like an Instagram feed. Manga was drawn for page turns. Two pages open at once. The reading rhythm, the reveal, the pause between panels, all of it assumes that pair.

And many authors use that to draw two-page spreads. Kaiju No. 8 does it several times. If the site stacks one page under the other, you can still read the speech bubbles, but the full composition is gone. You’re seeing half the art at a time and thinking you saw the whole thing.

The usual site looks like this:

Prettify opens a dark overlay, fits the art to the screen, and joins pages at the center seam when Book or Double mode is active. The spread looks like a real two-page spread again:

It has three modes: Single (one page per screen), Double (pairs from the start), and Book (first page alone, then pairs, like binding). It opens in Book by default. If an image is already horizontal, it stays as a full-width spread. It has scroll snap so every page lands in the right place, keyboard shortcuts, small mouse controls, help with ?, and an end-of-chapter card that tries to find previous/next chapter links when the site makes them obvious.

It also has a three-level night filter. Hit N and it warms the page with sepia, brightness, and contrast without turning the art into dead gray. A white manga page on a big monitor at night is a flashlight to the face. This fixes it.

To install it, go to the Prettify Manga Reader GitHub repo, download the zip from Releases, unzip it into a permanent directory, open chrome://extensions or brave://extensions, enable Developer mode, click Load unpacked, and select the unzipped folder. If you want to build from source, clone the repo, run npm test, then npm run package, unzip the package generated under dist/, and load that folder.

On Kindle Web Reader, Prettify deliberately does less. On URLs like read.amazon.com/manga/..., read.amazon.co.jp/manga/..., read.amazon.co.uk/manga/..., and read.kindle.* domains, it doesn’t try to rebuild the book inside its own overlay. Amazon’s reader already handles account, pages, and DRM; the extension only adds a discreet bottom-right toolbar and keyboard shortcuts on top of the native reader.

Space, PageDown, and arrows advance the page; Shift+Space, PageUp, and the opposite arrows go back; Home/End jump to the beginning or end when the native reader accepts them, with a scroll fallback; N cycles the night filter. It doesn’t store Amazon credentials, doesn’t touch sessions, and needs no token in the code. It’s just visual comfort and keyboard control on top of the Kindle Web that already exists.

Bonus 2: Frank Yomik now on the desktop too via extension

Anyone who read the AI marathon recap remembers Frank Yomik, my self-hosted project that takes a manga or webtoon page, detects the bubbles with RT-DETR-v2, runs OCR, sends it to a local Ollama (qwen3:14b) for translation, and returns the page with the translated text in place. I already covered the story and the technical details in My First Vibe Code Failure and How I Fixed It | Frank Yomik. The point here is the new desktop piece.

Originally it had only a Flutter client for Android and Linux, which opened Kindle Japan and Naver Webtoon inside a WebView. The thing is, running a Flutter app inside a WebView on the desktop just to read Kindle is using a sledgehammer to crack a nut. On the desktop you already have Chromium open. What was missing was a browser extension.

Over the past few weeks I added exactly that. A Manifest V3 extension for Chromium/Brave/Edge, talking to the same self-hosted Yomik server. It runs on read.amazon.co.jp, read.kindle.co.jp, comic.naver.com, and Naver’s mobile version. The page stays visually identical to the original, with no injected buttons or HUD in the reader’s face. All configuration lives in the popup:

The content script grabs the current page image and sends it to the server. The bearer token sits in the service worker, so it never leaks to the page’s JS. When the translation comes back, the image gets swapped in place of the original. There’s a local cache to avoid re-translating pages you’ve already seen, a “force reprocess” button for when you need to file a bug report, and autosave for the config. Details in the extension README, and the Load Unpacked zip ships with the repo’s Releases.

In practice, the 32" monitor is now my reading desk. Frank Manga+ opens Shueisha’s official catalog in English (One Piece, Chainsaw Man, and whatever else Shonen Jump publishes). When it’s fansub or Kindle Web and all I want is visual comfort, Prettify handles the reader, keyboard, and night filter. When I want to read something Japanese with no official translation, I open Kindle Japan in another tab and Yomik renders furigana or an LLM translation on top of the page. For Korean Naver webtoons, same story, same extension.

The nice part is that each project solves a different piece and they complement each other. Frank Manga+ exists because Shueisha has no website. Prettify makes browser readers less miserable. Yomik exists because the rest of the manga I read doesn’t have a decent official translation in any reasonable timeframe. For a manga addict like me, it’s the setup I’d been wanting for years.

I’ve always loved karaoke. I go out to sing with family or friends every now and then. In São Paulo there are good places in Liberdade and Bom Retiro, for instance, with private Japanese-style booths. If you’ve never been to a karaoke like that: you rent a private room by the hour, there’s a huge song catalog, two microphones, and a scoring system that grades your singing in real time. The best systems are Japanese, like Joysound and DAM. A score above 90 (out of 100) is considered advanced. DAM, in the LIVE DAM Ai series, even uses AI to give scores that feel more “human.”

But not every place has that level.

The problem with karaoke in Brazil

In Brazil we grew up with Videokê, the brand the Korean Seok Ha Hwang brought to the country in 1996, importing equipment from Korea. It became a craze in the 90s and 2000s, showed up in every bar, barbecue and birthday party. The problem is that those machines stopped in time. The current models, like the VSK 5.0, ship with around 12-13 thousand songs in the catalog, which you expand by buying cartridges or song packs. In practice, the repertoire is old, the interface is straight out of the 2000s, and if the song you want to sing came out after 2015, good luck.

The workaround a lot of bars adopted was to allow Chromecast or screen mirroring so that customers can search for songs directly on YouTube. Makes sense: on YouTube you can find karaoke for any song. With-lyrics version, instrumental version, vocal guide version.

But there’s a downgrade: you lose the scoring. One of the most fun parts of karaoke is the competition. Watching your score climb, comparing with friends, trying to beat the night’s record. If you’re just singing on top of a YouTube video, you get no feedback. It’s like bowling without a scoreboard.

And buying a professional system for home? Importing a Joysound F1 runs north of US$ 2,000 just for the hardware, not counting the monthly catalog subscription. For casual use it makes no sense.

The idea: YouTube with real-time scoring

Frank Karaoke came out of that frustration. If YouTube already has every song, why not build an app that works as a YouTube wrapper with a real-time scoring overlay? You search for any karaoke video, sing along, and the app analyzes your voice through the mic and shows a live score.

It’s a Flutter app for Android. Internally it loads YouTube into a webview and injects an overlay in HTML/CSS/JavaScript right into the page. The score display, the pitch trail, the settings panel, the mode selector — all of it rendered inside the webview through JS injection.

Scoring without a reference

Now, the real problem. Every professional karaoke system depends on prebuilt reference files for each song. Every single one.

Sony’s SingStar, which sold over 12 million copies between 2004 and the end of the PS3 era, had a hand-crafted note track for every song. Every note, every syllable, all mapped manually. The mechanism compared the singer’s pitch via FFT against that reference in real time. A detail I thought was clever: octave was ignored. If the right note was a C, it didn’t matter if you sang C3 or C4. Men sing women’s songs no problem.

Joysound and DAM in Japan go further and evaluate three separate dimensions: pitch accuracy (音感), rhythm/timing (リズム感) and expressiveness/dynamic volume (表現力). All based on MIDI data from the operator’s server. The open source equivalent format is UltraStar, where each song has a .txt file like:

: 12 4 5 Hel-    (NoteType StartBeat Duration Pitch Syllable)

Pitch 5 = MIDI 65 (F4). Scoring compares the singer’s pitch against the note’s pitch, modulo octave, with a tolerance of 1 semitone.

Frank Karaoke works with any YouTube video. There’s no reference file. There’s no MIDI. There’s no melody annotation. Zero metadata about what note you’re supposed to be singing.

I don’t know anything about karaoke scoring. I don’t know anything about audio processing, pitch detection, music theory applied to software. Nothing. So I asked Claude Code to do extensive research on the subject. What it brought back is documented in docs/scoring.md in the repository, and it’s a lot: academic papers on singing evaluation (Nakano et al. 2006, Tsai & Lee 2012, Molina et al. 2013), patents (Yamaha has one from 1999, US5889224A, that details MIDI-based scoring with 3 tolerance bands), and the source code of open source projects like UltraStar Deluxe, AllKaraoke, Vocaluxe and Nightingale.

The conclusion of the research: without a per-song reference, you have to evaluate vocal quality generically. Measure how the person is singing, not what they should be singing. And since no single metric works for every case, we decided to implement four different scoring modes, each measuring a different dimension of vocal quality.

The phone microphone problem

Before the scoring modes, I have to explain a more fundamental problem the research uncovered: the phone microphone.

When you sing karaoke with the phone, the mic picks up three things at once: your voice, the music coming out of the speaker, and ambient noise from the room. Your voice is physically closer to the mic, so it dominates the signal. But not enough for clean separation.

I tried several approaches to isolate the voice:

Spectral subtraction using YouTube’s reference audio. Dropped it. The YouTube CDN blocks direct audio extraction by non-browser user-agents, and even with the reference audio in hand, the speaker’s EQ, the room reverberation and the Bluetooth delay make the signal too different from what the mic captures. Naive subtraction produces artifacts worse than no subtraction at all.

Pre-emphasis + center clipping. Dropped that too. Center clipping destroys the waveform that the YIN algorithm needs for autocorrelation, and pre-emphasis amplifies noise as much as it amplifies voice.

What works is a 200-3500 Hz bandpass filter: a second-order IIR (Butterworth, Q=0.707) in cascade. The high-pass at 200 Hz kills bass, kick drum, bass guitar bleed from the speaker. The low-pass at 3500 Hz kills cymbals, hi-hats, high-frequency noise. Human voice fundamentals (85-300 Hz) and formants (300-3000 Hz) pass through the filter. It’s not perfect isolation, but it improves the voice/music ratio enough for pitch detection.

But the bandpass alone doesn’t solve everything. Guitars, synths and piano produce periodic signals in the same frequency range as voice, and YIN detects pitch in them too. To deal with that, the app does adaptive calibration: in the first 5 seconds of warmup (when nobody’s singing yet), it collects RMS samples from the signal to establish a baseline of the speaker’s level. During the song, it keeps that baseline updated (25th percentile of the last ~4 seconds of frames). For a frame to be scored, the RMS has to be at least 1.3x above the baseline. Your voice is closer to the mic, so it pushes the RMS above the speaker’s level. The instrumental melody stays near the baseline and gets filtered out. In testing, the original singer coming out of the speaker scored around 37 with sparse dots in the trail, while someone actually singing scored ~59 with dense dots.

Another annoying detail: on Android, specifically on Samsungs, the DSP’s AutomaticGainControl (AGC) attenuates the signal instead of amplifying it. On Galaxies, enabling AGC drops the mic peak from ~0.06 to ~0.003. Silence as far as pitch detection is concerned. So the app disables AGC, echo cancellation and noise suppression. When the peak falls below 0.01, it applies software gain (up to 30x) to bring the signal up to usable levels.

The YIN algorithm

To detect the voice’s pitch I use YIN, by Alain de Cheveigné (IRCAM-CNRS) and Hideki Kawahara (Wakayama University). It’s a fundamental frequency estimator in the time domain. The central idea is the Cumulative Mean Normalized Difference Function (CMNDF), which basically measures how periodic the signal is at each lag, normalizes it to reduce false positives, and uses parabolic interpolation to refine the result. It’s lightweight enough to run in real time on a phone, which is what matters here.

In the app, the YIN threshold is 0.70 (tuned for mixed voice + music signals), and frames with confidence below 0.3 get discarded. Below that, it’s probably noise or an instrument.

The 4 scoring modes

Each mode evaluates a different aspect of vocal quality. They all share the same audio pipeline (bandpass → YIN → confidence gate). The difference is how they interpret the detected pitch.

Pitch Match

Measures how cleanly you sustain notes. Uses Gaussian decay based on the standard deviation of MIDI values in a rolling ~15-frame window. Steady notes (deviation < 0.3 semitones) score 85-100%. A trembling voice (deviation > 2 semitones) scores near zero. Good for songs you already know well.

Contour

Measures the melodic shape of your singing. It doesn’t matter which exact note you hit, only the direction and the flow. Evaluates the pitch range and melodic movements (jumps > 0.5 semitone) in a rolling window. Monotone singing scores ~10%. Smooth melodic movement with a 2-6 semitone range scores 70-100%. Good for when you’re learning a new song.

Intervals

Measures the musical quality of jumps between consecutive notes. A whole tone (2 semitones) scores highest. Thirds and fourths score well. Wild jumps of an octave or more score low. Uses a Gaussian curve centered on the whole tone. Works when you’re singing in a different key from the original.

Streak

It’s Pitch Match with a combo multiplier. Each consecutive frame with a score above 0.4 increments the streak counter. The streak adds bonus points (up to +0.4 on a streak of 30+). Breaking a streak > 5 frames pushes a 0.05 penalty into the EMA. Silence freezes the streak, so instrumental breaks don’t hurt you. The most fun mode for parties.

The logic behind these four modes came from the research Claude did across academic papers. Each one measures a different dimension: pitch accuracy, melodic contour, phrasing and consistency. None of them is sufficient on its own, but together they cover, reasonably well, what you can evaluate without having the song’s reference melody.

The Pitch Oracle

Beyond the four purely vocal modes, the app has what I call the Pitch Oracle. The idea: instead of evaluating your voice in isolation, the app downloads the video’s reference audio via youtube_explode_dart, decodes it to PCM, runs YIN on it, and builds a timestamped pitch timeline of the entire song. During scoring, if the mic’s pitch matches the reference’s pitch at that moment in the video, it’s probably speaker bleed, and gets ignored. If it differs, it’s your voice, and gets scored.

The synchronization works through the currentTime of the HTML5 video element, sent to Dart through a JS timeupdate listener every ~250ms. The oracle queries the reference pitch at the exact playback position, accounting for pause, seek and speed change.

The first time you play a song, the oracle takes 5-15 seconds to download and analyze the audio. But the timeline is saved as JSON in the app’s local cache (pitch_oracle/<videoId>.json). If you play the same song again, it loads instantly from cache, no network request. That also fixes YouTube’s rate limiting problem for the songs you sing the most.

With the oracle active, the modes change behavior. Pitch Match compares the singer’s pitch class against the reference’s, agnostic to octave (like SingStar). Contour uses cross-correlation between the singer’s pitch movement and the reference’s. Intervals compares semitone jumps against the reference’s.

When YouTube blocks the download with rate limiting (happens after many consecutive requests from the same IP, clears in 15-30 minutes), the oracle silently fails and the modes fall back to purely vocal analysis.

The road to here

The app you see now went through a lot of iteration before reaching this state.

First, I tried to make a Linux desktop version to make debugging easier. Makes sense, right? Test on the desktop, iterate fast, then port to mobile. The problem is that Flutter has no webview backend for Linux desktop. webview_flutter simply doesn’t work. I tried webview_cef, which is based on the Chromium Embedded Framework. CEF spawns its own GPU process, and on Hyprland (a Wayland compositor based on wlroots) that conflicts with the compositor’s render pipeline. On my NVIDIA setup, the entire Hyprland session froze. Locked screen, no keyboard response, I had to kill it from a TTY. On top of that, CEF requires downloading a ~200MB binary on the first build. I gave up on CEF and wrote a native bridge in C++ with Claude using WebKitGTK and Flutter method channels. It worked, but every YouTube quirk required separate code for Linux and Android. just_audio also has no Linux desktop implementation. The Linux version turned into dead weight. I deleted ~1,500 lines of Linux-specific code and focused only on Android.

Then came the Samsung mic saga. On my Galaxy Z Fold, the mic was capturing an absurdly low signal. Peaks of ~0.005, basically silence as far as pitch detection was concerned. I spent two hours trying to figure it out. I lowered thresholds, raised software gain to 50x, disabled audio preprocessors. Nothing was working right. Until I figured out the real problem: Android’s AutomaticGainControl. The name says “automatic gain control,” which suggests it amplifies weak signals. In the Samsung DSP implementation, it does the opposite. It attenuates the signal to a low reference level, optimized for voice calls. With AGC on, the peak dropped from ~0.06 to ~0.003. Disabling AGC fixed it. But then the audio_session package was re-enabling AGC under the hood. I removed that one too. It was three rounds of fixes, each finding one more layer of the problem.

And the scoring. The scoring took longer than everything else combined. The first implementation used a cumulative average, which kept the score stuck at one value and never responded to live singing. I switched to a rolling window. Then the score was stuck at ~50% because of a bug in the primary score weight. I fixed it, and it started showing 70% even with nobody singing. Fixed it again. Streak mode wasn’t resetting properly during silence. The chromatic snap was giving high scores for anything. The pitch history wasn’t being cleared on silence gaps and the modes were going stagnant. Every fix revealed another bug. It took more than 25 commits just on the scoring, from the first prototype to the current state.

The result isn’t perfect. I know. But it works well enough to be fun, which was the goal from the start.

Settings

The settings panel lives behind the gear icon on the overlay. There are three mic presets for different environments (clean external mic, normal room, loud party), each adjusting confidence and amplitude thresholds. There’s a pitch shift for when the song is too high for your vocal range. The shift moves both the video audio and the scoring at the same time: it uses the HTML5 element’s playbackRate with preservesPitch=false, so +2 semitones speeds the audio up to 1.12x (pitch goes up) and -2 semitones slows it down to 0.89x (pitch goes down). The scoring compensates for the offset, so you sing in your comfortable range and the system grades you correctly. There’s mic calibration, a 3-second process that measures the room noise and adapts the thresholds. And there’s a restart to reset the score without reloading the video.

To switch scoring modes, tap the score box during playback.

Usage flow

1. Open the app. YouTube loads inside the app with the Frank Karaoke logo.
2. Search for a karaoke video. Any video works, but instrumental tracks with on-screen lyrics give better results.
3. The video pauses briefly to initialize the mic, download the song’s data for the pitch oracle, and prepare the overlay. The first time with a new song this takes 5-15 seconds. If you’ve played it before, it loads from cache instantly.
4. Sing. The “live” score reflects your current performance (exponential moving average with alpha 0.15, ~1 second response). The “overall” score is the cumulative average of the entire song.
5. When the video pauses, scoring pauses with it (so it doesn’t score ambient noise). If you seek, the score resets and gets a 5-second warmup.

How to install

The app isn’t on the Play Store yet, I’m waiting for Google to verify my developer identity. It should show up there in the next few days. In the meantime, it’s an open project and you can install it directly.

The easiest way is to download the signed APK directly from the GitHub releases page. On your Android phone or tablet, download FrankKaraoke-0.2.0-android.apk, open it and tap Install. If Android complains about “unknown sources,” enable it under Settings > Security for your browser. On the first run the app will ask for mic permission. Then go into settings (the gear icon) and calibrate the mic before singing — three seconds.

If you want to compile from source or contribute, the repository is on GitHub. You’ll need Flutter SDK 3.10+, Android SDK API 24+, and a physical device for mic testing (an emulator doesn’t give representative results).

git clone https://github.com/akitaonrails/frank_karaoke.git
cd frank_karaoke
flutter pub get
flutter run -d <device_id>

The README has the rest.

Stack: Flutter + Riverpod for state management, webview_flutter for YouTube, youtube_explode_dart for audio extraction, record for PCM mic capture, audio_decoder for reference decoding via Android MediaCodec, and the YIN algorithm implemented in pure Dart.

The technical documentation for the scoring system is in docs/scoring.md in the repository. It covers how SingStar, Joysound and DAM work, the academic papers, the pitch oracle architecture, the voice isolation problems on Android, and the roadmap.

The scoring is experimental

I have to be straight: the scoring system is experimental. Without per-song reference files, the evaluation is approximate. The app measures whether you’re in tune, whether you follow a melodic contour, whether your intervals are musical, whether you’re consistent. But it doesn’t tell you whether you’re singing the correct melody for this specific song (unless the pitch oracle manages to download the audio, and that doesn’t always work).

If you have experience with audio processing, pitch detection, or music evaluation, the repository is open and the research documentation in docs/scoring.md details what was tried, what works and what doesn’t. In particular: tuning the modes’ thresholds, improving voice isolation, and integrating with UltraSinger (which generates reference files from songs using Demucs + basic-pitch + WhisperX) are areas where contribution from people who know the subject would make a real difference. I’d appreciate any help from specialists on calibrating these systems.

Oh, and the name. Frank Karaoke. It’s a tribute to Sinatra. Who else?

Project on GitHub: github.com/akitaonrails/frank_karaoke

With that out of the way, let me explain why I built this.

The problem with the Brazilian press

I’m fed up.

Fed up of opening the newspaper and having to do mental gymnastics to separate information from narrative. Fed up of outlets like Folha de São Paulo, UOL, Carta Capital, Brasil 247, O Globo and several others that use misleading headlines, omit context on purpose, transpose evidence from other countries with no caveat, and create the appearance of consensus among outlets that are all saying the same thing because they’re following the same coordinated agenda.

This isn’t conspiracy theory. It’s a verifiable editorial pattern. And the worst part: most readers don’t have the time or the tools to notice. You read the headline, read the first two paragraphs, and walk away with the impression the article planted in your head.

What Frank Investigator does

You give it a news article URL. The system fetches the article with a headless Chromium (to get past paywalls and cookie walls), extracts the content while filtering out ads and sidebars, and decomposes the text into verifiable claims. Then the real analysis starts: divergence between headline and body, rhetorical fallacies (false causality, appeal to authority, strawman, bait-and-pivot), source distortion, temporal manipulation, selective citation, authority laundering. It expands the links cited in the article to verify whether the sources actually say what the author claims. It evaluates each claim with consensus from 3 AI models (Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro) through OpenRouter. It detects contextual gaps, coordinated campaigns across outlets, and measures the ratio between passion and evidence. 15 stages in total.

The central principle is “Truth Above Consensus”: a primary source (official data, government document, original academic study) vetoes any number of secondary sources repeating the same information. Ten newspapers repeating the same thing without a primary source still adds up to zero.

Let me show you five real examples.

Example 1: The Noelia Castillo case (BBC)

The BBC published a story with the headline “Noelia Castillo dies: a 25-year-old’s fight in the Spanish courts against her father to receive euthanasia.” At first glance it looks like a story about the right to euthanasia and a family dispute. A young quadriplegic woman who fought against her religious father’s opposition to exercise her right to die.

Except when you compare it with other outlets, like Veja, facts come up that the BBC almost completely omitted. And those facts change everything.

Noelia was taken from her family by the Spanish government at age 13 and placed under state custody. While she was under that custody, she suffered multiple gang rapes. The sexual violence resulted in serious psychiatric damage and a mental health history that already added up to 67% disability rating before the events of 2022. When she attempted suicide in October 2022 by jumping from the fifth floor of a building, she was left paraplegic. Her disability rating rose to 74%.

The euthanasia request was approved by Catalonia’s Guarantee and Evaluation Commission. The procedure was scheduled for August 2, 2024, but was suspended for over 600 days because of the father’s appeals. Five judicial instances ruled on it. The Constitutional Court dismissed any violation of fundamental rights. Spain’s Supreme Court denied the appeal. The European Court of Human Rights rejected the suspension request. On Friday, March 26, 2026, Noelia underwent euthanasia at the Sant Camil Residential Hospital, in Catalonia’s Garraf region.

But there’s a detail that Veja mentions that’s disturbing: Noelia reportedly expressed doubts before the procedure. And the hospital allegedly accelerated the process because her organs were already committed for donation.

The Frank Investigator report compared the coverage from several outlets.

The cross-analysis of the articles showed that some outlets, like the BBC, omitted facts that change the interpretation of the entire case. Others, like Veja, included the full context. The episode of gang sexual violence in October 2022, the criminal investigation, the psychiatric history since age 13, all of that appears in some coverage but is completely absent in others. And among the outlets that omitted these facts, none touched on the ethical question of whether the physical basis for the euthanasia request derives from a suicide attempt.

The convergent framing across outlets is one of “judicial battle,” “death she asked for,” “to stop suffering,” “to leave in peace,” softening the definitive nature of the procedure and positioning Noelia as the heroic protagonist and the father as the obstructive antagonist. The father, Gerônimo Castillo, and his Christian Lawyers are labeled “ultra-Catholics” or “ultra-conservatives” without any independent source backing that editorial classification.

Narrative coordination came in at 55%. It doesn’t seem to be active coordination between newsrooms, but thematic editorial alignment: everyone bought the autonomy-of-the-individual narrative without questioning it. What raises the score is the convergence of omissions. No outlet explains the legal distinction between the ECHR “actively authorizing” the euthanasia and simply refusing the provisional protective measures the father requested, which is what actually happened. The medical and bioethical implications of approving euthanasia in a case stemming from a suicide attempt show up nowhere. And any voice critical of the procedure is automatically framed as religious or ideological, never as medical or legal.

It’s the kind of case where the omission is the manipulation. The outlets that omitted these facts didn’t lie at any point. But by framing it as a “family dispute over euthanasia rights” and omitting the causal chain (state custody → gang rapes → psychiatric damage → suicide attempt → paraplegia → euthanasia), the reader walks away with an impression that’s radically different from reality. Comparing coverage is exactly the kind of thing the investigator does well: exposing what each outlet chose to show and what it chose to hide.

Example 2: “Government cuts taxes on nearly a thousand imports” (UOL)

UOL published that the government cut import taxes on nearly a thousand products, from medicine to hops. Positive headline, framed as a benefit to the consumer. Several other outlets ran the same thing with similar framing: the government did something good, prices are going down.

Except Gazeta do Povo tells the other half of the story. The government didn’t cut old taxes. What actually happened was: at some point before February 2025, the government raised import tariffs on more than 1,200 items, a measure that would have generated an estimated R$ 14 billion in revenue. Then, under social-media and public pressure, it partially backed down. Tariffs on around 970 capital goods, computing and telecommunications items were dropped to zero. Taxes on 120 IT products were reduced. And now they’re calling that a “tax cut.”

In other words: they raised taxes, took public pressure, partially walked it back, and rebranded it as a generous concession. The majority of the 1,200+ items that had tariffs raised still have higher tariffs than before. No final consumer prices went down. Prices went back to where they were for some products, and remain higher for most.

The Frank Investigator report cross-checked the articles and exposed what was omitted.

What the comparison between articles exposes: none of the outlets with the positive framing mentions that most of the 1,200+ items with raised tariffs still have higher tariffs after the two rounds of “cuts.” The fiscal impact on the R$ 14 billion revenue target from the original increases — nobody calculates it. Voices from the domestic industry that may be hurt by the tariff reduction on imported competitors — none. The Gecex’s objective criteria for defining “insufficient supply in the internal market” — they don’t show up.

The two articles analyzed build the same positive framing for the government. The paradox that the “cuts” are a partial reversal of increases made by the same government the previous year stays buried or simply absent.

It’s the classic kind of manipulation through reframing. Nobody lied. But “government cuts taxes” and “government backs down on tax hike after public pressure” describe the same event with opposite impressions. The editorial choice of which version to publish IS the manipulation.

Example 3: “Globo apologizes for PowerPoint” (Brasil 247)

This case blew up over the past few days. GloboNews showed a diagram on the Estúdio I program connecting President Lula, his ministers and Daniel Vorcaro, owner of Banco Master, who’s at the center of documented fraud. Globo later issued a public retraction, called the material “erroneous and incomplete,” and fired an editor.

Brasil 247 published a story with the headline “Globo apologizes for PowerPoint that tried to dump the Master case on Lula’s lap.”

The Frank Investigator report exposed what’s going on under the hood:

The central fact is real: Globo apologized and fired someone. But Brasil 247’s framing goes way beyond what the facts support. The headline saying “tried to dump it on Lula” attributes deliberate intent where the documents point to an editorial mistake. Globo’s retraction described the material as “erroneous and incomplete,” not as an attempt to incriminate anyone.

What stands out in this case is the coordinated campaign. The investigator gave it 62% narrative coordination.

Several outlets editorially aligned with the government used the phrase “without evidence” in a convergent way to describe the association between Lula and the Master case. All of them focused on Globo’s mistake as the central narrative point, instead of investigating the actual connections. No outlet mentioned which other political names were excluded from the original PowerPoint. None investigated Vorcaro’s documented connections with different spheres of power. The focus is meta-journalistic: they criticize the broadcaster instead of covering the scandal.

The fallacies detected: loaded language (“tried to dump,” “without evidence” used to frame an editorial mistake as a deliberate political attack), false causality (Globo’s retraction doesn’t prove the connections are false), cherry-picking (highlights the omission of names tied to the Lula government without contextualizing which other names were omitted), and bait-and-pivot (uses Globo’s apology as a hook to minimize the Banco Master scandal).

And the questions none of these outlets asked: which Supreme Court justices and politicians from other parties were also excluded from the PowerPoint? Does the Master case have documented connections to Lula government figures, or are they limited to previous administrations? Does Brasil 247, which is publishing this article, have a declared editorial alignment with the Lula government? What was the journalism Ethics Council’s reaction?

Overall confidence: 13%. The article doesn’t fabricate facts. But it selects, frames and omits in a way that builds a narrative the data doesn’t support.

Example 4: “Why expensive fuel is good” (Folha)

The economist Bernardo Guimarães published a column on Folha arguing that expensive fuel is good for society because it stimulates innovation in clean energy. He cites real academic articles (Popp 2002, NBER) and has verifiable academic credentials (PhD from Yale, professor at FGV EESP). It looks solid.

The full Frank Investigator report shows another picture.

The article is right to cite real studies. But it omits who pays the bill. The column completely ignores the distributive impact: low-income populations, residents of peripheral and rural areas, who depend more on personal vehicles and have less access to clean alternatives. For an economist, ignoring distributive effects is either incompetence or editorial choice.

There’s a worse problem. The empirical evidence he cites (US patents, electric vehicle data in California between 2014-2017) is transposed to Brazil with no caveat at all. Brazil has an ethanol matrix and flex-fuel infrastructure that completely changes the causal mechanism. The article treats it as if the Brazilian consumer were in the same situation as the Californian one, which is false.

And there’s the context the article mentions in passing but doesn’t develop: the war in Iran is making fuel prices rise around the world. Brazil should be in a privileged position thanks to the pre-salt and to ethanol. But decades of mismanagement and corruption at Petrobras mean we’re paying the same price as the rest of the world. Instead of questioning that, the column sells the idea that “at least it’ll stimulate clean energy.” It’s a rationalization of a problem that shouldn’t exist.

The investigator identified 5 questions the article refused to address, with 35% contextual completeness. The fallacies detected include false dilemma (presents expensive fuel as the only viable climate policy), cherry-picking (acknowledges short-term inelasticity but emphasizes only long-term effects), and loaded language (describes alternatives as “playing at planting a little sapling”).

Overall confidence: 25%. It isn’t fabricated disinformation. It’s opinion with cherry-picked evidence in favor of the thesis and omission of relevant counterpoints.

Example 5: “There’s no strong cinema without streaming regulation” (O Globo)

Renata Magalhães, president of the Brazilian Academy of Cinema, gave an interview in Miriam Leitão’s column on O Globo arguing that regulating streaming is a necessary condition for strengthening Brazilian cinema.

The Frank Investigator report found serious problems.

First: the central claim that “many films have low audiences” appears with no empirical data. No numbers, no historical series. It’s a pure authority claim with no analytical basis.

Second: there’s an internal contradiction the article doesn’t resolve. The text opens by saying that Brazilian cinema is “in international spotlight” (awards, festivals). And then immediately argues that the absence of regulation prevents the industry from being strengthened. But if Brazilian cinema is already winning international awards without that regulation, the argument that the regulation is a necessary condition collapses. The article doesn’t address that contradiction.

And here’s the elephant in the room that none of these articles mentions: people simply don’t want to watch most of these films. Internationally awarded Brazilian cinema is made to compete in Cannes and at the Oscars, not to fill movie theaters in Brazil. Instead of asking why the Brazilian audience isn’t interested, the industry would rather ask for streaming regulation to force platforms to fund and screen content that has no spontaneous audience. It’s the classic playbook: use public money and regulation to keep alive an industry that doesn’t sustain itself in the market.

The interviewee is the president of the Brazilian Academy of Cinema. She has a direct institutional interest in the regulation. The article doesn’t present any opposing voice and doesn’t discuss the costs to consumers: subscription price increases, catalog reduction. A single source, with a declared conflict of interest, with no counterpoint.

And here comes the coordinated campaign, with 55% narrative coordination. Multiple outlets reproduce the same emotional framing: cinema “at risk,” regulation as “essential.” None of the identified sources discusses comparable empirical international evidence on the effectiveness of content quotas (Europe has experiences with contradictory results). None mentions the Brazilian Academy of Cinema’s conflicts of interest. The fact that the internationally awarded Brazilian productions were made without the proposed regulation is omitted convergently across all outlets. Only one isolated site (targethd.net) mentioned negative impacts on consumers.

Overall confidence: 9%. The article is legitimate editorial advocacy, but with analytical flaws that limit its informational value to nearly zero.

What the investigator analyzes

The 5 examples above show different patterns, but the analysis criteria are the same.

The strongest signal of manipulation is omission. It isn’t what the article says that misleads, it’s what it leaves out. The contextual gap analysis identifies the questions the article should have answered and didn’t, and searches for counter-evidence on each one. In the examples above, articles that omit most of the relevant context aren’t informing anyone. And when cross-comparison between outlets shows that some covered the facts and others didn’t, like in the Noelia case or the tax cut, it’s hard to argue that the omission was accidental.

Then comes the detection of coordinated campaigns. Several newspapers covering the same subject is normal. All of them using the same loaded language, focusing on the same points and omitting the same counterpoints at the same time isn’t. The strongest signal of coordination isn’t what outlets say in common, but what they omit in common.

There’s also reframing, which is more subtle. In the tax case, the government raised tariffs, backed down under pressure, and the outlets called it a “cut.” Nobody lied technically, but the choice of framing completely changes the interpretation. This kind of manipulation is harder to detect because each individual statement is defensible.

The rhetorical fallacies catch specific constructions: false dilemma (“either you regulate or cinema dies”), bait-and-pivot (open with a positive fact and pivot to a crisis narrative), loaded language (“without evidence” used to attribute intent). Each detected fallacy comes with the exact citation of the passage and the explanation of why that construction is problematic.

And there’s the principle that ties it all together: if 10 outlets repeat the same claim citing each other, the LLM consensus has to reflect that the chain of evidence is circular, not that the claim is well supported. Volume of coverage is not a proxy for truth.

Why you can’t “just ask ChatGPT”

The first reaction many people will have is: “why do I need this if I can just paste the article into ChatGPT and ask it to analyze?”

Try it. Take a political article and ask ChatGPT to criticize it. It’ll criticize. Take the same article and ask it to confirm. It’ll find arguments to confirm. The LLM isn’t searching for truth. It’s predicting which response you most likely want to hear given the framing of your question. If you ask “analyze the problems with this article,” the model will find problems. If you ask “is this article correct?”, it’ll find merits. It’s automated confirmation bias.

There’s another problem. General-purpose LLMs are trained to be agreeable. The sycophantic tendency (agreeing with the user) is documented in every large model. If your conversation history indicates you’re left-leaning, the model tends to frame answers in a way that pleases that profile. If you’re right-leaning, same thing in the other direction. It’s not lying on purpose. It’s optimizing for user satisfaction, which is literally the metric it was trained for via RLHF.

And worse: LLMs hallucinate. If they don’t have enough evidence to support the answer they think you want to hear, they invent it. They fabricate plausible citations and data, attribute statements to people who never made them. If you ask it to criticize an article about fuel, it might invent a fictional study that “proves” the opposite of the article. It sounds convincing. But it doesn’t exist.

Frank Investigator was built precisely to avoid these problems. The first design decision is that no human asks the LLM a question. There’s no open-ended prompt like “analyze this article.” Each step in the pipeline has structured prompts that ask for specific analyses: “list the rhetorical fallacies in this passage,” “identify which contextual information is missing,” “compare the headline with the body.” The model doesn’t know whether the operator agrees or disagrees with the article, because the operator never expresses an opinion. That eliminates confirmation bias at the root.

To deal with hallucination, every analyzer that uses an LLM includes the instruction “CRITICAL — NO HALLUCINATION: Only reference URLs, sources, claims, quotes, and data that are EXPLICITLY present in the input provided to you. Do not invent, guess, or fabricate any URL, source name, statistic, quote, or claim. If you cannot verify something from the provided text, mark it as unverifiable — never fill in details.” It doesn’t eliminate hallucination completely, but it cuts it down a lot. And since 3 models from different companies (Anthropic, OpenAI, Google) answer the same questions, when one hallucinates the other two usually disagree. The consensus is weighted by confidence, not by simple majority. If two models say “supported” with 70% confidence and one says “mixed” with 95%, the “mixed” weighs more. The further apart the disagreement, the bigger the penalty on final confidence. If one model starts giving inconsistent answers, it gets put in quarantine and the other two carry on.

But the safeguard I consider most important is the primary source veto. If a primary source (IBGE data, court ruling, original study) contradicts a claim, confidence is capped at 60% and the verdict is forced to “mixed,” even if all 3 LLMs say “supported.” Ten newspaper articles repeating a claim don’t override one official datum that contradicts it. Along the same lines, if 5 stories “confirm” a claim but they all come from the same editorial group (Folha/UOL, Globo/G1/Valor), the system knows they’re the same voice and reduces the weight. Volume doesn’t replace independence.

None of this makes the system perfect. But it’s categorically different from pasting text into ChatGPT and asking “what do you think?”.

The numbers

Stack: Ruby 4.0.1, Rails 8.1.2, SQLite with WAL mode, Solid Queue (jobs inside Puma), Solid Cable (WebSockets), Tailwind CSS v4, headless Chromium via Ferrum CDP, deploy with Kamal to GitHub Container Registry. AGPL-3.0.

The development process

The project has 129 commits in 9 active days of work (March 11-16 and 25-27). The first day was the heaviest: more than 60 commits on March 11 alone, going from zero to a working system with content extraction, claim decomposition, LLM evaluation, and a web interface with live updates via Turbo Streams.

The commits tell the story. It started with the foundation:

1e32d5a - Initial Frank Investigator foundation
564eb97 - Add recursive source crawling and RubyLLM scaffold
c8c5357 - Add Brazil source registry and authority connectors
3d30617 - Add U.S. authority profiles, source role modeling, and specialized connectors

Then came the misinformation analyzers, one by one:

a65fef7 - Add rhetorical fallacy analyzer for detecting narrative manipulation
5dcf99d - Add headline-body divergence detection and headline citation amplification
a113efd - Add smear campaign defense with circular citation and viral volume detection
56d501a - Add media ownership modeling, syndication detection, and independence analysis

The hardening phase against noise and false positives is the one that took the most time:

46e4bc5 - Add pre-fetch defenses: URL filtering, circuit breaker, fetch prioritization
168fea1 - Add post-fetch content gate, claim noise filter, and duplicate content skip
b2843d7 - Add paywall detection, pricing noise filter, and ofertas.* host rejection
b1b230d - Rewrite Chromium fetcher with Ferrum CDP for anti-bot evasion

Then came the interface, deployment, and the more advanced analyzers:

c5afcea - Replace custom CSS with Tailwind CSS v4 and rewrite all templates
95a8ec4 - Add Docker deployment with bin/deploy script
ccfacc9 - Add coordinated narrative detection across media outlets
ba3e2f4 - Add 6 new misinformation detection analyzers with cross-analysis
fda984b - Add LLM-generated investigation summary with quality assessment
a4ebe78 - Add contextual gap analysis to detect manipulation through omission

And in the most recent commits, simultaneous 3-model consensus and test optimization:

5cc9c05 - Enable 3-model LLM consensus: Sonnet 4.6, GPT-4.1 Mini, Gemini 2.5 Pro
cdf5fb5 - Batch 5 content analyzers into single LLM call, add anti-hallucination
28c305e - Add WebMock stubs for LLM and web search — tests run in 1.4s (was 540s)

The tests that used to run in 9 minutes now run in 1.4 seconds with WebMock stubbing of every LLM and web search call. That made a huge difference in iteration speed.

Limitations

News fact-checking is a hard problem. A single article doesn’t contain everything needed for a complete analysis. The author chose what to include and what to omit, and that choice is already the first level of manipulation. The sources cited inside the article were selected by the author to support their narrative, not to give a balanced view.

Frank Investigator doesn’t tell you what’s true and what’s false. The result is a report with strong and weak points, not a “true” or “false” stamp. Even with all the safeguards I described above, the counter-evidence searched for automatically may not be the most relevant. The fallacies detected can have false positives. The coordinated campaign analysis depends on what web search returns at the moment of the lookup.

Use the reports as a starting point to form your own opinion, not as a final verdict.

The project is open source, AGPL-3.0. If you want to contribute, test, report bugs or suggest improvements: GitHub. If you want to follow the analyses, the The Makita Chronicles newsletter is going to have a “Notícias Duvidosas” (Dubious News) section with the summary and a link to the full report of each investigation.

It “works,” but this project was more about the exercise. With that out of the way, let me tell you why I did it.

The problem with OpenClaw

OpenClaw is a gateway that connects messaging channels (Telegram, Discord, Slack, WhatsApp, etc.) to AI providers (OpenAI, Anthropic, Ollama). You configure it, bring up the server, and you can chat with LLMs straight from Telegram or any other channel. It’s a popular project with plenty of activity.

Too much activity, actually.

I did a depth-1 clone of the repo and ran tokei:

Over a million lines of TypeScript. The 2,799 test files sound like a lot in absolute numbers, but proportional to the codebase size, the coverage is low. Most of the code lives in 29 packages of a monorepo with 21 channel extensions.

I went looking for more commits to understand the development pace. In the 100 commits I managed to pull, all of them landed in just 2 days (March 9 and 10). ~50 commits per day, from 42 different contributors. Vibe coding to the extreme.

The conclusion is the one you’re imagining: enormous volumes of AI-generated code being dumped into a repository at a speed that makes serious human review impossible. And that bothered me enough to go investigate further.

The security audit

I asked Claude to do a complete security audit of OpenClaw’s code. The report found:

Seven critical vulnerabilities. Let me list a few:

• Timing side-channel in token comparison — safeEqualSecret() does an early return on the type-check, letting an attacker distinguish malformed tokens from wrong tokens by measuring latency.
• eval() in the browser tool — arbitrary JavaScript execution with no sandbox.
• Shell with no allowlist — any tool can run any command on the system.
• Slack webhooks with no signature verification at all.
• Transcripts and config in plaintext on disk, no encryption.
• No effective rate limiting — IPs can be spoofed if the operator configures trusted proxies broadly.

Those are just the ones Claude found in an automated scan. There are probably more.

I’m not going to run that on my machine. Not even inside a Docker container. A gateway that receives webhooks from the internet, executes shell commands, connects to AI APIs with your keys, and stores conversation history, all of it with 7 known critical vulnerabilities? No, thanks.

So I did what any rational developer would do: I decided to build my own.

The first attempt: Claude Code

I started the most direct way. Cloned OpenClaw, pointed Claude Code at the code, and asked: “rewrite this in Rust.”

Didn’t work. The codebase is too big. Over a million lines of TypeScript spread across 29 packages. Claude can’t keep all of it in context. The initial result was very incomplete: lots of types created but no implementation, todo!() everywhere, too much boilerplate and not enough functionality.

I switched to Codex 5.4 to test. Same thing: I asked it to analyze and rewrite. It improved a bit in certain aspects, but the fundamental problem is the same. No AI today takes a project of that size and rewrites it in one go. The context doesn’t fit.

The technique that actually works

What works is going slowly. One step at a time.

Ask Claude (or Codex) to analyze the original code in stages. Make a long plan detailing each feature. Then implement one feature at a time in Rust, with tests, commit, and repeat. It’s tedious, but it produces code that compiles and actually works.

The reason is simple: the original code is so massive that no AI agent (and not even several in parallel) can keep all of it in context at the same time. You have to decide what matters, implement that, validate, and move on to the next thing.

And you have to decide what to cut. OpenClaw has 21 channel extensions: Google Chat, iMessage, IRC, Teams, Matrix, Mattermost, Nostr, Twitch… I don’t need any of those. I kept the mainstream channels: Web, Telegram, Discord, Slack, Signal, WhatsApp and Email. TTS? Out. Polls? Out. WhatsApp Web through Baileys? Out, I use the official Cloud API. They’re features that add complexity without proportional value.

Discovering IronClaw

In the middle of development, I came across IronClaw, which presents itself as “OpenClaw in Rust.” Great, I thought. Let me see what they did.

I cloned the repo and asked Claude to write a comparison report. IronClaw has good things. I adopted 12 features:

Circuit breaker with retry and exponential backoff for LLM provider resilience. Credential leak detection in the output. LLM response cache with SHA-256 of the prompt. Cost tracking with budget guards (warning at 80%, block at 100%). Extended thinking for Claude 3.7+ and o1. MCP client for external tool servers. Lifecycle hooks on inbound, tool calls and outbound. Smart model routing that sends simple queries to cheaper models. Tunnel support (cloudflared, ngrok, tailscale). Interactive REPL (frankclaw chat). Routines with event triggers beyond cron. Job state machine with auto-repair.

But IronClaw depends on PostgreSQL + pgvector, has a WASM sandbox (wasmtime adds ~10MB), and is part of the NEAR AI ecosystem. I want a single binary with embedded SQLite and zero external dependencies.

What FrankClaw brings from OpenClaw

The OpenClaw core is there: 7 messaging channels, multi-provider with failover, agent runtime, command system, skills, subagents, browser automation through CDP, bash tool with allowlist, cron jobs, interactive REPL. Plus the 12 IronClaw features I listed above.

But several pieces had to be rewritten in a way the original didn’t. Context compaction, for example, uses a sliding window with token estimation, message pruning and automatic repair of tool pairs that get orphaned when the context is cut. Provider failover is now model-aware: if you ask for a Claude model and the current provider is OpenAI, it skips automatically instead of erroring out. The canvas renders SVG, HTML and Markdown with revision conflict detection. Things that in OpenClaw either didn’t exist or were half-built.

Then came the phase of adding what was missing for parity. FrankClaw today has 30+ LLM tools: web_fetch (SSRF-safe with HTML-to-text), web_search (Brave API), file_read/file_write/file_edit (sandboxed in the workspace with path traversal protection), pdf_read, image_describe (through vision models), audio_transcribe, sessions_list/sessions_history/sessions_delete, message_send/message_react, cron_list/cron_add/cron_remove, config_get (auto-redacts secrets), agents_list, memory_get/memory_search, plus the browser tools (browser_open, browser_extract, browser_snapshot, browser_click, browser_type, browser_wait, browser_press, browser_sessions, browser_close, browser_aria).

Some additions that don’t exist in the original OpenClaw: a memory/RAG system with SQLite FTS5 and embeddings (OpenAI, Gemini, Voyage) that automatically syncs workspace files. An OpenAI-compatible API (/v1/chat/completions and /v1/models), so any client that speaks that protocol (Cursor, Continue, Open WebUI) can use FrankClaw as a backend with no adaptation. A ratatui TUI for people who prefer the terminal. Interactive approval of destructive tools before execution.

Smaller things that make a difference in practice. You can configure multiple API keys per provider with round-robin and automatic backoff, so if one key hits the rate limit, the next one takes over. The model catalog already knows context windows and costs of OpenAI and Anthropic models without you having to configure them. URL extraction from messages has a private IP blocklist against SSRF. The command system accepts inline directives (/think, /model) in addition to aliases.

On the operational side: ACP (Agent Client Protocol) over JSON-RPC 2.0 on top of NDJSON for people who want to integrate programmatically. Plugin system with manifests and enable/disable lifecycle. i18n with 9 locales via FRANKCLAW_LANG. Workspace identity files (SOUL.md, IDENTITY.md) to define the bot’s personality per project. Channel health monitor with auto-restart. WebSocket with ping keepalive that survives proxy and tunnel timeouts. frankclaw start/stop/status for people who want to run it as a daemon with PID tracking. And the entire configuration migrated from JSON to TOML.

Hardening: where the real difference is

The audit report we ran on OpenClaw found 7 critical and 9 high vulnerabilities. FrankClaw fixes all of them:

FrankClaw compiles with #![forbid(unsafe_code)] in all 13 crates. Zero unsafe blocks.

And the audit didn’t stop at OpenClaw. We did a per-component audit in 14 phases comparing each part of FrankClaw against the original: channels, providers, runtime, tools, sessions, crypto, cron, webhooks. All documented.

Deploy: how to install

FrankClaw runs with Docker Compose. Three containers: gateway, headless Chromium (for browser tools), and Cloudflare tunnel (to receive webhooks).

1. Clone and configure

git clone https://github.com/akitaonrails/frankclaw.git
cd frankclaw
cp .env.docker.example .env.docker

Edit .env.docker with your keys:

# Providers de IA (preencha os que usar)
OPENAI_API_KEY=
ANTHROPIC_API_KEY=

# Canais (preencha os que quiser usar)
TELEGRAM_BOT_TOKEN=         # via @BotFather
WHATSAPP_TOKEN=             # Meta Business Platform
WHATSAPP_PHONE_ID=
WHATSAPP_VERIFY_TOKEN=
DISCORD_BOT_TOKEN=
SLACK_BOT_TOKEN=
SLACK_APP_TOKEN=

# Embedding providers (só se usar memória/RAG)
# GEMINI_API_KEY=
# VOYAGE_API_KEY=

# Opcional: criptografia de sessions (recomendado)
# Gere com: openssl rand -base64 32
FRANKCLAW_MASTER_KEY=

# Opcional: scan de malware em uploads
VIRUSTOTAL_API_KEY=

2. Configure the gateway

The frankclaw.toml file defines agents, models and channels. Use the wizard or the examples:

# Generate a base config with the web channel
cargo run -- onboard --channel web

# Or copy from the examples
ls examples/channels/

For each channel, the CLI has ready-made templates:

cargo run -- config-example --channel telegram
cargo run -- config-example --channel whatsapp

3. Cloudflare Tunnel (to receive webhooks)

If you’re going to use channels that need a webhook (Telegram, Discord, Slack, WhatsApp), you need a public tunnel. The Docker Compose already includes cloudflared:

# Copy your Cloudflare credentials
cp docker/cloudflared/config.yml.example docker/cloudflared/config.yml
cp ~/.cloudflared/<tunnel-id>.json docker/cloudflared/credentials.json
cp ~/.cloudflared/cert.pem docker/cloudflared/cert.pem
# Edit config.yml with your hostname

4. Bring it up

docker compose up -d

The gateway comes up on port 18789 (internal to Docker). cloudflared routes external traffic. Chromium stays on the internal network for browser tools.

To test locally without Docker:

cargo run -- chat

Opens the interactive REPL straight in the terminal (it now also has a ratatui TUI with dark mode and tabs). No gateway, no webhook. Good for validating that the AI provider is responding before configuring channels.

Validation

cargo run -- check     # validates config
cargo run -- doctor    # full diagnostic
cargo run -- audit     # security audit with severity ratings

audit is the one I like the most. It checks whether you have encryption enabled, whether file permissions are correct, whether webhooks have signature verification, whether the bash tool is in deny-all. It exits with a non-zero exit code when it finds critical issues, so you can drop it in CI.

The development process

The project has 178 commits in ~5 days of work (March 10-16). Almost 57 thousand lines of Rust in 120 files, organized in 13 crates.

The commits tell the story. The first few dozens were scaffolding: workspace structure, basic types, the HTTP/WebSocket gateway, first version of the channel adapters. Mass-generated code, lots of incomplete pieces.

Then the channel adapters started, one by one:

236aa1c - Minimal Discord channel adapter
fd67017 - Minimal Slack channel adapter
9f51373 - Minimal Signal channel adapter
1052e47 - WhatsApp channel webhook adapter
035f86e - Email channel adapter (IMAP inbound, SMTP outbound)

When the basic channels were in place, the IronClaw integration came in one big commit:

c87ab32 - IronClaw-derived features: circuit breaker, retry, leak detection, cache, cost tracking, extended thinking

And then came the hardening. That was the phase where I had to step in manually the most, because Claude generates functional code but doesn’t think about attack vectors on its own:

db34198 - Prompt injection sanitization, external content wrapping, prompt size limit
5719b34 - Optional VirusTotal malware scanning for file uploads
ccd2b2b - Harden input validation across all user-facing entry points
aa918ee - Optional ai-jail sandbox for bash tool
2d7b1df - Security audit command with severity-rated findings
d12cc97 - 3-tier ToolRiskLevel system replacing binary browser mutation flag
21e0c91 - Timing-safe token comparison in WhatsApp, crypto audit tests
e240c1b - Webhook replay prevention with timestamp verification
876a78c - Gateway & media: SSRF redirect validation, filename hardening

22 security hardening commits. Plus 10 more component audits. Each finding became a commit with a fix.

Then came the per-channel audits, each one uncovering different edge cases:

43b085f - Discord audit: HELLO timeout, fatal close codes, message chunking
12c7cff - Telegram audit: caption overflow, parse fallback, edit idempotency
f515062 - WhatsApp audit: message type filtering, send error classification
3c42aff - Slack audit: fatal auth errors, send error classification

Browser tools needed extra attention. A headless Chrome that gets URLs from an LLM is an obvious attack vector:

3217a96 - Browser automation: CDP timeout, SSRF guard, session limits, crash recovery
d98a803 - Gate mutating browser tools behind operator approval
014f56e - Browser screenshot/ARIA tools for accessibility tree inspection

In the more recent commits, the project started diverging from OpenClaw:

5d73c4d - OpenAI-compatible HTTP API (/v1/chat/completions, /v1/models)
d832c36 - Memory/RAG system with SQLite FTS5, embeddings, and file sync
2b05f47 - Interactive tool approval for mutating/destructive tools
49034eb - Web console: dark mode, 8 tabs, focus mode, tool sidebar
9f51a18 - TUI, Gemini/Voyage embeddings, plugin management, ACP protocol
3c0703b - Config migration from JSON to TOML
eb130ad - Channel health monitor with auto-restart and rate limiting
2c3ea7e - Workspace bootstrap files (SOUL.md, IDENTITY.md) to system prompt
9df61bf - Model-aware failover routing, canvas SVG rendering
c7ba108 - WebSocket ping keepalive and auto-reconnect to web console

The OpenAI-compatible API is the one I use the most day to day. Cursor, Continue, Open WebUI, anything that speaks the OpenAI protocol can use FrankClaw as a backend without touching anything on the client side.

The numbers

Compared to OpenClaw:

The numbers aren’t directly comparable. OpenClaw has 21 channel extensions I cut, a more complete web UI, and niche features I didn’t port. But the core (gateway, mainstream channels, providers, runtime, sessions, tools, memory) is there with 22x less code.

How to help (beta testing)

FrankClaw works for basic conversation through Web and Telegram (I tested both). WhatsApp works for simple messages. Discord, Slack, Signal and Email are implemented but haven’t had extensive testing. We haven’t done any complex workflows yet.

If you want to test it: clone the repository, bring it up with Docker Compose, configure at least one channel (Telegram is the easiest) and try to use it normally. Send messages, test tool calls, try to break the system. Open Issues on GitHub with whatever you find.

What I know needs more eyes: workflows with tools (browser, bash, MCP), subagent orchestration, failover between providers, session persistence with encryption, smart routing between models, scheduled jobs, the memory/RAG system, and the OpenAI-compatible API. Basically everything that goes beyond “send a message, get a reply.”

You don’t have to be a Rust developer. The bigger value is in using the system in ways I didn’t think of and finding the edge cases that only show up under real use.

FrankClaw doesn’t replace OpenClaw today. OpenClaw has more channels, more features, more people working on it. But it carries the weight of over a million lines of TypeScript generated at 50 commits per day by dozens of contributors, with documented critical vulnerabilities. FrankClaw is the alternative for anyone who looks at that and thinks “I’m not running this code on my machine.”

But I’ll be honest: as fun as it was to build, I personally don’t know if I need this. FrankClaw is a generic gateway, designed to be flexible, to connect any channel to any provider, with an agent runtime, tools, subagents, jobs, hooks. It’s a lot of infrastructure.

What I’ve discovered over the last few months is that I can build custom bots for specific tasks much faster. In 1 day I have a bot working, focused on what I need, without carrying the weight of a generic framework. That’s what I did with Marvin on the newsletter project, for instance. A custom-built Discord bot that does exactly what I need and nothing else.

A generic gateway like FrankClaw makes more sense for someone who wants a unified interface between several chat channels and several AI models without coding. If that’s your case, give it a shot. If you’re a developer and you know what you want, maybe a custom bot will serve you better. Up to you.

The repository is here. AGPL-3.0.