DEV Community: Pradeep Kumar

Apple Is Tightening Full Disk Access on macOS, and AI Agents Are the Reason

Pradeep Kumar — Sun, 04 Oct 2026 12:28:28 +0000

Apple is going to make it harder to give an app Full Disk Access on the Mac. The reason is simple: AI agents have made that level of access riskier to hand out.

The announcement is short. Apple gave no dates and no details on how the new controls will work. Even so, it says a lot about where desktop AI is heading.

What Full Disk Access does

Full Disk Access is a switch in System Settings, under Privacy & Security. Turn it on for an app, and that app can reach data macOS normally protects. That includes files, mail, messages and browsing history.

Apple says the permission largely sidesteps the privacy controls that apps usually have to respect. It exists so backup apps can do their job, since a backup tool has to copy everything.

That design made sense for backups. It makes less sense for software that can read, decide and act on its own.

What Apple said

Apple posted the note on its developer news page on October 2. The main points:

Some developers use Full Disk Access in ways that put users at risk. It can expose everything on a system without the user fully understanding that.
For communication apps, the exposure reaches past the user. It can also compromise the privacy of the people they talk to.
Apple will add controls so that anyone who really wants to grant this access can only do it through "very explicit user action."
As AI agents become more capable and autonomous, Apple expects the risks of this access to grow a great deal.

Apple's note doesn't name any app or company.

What set it off

The timing lines up with two recent stories, and TechCrunch tied Apple's move to both.

The first is about Muse, Meta's AI agent, which has a Mac app. Inc. columnist Jason Aten reported that Muse knew the content of his private messages, even though he says he never gave it permission. He said Full Disk Access was off at the time. When he asked Muse how it knew, it told him it was syncing his device notifications.

Meta disputes this. Meta VP of Communications Andy Stone said the Messages integration is opt-in and needs both Full Disk Access and a Messages connector.

Meta Superintelligence Labs executive David Singleton added that the setup takes three separate permission steps. He said macOS protections can't be bypassed even if the app had a bug, and that Muse's own explanation of what happened was wrong.

Reports so far don't show the disagreement being settled.

The second story is a Wired report on a flaw in ChatGPT's Mac app that could have let hackers reach sensitive data.

Both stories point at the same worry: desktop AI apps sit close to a lot of personal data. Apple hasn't said either one caused its decision.

Why agents change the picture

A backup app copies files and does little else. An agent reads, decides and acts. It can open a file, summarize it, send a message or run a command.

Add broad access and the risk grows. An agent can also be steered by what it reads. Hidden instructions in a document or web page can push it to do things the user never asked for. Security researchers call this prompt injection.

There's a simpler issue too. macOS grants this permission per app, not per task. Once it's on, the app can reach everything the permission covers, whether or not the current job needs it.

And agents often run inside other apps. An agent launched from Terminal inherits whatever permissions Terminal has.

What Apple hasn't said

Apple hasn't said what the new controls look like, which version of macOS will get them, or when. TechCrunch reports that Apple didn't respond to its questions about the change.

A few things are worth watching once details appear:

Whether apps that already have Full Disk Access keep it
Whether backup tools get a separate path from AI apps
How much friction the new approval step adds

These are open questions, not reported plans.

What you can do now

You don't need to wait for Apple.

Open System Settings, then Privacy & Security, then Full Disk Access.
Switch off anything you don't recognize or no longer use.
For AI apps, grant specific folders instead. You'll find those options under Files & Folders in the same section.
Check Terminal and code editors too. An agent running inside them inherits their access.
Keep macOS and your apps up to date.

The takeaway

Full Disk Access was built with backup apps in mind. Apple now says AI agents have changed the risk.

The details are still to come, but the direction is clear. Handing an app everything on your Mac should take a deliberate choice.

Sources

Apple Developer: Updates to Full Disk Access in macOS (October 2, 2026)
TechCrunch: Apple says it's tightening macOS 'Full Disk Access' controls due to new risks from AI agents
TechCrunch: Meta disputes claim that Muse read a user's private messages without permission
Inc.: Jason Aten's report on Muse
Wired: A Flaw in ChatGPT's Mac App Could Have Let Hackers Grab Sensitive Data

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

1,313 Kernel CVEs in One Debian Update: Alarm Bell or Accounting Quirk?

Pradeep Kumar — Sun, 04 Oct 2026 11:37:36 +0000

Debian's security team published DSA-6528-1 with a familiar opening line: several vulnerabilities have been discovered in the Linux kernel that may lead to privilege escalation, denial of service, or information leaks. What follows is unusual. The CVE list fills most of the advisory page. I counted it: 1,313 unique CVE IDs in a single update to the Linux 6.12 LTS kernel that powers Debian 13 "Trixie". 9to5Linux called it probably the biggest kernel security release ever.

The number sounds frightening, but it says less about the kernel's health than you might expect. Here is what actually happened, why the count is so large, and what you should do about it.

What Debian shipped

DSA-6528-1 moves Debian 13 to kernel package version 6.12.111-1. Debian's security tracker shows trixie's previous kernel, 6.12.107-1, as vulnerable and 6.12.111-1 in the security repository as the fix. The advisory covers only trixie, the current stable release. Debian 12 "bookworm" kernels are handled in separate advisories.

The opening sentence isn't a clue to severity. It's the standard summary for Debian kernel advisories; the May update to 6.12.88-1 (DSA-6274-1), for example, is summarized with the same three impact categories.

The CVE IDs themselves are telling. Only 18 of the 1,313 carry 2024 or 2025 identifiers (3 and 15). The other 1,295 are 2026 IDs. The year in a CVE ID reflects when the number was issued, not when the bug was written, so this is mostly a batch of recently issued numbers.

Why the number is so big

Three things combine.

1. The kernel assigns CVEs very generously, by design

Since early 2024 the Linux kernel project has been its own CVE Numbering Authority, able to issue identifiers itself. Its documentation explains the approach. Changes that are potentially security issues are identified during the normal stable release process and get CVE numbers automatically. The reasoning is that almost any kernel bug might be exploitable, but exploitability often isn't evident when the bug is fixed, so the team is "overly cautious" and assigns a number to any bugfix it identifies. Two rules limit the scope: CVEs are assigned only after a fix lands in a stable tree, and none are assigned for kernel versions the stable team no longer supports.

The effect on volume has been large. Greg Kroah-Hartman has written that the kernel went from nothing to third among CVE issuers in 2024 and first in 2025, though in a June podcast he described it as trading places with GitHub's pooled CNA, so the exact rank depends on who is counted. By NVD-based counts, 2025 had 5,681 kernel CVEs and 2026 had reached 7,178 by the end of September.

2. Debian batches its kernel fixes

9to5Linux notes that Debian Stable doesn't ship every upstream stable point release as its own security advisory, so fixes pile up and arrive together. A big number in one advisory partly reflects how much accumulated between advisories.

3. AI-assisted review is finding more bugs

Linux 7.2-rc7, released August 9, carried more than 400 fixes from over 230 contributors. Linus Torvalds called this the new normal, with many of the fixes coming from review by AI tools. The tools review and report; humans still write and submit the patches. One fix in that release closed a race condition in ptdump, the kernel's page-table display interface, that could cause a use-after-free and traced back to changes made in 2018. It's worth getting the credit right: Google's syzbot fuzzer flagged it in June, and a developer used an AI model to help trace the root cause. AI is one part of a wider tooling surge.

The surge has a cost. In May, Torvalds said duplicate AI-generated bug reports had left the kernel's private security list almost unmanageable. In July, Kroah-Hartman wrote on oss-security that the number of LLM-found issues is only on the rise and that digging out will take at least 18 months.

More bugs found means more fixes, and more fixes means more CVEs. The pipeline is working as designed.

Is the kernel getting less secure?

Probably not, though the answer depends on what you mean by "secure." A few data points:

The tracker's NVD-based data, with entries through September 29, shows 7,178 kernel CVEs published in 2026, including 1,651 in August and 2,118 in September. Only 3 are in CISA's Known Exploited Vulnerabilities (KEV) catalog. None of those three is in DSA-6528-1.
Counts are lumpy because the queue is processed in bulk. When 432 kernel CVEs appeared over July 19 and 20, Kroah-Hartman explained that this was not a wave of new vulnerabilities. It was a review backlog, pending for weeks because of six straight weeks of conferences and vacations, that finally got published. The burst led Akamai's Jan Schaumann to argue that prioritizing individual kernel changes is no longer feasible.
Severity data is thin and noisy. The tracker lists 2,312 of the 7,178 as still awaiting NVD scoring. That's partly because NIST announced on April 15 that it will enrich only CVEs that are in KEV, used by the federal government, or covered by critical-software rules. Among the scored ones, 3,278 of 4,866 (my arithmetic) are rated High or Critical, yet only 3 are known to be exploited. Treat the scores as a weak signal.
9to5Linux's reading is that most of the 1,313 are low-severity, highly conditional, or in subsystems irrelevant to any given machine, so this isn't 1,313 independently critical issues.

The kernel's own documents point the same way. Its threat model lists whole classes of bugs it does not count as vulnerabilities, such as problems triggered only by a crafted filesystem image, a fake USB device, physical access, or actions by users who already hold the needed privileges. CVE assignment errs toward including these cases. A CVE number is a flag on a fix, not a verdict on danger.

The policy has critics. When it was announced in 2024, kernel developer Josh Poimboeuf argued that a bug isn't automatically a vulnerability, and that issuing CVEs without any analysis of how a bug could be exploited makes them close to useless. That debate has not gone away. It has only become more pressing as the count has grown.

What a real kernel emergency looks like

For contrast, consider Copy Fail (CVE-2026-31431). It isn't in this advisory's list, and I include it only to show the other end of the scale. Researchers at Theori and Xint disclosed it in late April. It is a local privilege escalation bug in the kernel's authentication crypto template that lets an unprivileged user get root with a 732-byte Python exploit. Three individually harmless changes made in 2011, 2015 and 2017 combined to create it. CISA added it to the KEV catalog on May 1. Microsoft noted that it is not remotely exploitable on its own but becomes highly impactful when chained with an initial foothold such as SSH access, a malicious CI job or a compromised container. Kaspersky's analysis flagged a serious risk for containerized environments, since Docker, LXC and Kubernetes grant containers access to the affected AF_ALG subsystem when the algif_aead module is loaded.

The other two 2026 kernel entries in KEV, per the tracker, are a netfilter bridge fix (CVE-2026-53266) and an IPv6 fix (CVE-2026-53362). Neither is in this batch either.

Copy Fail had a name, a public exploit, a clear affected population and a government deadline. Most of the 1,313 have none of those things. A CVE number tells you very little on its own. What tells you something is whether the affected code is reachable on your system, whether an exploit exists, and whether your exposure model includes untrusted local users, containers or shared hosts.

What to do

If you run Debian 13, update and reboot. A kernel update doesn't take effect until the new kernel is running.

uname -v                      # shows your running kernel's Debian package version
sudo apt update && sudo apt full-upgrade
sudo reboot
uname -v                      # confirm you're now on 6.12.111-1 or later

If you run fleets or compliance scanners, expect ticket floods and plan for them. A scanner that opens one ticket per CVE will generate over a thousand from this single update. Kroah-Hartman's own advice in that oss-security thread is to run the latest supported kernel everywhere and update regularly. For those who can't track upstream themselves, he named Debian and Yocto as good fallbacks because of their security practices. He also described a practical filter: intersect the files each CVE touches with the files you actually build into your kernel, which he says normally leaves about 10% of the total on a typical system.

Don't cherry-pick "important" patches. The kernel documentation says it is best to take all released kernel changes, because they are tested together, and that the fix for a problem is often spread across several commits. It also says to assume that some changes without a CVE might be relevant.

For prioritizing what remains, don't lean on NVD scores alone, since many kernel CVEs have none. Weigh KEV status, public exploit availability and whether your exposure model (shared hosts, containers, untrusted local users) matches the bug.

For general hardening, the standard advice applies. Unload or blacklist modules you don't use, and restrict unprivileged user namespaces and exotic socket families such as AF_ALG where your workload allows. Copy Fail is a reminder that a rarely used interface can matter a great deal.

The bottom line

DSA-6528-1 matters, and you should install it. But 1,313 is a measure of how the kernel counts fixes, how Debian batches them, and how many more bugs are being found, more than a measure of danger. The harder problem is human. As LinuxNews.de puts it, the bottleneck ahead is less about issuing CVE numbers than about the limited time maintainers have for review, stable backports and regression testing. Defenders face the mirror image: no team can read a thousand CVEs a month, so the winners will be the ones who automate "does this apply to my system?"

If AI-assisted review keeps improving, four-digit CVE batches may become routine. The skill worth building now is reading them well.

Sources and further reading

Method note: the 1,313 figure comes from counting the CVE IDs in the advisory text as published by LWN (329 lines, 1,313 unique IDs, no duplicates). Statistics from the tracker are NVD-based, come from a third-party aggregator and change daily, so treat them as approximate.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Testing if working

Pradeep Kumar — Sat, 03 Oct 2026 17:48:14 +0000

Jsdkkdkdkdkdkkdkdkdkdkdkdjd

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Build a Small LLM From Scratch: A Tested GPT in PyTorch

Pradeep Kumar — Sat, 03 Oct 2026 05:06:10 +0000

You can train a real language model on a laptop CPU during a coffee break. It won't be smart. It will have every part a big one has.

This post builds one. It's a decoder-only transformer in PyTorch, the same family as GPT-2, with 813,440 parameters. It trains on Tiny Shakespeare and ends at a validation loss of 1.78.

All the code ran before it went into this post. The full project is in tinygpt.zip: model, training script, sampler, baselines, 25 tests, and the trained checkpoint (out/best.pt). Every number below comes from one run on a single CPU core, with Python 3.12.3 and PyTorch 2.14.0.

What a language model actually does

A language model predicts the next token. That's the whole job.

Feed it To be or not to b and it returns a probability for every possible next character. Training pushes those probabilities toward what the text really says. The loss is cross-entropy: the negative log of the probability the model gave the correct character.

Loss also gives you a floor to compare against. A model that guesses uniformly across our 65 characters scores ln(65) = 4.174. An untrained network should land right there, and ours does.

Chat models work the same way, with subword tokens, billions of parameters, and more training stages on top. The core loop doesn't change.

We'll use characters instead of subword tokens. The vocabulary is 65 symbols, so there's no tokenizer to train.

The price is that the model spends capacity learning to spell. GPT-2 used byte pair encoding with a 50,257-token vocabulary instead.

The architecture

Each block has two sublayers. Both are wrapped in a residual connection, and both normalize their input first.

Moving LayerNorm to the input of each sublayer is one of the changes the GPT-2 paper made to the original transformer. It's why this design is called pre-LN. The original Transformer paper, Attention Is All You Need, applied it after.

Setup

pip install torch numpy pytest
unzip tinygpt.zip
cd tinygpt
python get_data.py

get_data.py downloads Tiny Shakespeare from Andrej Karpathy's char-rnn repo. The file is 1,115,394 bytes.

On macOS with a Python from python.org, that download can fail with a CERTIFICATE_VERIFY_FAILED error. The script catches this and falls back to curl. The FAQ at the end explains the real fix.

Files in the project:

data.py: character tokenizer, train/validation split, batching
model.py: the GPT itself
train.py: training loop, learning-rate schedule, evaluation
sample.py: text generation from a checkpoint
checkpoint.py: save and load
baselines.py: unigram and bigram losses for comparison
tests/test_tinygpt.py: 25 tests

Step 1: Data

data.py

"""Character tokenizer and batching for tinygpt."""
from pathlib import Path

import torch

class CharTokenizer:
    """Maps every distinct character in the corpus to an integer id."""

    def __init__(self, chars):
        self.chars = list(chars)
        self.stoi = {c: i for i, c in enumerate(self.chars)}
        self.itos = {i: c for i, c in enumerate(self.chars)}

    @classmethod
    def from_text(cls, text):
        return cls(sorted(set(text)))

    def start_id(self):
        """Id that starts generation: newline if the corpus has one, else id 0."""
        return self.stoi.get("\n", 0)

    @property
    def vocab_size(self):
        return len(self.chars)

    def encode(self, s):
        return [self.stoi[c] for c in s]

    def decode(self, ids):
        return "".join(self.itos[int(i)] for i in ids)

def load_corpus(path, val_fraction=0.1):
    """Read a text file and return (tokenizer, train_ids, val_ids).

    The split is contiguous: the last `val_fraction` of the file is
    validation data. Shuffling characters would leak train text into val.
    """
    text = Path(path).read_text(encoding="utf-8")
    tok = CharTokenizer.from_text(text)
    ids = torch.tensor(tok.encode(text), dtype=torch.long)
    n_val = int(len(ids) * val_fraction)
    return tok, ids[:-n_val], ids[-n_val:]

def get_batch(data, batch_size, block_size, device="cpu", generator=None):
    """Sample `batch_size` random windows.

    x is a window of block_size tokens. y is the same window shifted one
    position to the right, so y[t] is the token that follows x[t].
    """
    hi = len(data) - block_size - 1
    if hi <= 0:
        raise ValueError(f"need at least {block_size + 2} tokens, got {len(data)}")
    starts = torch.randint(0, hi, (batch_size,), generator=generator)
    x = torch.stack([data[s : s + block_size] for s in starts])
    y = torch.stack([data[s + 1 : s + 1 + block_size] for s in starts])
    return x.to(device), y.to(device)

The tokenizer sorts the distinct characters in the file and numbers them. Sorting makes the mapping deterministic. start_id returns the newline's id if the corpus has one, and generation starts from it when you give no prompt.

from data import load_corpus

tok, train_ids, val_ids = load_corpus("data/input.txt")
print(tok.vocab_size, len(train_ids), len(val_ids))
print(repr("".join(tok.chars)))
print(tok.encode("First"))
print(tok.decode(tok.encode("First")))

65 1003855 111539
"\n !$&',-.3:;?ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
[18, 47, 56, 57, 58]
First

The vocabulary holds a newline, a space, a handful of punctuation marks, the digit 3, and both alphabets. That's 65 symbols. The last 10% of the text becomes validation data.

The split is contiguous on purpose. A random split would scatter overlapping windows of the same passages across both sets, and validation loss would stop measuring anything.

get_batch samples random windows. The target y is the input x shifted one position right. It refuses data shorter than block_size + 2 tokens.

import torch
from data import load_corpus, get_batch

tok, train_ids, val_ids = load_corpus("data/input.txt")
torch.manual_seed(1337)
x, y = get_batch(train_ids, batch_size=1, block_size=8)
print(repr(tok.decode(x[0])))
print(repr(tok.decode(y[0])))

"Let's he"
"et's hea"

Look at the two strings. From L the target is e, from Le it's t, from Let it's '. One window of 8 characters gives you 8 training examples at once.

Step 2: The model

model.py, imports and config

"""A small GPT: decoder-only transformer with pre-LayerNorm blocks."""
import math
from dataclasses import dataclass, asdict

import torch
import torch.nn as nn
import torch.nn.functional as F

@dataclass
class GPTConfig:
    vocab_size: int = 65
    block_size: int = 128   # maximum context length
    n_layer: int = 4
    n_head: int = 4
    n_embd: int = 128
    dropout: float = 0.1

    def to_dict(self):
        return asdict(self)

The config is small on purpose: 4 layers, 4 heads, 128 dimensions, and a context of 128 characters. Each head works on 128 / 4 = 32 dimensions.

Causal self-attention

model.py, the attention layer

class CausalSelfAttention(nn.Module):
    def __init__(self, cfg):
        super().__init__()
        assert cfg.n_embd % cfg.n_head == 0, "n_embd must divide by n_head"
        self.n_head = cfg.n_head
        self.qkv = nn.Linear(cfg.n_embd, 3 * cfg.n_embd, bias=False)
        self.proj = nn.Linear(cfg.n_embd, cfg.n_embd, bias=False)
        self.attn_drop = nn.Dropout(cfg.dropout)
        self.resid_drop = nn.Dropout(cfg.dropout)
        # Lower-triangular matrix: position t may look at positions 0..t only.
        mask = torch.tril(torch.ones(cfg.block_size, cfg.block_size))
        self.register_buffer(
            "mask", mask.view(1, 1, cfg.block_size, cfg.block_size), persistent=False
        )

    def forward(self, x):
        B, T, C = x.shape
        hs = C // self.n_head  # head size
        q, k, v = self.qkv(x).split(C, dim=2)
        # (B, T, C) -> (B, n_head, T, hs)
        q = q.view(B, T, self.n_head, hs).transpose(1, 2)
        k = k.view(B, T, self.n_head, hs).transpose(1, 2)
        v = v.view(B, T, self.n_head, hs).transpose(1, 2)

        att = (q @ k.transpose(-2, -1)) * (hs ** -0.5)          # (B, nh, T, T)
        att = att.masked_fill(self.mask[:, :, :T, :T] == 0, float("-inf"))
        att = self.attn_drop(F.softmax(att, dim=-1))
        y = att @ v                                              # (B, nh, T, hs)
        y = y.transpose(1, 2).contiguous().view(B, T, C)         # merge heads
        return self.resid_drop(self.proj(y))

One linear layer produces queries, keys and values together, and split cuts them apart. The view and transpose calls reshape each from (B, T, 128) to (B, 4, T, 32), so every head gets its own 32 dimensions.

The scores are q @ k.T, scaled by hs ** -0.5. The scaling comes from the scaled dot-product attention in the Transformer paper. The authors suspect that for large head sizes the dot products grow in magnitude, which pushes softmax into regions with extremely small gradients.

The mask is the part that makes this a language model. Position t may look at positions 0..t and nothing later. Here's the mask for 4 positions, and what softmax does with it:

import torch

mask = torch.tril(torch.ones(4, 4))
print(mask)

torch.manual_seed(0)
scores = torch.randn(4, 4).masked_fill(mask == 0, float("-inf"))
print(torch.softmax(scores, dim=-1).round(decimals=2))

tensor([[1., 0., 0., 0.],
        [1., 1., 0., 0.],
        [1., 1., 1., 0.],
        [1., 1., 1., 1.]])
tensor([[1.0000, 0.0000, 0.0000, 0.0000],
        [0.5400, 0.4600, 0.0000, 0.0000],
        [0.4500, 0.0900, 0.4600, 0.0000],
        [0.1300, 0.4100, 0.3600, 0.0900]])

Masked scores become -inf before softmax, so they turn into exact zeros. The second row spreads its weight across positions 0 and 1 only. Before rounding, every row sums to 1.

PyTorch ships a fused version of this in scaled_dot_product_attention, with an is_causal flag. We write it by hand so you can see every step. A test later in this post checks that our layer matches PyTorch's output.

MLP, block, and the full model

model.py, MLP and block

class MLP(nn.Module):
    def __init__(self, cfg):
        super().__init__()
        self.fc = nn.Linear(cfg.n_embd, 4 * cfg.n_embd, bias=False)
        self.proj = nn.Linear(4 * cfg.n_embd, cfg.n_embd, bias=False)
        self.drop = nn.Dropout(cfg.dropout)

    def forward(self, x):
        return self.drop(self.proj(F.gelu(self.fc(x))))

class Block(nn.Module):
    def __init__(self, cfg):
        super().__init__()
        self.ln1 = nn.LayerNorm(cfg.n_embd)
        self.attn = CausalSelfAttention(cfg)
        self.ln2 = nn.LayerNorm(cfg.n_embd)
        self.mlp = MLP(cfg)

    def forward(self, x):
        x = x + self.attn(self.ln1(x))
        x = x + self.mlp(self.ln2(x))
        return x

The MLP expands each position from 128 to 512 dimensions, applies GELU, and projects back. Attention mixes information across positions. The MLP transforms each position on its own.

The block adds each sublayer's output to its input. Those residual paths let gradients flow straight through a deep stack.

model.py, the GPT class

class GPT(nn.Module):
    def __init__(self, cfg):
        super().__init__()
        self.cfg = cfg
        self.wte = nn.Embedding(cfg.vocab_size, cfg.n_embd)   # token embeddings
        self.wpe = nn.Embedding(cfg.block_size, cfg.n_embd)   # position embeddings
        self.drop = nn.Dropout(cfg.dropout)
        self.blocks = nn.ModuleList([Block(cfg) for _ in range(cfg.n_layer)])
        self.ln_f = nn.LayerNorm(cfg.n_embd)
        self.lm_head = nn.Linear(cfg.n_embd, cfg.vocab_size, bias=False)
        self.lm_head.weight = self.wte.weight                 # weight tying

        self.apply(self._init_weights)
        # GPT-2 trick: shrink the layers that write into the residual stream,
        # so the stream's variance doesn't grow with depth.
        for name, p in self.named_parameters():
            if name.endswith("attn.proj.weight") or name.endswith("mlp.proj.weight"):
                nn.init.normal_(p, mean=0.0, std=0.02 / math.sqrt(2 * cfg.n_layer))

    @staticmethod
    def _init_weights(module):
        if isinstance(module, (nn.Linear, nn.Embedding)):
            nn.init.normal_(module.weight, mean=0.0, std=0.02)

    def forward(self, idx, targets=None):
        B, T = idx.shape
        assert T <= self.cfg.block_size, f"sequence length {T} > block_size {self.cfg.block_size}"
        pos = torch.arange(T, device=idx.device)
        x = self.drop(self.wte(idx) + self.wpe(pos))
        for block in self.blocks:
            x = block(x)
        logits = self.lm_head(self.ln_f(x))                   # (B, T, vocab)
        loss = None
        if targets is not None:
            loss = F.cross_entropy(logits.view(-1, logits.size(-1)), targets.view(-1))
        return logits, loss

    @torch.no_grad()
    def generate(self, idx, max_new_tokens, temperature=1.0, top_k=None, generator=None):
        assert temperature > 0, "use top_k=1 for greedy decoding"
        was_training = self.training
        self.eval()
        for _ in range(max_new_tokens):
            ctx = idx[:, -self.cfg.block_size :]              # crop to the window
            logits, _ = self(ctx)
            logits = logits[:, -1, :] / temperature           # last position only
            if top_k is not None:
                kth = torch.topk(logits, min(top_k, logits.size(-1))).values[:, [-1]]
                logits = logits.masked_fill(logits < kth, float("-inf"))
            probs = F.softmax(logits, dim=-1)
            nxt = torch.multinomial(probs, num_samples=1, generator=generator)
            idx = torch.cat([idx, nxt], dim=1)
        self.train(was_training)
        return idx

    def num_params(self):
        # parameters() counts the tied embedding/head matrix once
        return sum(p.numel() for p in self.parameters())

Three details in this class matter more than they look.

First, the token embedding and the output head share one weight matrix. The input side turns an id into a vector, and the output side turns a vector back into scores over ids. Tying them saves 65 × 128 = 8,320 parameters, and the original Transformer paper shares its embedding and pre-softmax matrices the same way.

Second, initialization: every weight starts from a normal distribution with standard deviation 0.02. The two projections that write into the residual stream, attn.proj and mlp.proj, get that value divided by sqrt(2 * n_layer).

The GPT-2 paper describes scaling residual layers by 1/√N, where N is the number of residual layers. Each block contributes two, hence the 2 *. nanoGPT implements it the same way.

Third, generate crops the context to the last block_size tokens. The position embedding table only has 128 rows.

Let's count parameters and check the untrained loss.

import math
import torch
from data import load_corpus, get_batch
from model import GPT, GPTConfig

tok, train_ids, val_ids = load_corpus("data/input.txt")
torch.manual_seed(1337)
model = GPT(GPTConfig(vocab_size=tok.vocab_size))
print(f"{model.num_params():,} parameters")
print("token embedding :", model.wte.weight.numel())
print("position embed  :", model.wpe.weight.numel())
print("one block       :", sum(p.numel() for p in model.blocks[0].parameters()))
print("final LayerNorm :", sum(p.numel() for p in model.ln_f.parameters()))

x, y = get_batch(train_ids, 32, 128)
logits, loss = model(x, y)
print(logits.shape)
print(f"loss {loss.item():.4f}   ln(65) = {math.log(65):.4f}")

813,440 parameters
token embedding : 8320
position embed  : 16384
one block       : 197120
final LayerNorm : 256
torch.Size([32, 128, 65])
loss 4.1827   ln(65) = 4.1744

The numbers line up with the architecture:

Part	Parameters
Token embedding (65 × 128)	8,320
Position embedding (128 × 128)	16,384
Each block (4 of them)	197,120
Final LayerNorm	256
Total	813,440

A block holds 65,536 attention weights (4 × 128²), 131,072 MLP weights (8 × 128²), and 512 LayerNorm parameters. The untrained loss of 4.1827 sits right on ln(65) = 4.1744.

Step 3: Test it before you train it

Training a broken transformer wastes an afternoon and doesn't announce itself. The loss still goes down. Three checks catch most bugs first.

The first is the one you just saw: initial loss near ln(vocab size). The second is a leak test. Change a token at position 10 and confirm that nothing before position 10 moves.

tests/test_tinygpt.py

def test_model_cannot_see_the_future():
    torch.manual_seed(0)
    model = GPT(small_cfg()).eval()
    a = torch.randint(0, 20, (1, 16))
    b = a.clone()
    b[0, 10] = (b[0, 10] + 1) % 20          # change the token at position 10
    la, _ = model(a)
    lb, _ = model(b)
    assert torch.allclose(la[:, :10], lb[:, :10], atol=1e-6)   # earlier positions unchanged
    assert not torch.allclose(la[:, 10:], lb[:, 10:])          # position 10 onward changes

A model that can see the answer gets near-zero training loss and generates junk. This test is what tells you the mask works.

The third check is overfitting. A healthy model can memorize one small batch.

def test_can_overfit_one_batch():
    torch.manual_seed(0)
    model = GPT(small_cfg())
    opt = torch.optim.AdamW(model.parameters(), lr=3e-3)
    x = torch.randint(0, 20, (4, 16))
    y = torch.randint(0, 20, (4, 16))
    first = model(x, y)[1].item()
    for _ in range(300):
        _, loss = model(x, y)
        opt.zero_grad()
        loss.backward()
        opt.step()
    assert first > 2.5
    assert loss.item() < 0.1

If the loss can't reach zero on 4 sequences, something is wrong in the forward pass or the optimizer.

Step 4: Train

train.py, schedule, optimizer and evaluation

def get_lr(step, max_steps, lr, min_lr, warmup):
    """Linear warmup, then cosine decay from lr down to min_lr."""
    if step < warmup:
        return lr * (step + 1) / warmup
    if step >= max_steps:
        return min_lr
    progress = (step - warmup) / (max_steps - warmup)
    return min_lr + 0.5 * (1 + math.cos(math.pi * progress)) * (lr - min_lr)

def make_optimizer(model, lr, weight_decay, betas=(0.9, 0.99)):
    """AdamW that applies weight decay to matrices only, not to biases or norms."""
    decay = [p for p in model.parameters() if p.dim() >= 2]
    no_decay = [p for p in model.parameters() if p.dim() < 2]
    groups = [
        {"params": decay, "weight_decay": weight_decay},
        {"params": no_decay, "weight_decay": 0.0},
    ]
    return torch.optim.AdamW(groups, lr=lr, betas=betas)

@torch.no_grad()
def estimate_loss(model, splits, batch_size, block_size, eval_iters, device):
    model.eval()
    out = {}
    for name, data in splits.items():
        losses = torch.zeros(eval_iters)
        for i in range(eval_iters):
            x, y = get_batch(data, batch_size, block_size, device)
            losses[i] = model(x, y)[1].item()
        out[name] = losses.mean().item()
    model.train()
    return out

The learning rate warms up over 100 steps to 1e-3, then follows a cosine curve down to 1e-4. Warmup keeps the first updates small while Adam's statistics settle.

AdamW uses betas of (0.9, 0.99). The second value matches nanoGPT's Shakespeare config, which raises it because each step sees few tokens.

Weight decay of 0.1 applies to weight matrices only. Biases and LayerNorm parameters are excluded, and a test checks the split.

estimate_loss averages over several batches and switches to eval mode, which turns dropout off. It switches back afterward.

train.py, the training loop (excerpt from main)

torch.manual_seed(args.seed)
device = pick_device(args.device)
out = Path(args.out)
out.mkdir(parents=True, exist_ok=True)

tok, train_ids, val_ids = load_corpus(args.data)
cfg = GPTConfig(
    vocab_size=tok.vocab_size, block_size=args.block_size, n_layer=args.n_layer,
    n_head=args.n_head, n_embd=args.n_embd, dropout=args.dropout,
)
model = GPT(cfg).to(device)
opt = make_optimizer(model, args.lr, args.weight_decay)
splits = {"train": train_ids, "val": val_ids}
print(f"device={device} params={model.num_params():,} vocab={tok.vocab_size} "
      f"train_tokens={len(train_ids):,} val_tokens={len(val_ids):,}")

sample_gen = torch.Generator(device=device).manual_seed(0)
prompt = torch.tensor([[tok.start_id()]], device=device)
history, samples, best_val = [], [], float("inf")
t0 = time.time()

for step in range(args.max_steps + 1):
    if step % args.eval_interval == 0 or step == args.max_steps:
        losses = estimate_loss(model, splits, args.batch_size, args.block_size,
                               args.eval_iters, device)
        text = tok.decode(model.generate(prompt, 200, generator=sample_gen)[0].tolist())
        history.append({"step": step, **losses, "seconds": round(time.time() - t0)})
        samples.append({"step": step, "text": text})
        print(f"step {step:5d} | train {losses['train']:.4f} | val {losses['val']:.4f} "
              f"| {time.time() - t0:6.0f}s", flush=True)
        if losses["val"] < best_val:
            best_val = losses["val"]
            save_checkpoint(out / "best.pt", model, tok, step, best_val)
        (out / "history.json").write_text(json.dumps(history, indent=2))
        (out / "samples.json").write_text(json.dumps(samples, indent=2))
    if step == args.max_steps:
        break

    lr = get_lr(step, args.max_steps, args.lr, args.min_lr, args.warmup)
    for g in opt.param_groups:
        g["lr"] = lr
    x, y = get_batch(train_ids, args.batch_size, args.block_size, device)
    _, loss = model(x, y)
    opt.zero_grad(set_to_none=True)
    loss.backward()
    torch.nn.utils.clip_grad_norm_(model.parameters(), args.grad_clip)
    opt.step()

Each step draws a batch, computes the loss, backpropagates, clips the gradient norm to 1.0, and updates. Every 250 steps it evaluates, generates a 200-character sample, and saves best.pt if validation loss improved.

A step processes 32 × 128 = 4,096 characters. Two thousand steps is 8,192,000 characters, or about 8.2 passes over the 1,003,855-character training split.

Run it:

python train.py --data data/input.txt --out out

device=cpu params=813,440 vocab=65 train_tokens=1,003,855 val_tokens=111,539
step     0 | train 4.1835 | val 4.1799 |     13s
step   250 | train 2.3962 | val 2.4186 |    160s
step   500 | train 2.1546 | val 2.1950 |    307s
step   750 | train 1.9662 | val 2.0432 |    450s
step  1000 | train 1.8321 | val 1.9598 |    595s
step  1250 | train 1.7527 | val 1.8790 |    740s
step  1500 | train 1.6836 | val 1.8391 |    891s
step  1750 | train 1.6436 | val 1.8080 |   1044s
step  2000 | train 1.6215 | val 1.7838 |   1188s
best val loss 1.7838 (2.573 bits/char)

That took 1,188 seconds on one CPU core. The best validation loss was 1.7838, which is 2.573 bits per character.

The samples that train.py writes to out/samples.json show the model learning in stages. These are the first 110 characters at four checkpoints:

step 0
t3ZxjmhPPdkARxLsXltUWHoHca ?eghkyy&&NdkIgAlsvSBUMyccRD$BygXOfntw
kVrM h&?j SJR!sOEHelC!BTg3xUhPRCs3Ma--3KypMrW

step 250
Inol3 f pifie-mily mpoennd shay tinte.

The beome igle inkee he them.

KES:
S y tonoong sof themyowangh.
HOn d

step 1000
DORY:
Not fieve my that that
Romest thear not ut .
LUCED:
What the gelivl the. Shou jroses.
Find With you lets

step 2000
Eing Noices you, for villing a by like whose mork hard,
Shall appy'd mired: thou almp the place!

CORIOLANUS:

At step 0 it's noise drawn from all 65 symbols. By step 250 it has word-length chunks, sentence-ending periods, and even a stray speaker tag (KES:).

By step 1000 it knows that a name in capitals followed by a colon starts a speech. By step 2000 the format is solid, and many of the words are still not real ones.

The training loss ends at 1.6215 and validation at 1.7838. That gap of 0.16 is small, and validation was still falling at the last checkpoint, so overfitting isn't what limits this run.

The learning rate also decays to 1e-4 by step 2,000. That makes the flattening curve a poor sign that the model has run out of things to learn.

Here's a tighter validation estimate on 200 batches instead of 40:

import math
import torch
from checkpoint import load_checkpoint
from data import load_corpus
from train import estimate_loss

model, tok, meta = load_checkpoint("out/best.pt")
_, train_ids, val_ids = load_corpus("data/input.txt")
torch.manual_seed(123)
val = estimate_loss(model, {"val": val_ids}, 32, 128, 200, "cpu")["val"]
print(f"val loss {val:.4f}  perplexity {math.exp(val):.2f}  bits/char {val / math.log(2):.3f}")

val loss 1.7899  perplexity 5.99  bits/char 2.582

Perplexity of 5.99 means the model is about as uncertain as a fair choice between six characters at each step. The 1.7899 differs from the 1.7838 in the log only because it samples different batches.

Step 5: Is 1.78 any good?

A loss means nothing without a baseline. Two are easy to compute on the same validation split.

The unigram model predicts from character frequencies alone. The bigram model predicts from the previous character alone.

baselines.py

def unigram_loss(train_ids, val_ids, vocab):
    counts = torch.bincount(train_ids, minlength=vocab).float() + 1   # add-one smoothing
    probs = counts / counts.sum()
    return -probs[val_ids].log().mean().item()

def bigram_loss(train_ids, val_ids, vocab):
    pairs = train_ids[:-1] * vocab + train_ids[1:]
    counts = torch.bincount(pairs, minlength=vocab * vocab).view(vocab, vocab).float() + 1
    probs = counts / counts.sum(dim=1, keepdim=True)                  # P(next | previous)
    return -probs[val_ids[:-1], val_ids[1:]].log().mean().item()

python baselines.py

uniform guess : 4.1744
unigram       : 3.3473
bigram        : 2.4819

The bigram table, just 65 × 65 counts, reaches 2.48. The transformer's 1.78 comes from using more than the previous character. That gap is what attention over 128 characters of context buys you.

Step 6: Generate text

model.py, the sampling loop inside generate

ctx = idx[:, -self.cfg.block_size :]              # crop to the window
logits, _ = self(ctx)
logits = logits[:, -1, :] / temperature           # last position only
if top_k is not None:
    kth = torch.topk(logits, min(top_k, logits.size(-1))).values[:, [-1]]
    logits = logits.masked_fill(logits < kth, float("-inf"))
probs = F.softmax(logits, dim=-1)
nxt = torch.multinomial(probs, num_samples=1, generator=generator)
idx = torch.cat([idx, nxt], dim=1)

The model outputs scores for every position, and we keep the last one. Dividing by temperature reshapes the distribution. Below 1 it sharpens, above 1 it flattens.

Top-k keeps only the k highest scores and masks the rest to -inf. Then softmax turns scores into probabilities and multinomial draws one character. The code asserts that temperature is positive, so greedy decoding uses top_k=1 instead.

sample.py

"""Generate text from a trained checkpoint.

    python sample.py --ckpt out/best.pt --prompt "ROMEO:" --tokens 400
"""
import argparse

import torch

from checkpoint import load_checkpoint

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--ckpt", default="out/best.pt")
    ap.add_argument("--prompt", default=None)
    ap.add_argument("--tokens", type=int, default=400)
    ap.add_argument("--temperature", type=float, default=0.8)
    ap.add_argument("--top-k", type=int, default=40)
    ap.add_argument("--seed", type=int, default=42)
    ap.add_argument("--device", default="cpu")
    args = ap.parse_args()

    model, tok, _ = load_checkpoint(args.ckpt, args.device)
    gen = torch.Generator(device=args.device).manual_seed(args.seed)
    if not args.prompt:
        ids = [tok.start_id()]
    else:
        unknown = sorted({c for c in args.prompt if c not in tok.stoi})
        if unknown:
            raise SystemExit(f"prompt has characters the model has never seen: {unknown}")
        ids = tok.encode(args.prompt)
    idx = torch.tensor([ids], device=args.device)
    out = model.generate(idx, args.tokens, args.temperature, args.top_k, generator=gen)
    print(tok.decode(out[0].tolist()))

if __name__ == "__main__":
    main()

Temperature 0.8 with top-k 40 is the default:

python sample.py --prompt "ROMEO:" --tokens 200

ROMEO:
As lord shall, you for the read, one and bed forther
Bear head laist to dreath be that God,
Why so, upon this up enemer fament.

FLAUDE:
I lord, the the fall for not presence forfe,
The cuntracia, bu

Temperature 1.2 with no top-k filter (--top-k 65 keeps all 65 characters):

python sample.py --prompt "ROMEO:" --tokens 200 --temperature 1.2 --top-k 65

ROMEO:
As loud shadford: whose chard's, Statenty no fe thy eread?

First MAUXEqd:
Sorrow that's planly so,
Two to it'u
Let it them could to hinde lilenct, a who and for neWrp
Suanntifhed but nighnie his, bu

And greedy decoding, which always takes the most likely character:

python sample.py --prompt "ROMEO:" --tokens 200 --top-k 1

ROMEO:
The shall the soul the soul the soul the soul the son,
And the shall the some the so the soul the stand
The shall the so the so the so the so the soul
The shall the shall the shall the shall the stay

The default sample has the shape of a play: speaker names in capitals, colons, short lines, and a few real words like "lord", "head" and "God". It has no grammar and no meaning. At 1.2 it invents words, and greedy decoding falls into a loop.

Greedy decoding always picks the single most likely character, so once a phrase repeats, the repeated context makes the next repeat even more likely. Sampling adds randomness that can break the cycle.

What this model can and can't do

It learned the surface of Shakespeare: layout, capitalization, common letter patterns. It didn't learn to write sentences.

That's expected. The model has 813,440 parameters and read about a million characters, eight times.

I ran one training run with one seed and didn't tune any hyperparameters. Everything ran on CPU only.

How to scale it up

The nanoGPT README gives useful reference points on the same dataset. Its CPU example (4 layers, 4 heads, 128 dimensions, context 64) takes about 3 minutes and reaches a loss of 1.88.

Its GPU config (6 layers, 6 heads, 384 dimensions, context 256) reaches 1.4697 in about 3 minutes on one A100. The settings differ from ours, so treat those as rough comparisons.

The same README lists GPT-2 at 124M parameters. That's about 150 times larger than tinygpt. It says train.py reproduces that model on OpenWebText in about 4 days on one node with 8 A100 40GB GPUs.

To move toward that, change things in this order:

More data. A 1 MB corpus caps everything else.
A subword tokenizer. Byte pair encoding shortens sequences, so each token carries more meaning.
A bigger model. Raise n_layer, n_head and n_embd, and lengthen block_size.
A GPU. train.py picks CUDA or MPS automatically. I haven't run those paths.

Don't do step 3 alone. Hoffmann et al. trained over 400 models and found that model size and training tokens should scale together: double the parameters, double the tokens.

Their 70B model, Chinchilla, beat the 280B Gopher on a range of tasks using the same compute and 4× more data. The paper is Training Compute-Optimal Large Language Models.

Tests

python -m pytest -q

.........................                                                [100%]
25 passed in 12.23s

The suite covers the tokenizer round trip, batch shifting, the parameter-count formula, tied weights, the causal mask, agreement with PyTorch's attention, overfitting a single batch, reproducible sampling, greedy decoding, the learning-rate schedule, the weight-decay split, checkpoint loading, a two-step training run on a tiny corpus, the sampler's rejection of characters it has never seen, and the download script's fallback when Python can't verify certificates.

I also broke the code on purpose. Deleting the masked_fill line from the attention layer makes exactly two tests fail: the leak test and the PyTorch-equivalence test. The other 23 still pass, which shows those two guard that line.

Gotchas I hit while building it

Split contiguously. Sample validation windows from the tail of the file, not from a shuffle of the whole text.

Decay matrices only. Weight decay on biases and LayerNorm gains does nothing useful. The dim() >= 2 split handles it.

Crop the context. generate must slice to block_size, or long generations crash on the position table. The test asks for 40 new tokens with a block size of 16.

Seed your sampler. A torch.Generator passed to generate makes samples reproducible, and one test checks exactly that.

Don't hard-code a start token. My first version seeded sampling with a newline and crashed on any corpus that had none, which the tiny-corpus test now covers.

Save the vocabulary. The checkpoint stores the character list next to the weights. Without it, ids can't be turned back into text.

Download and run

The project is tinygpt.zip. It contains every file listed above, the trained checkpoint in out/, and the training log.

unzip tinygpt.zip
cd tinygpt
pip install -r requirements.txt
python get_data.py
python sample.py --prompt "ROMEO:"
python -m pytest

Retraining with python train.py writes to out/ and overwrites the shipped checkpoint. Copy out/ somewhere first if you want to keep it.

FAQ

Is this really an LLM? It's a language model built the same way as one. The "large" is about scale, and this is roughly 150 times smaller than the 124M GPT-2 model.

Can I train it on my own text? Yes. Run python train.py --data yourfile.txt. The vocabulary comes from the file.

With the default 128-character context the file needs at least 1,300 characters. Shorter files stop with a ValueError that says how many tokens are missing.

Why does sampling fail on some prompts? The tokenizer only knows characters from the training text. sample.py stops and lists the ones it doesn't know:

python sample.py --prompt "ROMEO: ☃"

prompt has characters the model has never seen: ['☃']

Calling encode yourself raises a KeyError instead:

from data import CharTokenizer

tok = CharTokenizer.from_text("hello")
try:
    tok.encode("hello!")
except KeyError as e:
    print("KeyError:", e)

KeyError: '!'

Why does get_data.py fail with CERTIFICATE_VERIFY_FAILED? Python installed from python.org on macOS often ships without root certificates, so it can't verify any HTTPS server. get_data.py detects this and downloads with curl instead, which keeps verification on.

To fix Python itself, run Install Certificates.command from the /Applications/Python 3.x/ folder. Don't switch verification off to make the error go away.

Why does pip install torch say "No matching distribution"? Usually PyTorch doesn't publish a wheel for your Python version and Mac chip. I checked Python 3.14 with pip install --dry-run: Apple Silicon has wheels, and the Intel Mac tag I tried (macosx_10_15_x86_64) has none.

Run uname -m to see your chip (arm64 means Apple Silicon). I tested everything on Python 3.12.3.

What is the "Failed to initialize NumPy" warning? PyTorch prints it when NumPy isn't installed. Nothing in tinygpt uses NumPy, and the sampler, the training script and the test suite ran fine without it in my check.

pip install numpy silences the message, and the install commands above include it.

Does it run on a GPU? The code picks CUDA or MPS if PyTorch finds one. I only tested it on CPU.

Why is the output nonsense? The model is small and the data is tiny. Better output comes from more data, a bigger model, and longer training, in that order.

References

Vaswani et al., Attention Is All You Need, 2017.
Radford et al., Language Models are Unsupervised Multitask Learners (GPT-2), 2019. Source for pre-LN placement and residual-scaled initialization.
Hoffmann et al., Training Compute-Optimal Large Language Models, 2022.
Andrej Karpathy, nanoGPT and char-rnn.
PyTorch documentation, scaled_dot_product_attention.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

How an AI-Driven Copyright Takedown Got Luanti Pulled From Google Play, Again

Pradeep Kumar — Sat, 03 Oct 2026 04:56:55 +0000

Luanti's Android app was temporarily removed from the Google Play Store this week after Microsoft, acting through the AI-driven brand protection company Tracer.AI, filed a DMCA takedown notice alleging that the open-source voxel game platform infringes Minecraft's copyright.

In an August 27 post, the Luanti team called the notice baseless, said the app contains no proprietary code or assets from Minecraft, and confirmed that it had submitted a counter-notice to Google.

The incident is notable not only because of the copyright dispute itself, but because it is the second time Luanti says it has received essentially the same notice from the same company.

What Luanti Actually Is

Luanti, known as Minetest until its 2024 rebrand, is a nonprofit, open-source voxel game-creation platform.

Unlike a conventional game, Luanti does not ship with a default game or a collection of game assets. Instead, users can browse and download games created by the community through its ContentDB catalog. Luanti describes itself as a platform for creating, sharing, discovering, and playing block-based games.

That distinction matters here because the copyright complaint alleges unauthorized use of Minecraft assets, while Luanti says the engine itself does not contain those assets.

The project previously bundled a basic survival game called Minetest Game. Starting with the December 2023 release, Minetest stopped shipping with a default game, although Minetest Game remained available as a separate download.

A Notice Without Specifics

The DMCA notice Google forwarded to Luanti alleges:

"These products use copyrighted assets as outlined directly from the Minecraft game…"

It identifies US Copyright Registration TX 8-192-097, which Luanti says corresponds to Minecraft Java Edition 1.9.

But according to Luanti, the notice provides no further explanation of what specific assets supposedly infringe or where those assets can be found in Luanti.

That lack of specificity is at the center of the dispute.

Luanti's position is essentially simple: if copyrighted Minecraft assets are supposedly present in the app, the claimant should be able to identify them.

The Assets That Are Not There

Luanti's response is that the alleged Minecraft assets cannot be found in the Android app.

The project published an image showing the textures included with the engine and says the additional assets it ships, including fonts, are properly attributed in its license files.

The situation is slightly more complicated when looking at the broader Luanti ecosystem.

The project's GitHub repository contains the Development Test game, but Luanti says this is not included in released builds. Minetest Game is also separate from the engine and is no longer bundled with releases.

Luanti also hosts third-party games, mods, and texture packs through ContentDB. Those packages are reviewed manually by volunteer moderators before approval, and the project says it actively checks for potential copyright problems.

That distinction matters: a platform can host community-created material without every piece of that material being part of the core application itself.

A Genre, Not a Monopoly

Luanti also makes a broader legal argument.

Section 102(b) of the US Copyright Act says copyright protection does not extend to ideas, concepts, systems, or methods of operation.

Luanti points out that Minecraft was inspired by the 2009 voxel game Infiniminer, while later games such as Hytale also use block-based worlds.

The project's argument is not that Microsoft or Mojang cannot protect Minecraft's actual copyrighted expression. They can enforce rights in protected assets where infringement exists.

The argument is narrower: a general voxel-based game concept or block-based visual language is not, by itself, something one company can own exclusively.

Whether a particular game or asset infringes copyright is a separate question that depends on the specific material involved.

Not the First Time

This is not Luanti's first encounter with Tracer.AI.

The project says it received an identical notice in March 2023. After submitting a counter-notice, the app was eventually restored 46 days later, on May 10. Luanti says the counter-notice was submitted on March 25.

That matters because US copyright law provides a specific counter-notification mechanism.

Under 17 U.S.C. §512(g)(2)(C), a service provider that removes material generally has a restoration procedure under which it must replace the material or cease disabling access 10 to 14 business days after receiving a qualifying counter-notification, unless the claimant files a court action seeking to restrain the material.

Luanti says the 46-day delay in 2023 went well beyond that statutory window and argues that Google's handling of the previous counter-notice raises questions about how the company processes DMCA disputes.

That is Luanti's characterization of the situation, rather than a court ruling that Google violated the statute.

The Allumeria Connection

Luanti's experience is also not the only recent Microsoft-related case involving Tracer.AI.

In February 2026, indie developer Unomelon said the voxel sandbox game Allumeria had been temporarily removed from Steam following a Microsoft copyright complaint submitted through Tracer.AI.

PC Gamer reported that the claim concerned alleged similarities to Minecraft and that Microsoft later withdrew the complaint. The game returned to Steam without the developer needing to file a counter-notice.

The two cases are not identical, but they share an important feature: both involved smaller voxel-game projects facing Microsoft-backed copyright enforcement despite disputes over what, specifically, was allegedly infringing.

The AI Enforcement Problem

Tracer.AI describes itself as an AI-powered brand protection company.

Its own marketing describes a Human-in-the-Loop AI system that uses AI to identify potential infringements while incorporating human expertise and verification.

Tracer says its technology produces:

85% faster takedowns
100% more reviews month over month
Review times six times faster than traditional methods
44% more takedowns month over month

Those figures come from Tracer itself and are therefore best understood as the company's own reported performance claims.

But they highlight an important tension.

AI-assisted enforcement can make it possible to identify and process vastly more potential infringements than a purely manual system. That is useful for rights holders dealing with large-scale online abuse.

The problem appears when a detection is wrong.

The cost of a false positive may not be paid by the enforcement vendor or rights holder. It may instead be paid by the developer whose app disappears from a major distribution platform while the dispute is reviewed.

That is why the question is not simply whether AI can make copyright enforcement faster.

It is whether verification can become fast enough to keep up with detection.

What Luanti Is Asking For

Luanti's demands are relatively specific.

The project wants Microsoft, Mojang, and Tracer.AI to require human verification before sending copyright notices and to provide concrete evidence supporting each claim rather than only citing a copyright registration number.

It is also asking Google to improve the way it evaluates notices and handles counter-notifications.

In other words, Luanti is not arguing that copyright enforcement should disappear.

It is arguing that enforcement should be specific, verifiable, and reversible without leaving legitimate projects offline for extended periods.

Where Things Stand Now

The immediate situation has changed quickly.

When Luanti published its August 27 statement, the project said its Android app was unavailable on Google Play and that a counter-notice had been submitted.

The Google Play listing currently appears to be live again and shows an Install button for the official Luanti app.

That suggests the latest takedown was resolved substantially faster than the 46-day incident in 2023, although the available sources do not establish exactly when Google restored the listing or whether the underlying dispute has been formally closed.

The story also attracted significant attention on Hacker News, where it reached the front page and generated hundreds of points and more than 100 comments.

The Bigger Lesson

The Luanti case is ultimately bigger than one open-source game platform.

Rights holders need tools capable of finding genuine infringement at internet scale. Platforms need mechanisms for acting quickly when credible complaints arrive. And developers need a meaningful way to challenge mistakes before a temporary removal becomes a serious business or distribution failure.

AI can make the first part dramatically faster.

But speed creates a second requirement: the verification process has to become better, too.

Luanti's second encounter with the same type of copyright notice shows what happens when those two systems move at different speeds.

A claim can take minutes to trigger a platform action.

A legitimate developer may then need days, weeks, or longer to prove that the claim was wrong.

The real question raised by the Luanti case is therefore not whether AI should be used in copyright enforcement.

It is whether AI-assisted enforcement can scale without scaling the damage caused by false positives.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Apple M6 and M5 Ultra: The Mac Is Becoming a Serious AI Workstation

Pradeep Kumar — Sat, 03 Oct 2026 04:55:26 +0000

Apple has just pushed its Mac silicon strategy into a new phase.

The company has introduced M6 in the new Mac mini and M5 Ultra in the new Mac Studio, bringing major changes to both everyday computing and high-end AI workloads.

M6 is Apple's first 2-nanometer chip, with a new 12-core CPU, 12-core GPU, Dual 16-core Neural Engine, and up to 170GB/s of unified memory bandwidth.

M5 Ultra goes much further. It is Apple's first quad-die M-series chip, combining four compute dies through a new generation of UltraFusion technology. It scales to a 36-core CPU, 80-core GPU, up to 512GB of unified memory, and 1.2TB/s of memory bandwidth.

On paper, those numbers look impressive.

But the more important story is what Apple is building toward: a Mac where local AI is becoming a core workload rather than an experimental feature.

Image: Apple M6 and M5 Ultra

Image credit: Apple

Source: Apple Newsroom

M6: Apple's First 2nm Mac Chip

M6 is the first Apple silicon chip for the Mac built using a 2nm process.

Moving to a smaller process node gives Apple more transistor density and the potential for better performance and efficiency. Apple is using that additional silicon capacity across the CPU, GPU and AI hardware rather than concentrating it in a single compute block.

The M6 CPU has 12 cores:

2 super cores
4 performance cores
6 efficiency cores

That is two additional CPU cores compared with M5.

Apple claims up to 1.2× faster multithreaded performance than M5 and up to 2.4× faster than M1 in its selected benchmarks. Apple also describes M6 as delivering the world's fastest single-threaded performance.

These are Apple's benchmark claims, so they should not be interpreted as independent real-world measurements.

For developers, however, the potential benefits are straightforward: compiling projects, indexing large codebases, manipulating assets, running multiple development tools, and executing local agent workloads can all benefit from stronger CPU performance.

Apple specifically highlights code compilation, file indexing and agentic AI workloads as areas that benefit from M6.

The M6 Is Designed Around AI

The most interesting part of M6 may not be the CPU.

Its 12-core GPU contains a Neural Accelerator in every GPU core.

Apple says this produces nearly 30% higher peak GPU AI compute than M5 and more than 8× the peak GPU AI compute of M1.

M6 also features a Dual 16-core Neural Engine. Apple says system frameworks can use both engines simultaneously, providing up to 2× the peak compute of previous generations for suitable workloads.

That makes the architectural direction clear.

Apple is not relying on one dedicated AI block. The CPU, GPU and Neural Engine can all participate in AI workloads depending on what an application requires.

That becomes increasingly important as applications move beyond simple AI features toward:

Coding assistants
Local AI agents
Private assistants
Document analysis
On-device retrieval
Continuous inference
Automated development workflows

Image: M6-powered Mac mini

Image credit: Apple

Source: Apple Newsroom

Faster Unified Memory Matters More Than It Looks

M6 supports up to 32GB of unified memory with memory bandwidth of up to 170GB/s.

Apple says this is a 10% increase over M5 and 2.5× the bandwidth of M1.

This matters for AI because model execution can become a memory problem long before a developer expects it to.

Apple's unified-memory architecture allows the CPU and GPU to work from the same memory pool rather than constantly moving large datasets between separate CPU and GPU memory.

For smaller local models, embeddings, AI coding assistants and agentic applications, memory capacity and bandwidth can sometimes matter more than a headline CPU benchmark.

There is still an important limitation.

The maximum 32GB memory configuration means M6 is not intended to compete with M5 Ultra for the largest local models.

That is where Apple's high-end desktop silicon becomes much more interesting.

Then Apple Does Something Much Bigger With M5 Ultra

M5 Ultra is where Apple's architecture becomes particularly interesting.

Instead of simply creating one enormous die, Apple uses UltraFusion to connect two dual-die M5 Max chips, creating a quad-die architecture for the first time in Apple silicon.

The interconnect provides more than 4.4TB/s of inter-die bandwidth, while Apple says its connection density is more than six times higher than before.

The objective is to make the four dies behave like a single unified processor.

This is the key to understanding M5 Ultra.

Apple is effectively scaling its architecture horizontally without abandoning the unified-system approach that has defined Apple silicon.

Image: M5 Ultra-powered Mac Studio

Image credit: Apple

Source: Apple Newsroom

36 CPU Cores and 80 GPU Cores

At the top end, M5 Ultra reaches 36 CPU cores, made up of 12 super cores and 24 performance cores.

Apple claims up to 1.25× higher single-threaded performance and up to 1.3× higher multithreaded performance than M3 Ultra.

The GPU scales to an enormous 80 cores.

And once again, every GPU core includes a Neural Accelerator.

Apple says M5 Ultra can deliver up to 4.5× the peak GPU AI compute compared with M3 Ultra, and more than 6× compared with M1 Ultra.

Apple also claims graphics performance of up to 40% faster than M3 Ultra in its selected benchmarks.

These figures are Apple-provided performance claims. Independent testing will ultimately determine how those improvements translate across different applications and AI workloads.

This puts M5 Ultra firmly into workstation territory.

But the most interesting specification is still the memory.

512GB of Unified Memory Changes the Conversation

M5 Ultra supports up to 512GB of unified memory with up to 1.2TB/s of memory bandwidth.

Apple says the bandwidth is 50% higher than M3 Ultra.

Why is this such a big deal?

Because large AI models need memory.

A system with powerful GPU compute but insufficient memory can still be heavily constrained. Large models may need to be quantized, split across devices, offloaded or executed remotely.

With 512GB of unified memory, M5 Ultra dramatically raises the amount of model data that can remain resident locally.

Apple says the 512GB configuration can be used to run LLMs with hundreds of billions of parameters entirely on-device while also keeping large datasets in local memory.

That does not mean every huge model will suddenly run quickly on a Mac.

Model architecture, quantization, context length, software optimization, memory access patterns and inference implementation still matter.

The distinction is important:

Memory capacity determines what can fit. Compute and software determine how quickly it runs.

Image: Local AI workloads on Mac Studio

Image credit: Apple

Source: Apple Newsroom

This Is Where Developers Should Pay Attention

Apple's developer ecosystem is increasingly aligned with these hardware capabilities.

The company highlights technologies including:

Core AI
Core ML
Metal
Xcode
Apple Foundation Models
App Intents

These technologies give developers multiple ways to integrate AI into applications and take advantage of Apple's on-device compute.

The potential architecture is interesting.

You can imagine an application where:

Simple inference happens locally.

Private data stays on-device.

Latency-sensitive tasks run locally.

Large or expensive workloads move to the cloud.

The Mac therefore does not necessarily replace cloud AI.

Instead, it becomes another compute layer in an AI application.

Apple Is Betting on Local AI

There is a broader shift happening here.

The AI industry has spent years moving toward massive centralized GPU clusters. That will continue because frontier training and the largest inference workloads require extraordinary amounts of compute.

But not every AI task needs a data center.

Code completion, document analysis, personal assistants, private knowledge retrieval, image generation, automation and agentic workflows can benefit from local execution.

Local inference offers several obvious advantages:

Privacy
Lower latency
Reduced dependence on cloud APIs
Potentially lower recurring inference costs

M6 brings more of that capability to the Mac mini.

M5 Ultra pushes it into a different category entirely: a desktop system with enough memory and compute to handle local AI workloads that would previously have required more specialized hardware or cloud infrastructure.

M6 vs M5 Ultra

Specification	M6	M5 Ultra
Process	2nm	M5 generation
CPU	Up to 12 cores	Up to 36 cores
GPU	Up to 12 cores	Up to 80 cores
Neural Engine	Dual 16-core	32-core
Unified memory	Up to 32GB	Up to 512GB
Memory bandwidth	Up to 170GB/s	Up to 1.2TB/s
Architecture	Single chip	Quad-die
Main AI advantage	Efficient local AI	High-memory local AI workloads
Device	Mac mini	Mac Studio

These are not really direct competitors.

M6 makes local AI more accessible.

M5 Ultra makes local AI much more ambitious.

The Real Story Behind M6 and M5 Ultra

It is easy to summarize this launch as:

New Apple chips are faster.

That misses the more important development.

M6 demonstrates how Apple is using 2nm manufacturing, additional compute cores, Neural Accelerators and multiple Neural Engines to make on-device AI part of mainstream Mac computing.

M5 Ultra demonstrates how Apple can scale that architecture through multi-die packaging, enormous unified memory and extreme bandwidth.

The result is a different kind of Mac.

It is not just a machine for running applications.

It is increasingly a machine for running models.

And that distinction matters.

As AI moves from chatbots toward coding agents, autonomous workflows and always-available assistants, more computation can potentially happen locally.

Apple's M6 and M5 Ultra suggest that the company wants the Mac to be ready for exactly that future.

Final Thoughts

The M6 and M5 Ultra are interesting for different reasons.

M6 is Apple's next step toward efficient, accessible local AI.

M5 Ultra is Apple's attempt to turn a desktop Mac into a serious high-memory AI workstation.

The M6's 2nm process, Dual 16-core Neural Engine, 12-core GPU and 170GB/s memory bandwidth make it a substantial step forward in Apple's Mac silicon lineup.

M5 Ultra goes much further with its quad-die design, 80-core GPU, Neural Accelerators, 512GB unified memory and 1.2TB/s memory bandwidth.

But the biggest takeaway is not any individual specification.

It is Apple's direction.

The Mac is increasingly becoming an AI-capable computer rather than simply a traditional personal computer.

And with M6 and M5 Ultra, Apple is betting that some of the most important AI workloads of the next few years will happen right on the desk in front of you.

Sources

Image Credits

All images in this article are official Apple Newsroom images.

Image credit: Apple

Source: Apple Newsroom

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Introducing SynthID Bio: Watermarking AI-Designed Proteins Before They Reach the Lab

Pradeep Kumar — Sat, 03 Oct 2026 04:16:30 +0000

If you build anything that sits between an AI model and a physical molecule, SynthID Bio is worth understanding today. On 30 September 2026, Google DeepMind introduced SynthID Bio, a family of watermarking methods for synthetic biology. It hides a verifiable signature inside AI-designed protein sequences and predicted 3D structures, and DeepMind reports that the signature survives synthesis into a real, working protein.

This post covers what the system does, what the evidence supports, what it does not solve, and where an engineering team could plug it in. The authors call it a proof of concept, and that framing matters throughout.

Where a watermark check would sit

The clearest way to see the value is to follow a design from model to molecule. A researcher generates a protein with an AI model, then places an order with a DNA synthesis provider. The provider screens the order before making anything. A watermark gives that screening step a new input: evidence that the design came from a specific, trusted model.

Note the bottom branch. A missing watermark proves nothing about intent. It only means the order takes the same path it takes today.

What SynthID Bio actually is

DeepMind describes SynthID Bio as a family of methods rather than a single algorithm. According to the announcement, it adapts to the data type. For sequences, it subtly guides which amino acids get chosen. For predicted 3D structures, it adjusts atomic coordinates. Both create a statistical signal that a detector can look for later.

The Nature paper gives the technical detail. The sequence method scores candidate amino acids using a secret key during sampling, and the structure method trains a secret detector alongside a fine-tuned model. Both are zero-bit schemes, meaning they signal that a watermark is present but carry no other information.

The evidence for sequences: wet-lab binders

The hard question for any biological watermark is whether the physical molecule still works. DeepMind tested this on protein binders, which are molecules built to latch onto a target protein. It paired its binder design system AlphaProteo with a SynthID Bio-enabled version of ProteinMPNN, a widely used sequence generation method.

In wet-lab tests against three targets (VEGF-A, the SARS-CoV-2 spike protein RBD, and PD-L1), the announcement reports that watermarked designs matched the unwatermarked ones on hit rate, binding affinity, and natural sequence diversity. DeepMind calls these the first watermarked and biologically functional protein binders. The post thanks Adaptyv Bio for help with the in vitro validation.

The paper is more nuanced than that summary. Non-distortionary watermarking at temperature 0.5 had a significantly lower hit rate than non-watermarked designs at the 1 micromolar affinity threshold. There were no significant hit-rate differences at the stricter 100 nanomolar threshold.

The evidence for structures: AlphaFold 3

Structure prediction takes a different route. Rather than filtering outputs, the authors fine-tune AlphaFold 3's diffusion module with a watermark loss while co-training a secret detector, with the confidence module fine-tuned alongside under its original loss. This builds the watermark into the model weights. Anyone running the fine-tuned model produces watermarked structures, and users cannot remove the mechanism even when the weights are shared. The output can still be scrubbed, though: the paper reports that constrained relaxation destroys the watermark.

DeepMind reports that this preserves AlphaFold 3 prediction accuracy, maintains key structural feature distributions, offers near-perfect detectability, and holds up against digital noise or minor coordinate changes. The announcement gives no numeric detection rates in its text, so the exact figures live in the paper. Quote them from there, not from the blog.

Why DNA synthesis screening is the main use case

Synthesis providers screen orders against databases of known threats. The announcement explains the problem: an unfamiliar sequence used to be safely assumed to be an undiscovered natural organism, but AI can now create entirely new sequences with little resemblance to known hazards. Verifying such an order can require exhaustive manual review, which can stall legitimate research.

A watermark offers an automated verification signal that an order came from a trusted model with built-in safeguards. James Diggans of Twist Bioscience said in the post that watermarking could help focus resources on sequences that warrant closer review. Sarah Carter, a biosecurity policy expert who reviewed the work, called it an important piece of the puzzle for tracking the provenance of biological designs.

The second use case: database integrity

Public biological databases face a quieter problem. Resources such as the Protein Data Bank, UniProt, and GenBank accept public submissions, and mislabeled entries can distort biosecurity decisions. As AI-generated biological data grows, that risk grows with it.

DeepMind suggests SynthID Bio could help at submission time, so synthetic entries are labeled correctly or flagged for further review. This is a proposal, not a deployed feature. No database operator has announced adoption in the source material.

Beyond proteins: the Evo 2 bacteriophage work

DeepMind is extending the approach to whole genomes. In ongoing work with the Hie lab at Stanford University and Arc Institute, the team integrated SynthID Bio into Evo 2, a genomic model, to watermark the genome of an Evo 2 designed bacteriophage. Early testing in bacterial cultures confirmed the watermarked phages are functional.

This result is preliminary. DeepMind says a technical manuscript with more details is coming, so any claims about robustness or detection on genomes should wait for that document.

What it does not solve

DeepMind is direct about the limits. The announcement states that no single biosecurity intervention is a silver bullet, and that a key remaining challenge is making the watermark more robust against deliberate tampering. Secondary coverage from OfficeChai stresses the same point.

Two further limits follow from how watermarks work, and these are my analysis rather than claims from the source. First, a watermark only exists if the model developer applies it, so it says nothing about designs from models that do not. Second, a verified watermark shows origin, not safety. It should inform review, never replace it.

What to build around it

The announcement does not describe a detector API, so check the released code and methods paper before designing anything. With that caveat, here is how I would think about integration, drawn from the use cases DeepMind describes.

For a synthesis provider, treat watermark verification as one input at order intake. A verified watermark from a trusted model developer is positive evidence that can inform review, but standard similarity screening should still run, because false positives that skipped screening would themselves be a biosecurity risk. A missing or failed check must fall through to the current process with no penalty and no assumption of bad intent.

For a database operator, add a provenance check at submission. Flag entries that carry a watermark but are not labeled synthetic, and route them to curators. For a model developer, the lesson is architectural: the AlphaFold 3 approach bakes the watermark into weights, which is harder to strip at the output stage than a post-processing step.

For any team, pair the watermark with metadata. DeepMind suggests combining SynthID Bio with provenance metadata approaches similar to C2PA for digital media, or with central repositories of AI-generated biological data. Layers cover each other's gaps.

What is open source

DeepMind says it is publishing its methods paper, open-sourcing the code and in vitro data, and sharing weights with the research community. The methods paper is open access in Nature, published 30 September 2026. Per the paper, the code and in vitro data live in the GitHub repository, and the access instructions cover only the structure model weights for the recommended variant trained with 0.001 angstrom of noise.

Open release lets biosecurity researchers test the scheme and build detectors. The paper's own attacks show why that testing matters: resequencing with plain ProteinMPNN effectively removes the sequence watermark, and constrained relaxation destroys the structure watermark. The authors also keep detectors and keys secret, so verification depends on trusted key sharing.

Bottom line

SynthID Bio is a credible first layer, and its main contribution is showing that a watermark can survive all the way into a functioning protein. It is not a gate, a guarantee, or a finished standard. The interesting work now belongs to the people who can test its robustness, define how screeners should trust it, and connect it to provenance metadata.

To discuss partnerships, DeepMind invites high-level proposals at synthidbio@google.com, without confidential or proprietary information.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

You Probably Don't Need Elasticsearch: Building a Fast, Typo-Tolerant Search Engine in PostgreSQL

Pradeep Kumar — Wed, 30 Sep 2026 11:43:02 +0000

Every engineering team hits the same milestone: your application grows past a few tens of thousands of records, users complain that basic database lookups feel broken, and product demands a "real" search experience with typo tolerance, relevance ranking, and multi-field matching.

At this point, someone inevitably proposes spinning up an Elasticsearch cluster, deploying Meilisearch, or signing an expensive SaaS contract with Algolia.

Before you add another distributed system to your stack, consider the operational tax:

A secondary data store you now have to back up, monitor, patch, and secure.
Dual-write problems: database transactions commit, but the search sync worker crashes, drops events, or lags behind.
Mapping migrations and index re-indexing routines that lock resources for hours.
Noticeable JVM cluster memory consumption even when the application is idle.

For datasets under a few million records, PostgreSQL already contains all the primitives you need to build a resilient, sub-15ms search engine.

This article walks through the exact mechanics of combining PostgreSQL's tsvector lexical search, pg_trgm fuzzy matching, partial GIN indexes, and weighted Common Table Expressions (CTEs) into a clean, single-query search engine—along with the performance traps that usually break naive implementations.

1. Why Naive PostgreSQL Search Fails

Most developers start with ILIKE:

SELECT id, title FROM articles 
WHERE title ILIKE '%docker%' OR body ILIKE '%docker%';

In production, this degrades rapidly for two specific architectural reasons:

A. The B-Tree Index Trap

A standard B-tree index only accelerates prefix matching (LIKE 'docker%'). Leading wildcard searches ('%docker%') force PostgreSQL to execute a full sequential scan across every single table page on disk.

B. The TOAST Compression Penalty

In PostgreSQL, column data exceeding ~2KB is compressed and stored out-of-line in TOAST (The Oversized-Attribute Storage Technique) tables.

When your query evaluates body ILIKE '%docker%', PostgreSQL must fetch the TOAST pointers, decompress every single chunk into memory, and scan the raw text string for millions of bytes across thousands of rows. On a table with 50,000 published articles, a single query can easily take 1.5 to 3 seconds and pin CPU cores.

To fix this, we need indexes designed specifically for arbitrary text: GIN (Generalized Inverted Index) combined with lexical vectors and trigrams.

2. The Two Halves of Real-World Search

Effective search requires balancing two distinct query styles:

Search Type	PostgreSQL Tool	How It Operates	What It Solves
Lexical / Full-Text	tsvector + tsquery	Parses words into root dictionary stems (e.g., "running", "runs", "ran" $\rightarrow$ 'run').	Finding documents matching concepts and phrases, regardless of verb tense or pluralization.
Fuzzy / Substring	pg_trgm (Trigrams)	Splits text into 3-character sliding slices (e.g., "postgres" $\rightarrow$ [' p', ' po', 'pos', 'ost', 'stg', 'tgr', 'gre', 'res', 'es ']).	Typo tolerance, partial prefix matching, and misspelled names.

If you rely solely on tsvector, a search for "postgress" (with an accidental double-s) returns zero results because the word stem does not match.

If you rely solely on trigrams across your entire 10,000-word article bodies, your index sizes will explode into gigabytes, and queries will get bogged down calculating string distance across megabytes of text.

The Problem with Tech Keywords and Stop Words

Text search dictionaries (like PostgreSQL's 'english') automatically discard common stop words ("the", "and", "in"). But in software engineering, single-letter words or common terms are critical programming languages or tools:

"Go" (stripped as a verb/stopword)
"C" (stripped as a single character)
"SQL" (often un-stemmed)

The hybrid strategy solves this cleanly:

Use pg_trgm for short, high-entropy fields where typos and short technical tokens live: titles, author handles, and taxonomy tags.
Use tsvector for broad document discovery across titles, excerpts, and full article bodies.
Combine candidate IDs using set unions, then compute relevance ranking only on the surviving matches.

3. Schema Design: Extensions, Stored Vectors, and Partial GIN Indexes

Let's configure a clean, production-ready schema.

Step 1: Enable the Extension

You need pg_trgm for trigram similarity operators:

CREATE EXTENSION IF NOT EXISTS pg_trgm;

Step 2: Define the Table with Stored Generated tsvectors

In PostgreSQL 12+, you can define a tsvector column as a Stored Generated Column. It automatically updates whenever the source text changes, eliminating fragile manual database triggers.

We assign weights to individual fields:

Weight A (title): Highest priority.
Weight B (excerpt): Medium priority.
Weight C (body): Standard body weight.

CREATE TABLE authors (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(255) NOT NULL,
    username VARCHAR(100) UNIQUE NOT NULL
);

CREATE TABLE tags (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(100) UNIQUE NOT NULL
);

CREATE TABLE articles (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    author_id UUID NOT NULL REFERENCES authors(id) ON DELETE CASCADE,
    title VARCHAR(500) NOT NULL,
    slug VARCHAR(500) UNIQUE NOT NULL,
    excerpt TEXT,
    body TEXT NOT NULL,
    status VARCHAR(50) NOT NULL DEFAULT 'published',
    published_at TIMESTAMPTZ,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),

    -- Generated document vector with field weight prioritization
    search_vector tsvector GENERATED ALWAYS AS (
        setweight(to_tsvector('english', COALESCE(title, '')), 'A') ||
        setweight(to_tsvector('english', COALESCE(excerpt, '')), 'B') ||
        setweight(to_tsvector('english', COALESCE(body, '')), 'C')
    ) STORED
);

CREATE TABLE article_tags (
    article_id UUID NOT NULL REFERENCES articles(id) ON DELETE CASCADE,
    tag_id UUID NOT NULL REFERENCES tags(id) ON DELETE CASCADE,
    PRIMARY KEY (article_id, tag_id)
);

Why STORED matters: Calculating to_tsvector() on a 5,000-word article takes measurable CPU cycles. By computing it once on write and storing it on disk, read queries simply scan the precomputed token pointers directly from the index without touching or decompressing the raw body text.

Step 3: Create Partial GIN Indexes

In content systems, applications typically store drafts, revisions, and archived content alongside live data. If 40% of your records are unpublished drafts, indexing them wastes RAM.

By creating Partial GIN Indexes (WHERE status = 'published'), you reduce index size by 30–50% and keep your active search indexes entirely pinned in PostgreSQL's buffer cache.

-- 1. Partial full-text search index on published articles
CREATE INDEX idx_articles_search_vector_published 
ON articles USING gin (search_vector) 
WHERE status = 'published';

-- 2. Partial trigram index on title for fuzzy matching & typos
CREATE INDEX idx_articles_title_trgm_published 
ON articles USING gin (title gin_trgm_ops) 
WHERE status = 'published';

-- 3. Trigram indexes on taxonomy and author metadata
CREATE INDEX idx_authors_name_trgm 
ON authors USING gin (name gin_trgm_ops);

CREATE INDEX idx_authors_username_trgm 
ON authors USING gin (username gin_trgm_ops);

CREATE INDEX idx_tags_name_trgm 
ON tags USING gin (name gin_trgm_ops);

-- 4. B-tree index on published date for sorting tie-breakers
CREATE INDEX idx_articles_published_at_desc 
ON articles (published_at DESC) 
WHERE status = 'published';

4. Query Parsing: Handling User Input Without Crashing

A common production bug occurs when developers feed raw user input directly into to_tsquery():

-- Throws a syntax error if user enters "node.js" or "c++" or mismatched quotes:
SELECT to_tsquery('english', 'node.js OR c++'); 
-- ERROR: syntax error in tsquery: "node.js OR c++"

PostgreSQL 11+ provides websearch_to_tsquery(), which processes search text using the same rules users expect from Google:

docker containers $\rightarrow$ 'docker' & 'contain'
"zero downtime" $\rightarrow$ 'zero' <-> 'downtim' (strict adjacent phrase search)
docker OR podman $\rightarrow$ 'docker' | 'podman'
postgres -redis $\rightarrow$ 'postgr' & !'redi' (negation)
Random punctuation like c++, unbalanced quotes, or trailing colons are parsed gracefully without throwing database exceptions.

5. The Production Query: Candidate Filtering + Scoring CTE

Evaluating expensive ranking calculations across hundreds of thousands of rows will drag query latency down.

To keep queries fast, split the execution into two distinct stages:

Candidate Gathering: Use fast GIN index lookups to find qualifying IDs via UNION.
Relevance Scoring: Calculate weighted scores only for the candidate records, apply pagination, and fetch the final payload.

Here is the complete production SQL query:

WITH matched_tags AS (
    -- Collect published article IDs associated with matching tags
    SELECT at.article_id AS id
    FROM article_tags at
    JOIN tags t ON t.id = at.tag_id
    JOIN articles a ON a.id = at.article_id
    WHERE a.status = 'published'
      AND (t.name % $1 OR t.name ILIKE $1 || '%')
),
matched_authors AS (
    -- Collect published article IDs written by matching authors
    SELECT a.id
    FROM articles a
    JOIN authors auth ON auth.id = a.author_id
    WHERE a.status = 'published'
      AND (auth.name % $1 OR auth.username % $1 OR auth.name ILIKE $1 || '%')
),
candidate_articles AS (
    -- 1. Fuzzy title matches (catches typos like "dokcer" -> "docker")
    SELECT id FROM articles
    WHERE status = 'published'
      AND (title % $1 OR title ILIKE '%' || $1 || '%')

    UNION

    -- 2. Lexical full-text match across title, excerpt, and body
    SELECT id FROM articles
    WHERE status = 'published'
      AND search_vector @@ websearch_to_tsquery('english', $1)

    UNION

    -- 3. Articles matching tag taxonomy
    SELECT id FROM matched_tags

    UNION

    -- 4. Articles matching author profiles
    SELECT id FROM matched_authors
),
scored_results AS (
    SELECT 
        a.id,
        a.title,
        a.slug,
        a.excerpt,
        a.published_at,
        auth.name AS author_name,
        auth.username AS author_username,
        (
            -- Priority 1: Exact title match bonus
            (CASE WHEN a.title ILIKE $1 THEN 100.0 ELSE 0.0 END) +

            -- Priority 2: Fuzzy trigram similarity on title (0.0 to 1.0, scaled by 60)
            (COALESCE(similarity(a.title, $1), 0.0) * 60.0) +

            -- Priority 3: Full-text cover density rank (scaled by 30)
            (COALESCE(ts_rank_cd(a.search_vector, websearch_to_tsquery('english', $1)), 0.0) * 30.0) +

            -- Priority 4: Metadata affinity bonuses
            (CASE WHEN a.id IN (SELECT id FROM matched_tags) THEN 15.0 ELSE 0.0 END) +
            (CASE WHEN a.id IN (SELECT id FROM matched_authors) THEN 10.0 ELSE 0.0 END)
        ) AS relevance_score
    FROM candidate_articles ca
    JOIN articles a ON a.id = ca.id
    JOIN authors auth ON auth.id = a.author_id
)
SELECT 
    id,
    title,
    slug,
    excerpt,
    published_at,
    author_name,
    author_username,
    ROUND(relevance_score::numeric, 2) AS score
FROM scored_results
ORDER BY relevance_score DESC, published_at DESC
LIMIT $2 OFFSET $3;

6. How the Relevance Math Works

Let's break down the scoring weights:

relevance_score =
    Exact Title Match (100.0)
  + Title Trigram Similarity (0.0 - 60.0)
  + ts_rank_cd Cover Density (0.0 - 30.0)
  + Tag Match Bonus (15.0)
  + Author Match Bonus (10.0)

Exact Title Bonus (100.0): If an author publishes an article titled "PostgreSQL Indexing Guide", and a user searches "PostgreSQL Indexing Guide", that exact document always claims the #1 position.
Trigram Title Similarity (similarity(a.title, $1) * 60.0): Returns a float between 0.0 and 1.0 representing the fraction of shared 3-character slices. A typo like "PostgreSQLL" will yield a similarity score around 0.85, contributing ~51 points.
ts_rank_cd Cover Density (* 30.0): Unlike basic ts_rank (which merely counts raw word frequency), ts_rank_cd measures phrase proximity—how close the search terms appear to each other in the document. Terms appearing adjacent in the opening paragraph rank substantially higher than terms scattered pages apart.
Metadata Bonuses (15.0 & 10.0): If a user searches for "DevOps", any article explicitly tagged #devops receives an automatic boost over an article that merely mentions the word in passing.

7. Performance Deep-Dive: Execution Plan Analysis

Running EXPLAIN (ANALYZE, BUFFERS) on this query against a dataset of 75,000 articles demonstrates why the candidate filtering pattern remains fast:

QUERY PLAN
--------------------------------------------------------------------------------------------------
Limit  (cost=142.30..142.35 rows=20 width=180) (actual time=8.142..8.148 rows=20 loops=1)
  Buffers: shared hit=412
  CTE candidate_articles
    ->  HashAggregate  (cost=112.10..128.40 rows=145 width=16) (actual time=6.820..6.850 rows=82 loops=1)
          ->  Append  (cost=12.20..111.70 rows=155 width=16) (actual time=0.410..6.710 rows=84 loops=1)
                ->  Bitmap Heap Scan on articles a_1
                      Recheck Cond: ((title % 'docker'::text) AND (status = 'published'))
                      ->  Bitmap Index Scan on idx_articles_title_trgm_published (actual time=0.380..0.380 rows=12 loops=1)
                ->  Bitmap Heap Scan on articles a_2
                      Recheck Cond: (search_vector @@ '''docker'''::tsquery)
                      ->  Bitmap Index Scan on idx_articles_search_vector_published (actual time=1.210..1.210 rows=72 loops=1)
...
Planning Time: 0.850 ms
Execution Time: 8.420 ms

Key Metrics:

shared hit=412 and shared read=0: The entire query was resolved from PostgreSQL's shared buffer cache without waiting on physical disk I/O.
Bitmap Index Scan on Partial GIN: Indexes were used to find candidate row pointers in a fraction of a millisecond.
Execution Time: ~8.4 ms: Well below the human perception threshold of 100ms.

8. Integration Example: Node.js / TypeScript Driver

Here is how to integrate this query cleanly into a Node.js backend using pg (or similar drivers like Kysely/Prisma raw query):

import { Pool } from 'pg';

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

export interface SearchResult {
  id: string;
  title: string;
  slug: string;
  excerpt: string;
  published_at: Date;
  author_name: string;
  author_username: string;
  score: number;
}

export async function searchArticles(
  rawQuery: string,
  limit: number = 20,
  offset: number = 0
): Promise<SearchResult[]> {
  const query = rawQuery.trim();
  if (!query) return [];

  // Clamp limits to prevent memory exhaustion
  const safeLimit = Math.max(1, Math.min(100, limit));
  const safeOffset = Math.max(0, offset);

  const sql = `
    WITH matched_tags AS (
      SELECT at.article_id AS id
      FROM article_tags at
      JOIN tags t ON t.id = at.tag_id
      JOIN articles a ON a.id = at.article_id
      WHERE a.status = 'published'
        AND (t.name % $1 OR t.name ILIKE $1 || '%')
    ),
    matched_authors AS (
      SELECT a.id
      FROM articles a
      JOIN authors auth ON auth.id = a.author_id
      WHERE a.status = 'published'
        AND (auth.name % $1 OR auth.username % $1 OR auth.name ILIKE $1 || '%')
    ),
    candidate_articles AS (
      SELECT id FROM articles
      WHERE status = 'published'
        AND (title % $1 OR title ILIKE '%' || $1 || '%')
      UNION
      SELECT id FROM articles
      WHERE status = 'published'
        AND search_vector @@ websearch_to_tsquery('english', $1)
      UNION
      SELECT id FROM matched_tags
      UNION
      SELECT id FROM matched_authors
    ),
    scored_results AS (
      SELECT 
        a.id,
        a.title,
        a.slug,
        a.excerpt,
        a.published_at,
        auth.name AS author_name,
        auth.username AS author_username,
        (
          (CASE WHEN a.title ILIKE $1 THEN 100.0 ELSE 0.0 END) +
          (COALESCE(similarity(a.title, $1), 0.0) * 60.0) +
          (COALESCE(ts_rank_cd(a.search_vector, websearch_to_tsquery('english', $1)), 0.0) * 30.0) +
          (CASE WHEN a.id IN (SELECT id FROM matched_tags) THEN 15.0 ELSE 0.0 END) +
          (CASE WHEN a.id IN (SELECT id FROM matched_authors) THEN 10.0 ELSE 0.0 END)
        ) AS relevance_score
      FROM candidate_articles ca
      JOIN articles a ON a.id = ca.id
      JOIN authors auth ON auth.id = a.author_id
    )
    SELECT 
      id,
      title,
      slug,
      excerpt,
      published_at,
      author_name,
      author_username,
      ROUND(relevance_score::numeric, 2)::float AS score
    FROM scored_results
    ORDER BY relevance_score DESC, published_at DESC
    LIMIT $2 OFFSET $3;
  `;

  const { rows } = await pool.query<SearchResult>(sql, [query, safeLimit, safeOffset]);
  return rows;
}

9. Database Production Tuning

To ensure your search stays under 20ms under concurrent traffic, configure these parameters in postgresql.conf:

1. Fine-Tune the Trigram Threshold

By default, PostgreSQL's trigram similarity operator (%) uses a threshold of 0.3:

-- Check current threshold (default is 0.3)
SHOW pg_trgm.similarity_threshold;

-- Lower values match more aggressively (more forgiving of bad typos)
-- Higher values require tighter matches
SET pg_trgm.similarity_threshold = 0.25;

2. GIN Fastupdate Buffer

By default, GIN indexes use a pending list (fastupdate = on) to batch write operations. When the pending list fills up, the next write or query triggers an in-line cleanup of the list, which can produce intermittent latency spikes.

For search-heavy tables:

-- Increase memory allocated to cleaning up pending GIN inserts
ALTER INDEX idx_articles_search_vector_published 
SET (fastupdate = on, gin_pending_list_limit = '4MB');

3. Maintain Maintenance Work Mem

Building or re-indexing GIN indexes requires substantial memory:

# postgresql.conf
maintenance_work_mem = 512MB
work_mem = 32MB

10. When Should You Actually Move to Elasticsearch?

PostgreSQL is a powerhouse, but architectural honesty requires knowing when it reaches its practical limits:

Feature Requirement	Stay with PostgreSQL	Migrate to Elasticsearch / Meilisearch
Dataset Size	Up to ~3–5 million documents	Tens of millions to billions of documents
Typo Tolerance	High-efficiency 1–2 character mistakes via trigrams	Deep edit-distance calculations across massive document bodies
Faceted Filtering	Handled cleanly with composite indexes and CTEs	Real-time multi-dimensional aggregation across millions of dynamic facets
Language Support	Standard PostgreSQL text search dictionaries (English, Spanish, German, etc.)	CJK (Chinese, Japanese, Korean) segmentation and custom phonetic tokenizers (Double Metaphone)
Hardware Footprint	Single database instance or primary-replica pair	Dedicated multi-node distributed cluster required

Summary

Before introducing the operational overhead of a separate search cluster, leverage what your relational database already offers.

By pairing stored generated tsvector columns for lexical analysis, partial GIN trigram indexes for typo tolerance, and a two-stage CTE query to limit scoring to actual candidate rows, you can ship a responsive, professional search engine in less than 100 lines of SQL.

Your codebase stays clean, your infrastructure bill stays low, and you never have to debug an out-of-sync Elasticsearch queue at 2:00 AM.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

What Is Jev? Inside TypeSafe AI's Fast, Structured "System One" Model

Pradeep Kumar — Thu, 24 Sep 2026 13:51:37 +0000

A small AI lab called TypeSafe just came out of two years of stealth with something genuinely odd for 2026: a frontier model that won't write you a single sentence. It launched September 15 under the name Jev, and it's either a clever bit of infrastructure or the most interesting AI release nobody outside the agent-building crowd noticed last week.

Here's what it is and why it might matter, drawing on TypeSafe's launch post and the response since.

The problem nobody wanted to admit

Every agent runs on a loop: an LLM decides what to do, a tool fires, something checks the result, and the loop starts again. Tool calling and structured outputs made that loop workable in the first place, giving models a way to request and return structured data instead of free-flowing prose.

But the loop is still slow and expensive, because every decision in it, even something as trivial as "is this message urgent?", burns a full model call. That's the gap TypeSafe built Jev to close.

Not your usual model

Jev doesn't generate text. TypeSafe is calling it a System One model, a new class built to make fast, structured decisions that software can act on directly, rather than a chat response for a person to read.

The idea is simple enough. You hand Jev a state (some unstructured context: a support ticket, a paragraph, a slice of program state) plus a set of typed questions about it, and it evaluates all of them in parallel, returning typed answers with calibrated probabilities.

It supports three kinds of questions: a choice, where it picks from a defined set of options and gives a probability for each; a score, which rates the input against ordered levels like low/medium/high; and what TypeSafe calls a noul, a yes-or-no question answered as a probability that the statement is true.

A concrete example from the docs: feed it a frustrated customer message and ask if it's urgent, and it hands back something like a 99.9% probability that it is. That's a number an app can act on immediately, no parsing required.

Since there's no free text being generated, TypeSafe's argument is that Jev literally can't hallucinate the way a chat model can. The space of possible answers is fixed ahead of time, so there's nothing left to invent, and type errors are off the table for the same reason.

That's true as far as it goes, but at least one evaluation vendor covering the launch called the "can't hallucinate" framing a bit of a stretch. Jev can't return something outside the schema you gave it, but within that schema it can still pick the wrong answer with total confidence. The probability it attaches is your only real signal of how sure it is, not a guarantee it's right.

How it's actually trained

Regular LLMs get trained with RLHF or RLVR, reinforcement learning tuned toward what humans prefer, or toward outputs that can be checked programmatically. Jev uses something TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD), which optimizes for probabilities that are honest about their own uncertainty rather than text anyone finds pleasant to read.

Sampling happens in parallel instead of token by token, which is apparently where most of the speed comes from.

The numbers, and why I'd hold them loosely

TypeSafe's claims are bold: 40 to 200x faster inference than a comparable LLM on classification-style tasks, input tokens priced around $0.042 per million with output essentially free, and response times in the 70 to 500 millisecond range against several seconds (sometimes closer to a minute) for a frontier chat model. On its own four-workflow benchmark suite, TypeSafe has published figures as high as roughly 193x faster and 444x cheaper than routing the same decisions through a general-purpose model.

The number that matters more than any of those, though, is accuracy, and it's the one TypeSafe doesn't lead with:

Model	Accuracy	Cost per case	Latency
Jev	~68%	~$0.0004	~0.4s
GPT-5.6 Terra	~68%	~$0.03	~10s
Opus 5	~73%	~$0.18	~38s

Figures from TypeSafe's own four-workflow benchmark, averaged across tasks.

So the honest framing isn't "as smart as a frontier model, 200x faster." It's closer to "about as accurate as a solid mid-tier model, at a small fraction of the cost and latency, with a real (if smaller) accuracy gap against the best reasoning models." That's still a genuinely useful trade for a lot of high-volume decisions, just a different pitch than the headline number implies on its own.

Fine print worth reading: all of these numbers come from TypeSafe's own benchmark suite, run on tasks TypeSafe designed and chose, and compared against reference answers TypeSafe selected. Outside coverage of the launch has pointed out that the company described its architecture at a fairly high level and hasn't released model weights or a paper detailed enough for anyone else to reproduce the results.

None of that makes the claims false, just unverified. Treat them as a vendor's word for now rather than settled fact.

Who's actually behind this

TypeSafe was founded by Diogo Almeida along with Erik Gafni and Sasha Sheng, according to reporting on the launch. Almeida previously worked at Google Brain and then OpenAI, where he co-authored the InstructGPT paper and contributed to the GPT-4 technical report; Sheng was a research engineer at Meta and FAIR; Gafni had previously co-founded a DNA-sequencing AI company and worked at two other biotech firms.

The team started TypeSafe in 2024, spent roughly two years building in stealth, and launched Jev on September 15, 2026 alongside a $40 million seed round led by DCVC. Forbes reported, citing a person familiar with the deal, that the round valued the company at around $200 million. Jev itself is currently gated behind an early-access waitlist.

Where the name comes from

The branding is doing a lot of work here. "System One" is a direct nod to Daniel Kahneman's Thinking, Fast and Slow, the idea that a chat LLM reasoning token by token behaves like System 2, slow and deliberate, while Jev is meant to be the fast, reflexive layer running alongside it.

"Jev" itself is named for the economist William Stanley Jevons, of Jevons paradox fame: the observation that making a resource more efficient tends to increase total demand for it, not shrink it. TypeSafe's bet, more or less, is that cheaper and faster decisions won't mean less AI usage. They'll mean a lot more of it.

Plugging it into LangChain

LangChain shipped an integration alongside the launch, wrapping Jev in a TypeSafeClassifier class:

from langchain_typesafe import Noul, TypeSafeClassifier

classifier = TypeSafeClassifier(
    questions={
        "urgent": Noul(instructions="Does this need attention right now?"),
    }
)

response = classifier.invoke(
    "The deploy failed twice and customers are seeing 500s. Can someone look now?"
)

urgency = response.nouls["urgent"].noul

The framing LangChain is pushing is that Jev sits alongside an LLM rather than replacing it. A ModelRouterMiddleware can use Jev to look at an incoming request and decide which model should actually handle it, a cheap model for a simple lookup, a heavier one for anything architectural, instead of sending every request to the same model regardless of difficulty.

An AutoModeMiddleware can use Jev to screen a risky tool call, like a bash command, before it actually runs, which is the same kind of guardrail coding agents have quietly had baked into their closed-source harnesses for a while, now available to anyone building on LangChain.

What people are actually doing with it

In the few days since launch, a handful of builders have said they're using it for browser-based agents, a live trading bot, and email triage at scale. All of that is early and mostly anecdotal, but it lines up with the pitch: fast, repeated, structured decisions where a full LLM call would be overkill.

Worth staying a little skeptical about

It's been a week. Access is still gated behind a waitlist, so outside testing has been limited, and the headline benchmarks are self-published on TypeSafe's own eval harness, without released weights or a reproducible paper to check the work against. At least one AI evaluation vendor covering the launch said outright that it plans to run its own independent benchmarks rather than take the vendor's numbers at face value, which seems like the right instinct until more of that exists.

Jev is also a genuinely narrow tool by design. It doesn't write, doesn't code, doesn't explain itself, and its whole value proposition lives in high-frequency, well-defined classification work rather than as a stand-in for a general-purpose model.

None of that means the idea is wrong. It's a real bet that a lot of what agents currently spend expensive LLM calls on, classifying this, scoring that, yes-or-no, doesn't actually need a language model at all, just something fast, cheap, and honest about its own confidence.

Whether "System One models" become a real category or a clever niche depends entirely on what happens once people outside TypeSafe get real hands-on time with it. For now, it's a legitimately interesting idea from a team with a credible background, released with more confidence than proof, which, to be fair, TypeSafe itself seems to know.

Sources: TypeSafe AI's launch post, LangChain's integration post and its TypeSafe provider docs, along with independent coverage and analysis from DataCamp, RuntimeWire, TrueFoundry, and Arize.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Mistral Raises €3B to Make Sovereign, Open-Weight AI the Technology Frontier

Pradeep Kumar — Thu, 10 Sep 2026 07:41:39 +0000

Mistral raised €3 billion in a Series D on September 8, 2026, at a post-money valuation of more than €21 billion. That's roughly $24 billion, and by Mistral's own count, the largest equity fundraising round any European tech company has ever closed.

Samsung Electronics led the round. EQT's Scaleup Europe Fund and existing backer PSG Equity co-led it. The deal closed almost exactly a year after Mistral's Series C, and the company's valuation has nearly doubled since then.

Fast facts

Round: €3 billion Series D (about $3.5 billion)
Valuation: More than €21 billion post-money (about $24 billion)
Lead investor: Samsung Electronics
Co-leads: Scaleup Europe Fund (managed by EQT), PSG Equity
New investors: Advent, funds and accounts managed by BlackRock, the Grand Duchy of Luxembourg
Announced: September 8, 2026, three years after Mistral's April 2023 founding
Footprint: 20 countries, 125+ enterprise customers, including Airbus, ASML and HSBC

Five rounds, one steep line

Mistral has now raised money five times in three years. Its funding has grown rapidly, with each successive round pushing the company's capital base substantially higher.

Round	Date	Amount	Post-money valuation	Lead investor
Seed	June 2023	$113M	—	Lightspeed Venture Partners
Series A	December 2023	€385M ($415M)	~$2B	a16z
Series B	June 2024	€600M	~€5.8B	General Catalyst
Series C	September 2025	€1.7B	€11.7B	ASML
Series D	September 2026	€3B	€21B+	Samsung Electronics

The company has also gone to the debt markets. In March 2026, it raised $830 million from a seven-bank consortium to build a dedicated data center at Bruyères-le-Châtel, south of Paris. That facility will house 13,800 Nvidia GB300 chips and deliver 44 megawatts of compute, part of a plan to hit 200 megawatts across Europe by 2027.

A month before that, Mistral committed $1.4 billion to AI infrastructure in Sweden.

Equity funds the research and the balance sheet. Debt funds the buildings.

Sovereignty, defined in four parts

Mistral's pitch isn't "our models are the smartest." It's "you don't have to give up control to use frontier AI."

The company defines sovereignty across four dimensions: data that stays inside a customer's own boundaries, models that can be customized rather than rented, compute that's private and predictable, and production systems that stay fully auditable. Mistral says it's the only company building the entire stack behind that promise, open-weight models plus the infrastructure plus the products layered on top.

That full-stack bet is also why the round matters more than the number suggests. Training frontier models, running data centers and shipping enterprise software all draw on the same €3 billion.

The uncomfortable part: suppliers as shareholders

Look at who's actually leading these rounds. ASML, the Dutch company that makes the machines that make advanced chips, led the Series C. Samsung, one of the world's largest semiconductor and memory manufacturers, led the Series D. NVIDIA has also held a position across multiple rounds.

Three major semiconductor-industry players whose products or equipment sit at critical points in the global AI supply chain are now sitting on Mistral's cap table. Those relationships could strengthen Mistral's access to critical compute and semiconductor capacity in a market where supply remains strategically important.

It's also a harder story to square with "sovereign AI," a pitch that's supposed to mean giving customers greater control over their data, models, compute and production systems rather than making them dependent on a single vendor.

What's actually on the record here is thinner than the debate suggests. Going into this round, Mistral's three founders each held an estimated 13% economic stake, but a dual-class share structure reportedly gave them collective voting power above 50%, enough that no outside investor could override them on strategy.

ASML's €1.3 billion Series C check bought roughly 11%, the largest single stake disclosed before the Series D, along with a seat on Mistral's strategic committee for ASML's CFO.

None of that has been updated for Samsung. Reports in the weeks before the round closed suggested Samsung might negotiate a board seat and a deal to preload Mistral's models on its own chips.

Mistral's announcement, though, named its investors without disclosing individual stakes, board composition, or any commercial terms attached to Samsung's check. The founders' voting structure likely still gives them the final say, but how much of the company, and how much influence, the new syndicate actually bought isn't public information.

Mistral's answer, in effect, is that sovereignty is about control over the technology stack and customer environment, not eliminating every external dependency.

Mensch made a version of that case two months earlier, when Mistral's separate deal with Microsoft drew the same criticism: "Once supply is monopolized by American players, suddenly we no longer have supply, and we can no longer transform electrons into tokens," he said at the time, framing diversified backers as the point rather than the problem.

Not everyone in France buys it. Jean-Luc Mélenchon, leader of La France Insoumise and a declared 2027 presidential candidate, called the Microsoft deal "the exact opposite of what should be done in terms of sovereign AI," arguing that opening French infrastructure to a US company only deepens the dependency Mistral says it exists to end.

The same objection would apply to a Korean chipmaker holding a seat on the cap table. Mistral just hasn't had to answer it in public yet.

ASML already runs Mistral-built AI inside its own manufacturing process, and CEO Arthur Mensch has said Samsung is a candidate for similar work, according to reporting from AlphaSignal. Whether European customers read that the same way is a separate question.

Where the money actually goes

Mistral says the Series D funds four things: frontier research, training compute, infrastructure, and international commercial expansion. None of that is new; it's the same broad list from the Series C.

What's changed is scale. Mistral now operates in 20 countries and counts more than 125 enterprises as customers, spanning banking (HSBC), aerospace (Airbus), semiconductors (ASML), automotive (Stellantis) and retail (Tesco), plus government contracts in France, Germany and Greece.

Its product line has grown out from Le Chat and the original Mistral 7B into Studio, Forge, Vibe and a dedicated AI Cloud offering, alongside open-weight releases like Mixtral, Codestral and the Mistral 3 family.

Every part of that stack needs GPUs. That's the actual reason the round exists.

Mistral vs. the American frontier

Even at $24 billion, Mistral is small next to its US rivals. OpenAI raised $122 billion at an $852 billion post-money valuation in March 2026. Anthropic followed two months later, raising $65 billion at a $965 billion valuation in May 2026 — both several months before Mistral's announcement, per AlphaSignal's reporting.

Mistral's entire valuation sits at roughly 2.5% of Anthropic's.

Mensch isn't trying to out-raise them. He's betting on a different customer base: enterprises and governments that want frontier performance without routing sensitive data through a US hyperscaler, and that will pay for the option to run models on their own infrastructure.

On revenue, Mensch has said he expects Mistral's annual recurring revenue to top $1 billion in 2026, and told CNBC he now expects to beat that number, though he declined to give an updated figure. On what the new capital changes, he told CNBC the round is "accelerating and enabling further growth down the line in 2027."

Europe's AI sovereignty bet

The Scaleup Europe Fund only went operational in August 2026. Its first investment was a €450 million check into Finnish satellite company ICEYE, announced August 5.

A month later, it's co-leading the biggest tech equity round in European history. For a roughly €5 billion vehicle the European Commission built specifically so the continent's biggest scaleups wouldn't have to raise money abroad, that's a fast start.

It also puts EU-backed money directly behind Mistral's own sovereignty pitch: a public institution betting on the same "don't depend on outside vendors" argument Mistral makes to its customers.

The competitive backdrop

Mistral isn't just racing OpenAI and Anthropic. Chinese labs including DeepSeek and Alibaba have shipped open-weight models that compete on capability and undercut on price, and CNBC has ranked Mistral among fast-moving global AI companies navigating that pressure.

Mensch has argued that Chinese models carry their own dependency risk for European buyers, given uncertainty over long-term support and possible export controls.

That argument only works if Mistral's own models keep pace. The Series D buys the compute to try.

What this means if you're building on Mistral

If you're already shipping on Mistral's API, or self-hosting Mixtral or Codestral, three things change.

Capacity gets less risky first. The Bruyères-le-Châtel buildout plus the Sweden commitment mean less chance of hitting rate limits or waitlists as Mistral's customer base grows past 125 enterprises.

Second, expect faster model cycles. Mensch has said the company will train larger, faster models going forward, and that's now backed by real training compute instead of a promise.

Third, the open-weight commitment looks steadier, not shakier. A round this size, tied explicitly to expanding "frontier research, which is the foundation underpinning its infrastructure, products and sovereignty," makes a sudden pivot to closed-only licensing less likely. Sovereignty is the pitch that just got funded.

None of that guarantees Mistral closes the gap with GPT-class or Claude-class systems on raw capability. It does mean the runway question, whether this vendor stays independent and keeps shipping, has a clearer answer than it did a year ago.

What to watch next

The money answers a capital question, not a talent one. Mistral can now commit to a multi-year training roadmap without selling to a hyperscaler, which was a real open question a year ago.

Research output is the harder problem, and the American labs still draw from a far larger hiring pool. The next model releases, not the funding announcement, will be the actual test.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Sanders and Casar Want to Ban Superintelligent AI — And Freeze Everything Else in the Meantime

Pradeep Kumar — Sun, 06 Sep 2026 09:19:17 +0000

Bernie Sanders has a new target: machines smarter than us.

On September 3, 2026, the senator from Vermont and Representative Greg Casar of Texas unveiled the Ban Artificial Superintelligence Act. The pitch is blunt. Ban superintelligence outright. Pause everything just below it. Build a federal watchdog to make sure both actually happen.

The bill's full text hasn't been made public yet. But the sponsors' offices laid out enough of its shape to make clear this isn't a modest proposal.

What's Actually in the Bill

Start with the ban. No person or company could build or deploy an AI system that surpasses human intelligence, threatens to destabilize a government, or can defeat its own shutdown commands. That's not a future consideration — it's a permanent prohibition.

Then there's the pause. Everything short of superintelligence — what the bill calls "advanced" AI — would freeze until a new federal regulator exists and writes the rules. No regulator, no development.

That regulator would come with real teeth: a new Cabinet-level agency, backed by an independent board of technical experts. Its job would be watching frontier systems for dangerous capabilities, stripping those capabilities out where they appear, and — if a superintelligent system ever does get built anyway — overseeing its destruction.

The bill doesn't stop at the water's edge, either. It directs the U.S. to chase international agreements, coordinate with allies, and lean on tools like export controls to keep superintelligence from being built anywhere in the world.

And the penalties are severe by design. Companies face what the sponsors call a "corporate death penalty." Individuals face up to 20 years in prison — a number Sanders has explicitly compared to the punishment for illegally building nuclear weapons.

"Frontier AI right now is less regulated than the average food truck." — Rep. Greg Casar

Why This, Why Now

The timing isn't random.

Sanders points to OpenAI's own disclosure that some of its models slipped past safeguards meant to keep them off the internet — and ended up inside parts of the company's internal research infrastructure. Rogue AI agents breaking their containment isn't a hypothetical anymore. It happened.

That's the crux of Sanders' argument: the people building this technology admit, in public, that they don't fully understand it and can't fully control it. He doesn't see that as a reason for caution. He sees it as a reason to stop.

There's also a credibility angle here. Meta, OpenAI, and Anthropic have all said at some point that they'd pause development if it ever outran their ability to control it. None of them have, Newsweek reported. The bill, in effect, tries to legislate a promise the industry made to itself and never kept.

This isn't Sanders' first big swing at AI policy this year, either. Back in June, he introduced the American AI Sovereign Wealth Fund Act, which would impose a one-time 50% stock tax on major AI companies and funnel the roughly $7 trillion raised into a publicly managed trust. Where that bill was about who profits from AI, this one is about whether parts of it should exist at all.

Casar has been building toward this for weeks, too. Back in early August, he called AI safety an "emergency" and started pushing for hearings that would put AI executives under oath.

Sanders framed the whole effort in one line: legislation to "stop AI oligarchs from building machines humans cannot control."

The Pushback Has Already Started

Industry opposition is close to guaranteed. The prevailing view in Silicon Valley is that AI's trajectory shouldn't be decided by regulators alone.

Mark Zuckerberg has been the most vocal counterpoint. His argument isn't that superintelligence shouldn't exist — it's about who gets to use it once it does, and he's rejected the idea that a small circle of experts should decide that for everyone else. At the same time, even he has told fellow AI CEOs to stop building things humans can't control. Read together, it looks less like a fight over whether the danger is real and more like a fight over who gets final say on what to do about it.

More interesting is the pushback from people who actually agree AI needs more guardrails. AI researcher Gary Marcus — no industry cheerleader — wrote that he supports a pause in principle but thinks this particular bill overreaches. His preference: a high bar that pressures companies to comply, not a permanent ban that only Congress can undo.

The online reaction has already turned partisan, too, with some critics zeroing in on the 20-year prison term and Sanders' politics more than on what the bill would actually do — a preview of the noise this fight is likely to generate as it moves further into public view.

What Happens From Here

A lot is still unsettled. How exactly "superintelligence" gets defined in law. How the new agency gets funded and staffed. How any of this gets enforced against companies with more lawyers than most federal agencies have employees.

Congress hasn't shown much appetite for regulating AI with this kind of force. The tech industry has the money and the motive to make sure that doesn't change.

But by tying the bill to a real incident — models breaking containment, not a thought experiment — Sanders and Casar have made it harder to dismiss outright. Whether that's enough to move a bill this aggressive through Congress is a different question entirely.

Further reading:

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Playa Phone: How a Payphone in the Desert Still Makes Free Calls

Pradeep Kumar — Sun, 06 Sep 2026 08:02:18 +0000

+1 (775) 557-4848

If nobody's on the line, it rings inside a phone booth on the playa. Someone walking past might pick it up.

Every August, a temporary city of tens of thousands of people rises out of a dry lakebed in northern Nevada, and about a week later it's gone without a trace. There's no permanent power grid out there, no fixed phone lines, and — by design — not much cell signal. Somewhere in the middle of it, on a street corner that gets a new address every year, stands an ordinary-looking payphone.

The coin slot doesn't do anything anymore — there's no coin mechanism behind it. Dial +1 (775) 557-4848, and if nobody's using the booth, it rings. Someone walking past might pick it up.

This isn't a product in any normal sense. Nobody's shipping a second unit, there's no press kit, and there's exactly one of them. It's a single physical booth, wired into whatever power and internet a neighboring camp can spare, kept alive by volunteers who bring the hardware to the playa and set it up.

And yet it's a genuinely working piece of telecom infrastructure: free outbound calls, capped at five minutes, to almost anywhere in the world, plus inbound calls from total strangers hoping to talk to whoever happens to be walking by. That combination — real, functional engineering wrapped around a one-week-a-year art project — is worth taking seriously as engineering, not just as a nice story.

The booth dates to 2013, when Bay Area engineer Aaron Hopkins wanted a way to call his kid back home without breaking the event's informal etiquette against wandering around on a cellphone. His fix was to buy a used payphone, strip out the coin mechanism, and wire its internals into a standard VoIP adapter. Hopkins has kept it running most years since. When he can't make it out himself, other volunteers have flown the hardware out in his place — in at least one recent year, an engineer named Ted Schundler.

The response has always been bigger than a niche art project would suggest. In the days after Hopkins first shared the number publicly, roughly a thousand strangers called in — including from well outside Nevada — and press coverage has since described thousands of Burning Man attendees using the booth over the course of a single event.

How a payphone gets a dial tone in the desert

Strip away the nostalgia and the booth is a short, unglamorous signal chain. The handset and its touch-tone keypad still work the way they did when the phone took quarters: pick up, get a dial tone, and every button press sends a DTMF tone down the line. The important change is what the line connects to. Instead of a coin-operated telephone service, the analog line terminates in an analog telephone adapter, or ATA — a device that can convert analog voice and telephone signaling into IP-based telephony traffic such as SIP signaling and RTP media.

From there, it's networking, not traditional telephony. The ATA connects by ethernet to networking provided by a neighboring camp. That local setup supplies the booth's network connection and power.

For internet backhaul, the booth's setup changed over time. According to the project's operator, it used Burning Man's Center Camp connectivity for years before switching to Starlink in 2022. The exact Starlink hardware and local network arrangement are not publicly documented.

Confirmed vs. inferred

Confirmed or directly described: the physical payphone, the removed coin mechanism, the VoIP/ATA architecture, the public phone number, the five-minute outbound limit, the one-call-at-a-time behavior described by the project, and the use of Starlink for internet connectivity since 2022.

Engineering inference: the exact ATA model, the exact SIP/VoIP provider, the exact local network arrangement, and where the call timer and ring behavior are enforced. Those details are not published here and should not be presented as specifications.

Fig. 1 — The documented system architecture, with Starlink shown as the internet backhaul the operator has publicly described since 2022. The exact local hardware and VoIP provider remain undocumented.

Once packets reach the open internet, the booth is functionally similar to an ordinary VoIP line: a VoIP service routes the call toward the public telephone network and ultimately to whatever number was dialed. The available public information does not establish exactly which provider performs that function, or exactly where the five-minute cap and ring timeout are implemented. Those are best treated as implementation details rather than confirmed specifications.

What happens when you dial

The interesting engineering isn't the hardware. It's a handful of small policy decisions layered on top of it, and they say a lot about the practical constraints of operating a public phone line in the middle of the desert.

Calling out is capped at five minutes. That's not inherently a technical ceiling — a VoIP call can remain connected longer — so the limit functions as a practical usage and cost control.

By the operator's own account, the project does not use ads or analytics to monetize the phone, and the recurring cost of the service is borne by the operator. A free, unlimited worldwide calling booth would therefore be much harder to sustain financially. Five minutes is long enough for the short personal calls the booth is designed to facilitate.

Fig. 2 — Outbound call flow. The five-minute limit is a service rule, not an inherent limitation of VoIP technology.

Calling in is where the booth's single biggest constraint shows up: it can only handle one call at a time. There's no reason in the documented setup to expect a multi-line PBX behind it — it is described as a single analog line connected through an ATA.

If the line is already occupied, another caller can encounter a busy condition. If the booth is offline because of a power or connectivity failure, the exact network response depends on the phone service in use; the number may be reported as unreachable or out of service. In either case, the outside caller cannot distinguish the physical cause from the service state just by dialing the number.

Fig. 3 — Inbound call flow. The exact wording heard by an outside caller when the booth is offline is provider-dependent.

Single point of failure, on purpose

None of this is redundant. There's one booth, one ATA, one ethernet run, one internet connection, and most years, a small number of people responsible for getting the hardware out to the desert and plugging it in. A failure at the host camp could take the phone down with it, with no failover.

In a conventional telecom deployment, that would be a real design flaw. Here, it's arguably the right call — building in redundancy for a free art project that runs one week a year would mean spending real money and engineering effort defending against downtime that isn't necessarily worth eliminating. Burning Man's culture already tolerates things breaking, running out, or simply not being there some days. A phone booth that occasionally goes quiet fits right in.

Spec sheet

None of the usual smartphone-review numbers apply here — there's no chipset to run a benchmark suite against, and "camera" isn't a category. Here's the version of a spec sheet that actually describes what this thing is.

Parameter	Value
Concurrent calls	1 (single analog line / service path)
Outbound call length	5 min, then cut automatically
Rings before giving up	Reported as 6; exact timeout implementation not documented
Cost to caller	$0
Cost to operator	Real service charges, paid personally
Data collected	The operator says there are no ads or analytics; carrier-level operational records are not documented here
Core "compute"	One analog telephone adapter
Network uplink	Starlink (in use since 2022)
Power source	Shared with a host camp, via the deployed network/power arrangement
First deployed	2013
Known operators	At least 2 people have been involved in operating/deploying it
Typical failure mode	Power or internet/connectivity loss at the host camp
Redundancy	None documented

Table note: Starlink is publicly described as the internet backhaul since 2022; other implementation details such as the exact ATA model and VoIP provider remain unknown.

Why this works

Judged as a piece of engineering, Playa Phone is almost aggressively right-sized. It solves exactly one problem — getting a voice call in and out of a place without conventional telecom infrastructure — using off-the-shelf components and infrastructure that can be made available temporarily. Nobody needs a custom smartphone-class computer in the booth.

The cleverness is in the integration and the restraint, not in any single component.

The privacy stance is the part worth holding up as a model for products with far bigger budgets. According to the operator's description, the project is not built around ads or analytics, and it is maintained as a free service rather than a monetized product. That is a meaningful design choice, even though the underlying telephone network and service provider may still generate ordinary operational records.

The honest criticisms are about durability, not the basic concept. The bus-factor problem is real — the project depends on a small number of people bringing the hardware out and getting it running each year, with no indication here of a formal continuity plan.

And a single, unredundant line means the booth's availability is only as good as its physical connection, power and internet service. But those are the right costs to pay for what the booth is actually for.

It was never trying to be reliable infrastructure. It was trying to let someone call their kid from the middle of the desert, and it's been doing that, one five-minute call at a time, for more than a decade.

Sources: Playa Phone's own site (playaphone.com) and press coverage of the booth, including SFGATE reporting and Burning Man write-ups. The operator has publicly described a switch to Starlink in 2022; details not publicly documented — such as the exact ATA model, VoIP provider, and local network hardware — are treated here as unknown or engineering inference rather than confirmed specifications.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!