1 The decomposition

Write for the time (or dollars) needed to reach target , for the operations algorithm needs to reach it, and for the operations per second (or per dollar) our hardware delivers. Then .

Moving from an old setup to a new one , the speedup telescopes:

This is an identity, so it always holds. In logs, the three terms add, and “what share of the progress is algorithmic?” looks like it has an answer. It only has one if the identity is also a production function, in which the factors do not depend on one another. Even as accounting, it has gaps. One is that the split depends on the order in which we apply the changes. Another is that some of the factors can be infinite. If the old method cannot reach the new target at any budget, or the new method only makes sense for a target the old problem never posed, the ratio is infinite or undefined. Infeasible-to-feasible transitions are arguably where most of the value lies, and a cost ratio cannot see them.

2 Example

Gaussian-process regression makes a handy worked example. The task is posterior predictive inference. With training points, kernel matrix and noise , the predictive mean at a test point is and the predictive variance is ; fitting the hyperparameters also needs . The cost of a prediction is dominated by an linear solve with respect to a symmetric matrix.

• Exact, naive: transcribe the equations, form explicitly and multiply. About operations and poor conditioning, i.e., numerically unstable. This is the cost of the base problem as written.
• Exact, competent: Cholesky at operations, triangular solves at per right-hand side, read off the diagonal of for free. Same answer in principle but due to floating point shenanigans, much faster and more stable. Still but less awful. A pure algorithmic gain: same answer, fewer operations.
• Same answer to tolerance : the same posterior but we allow some error. Conjugate gradients for the solve and Lanczos methods for cost per iteration and stop at ; randomized sketches (Halko, Martinsson, and Tropp 2011) give an -approximate answer with a probabilistic guarantee. Admits more data at a known loss of precision, so now we have a tradeoff.
• Same predictive risk, different estimator: a variational posterior. Inducing-point methods summarize the data by pseudo-inputs at cost. The output is no longer the GP posterior per se; it is a different distribution we hope has about the same predictive risk, which in practice we assess by scoring on a held-out set.
• Same held-out score, different model class: a neural network that scores as well on the held-out set. There is no system to solve any more, so the cost of inference is . There is also no posterior per se: the network returns a point prediction, or an uncertainty estimate of some other kind.

Only the second step leaves the target alone. Each later step is a looser contract about what counts as success: the output to tolerance, then the risk of the estimator, then a benchmark score, and at the far end, the task the benchmark was meant to stand in for.

3 As a production function

The multiplicative form treats hardware and algorithms as inputs to a production function in which only their product matters, the “effective compute” of the scaling-law literature. Its isoquants are hyperbolae, so it is Cobb-Douglas between the two, with elasticity of substitution and no cross terms; in translog terms it is the first-order expansion with every . The hardware lottery (Hooker 2020) says the cross terms are not zero.

A cost function makes the structure easier to see. Hardware does not have a speed; it has a price for each kind of operation: FLOPs at each precision, bytes moved from memory, synchronizations, mispredicted branches. Write for that price vector on hardware . An algorithm that reaches target uses a bundle of those operations in fixed proportions, like a Leontief technique in activity analysis. The cost of reaching is then

where is the set of algorithms we know that reach . Algorithmic progress adds techniques to ; hardware progress changes .

Uniform hardware gains are exactly multiplicative. A cost function is homogeneous of degree one in prices, , whatever the algorithm. If every operation got cheaper by the same factor, the hardware factor would be well defined and independent of the algorithm. Clock-speed scaling up to about 2005 was the nearest thing we had, and even then memory latency fell behind.

Small uneven gains are multiplicative at the margin. By the envelope theorem, the first-order change in cost from a small change in prices is , evaluated at the algorithm we already use; switching algorithms gains only at second order. So locally the multiplicative form is fine, and that is the sense in which hardware and algorithms are separable.

Large uneven gains are not. When relative prices tilt far enough, the cheapest algorithm changes. That is the hardware lottery restated as a change in relative prices. Since about 2005 tilting has been the norm: GPU FLOP/s double every 2.3 years against memory bandwidth every 4.1 (Hobbhahn, Heim, and Aydos 2023), and SIMD units and GPUs made regular, dense, branch-free operations far cheaper than irregular ones. FlashAttention (Dao et al. 2022) is a tidy example. It computes exact attention with more FLOPs than the standard implementation, and runs faster because it moves less data between memory levels. Counted in FLOPs it is negative algorithmic progress, and it pays only because of the price vector. The gain from switching algorithms after a large price change belongs to neither factor; it is the interaction term, and the order in which we price the factors decides which one gets it. Fichte, Hecher, and Szeider (2023) measured it directly: SAT solvers from 2003 built on clause learning solve 1.7 to 2.8 times as many instances on 2019 hardware as on 1999 hardware, while the older solvers barely gain.

There is a possible rescue at the aggregate level. Houthakker (1955) showed that aggregating many fixed-coefficient activities, with capacity Pareto-distributed over their input coefficients, gives a Cobb-Douglas industry production function, and Jones (2005) turned this into a theory of ideas: if techniques are discovered as draws from a Pareto distribution, the envelope over all discovered techniques, the global production function, is Cobb-Douglas, even though each technique has fixed proportions and the short-run production function substitutes poorly. Mapped onto this problem, the global cost function would be Cobb-Douglas in operation prices. An uneven hardware gain would then enter as a cost-share-weighted product of the per-operation price falls, and new algorithms would shift the constant in front. The multiplicative form would survive as a description of the frontier over many algorithm–hardware pairings, with kinks, even though no single pairing behaves that way. That would reconcile smooth trend lines with lumpy individual cases. Sherry and Thompson (2021)’s bimodal gains are at least heavy-tailed; whether they are Pareto enough for this to hold, I do not know.

The target fits the frame worse, because it is not an input.

• Loosening changes the menu. depends on : conjugate gradients is only an option once we accept a tolerance, and the neural network only once a held-out score is the criterion. The main effect of loosening is to enlarge the feasible set of techniques, and the “algorithm” factor is then measured over techniques that were not available before.
• Loosening interacts with hardware. Lower precision only pays where low-precision operations are cheap, and randomized linear algebra wins partly because it turns a sequential factorization into large dense matrix products. So there are three-way interactions as well.
• Loosening may not be a cost reduction at all. The output has several dimensions (accuracy, guarantees, calibrated uncertainty, which instances are covered), so we are on a multi-output transformation frontier rather than a production function. Whether a cheaper output counts as the same good depends on what the user wanted, that is, on the task. For someone who wants a held-out score, the neural network and the GP are the same good; for someone who needs a calibrated posterior variance, they are not. This is the quality-adjustment problem from price indices, as in the computing price series of Nordhaus (2007), and it means the loosening factor is set by demand as much as by production technology.

4 Measured progress

A measurement of algorithmic progress has to hold some target fixed, and it can only hold fixed a target it can check: the exact output, a tolerance, a benchmark score. Call that the measured target . What a user wants done, the task , is something else: a PDE solution accurate to the discretization error, say, or a classifier that works on the photos it will meet in deployment. A benchmark stands in for a task that is hard to measure directly, which is the construct-validity problem of Raji et al. (2021).

The measurement reports the algorithm factor at . Multiplying and dividing by each method’s cost at the task splits that into two factors:

For each method, is how much more it would cost that method to do the task than to reach the measured target. The second factor compares that gap for the new method against the old one. It is 1 when the measured target is the task, or when both methods find the two equally far apart, and in those cases the measurement is progress on the task. The table sorts the published measurements by their measured target.

setting	measured target	algorithms	hardware	source
LP, 2001–2020	exact solution			Koch et al. (2022)
MILP, 2001–2020	exact solution			Koch et al. (2022)
SAT, 1999–2019	instances solved in time limit	about equal	about equal	Fichte, Hecher, and Szeider (2023)
exact algorithm families	output	median 6%/yr at , 28%/yr at		Sherry and Thompson (2021)
ImageNet, 2012–2019	AlexNet-level accuracy	/ 16 months		Hernandez and Brown (2020)
ImageNet	accuracy, model-based	/ 9 months		Erdil and Besiroglu (2023)
language models, 2012–2023	perplexity, model-based	/ 8 months		Ho et al. (2024)
GPUs			/ 2.3 yr FLOP/s; / 2.1 yr FLOP per dollar	Hobbhahn, Heim, and Aydos (2023)

The two halves of the table miss the task in different ways.

The classical rows hold a target stricter than the task. They fix the exact output, while most tasks only need it to some tolerance. Then , and it is smallest for the methods that can exploit the tolerance, so when the new method is one of those, the mismatch factor is below 1 and the measurement undercounts progress on the task. Sherry and Thompson (2021)’s exclusion of approximate algorithms is the extreme case: methods that only pay off at a tolerance are left out altogether.

The best-known chart of algorithms beating Moore’s law shows what changes when we measure against the task instead. Rüde et al. (2018) plot the cost of solving the Poisson equation on an grid, from banded Gaussian elimination in 1947 at operations to Brandt’s multigrid in 1974 at . At the ratio is , which they match to the 24 doublings of Moore’s law over the same period. Gaussian elimination solves the discretized system exactly, while multigrid’s is the cost of an iterative solve stopped once its error is down to the size of the discretization error. Against the exact solve, part of that speedup is loosening. Against the task, which never needed more than the discretization accuracy, all of it is algorithm, because Gaussian elimination has no way to stop early: . That is the order dependence of the Cholesky example, settled by taking the task as the reference target.

The ML rows hold a target that differs from the task in both directions. A benchmark score can be reached without doing the task, wherever the score fails to check something the task needs: robustness, calibration, the photos the model will meet in deployment. It can also demand things the task does not need, such as telling apart the hundred-odd dog breeds in ImageNet’s label set, or agreeing with labels that are themselves wrong; at least 6% of the ImageNet validation labels are (Northcutt, Athalye, and Mueller 2021). So each method’s gap can sit on either side of 1, and nothing in the setup fixes the sign of the mismatch factor.

Selection fixes it, roughly. When a benchmark is new, nobody has optimized against it, so the first method to reach a given score has no special relationship to the benchmark’s quirks. Later methods are selected for reaching the score cheaply, that is, for a small , and nobody selects them for a small . Whichever way the benchmark differs from the task, that selection favours methods specialized to the benchmark: good at what it checks, whether or not the task needs it, and indifferent to what it does not check. So the mismatch factor drifts above 1, and the measurement overcounts. This is Goodhart’s law written into the identity: the benchmark measured the task well until it became the target. Shortcut learning is the limit, where a model reaches the score and cannot do the task at any budget, so is infinite (Geirhos et al. 2020).

There are two checks I know of on how large the overcount is, and they point in different directions. Recht et al. (2019) rebuilt the ImageNet test set by following the original collection process, and found that models lost 11–14 points of accuracy on it, but that gains on the original test set came with larger gains on the new one. That rules out one route to overcounting, reuse of the same test set, at least on ImageNet up to 2019. It cannot see the other routes, since a fresh test set built the same way shares the original’s quirks. Beyer et al. (2020) relabelled the ImageNet validation set with a more careful annotation procedure, and found the gains of recent classifiers substantially smaller on the new labels than on the original ones. That is the overcount from fitting the benchmark’s quirks, measured directly.

Three more details from these measurements feed into the inferences. The MILP figure covers only the instances both generations of solver could finish; 149 of the 240 MIPLIB 2017 instances were out of reach of every 2001 solver within 24 hours. Sherry and Thompson (2021) find algorithmic gains bimodal: just under half of algorithm families never improve, and a few jump by orders of magnitude, so the median family overtakes hardware only around . And Gundlach et al. (2025) find that the LSTM-to-transformer gain is a change of scaling exponent rather than a constant multiplier: about at FLOP, over at .

5 Minimal inferences

Where the target is held exact, algorithms and hardware are roughly even. Three different designs agree on this: solver binaries swapped across machines (Koch et al. 2022), the time-leap SAT experiment (Fichte, Hecher, and Szeider 2023), and Grace (2013)’s survey across six domains, which puts algorithmic gains at 50–100% of hardware gains. The algorithmic gains are lumpier, which matters for forecasting even when the averages match. An exact target is stricter than most tasks, so this undercounts algorithmic progress on the task by however much the approximate methods are worth. In the area I know best, Gaussian processes, approximate methods are what people mostly use; I do not know how big the undercount is elsewhere.

ML’s faster algorithmic rates are measured against a different target. An 8-month doubling against a 2-year hardware doubling makes algorithms look like the bigger term, but part of it may be mismatch between benchmark and task, which Goodhart’s law predicts will grow the longer a field optimizes against one benchmark. Since loosening is a one-off per task, I would not extrapolate those rates as if they were hardware-like trends. If this is right, a new task should show a burst of fast early “algorithmic” progress while people discover what can be thrown away, then slow down. That is at least consistent with how benchmarks tend to saturate, though I have not checked it.

Some hardware progress is loosening too. Epoch fits accelerator FLOP/s within one number format and reports the move to lower precision separately, as a one-off of roughly for FP16 tensor cores and for INT8 (Hobbhahn, Heim, and Aydos 2023). At a 2.3-year doubling time, those single steps are worth about 7 and 8.5 years of FP32 progress. Lower precision loosens the target, and gets booked as hardware.

At the frontier, the split is not well defined. This is the envelope problem, in the quantity of compute rather than the price of operations. If the transformer’s advantage grows with compute, then the “algorithmic” gain at frontier scale grew because frontier compute grew, and listing it beside compute as a separate factor counts that growth twice. At a fixed small scale the comparison is cleaner, and there Gundlach et al. (2025) put a decade of algorithms at around at FLOP, a bit less than the hardware gain over the same decade.

The most valuable progress is invisible to all of these. Infeasible-to-feasible transitions give infinite ratios, and loosening is the usual way they happen. So any account of “how much faster we got” built from cost ratios underweights loosening, and that is the factor I would most like a handle on.

🚧TODO🚧 Can we estimate in advance how far a task’s target can be loosened? For statistical tasks there is a floor: Thompson et al. (2022) argue compute must grow at least as performance to the fourth power, and measure something closer to the twelfth on ImageNet. The fourth power comes from two square laws: at the usual statistical rate, halving the error needs the data, and training an overparameterized model costs about in the data size, so the compute. That gap looks like a candidate measure of how much loosening is left.

6 Incoming

• Neural scaling laws
• ML benchmarks
• Grammar induction
• Bloom et al. (2020) on why constant exponential progress needs exponentially growing research effort.
• Sanderson et al. (2025) on compute-dependent advances, which make algorithms and compute complements rather than substitutes.
• Pilz, Heim, and Brown (2024) on separating the falling cost of a given capability from the rising capability per dollar.

7 References

1 Setup

I assume there are two types of authors: high-quality authors (type ) and slop authors (type ). They differ only in the substance of their manuscripts and behave strategically regarding presentation. The proportion of high-quality authors is , and the rest are slop authors. Articles have apparent substance , which is the quality the manuscript presents to a reviewer—the quality a reviewer can assess. I measure it in citoms, my idiosyncratic unit of “citability,” which happens to be what citations count. These are themselves an imperfect proxy for the true output we desire, scientific progress , which is what a reader gets if the manuscript is published. I measure that in scientillas.²

A high-quality author spends substance time on each manuscript—the hours of research and thinking rather than writing up. The result is a manuscript that reads as well as it actually is, with as many citoms as scientillas:

A spread of author skill acts as a multiplier on ; I ignore it.

The rest of the authors produce slop, which in my model means manuscripts worth citoms at a glance but zero scientillas upon deep reading, , made with the minimum substance time . All of which is to say, the authors aren’t deceptive, whereas the authors produce low-quality outputs masquerading as adequate.

Every manuscript additionally requires drafting time : hand-drafting costs , AI drafting costs , where is the AI’s drafting efficiency. At AI saves nothing, so everyone might as well hand-draft; I call that no-AI state the hand-drafting equilibrium, and it is the baseline for all other policies. An author has a time budget per period (year?), so an author who produces manuscripts at a cost of substance effort time satisfies . We write and for the substance time and manuscript count an -type author chooses, and for a slop author’s manuscript count; slop authors have no substance time to choose.

Reviewing a manuscript to the journal’s standard takes reviewer-hours, which we call the depth of review, and there are total reviewer-hours, so the journal can review at most manuscripts. Facing submissions, it reviews of them and rejects the rest unread, so a submission’s chance of being read at all is the coverage rate

A manuscript that receives a review is accepted with a probability depending on both its substance and the review time ,

i.e., deeper reviews detect the scientific substance more precisely. Here is the journal’s bar—the number of citoms at which we accept a reviewed manuscript half the time. We write and for the acceptance probability of a reviewed high-quality manuscript and a reviewed slop manuscript, respectively. The journal holds the depth fixed with respect to queue size. Review slots are the scarce resource in what follows: every submission takes one, and a submission that goes unread costs its author nothing but costs the journal whatever it displaced.

Authors are assumed to be careerist, in that they care only about a payoff per accepted paper. The payoff is earned by clearing the bar in citoms; scientillas earn an author nothing beyond that. A high-quality author facing a drafting cost thus solves

maximizing accepted papers per unit of time. No author can change the coverage rate , and it scales the payoff of every candidate identically, so it drops out of the optimization. As such, congestion never influences the choice of how much effort we dedicate to substance. What influences the choice is the drafting cost , which is by hand or with AI. Every hour spent on the substance of one manuscript is an hour not spent starting the next, and controls how much that next manuscript would have cost. The first-order condition is

As AI capability rises, falls, the next manuscript gets cheaper, and the optimum tilts toward more, thinner papers.

Now let us consider the target audience, the readers. Recall our goal as benevolent planners to maximize the readers’ welfare. I operationalize that as the number of good papers published per period—the total amount of science we are pumping out to all readers. Of the high-quality manuscripts written, a fraction get reviewed and a fraction of those pass, so the flow of high-quality papers into print is the throughput

The obvious alternative is the average scientillas per published article, , roughly the amount of science a reader finds by sampling the published literature at random; slop counts against , whereas merely ignores it. Every ranking of one policy against another below comes out the same way under both, so I track and mention only at the point where they disagree: how high we should set the fee in Policy D. Both count scientillas, which measure public-good outcomes. The authors’ incentives, by contrast, count citoms, career-wise goals measured in citations. Slop writing is the stuff that produces the latter without the former.

I make three other simplifying assumptions:

1. AI drafting here introduces no errors and incurs no cognitive debt³
2. Accepted slop delivers zero value but is not actively harmful.⁴
3. The review budget is exogenous: is money divided by the going wage for qualified reviewer attention, and the model holds both fixed.

import numpy as np
import matplotlib.pyplot as plt
from livingthing.matplotlib_style import set_livingthing_style
set_livingthing_style()

P = dict(theta=1.0, s_L=0.30, sbar=0.50, t_min=0.05, f=0.50,
         T=1.0, lam=0.25, R=16.0, h=10.0, b=1.0)

T_GRID = np.geomspace(P["t_min"], 25.0, 4000)

def logistic(x):
    return 1.0 / (1.0 + np.exp(-np.clip(x, -60, 60)))

def accept_H(t, p=P):
    return logistic(p["h"] * (p["theta"] * np.sqrt(t) - p["sbar"]))

def accept_L(p=P):
    return logistic(p["h"] * (p["s_L"] - p["sbar"]))

def best_H(d, p=P, fee=0.0):
    """Substantive author's optimum: maximize (b*accept - fee)/(t+d).
    The coverage rate r is a common factor, so it never appears here.
    Returns (value per unit time, t*)."""
    obj = (p["b"] * accept_H(T_GRID, p) - fee) / (T_GRID + d)
    i = int(np.argmax(obj))
    return obj[i], T_GRID[i]

def outcomes(nH, wH, tH, nL, wL, p=P):
    """Coverage, mean substance per article, and good-paper flow."""
    N = p["lam"] * nH * wH + (1 - p["lam"]) * nL * wL
    r = min(1.0, (p["R"] / p["h"]) / N) if N > 0 else 1.0
    aH = p["lam"] * nH * wH * accept_H(tH, p)
    aL = (1 - p["lam"]) * nL * wL * accept_L(p)
    sH = p["theta"] * np.sqrt(tH)
    W = aH * sH / (aH + aL) if aH + aL > 0 else 0.0
    return dict(r=r, W=W, thruH=r * aH, tH=tH, sH=sH)

def solve_A(a, p=P):
    """Free-for-all: everyone AI-drafts, triage to capacity."""
    delta = p["f"] / a
    _, tH = best_H(delta, p)
    return outcomes(p["T"] / (tH + delta), 1.0, tH,
                    p["T"] / (p["t_min"] + delta), 1.0, p)

def mu_star(a, p=P):
    """True-positive rate above which slop producers abandon AI drafting."""
    return 1.0 - (p["t_min"] + p["f"] / a) / (p["t_min"] + p["f"])

def mu_sub(a, p=P):
    """True-positive rate above which high-quality authors abandon AI drafting."""
    Vh, _ = best_H(p["f"], p)
    Va, _ = best_H(p["f"] / a, p)
    return 1.0 - Vh / Va

def solve_B(a, mu, p=P):
    """Detector ban: AI-drafted papers desk-rejected with true-positive rate mu."""
    delta = p["f"] / a
    dH, wH = (delta, 1 - mu) if mu < mu_sub(a, p) else (p["f"], 1.0)
    dL, wL = (delta, 1 - mu) if mu < mu_star(a, p) else (p["f"], 1.0)
    _, tH = best_H(dH, p)
    return outcomes(p["T"] / (tH + dH), wH, tH,
                    p["T"] / (p["t_min"] + dL), wL, p)

def solve_C(a, p=P, eps=1e-3):
    """Fee at slop's uncongested break-even: slop exits entirely."""
    delta = p["f"] / a
    fee = p["b"] * accept_L(p) + eps
    _, tH = best_H(delta, p, fee=fee)
    out = outcomes(p["T"] / (tH + delta), 1.0, tH, 0.0, 0.0, p)
    out["fee"] = fee
    return out

2 Policy A — Free-for-all

Under this policy, anyone may use AI, and we triage submissions according to capacity (if we receive too many papers, we reject the excess). tl;dr everyone drafts their manuscripts with AI, as it is cheaper and goes unpunished, and the extra manuscripts mostly go unread. The equilibrium is easy to compute: the substance choice depends only on the drafting cost , submission counts follow from the time budget, and coverage follows from the counts.

Code

a_grid = np.geomspace(1, 100, 25)
eqA = [solve_A(a) for a in a_grid]

fig, axes = plt.subplots(1, 3, figsize=(9.5, 3), sharex=True)
axes[0].plot(a_grid, [q["tH"] for q in eqA])
axes[0].set_title("substance time $t_H$")
axes[1].plot(a_grid, [q["r"] for q in eqA])
axes[1].set_title("coverage $r$")
axes[2].plot(a_grid, [q["thruH"] for q in eqA])
axes[2].set_title("good papers per author-period $Q$")
for ax in axes:
    ax.set_xscale("log")
    ax.set_xlabel("AI capability $a$")
fig.tight_layout()
plt.show()

Optimistically, we might hope that cheaper AI drafting frees up time compared to the manual alternative, allowing for more substance per paper. That does not happen under this model. The left edge of the capability sweep, , is the hand-drafting equilibrium. For the high-quality tier , the substance time per manuscript falls modestly as rises, from to about : cheaper drafting makes each manuscript cheaper, so authors choose quantity over quality. The fall is not too precipitous though: high-quality manuscripts stay above the bar ( drifts from down to scientillas, against a bar of citoms), and their authors write three of them where they used to write one. For the low-quality tier , the slop authors’ output grows much faster, because a slop manuscript is nearly all drafting time: rises from under to over .

The downside is visible through the effect on the queue. The submission pool ends up slop and coverage falls from roughly to , so the journal publishes about four times fewer high-quality papers, even though the high-quality authors are writing more of them than before. Most of their extra manuscripts are simply never read. In the units of the model that is falling from to good papers per author-period: a journal drawing on a hundred authors goes from printing 22 good papers a period to 6. The average quality of what it does print falls too, since slop passes a full review of the time and the pool is slop, so most of what the journal accepts is slop.

The collapse is smooth and the equilibrium is unique. The coverage rate cancels out of every author’s problem, so there is no feedback loop to amplify anything, and no tipping point. We could expand upon that but we do not right now.

3 Policy B — Automated ban on AI-drafted manuscripts

A stylometric detector (e.g. Pangram) flags manuscripts it thinks are AI-drafted, and we desk-reject those.⁵ This is the only desk-reject stage; anything it passes goes into the capacity triage of the review queue. I assume the detector has true-positive rate , which the machine-learning literature calls its recall: it correctly flags a fraction of AI-drafted manuscripts. For now, I assume it has a zero false-positive rate to keep it simple.⁶ Desk-rejected papers consume no reviewer time. The rest get a normal review.

Before anyone changes behaviour, notice what the detector is to an author who drafts with AI: a fee. A fraction of their manuscripts is thrown away unread, so each one loses times its expected return, for a good manuscript and for slop. That is a proportional levy on expected return, and since it charges a good manuscript more than a slop one; a separating fee would do the opposite. We return to this with the flat congestion charge of Policy D. That by the way, is the sense in which the ban is an imperfect approximation to a fee.

Now, knowing this policy, everyone chooses how/if to write their papers. For low-quality authors, the trade-off is between the time saved by using AI and the risk of being desk-rejected. Their acceptance probability if they get past desk-rejection is the same however the manuscript was drafted, so it cancels from the comparison, and what remains is: papers per hour with AI, discounted by the survival rate , against papers per hour by hand. They keep AI drafting while , where

In this setting, the detector’s true-positive rate is pivotal, and the threshold it needs to clear depends on the time costs of producing slop. In particular, as AI capability rises toward , the share of a hand-drafted slop manuscript’s time spent drafting is about at my parameters. As such, a detector with a true-positive rate below that threshold deters slop authors only while AI is weak enough that is under its rate; as capability grows past that point, the same detector stops working without any change in the policy or the detector. On unmodified LLM output, the best commercial detector clears that comfortably: Pangram reports a false-negative rate of at a false-positive rate of (Glickenhaus et al. 2026), and independent tests put it near (Russell, Karpinska, and Iyyer 2025). The rate that matters, though, is the one sustained against slop authors who rewrite to evade detection once it cuts into their earnings, and there the numbers are grim: Pangram’s own figure on AI-edited human text is – (Glickenhaus et al. 2026), and on academic abstracts a rate falls to once rewrite prompts are searched against the detector (Ren, Raghavan, and Garg 2026) and below after a commercial humanizer (Karr et al. 2026). And because rises with capability, a ban that deters slop today can fail later without any policy change and without any decline in the detector. We ignore that twist for now.

The high-quality authors have a different behaviour threshold. Write for the best rate of expected acceptances per unit time that a high-quality author can achieve at drafting cost . High-quality authors abandon AI drafting once falls below , that is at

The two thresholds are strictly ordered: for every (at both are zero). To see this, let be the substance time a high-quality author chooses when drafting with AI. A hand-drafting author could choose that same ; it is not their optimum, so is at least what it yields, namely . The ratio increases in , and a slop author is at , so their ratio is smaller and their threshold is larger. In other words: the more substance time we invest in a manuscript, the smaller the share of its cost that AI drafting saves, so the less detection risk we will accept to keep using it. A detector therefore stops high-quality authors from using AI strictly before it stops slop authors. Neither type is ever deterred from submitting: at worst, slop authors revert to hand-drafting, which restores the hand-drafting equilibrium’s spam rate, never less. Being flagged costs a high-quality author a manuscript full of work; it costs a slop author almost nothing.

Code

mu_fix = 0.5
eqB = [solve_B(a, mu_fix) for a in a_grid]
a_star = P["f"] / ((1 - mu_fix) * (P["t_min"] + P["f"]) - P["t_min"])
lo, hi = 1.0, 1e4
for _ in range(60):
    mid = np.sqrt(lo * hi)
    lo, hi = (mid, hi) if mu_sub(mid) < mu_fix else (lo, mid)
a_H = np.sqrt(lo * hi)

fig, axes = plt.subplots(1, 3, figsize=(9.5, 3), sharex=True)
grey = dict(color="#888888", alpha=0.7)
axes[0].plot(a_grid, [q["tH"] for q in eqA], **grey)
axes[0].plot(a_grid, [q["tH"] for q in eqB])
axes[0].set_title("substance time $t_H$")
axes[1].plot(a_grid, [q["r"] for q in eqA], **grey)
axes[1].plot(a_grid, [q["r"] for q in eqB])
axes[1].set_title("coverage $r$")
axes[2].plot(a_grid, [q["thruH"] for q in eqA], **grey)
axes[2].plot(a_grid, [q["thruH"] for q in eqB], label="detector ban")
axes[2].plot([], [], label="free-for-all", **grey)
axes[2].set_title("good papers per author-period $Q$")
axes[2].legend(fontsize=8)
for ax in axes:
    ax.set_xscale("log")
    ax.set_xlabel("AI capability $a$")
    ax.axvline(a_star, color="#555555", lw=0.8)
    ax.axvline(a_H, color="#555555", lw=0.8, ls="--")
fig.tight_layout()
plt.show()

Three regimes appear as capability grows, with the detector’s true-positive rate held fixed. While is still below the detector’s rate (left of the solid line), even slop authors dare not use AI; everyone hand-drafts, and the hand-drafting equilibrium persists whatever is: the ban works, at the price of forfeiting the hours that an AI would have saved. Once climbs past the detector (between the lines), the ban’s only behavioural effect is on the wrong people. High-quality authors still find AI not worth the risk and hand-draft, writing one manuscript where they could have drafted three; slop authors draft with AI, submit at full rate, and write off the fraction that is desk-rejected as a cost of doing business. The ban thins the queue here because chokes the inflow of spam, rather than because anyone has stopped spamming; the good authors’ fewer, fuller papers raise the average quality of what is printed, not the count. Once climbs past the detector too (right of the dashed line), the ban deters nobody. Both author types draft with AI, the detector desk-rejects the same fraction of each type’s manuscripts, and so long as the queue is congested, the review slots freed by desk rejection compensate for the good manuscripts lost, so the free-for-all equilibrium returns unchanged. Read against the detector instead, at fixed capability, the same three regimes run in reverse: nothing below , a tax on the compliant between and , and the hand-drafting equilibrium above . If we instead hold capability fixed but raise the true-positive rate , the same three regimes appear in the opposite order: below the ban changes nothing; between and it taxes only the compliant; above the hand-drafting equilibrium returns.

The standard objection to a ban is that it takes the time savings of AI drafting away from the compliant. My model agrees that the ban forfeits those savings, but so does the free-for-all, which converts them into extra manuscripts that mostly go unread. The savings are only worth having under a policy that can turn them into published papers, and that is what the submission fee of Policy C does.

4 Policy C — submission fees

Under this policy, we charge per submission, allow anything, and triage and review whoever pays for it. To be clear: this is not on the table for the Alignment Journal, but is included as a baseline.

An economist would say that submission fees are always charged, in waiting time if not in cash, and a journal chooses a mix of the two whether or not it admits to pricing (Cotton 2013). This doesn’t change how it feels to be charged such a fee, nor the fact that many authors have no cash budget to pay it. Nonetheless…

Recall that a submission’s expected private return is times its acceptance probability: for slop, and roughly — much larger — for a high-quality paper. Any fee between those two numbers is separating: submitting slop now loses money, while submitting good work still pays. Nobody is forced back to hand-drafting, because the fee remains the same however the paper was drafted — which is fine, since here at least we don’t care about provenance except as a proxy for spamminess.

If the submission fee is too low, slop authors keep entering until congestion drives their expected return down to the fee, . That pins the coverage rate at : slop manuscripts fill every review slot that high-quality manuscripts do not. Raising buys back coverage, but the accepted papers stay mostly slop until the fee exceeds the value a slop author places on each submission.

Full exclusion of slop is sadly expensive. A slop author facing an uncongested queue () expects per submission, so the fee at which slop authors stop submitting entirely is

about an eighth of the private value of an acceptance (using my parameters). does not depend on : the review depth is fixed, so a slop manuscript’s acceptance odds remain the same however large the flood. The fee must handle all the deterring, which gives this policy the nifty feature of excluding slop authors with a single fee setting even as capabilities advance, unlike the ban, which we have to re-check as moves. At every slop author stops submitting, at least if they are rational expected-value maximizers.

Code

fig, ax = plt.subplots(figsize=(6.5, 3.4))
eqC = [solve_C(a) for a in a_grid]
ax.plot(a_grid, [q["thruH"] for q in eqA], color="#b5541c",
        label="A: free-for-all")
for mu, ls in ((0.6, "--"), (0.95, "-")):
    ax.plot(a_grid, [solve_B(a, mu)["thruH"] for a in a_grid], ls,
            color="#2d6e8e", label=f"B: detector, $\\mu={mu}$")
ax.plot(a_grid, [q["thruH"] for q in eqC], color="#3a7d44", label="C: fee")
ax.set_xscale("log")
ax.set_xlabel("AI capability $a$")
ax.set_ylabel("good papers per author-period $Q$")
ax.legend(fontsize=8)
fig.tight_layout()
plt.show()

Interestingly, under the fee policy, more AI capability is simply good. High-quality authors keep all the time AI saves them and spend it writing more manuscripts. Huzzah! The journal, its queue protected, has the capacity to review and publish them; and the flow of good papers into print more than doubles across the plotted range. Under the other regimes, we burn that time surplus: the ban burns it by forcing high-quality researchers back to hand-drafting, and the free-for-all converts it into unread submissions. The fee curve in the figure is computed at , the price at which slop authors stop submitting, so no slop reaches the accepted papers at all. At any lower fee, slop authors keep submitting until the queue congestion lowers their expected return to the fee, so slop manuscripts fill every review slot the high-quality manuscripts leave free, and reviewers still accept some of those.

The fee’s lead has a second component that does not show: the share of what gets printed that is high-quality. We can understand the gap as a mismatch between the proxy (was AI used to write this?) and the true target (was this article high-quality?). The best the ban can do, at any true-positive rate, is restore the hand-drafting equilibrium, which at these parameters means about high-quality articles; a fee at removes all slop from the queue, so the share is . An entailment of that calibration is that the journal was hypothetically going to be about bullshit in the absence of AI drafting. That number follows from parameter choices I made for , and , which, as I said, are not crazy. Readers who believe their journal is purer than that should raise or and watch the fee’s lead on that share shrink accordingly: the fee’s advantage arises from the hand-drafted slop it eliminates, so the dirtier we think journals already are, the stronger the case for pricing submission over policing provenance, and vice versa.

Of course, many journals cannot charge submission fees, for reasons of custom and equity, and because no matter how eloquent the justification it will still look like predatory-journal behaviour; the Alignment Journal is not exempt. The deadweight losses of dealing with spam are still imposed on someone, and in fact authors bear them, paying in lost time queuing for a review slot: with cash fees near zero, first-response delay is the de facto submission price (Azar 2005). So Policy C is useful as a benchmark: it charges for review slots in cash rather than in waiting time, which is more efficient in the raw economic sense as well as feeling better for not wasting time when we have a perfectly good substitute. The gap between it and the best policy we could feasibly adopt is the price we pay for dwelling in the earthly realm of imperfect maximizers of expected-utility and within departmental budget constraints.

A journal that did go this way would need to do some work to avoid moral hazard, or the perception of it. For example, the journal could do so by optimizing for transparency, demonstrably spending the fee revenue on reviewing.

The moral hazards look different for different types of fees. A fee charged on acceptance pays the journal for accepting, which is the predatory-journal model. A flat submission fee pays the journal either way, so the decision itself is financially neutral, but if they pay reviewers they end up ahead when rejecting. A fee refunded on acceptance charges bad papers more than good ones in expectation, but the journal keeps the cash only when it rejects, which is the opposite moral hazard.⁷ One fix is for forfeited fees to go to a third party, such as a disinterested charity, so that the journal has no stake in its own academic decisions. Elaborations are left as homework.

5 Policy D — authors pay to skip the detector

Authors could pay a fee per manuscript to have it reviewed without passing through the detector. (Once again, not on the table for the Alignment Journal at the current time). Manuscripts that do not pay go through Policy B: the detector runs, and what it flags is desk-rejected. Hand-drafted manuscripts are never flagged, so their authors have no reason to pay. The fee is only ever paid by authors who drafted with AI and would rather not gamble on the detector. It imposes Policy C’s submission fee, but charges only AI drafters. Each manuscript now has three routes: draft by hand and pay nothing, draft with AI and risk desk rejection, or draft with AI and pay the fee.

Consider the slop authors first. A slop manuscript’s acceptance odds do not depend on how it was drafted, so if it reaches review it is worth to its author however it got there. An author who drafts with AI and does not pay has a fraction of their manuscripts desk-rejected, which costs them per manuscript in expectation. So paying the fee beats risking desk rejection only when the fee is less than . Paying the fee beats drafting by hand only when the fee is less than , by the same arithmetic that gave us under the ban. So a slop author pays the fee only when

We call the right-hand side the floor fee, : below that price every slop author pays to skip the detector, and above it none does. Any fee the journal wants slop authors to avoid must be at least that high. At a fee above the floor, slop authors ignore the exemption option and behave as under Policy B. Below they draft with AI and submit anyway, writing off the fraction of their manuscripts that is desk-rejected as a cost of doing business. Above they draft by hand, are never flagged, and submit at the hand-drafting equilibrium rate. The floor is lower than Policy C’s full-exclusion fee by the factor . Skipping the detector is worth exactly the fee it replaces, for slop, and in a congested queue a submission is reviewed only with probability , which scales its expected return and so the fee an author will pay ( was defined at ). That is the floor, not the fee the journal ends up charging. The optimal exemption fee comes out above at my parameters, as we see in a moment, because it is set by congestion among the high-quality authors rather than by what it takes to deter slop.

The high-quality authors need to estimate

which is a fancified version of the same calculation in Policy C, differing in a few elaborations.

First, the coverage rate no longer cancels. The fee is a fixed sum while the return scales with , so the amount an author writes now depends on how congested the queue is, and that congestion depends on how much everyone writes. The equilibrium is the point where the two agree. It is unique: a higher makes the fee smaller relative to the return, which makes authors write more, which lengthens the queue and lowers again. Second, they pay only while the exemption is worth buying. At a given substance choice, paying the fee beats risking desk rejection only when . Call this the cap, : the detector’s fee-equivalent for a good manuscript, and therefore the highest fee the high-quality authors will pay. If the detector rarely catches anyone, nobody will pay to skip it. For those who do pay, the fee acts like an extra drafting cost. It pushes toward fewer, more substantial manuscripts, the opposite of what cheap drafting did in the first-order condition above.

Which fee? Think of the review budget as a road with a fixed number of lanes. Every submission takes a review slot, and when the queue is congested () one more submission pushes some other manuscript out unread. If the pushed-out manuscript was good, the journal loses a good paper, and the author who did the pushing pays nothing for that loss. Economists call this a congestion externality, and the standard remedy is a congestion charge: we bill each author for the damage their submission does to everyone else’s work. In this model, the charge is easy to write down. In the congested case, the throughput is , where is the number of accepted high-quality manuscripts per period and is the length of the queue. One more high-quality manuscript adds to and one slot to , so it changes by . The author counts only the first term—the paper they might get accepted. The second term accounts for the good papers they displace, the costs of which fall on the other high-quality authors. A fee equal to the second term, converted to money at per paper, makes the author’s calculation match the journal’s, and that is the optimal fee.

where is the high-quality share of the queue. In words: we calculate the return on a high-quality submission, discounted by the share of the queue that is high-quality. We must also set the fee above the floor , so that slop authors don’t pay it, and yet below the cap , so that high-quality authors do. That gives

Everything on the right depends on the equilibrium, and the equilibrium depends on the fee, so we solve this by numerically iterating to convergence. Is the formula right? Figure 5 checks it the slow way: we hold and fixed, try every fee from zero upward, solve for the equilibrium at each, and plot the resulting throughput . The fee at which that curve peaks is the best fee the journal could charge, found by search rather than by formula; the solid vertical line marks the formula’s predicted best fee, and they agree. The folded cell after the figure repeats that comparison at four capability levels, from to , and six true-positive rates, from to , and reports the largest amount by which charging the formula fee falls short of the best fee found by search. It is zero at every point of the grid. When the congestion charge is below the cap, the best fee is itself. When would exceed the cap, the best the journal can do is charge the cap: any higher and the high-quality authors stop paying, take their chances with the detector, and falls off the cliff visible in Figure 5. At my parameters, the congestion charge is always above the floor, so the floor never matters. When the queue is uncongested, nobody displaces anybody, the charge is zero, and drops to the floor, which at is , a fraction of the of Policy C, because a slop author who cannot slip past the detector still has hand-drafting to fall back on.

def respond_D(r, a, mu, fee, p=P):
    """Best responses at coverage r when a fee buys exemption from the detector.
    Each manuscript takes one of three routes: hand-draft free, AI-draft and risk
    the desk, or AI-draft and pay. Returns queue load and accepted count per type."""
    delta = p["f"] / a
    ret = r * p["b"] * accept_H(T_GRID, p)
    routes = [(ret / (T_GRID + p["f"]), p["f"], 1.0, "hand"),
              ((1 - mu) * ret / (T_GRID + delta), delta, 1 - mu, "risk"),
              ((ret - fee) / (T_GRID + delta), delta, 1.0, "pay")]
    obj, dH, wH, H_mode = max(routes, key=lambda o: o[0].max())
    tH = T_GRID[int(np.argmax(obj))]
    loadH = p["lam"] * p["T"] / (tH + dH) * wH
    piL = r * p["b"] * accept_L(p)
    routes = [(piL / (p["t_min"] + p["f"]), p["f"], 1.0, "hand"),
              ((1 - mu) * piL / (p["t_min"] + delta), delta, 1 - mu, "risk"),
              ((piL - fee) / (p["t_min"] + delta), delta, 1.0, "pay")]
    _, dL, wL, L_mode = max(routes, key=lambda o: o[0])
    loadL = (1 - p["lam"]) * p["T"] / (p["t_min"] + dL) * wL
    return dict(loadH=loadH, loadL=loadL, aH=loadH * accept_H(tH, p),
                aL=loadL * accept_L(p), tH=tH, H_mode=H_mode, L_mode=L_mode)

def solve_D(a, mu, fee, p=P, iters=60):
    """Exemption fee: coverage no longer cancels from anyone's problem, so bisect
    for the fixed point in r. At a jump in either type's response that type
    mixes, so blend the two sides of the jump in the proportion that fills the queue."""
    M = p["R"] / p["h"]
    lo, hi = 1e-6, 1.0
    for _ in range(iters):
        mid = 0.5 * (lo + hi)
        q = respond_D(mid, a, mu, fee, p)
        if min(1.0, M / (q["loadH"] + q["loadL"])) > mid:
            lo = mid
        else:
            hi = mid
    r = 0.5 * (lo + hi)
    qlo, qhi = respond_D(lo, a, mu, fee, p), respond_D(hi, a, mu, fee, p)
    Nlo, Nhi = qlo["loadH"] + qlo["loadL"], qhi["loadH"] + qhi["loadL"]
    congested = r < 1 - 1e-6
    alpha = np.clip((M / r - Nhi) / (Nlo - Nhi), 0, 1) if congested and abs(Nlo - Nhi) > 1e-9 else 1.0
    mix = lambda k: alpha * qlo[k] + (1 - alpha) * qhi[k]
    aH, aL, N = mix("aH"), mix("aL"), mix("loadH") + mix("loadL")
    sH = p["theta"] * (alpha * qlo["aH"] * np.sqrt(qlo["tH"])
                       + (1 - alpha) * qhi["aH"] * np.sqrt(qhi["tH"])) / aH
    W = aH * sH / (aH + aL) if aH + aL > 0 else 0.0
    return dict(r=r, W=W, thruH=r * aH, tH=mix("tH"), sH=sH, N=N,
                H_pays=qlo["H_mode"] == "pay",
                floor=min(mu, mu_star(a, p)) * r * p["b"] * accept_L(p),
                charge=p["b"] * r * aH / N if congested else 0.0)

def fee_D(a, mu, p=P, eps=1e-3, iters=200):
    """Q-optimal fee: the fixed point of P = max(b Q / N, floor + eps), capped at
    the largest fee the high-quality authors will pay rather than risk the desk."""
    fee = p["b"] * accept_L(p)
    for _ in range(iters):
        q = solve_D(a, mu, fee, p)
        new = max(q["charge"], q["floor"] + eps)
        if abs(new - fee) < 1e-7:
            break
        fee = 0.5 * (fee + new)
    if not solve_D(a, mu, fee, p)["H_pays"]:
        lo, hi = 0.0, fee
        for _ in range(40):
            mid = 0.5 * (lo + hi)
            lo, hi = (mid, hi) if solve_D(a, mu, mid, p)["H_pays"] else (lo, mid)
        fee = lo
    return fee

Code

from matplotlib.lines import Line2D
fees = np.linspace(0.0, 0.5, 251)
fig, axq = plt.subplots(figsize=(6.5, 3.2))
for mu, col in ((0.6, "#2d6e8e"), (0.95, "#3a7d44")):
    sweep = [solve_D(100, mu, f) for f in fees]
    axq.plot(fees, [q["thruH"] for q in sweep], color=col, label=f"$\\mu = {mu}$")
    fd = fee_D(100, mu)
    axq.axvline(fd, color=col, lw=0.8)
    axq.axvline(solve_D(100, mu, fd)["floor"], color=col, ls=":", lw=0.8)
axq.set_ylabel("good papers per author-period $Q$")
axq.set_xlabel("fee $P$")
handles, labels = axq.get_legend_handles_labels()
handles += [Line2D([], [], color="#555555", lw=0.8),
            Line2D([], [], color="#555555", ls=":", lw=0.8)]
labels += ["$P_D$", r"floor $\underline{P}$"]
axq.legend(handles, labels, fontsize=8)
fig.tight_layout()
plt.show()

worst = 0.0
for a_chk in (2, 5, 15, 100):
    for mu_chk in (0.24, 0.4, 0.6, 0.8, 0.95, 0.993):
        best = max(solve_D(a_chk, mu_chk, f)["thruH"] for f in fees)
        got = solve_D(a_chk, mu_chk, fee_D(a_chk, mu_chk))["thruH"]
        worst = max(worst, (best - got) / best)
print(f"largest throughput shortfall of the formula fee against the sweep: {100 * worst:.2f}%")

largest throughput shortfall of the formula fee against the sweep: 0.00%

The detector’s true-positive rate does not appear in the congestion charge. In Policy D the detector does one thing: it gives AI-drafting authors a reason to pay by desk-rejecting a fraction of AI-drafted, non-fee-paying manuscripts. The true-positive rate enters only the floor and the cap, both of which rise with because skipping a better detector is worth more; a better detector widens the range of fees that high-quality authors will pay and slop authors will not. At a low enough true-positive rate, the cap falls below the congestion charge, and the journal can charge only what high-quality authors will still pay. Unlike , this fee changes as grows, because and do. This is the one place where the average-quality metric would disagree with our overall value metric : is blind to volume as long as the average quality is high, so it would prefer the largest fee the high-quality authors will pay, right up to the cap. Near , the fee pushes high-quality authors back to hand-drafting, because AI saves them almost nothing there, and Policy D degenerates into Policy B.

Code

fig, ax = plt.subplots(figsize=(6.5, 3.4))
eqD = {mu: [solve_D(a, mu, fee_D(a, mu)) for a in a_grid] for mu in (0.6, 0.95)}
ax.plot(a_grid, [q["thruH"] for q in eqA], color="#b5541c", label="A: free-for-all")
for mu, ls in ((0.6, "--"), (0.95, "-")):
    ax.plot(a_grid, [solve_B(a, mu)["thruH"] for a in a_grid], ls,
            color="#2d6e8e", label=f"B: detector, $\\mu={mu}$")
    ax.plot(a_grid, [q["thruH"] for q in eqD[mu]], ls,
            color="#7f4c94", label=f"D: exemption fee, $\\mu={mu}$")
ax.plot(a_grid, [q["thruH"] for q in eqC], color="#3a7d44", label="C: submission fee")
ax.set_xscale("log")
ax.set_xlabel("AI capability $a$")
ax.set_ylabel("good papers per author-period $Q$")
ax.legend(fontsize=7)
fig.tight_layout()
plt.show()

The exemption fee lands between the ban and the submission fee at every capability level in Figure 6. Above the ban restores the hand-drafting equilibrium, good papers per author-period at my parameters, regardless of ; the exemption fee at the same true-positive rate publishes at (39 a period per hundred authors, against 22), because high-quality authors keep the time AI saves them and the congestion charge stops them from spending all of it on extra manuscripts. Below , at , the exemption fee roughly doubles the ban’s throughput, but both are poor, because the of AI-drafted slop manuscripts that the detector misses still fill the queue. What separates the exemption fee from the submission fee is hand-drafted slop: under Policy C slop authors pay whether or not they used AI, so they stop submitting; under Policy D a slop author who drafts by hand pays nothing, is never flagged, and stays in the queue. At every AI drafter pays, and Policy D is Policy C levied on AI drafters alone; the slop authors who draft by hand are the whole difference.

For the Alignment Journal the exemption fee faces the same objection as the submission fee—that we would be charging money from a cash-constrained author base. Only authors who choose to pay are charged. Paying is also a disclosure: a hand-drafted manuscript is never flagged, so the only reason to buy the exemption is that the manuscript was AI-drafted. Most journals now ask authors to declare AI use but can at best partially check the claim; here it arrives with a fee attached, so it is truthful by construction. A false positive still costs a hand-drafting author their manuscript, as under the ban. And the revenue arrives in proportion to the number of AI-drafted manuscripts the journal has to review, so a journal that pays its reviewers could route it straight back into .

I am indebted to Vanessa Kosoy for helpful discussions which led to this proposal.

6 Future work

On this analysis the detector ban is a clumsy approximation to a congestion charge, and Policy D makes the charge explicit: what we are charging for is constrained review slots. Whether the Alignment Journal, or any journal, has a reasonable economic basis to adopt the ban depends on two parameters I have only guessed here:

• the true-positive rate a detector can sustain against motivated rewriting, compared against a we could estimate from the time costs of producing slop; and
• how many good AI-drafted papers we would tolerate losing in the range of true-positive rates between the two thresholds.

7 Ballpark real-world estimates

The model prices everything in units of , the value of one accepted paper to its author, so a fee in dollars needs a guess at in dollars. My best anchor is cost: a typical ICLR paper has historically taken about four researcher-months, and a careerist keeps spending that only if an acceptance is worth at least as much to them, so four researcher-months is a lower bound on . At USD 5,000 to USD 15,000 per researcher-month, from a PhD stipend to a fully loaded academic salary, that puts at USD 20,000 to USD 60,000. I will carry both ends through.

Under Policy C the fee at which slop authors stop submitting is , which at my parameters is about an eighth of : USD 2,500 to USD 7,500 per submission.

Under Policy D with a Pangram-grade detector, taking the true-positive rate from credible independent tests (Russell, Karpinska, and Iyyer 2025) as (i.e. ) with no false positives, that rate clears the large- limit, i.e.  for every , so slop authors draft by hand, take their chances and never pay the fee. The fee is then a pure congestion charge. It rises slowly with , from at to at . Call it a fifth of : USD 4,000 to USD 12,000 per AI-drafted submission. The floor is –, well below that, so slop authors do not pay at any fee in this range. Those dollar figures assume the detector wins the arms race. At the that survives a rewrite attack, the exemption fee collapses to , a few hundred dollars, because skipping a detector that catches a quarter of manuscripts is worth little to anyone, and throughput barely improves on the free-for-all ( against good papers per author-period). A detector that slop authors can defeat prices nothing.

The ban has a price too, paid in time rather than money. Above every high-quality author drafts by hand, so each of their manuscripts costs more time than it would with AI, about time units at . On the same anchor, a paper takes about time units and four researcher-months, so the ban costs a good author about two researcher-months per manuscript: roughly half of , or USD 10,000 to USD 30,000. That is between two and three times the exemption fee, and the journal does not even collect it. A second way to price the ban gives its fee-equivalent directly: the exemption fee at which a high-quality author would be as well off as under the ban is at , USD 9,000 to USD 26,000, falling to at , USD 4,000 to USD 11,000, where AI saves little drafting time and the ban costs little. Either way the ban is a fee of the same order as the exemption fee, levied in time, on the good authors only, and collected by nobody.

The ideal exemption fee face value is higher than the submission fee. Under Policy C the fee only has to keep slop authors out, and once they are gone the queue is uncongested, so there is no congestion to charge for. Under Policy D the slop authors who draft by hand stay, the queue stays congested, and the fee is a congestion charge on the high-quality authors.

Both fees are large next to what journals that do charge actually ask; economics journals charge around USD 100–300 per submission, I believe. Either the going rate is low, or is smaller than I have guessed for most authors, or my is too high. A journal whose full review lets through fewer than of slop manuscripts needs a proportionately smaller fee, since scales with .

8 Incoming

• AI Detection for Newsrooms
• mdmakowsky on the Intellectual Squatting – Economist Writing Every Day / Andrew Gelman

9 References

1 Connection to optionality

Kelly-style ruin aversion is the load this argument bears in optionality-as-end: maximizing time-average growth disfavors any action that risks ejecting the agent from the support of viable trajectories, so optionality-flavored behavior falls out without anyone having to add “preserve options” as a separate goal. Whether that observation needs the full ergodicity-economics apparatus, or just the Kelly criterion, is the question the spicy take above asks.

2 Incoming

• Betting for Kelly sizing in practice.
• Martingales for the fair-game formalism.
• Ergodicity and mixing for what ergodicity means when it is at home in dynamical systems.

3 References

1 Sequential Monte Carlo Steering for LLMs

The thing that first drew my attention was the Sequential Monte Carlo (SMC) steering trick for LLMs (Lew et al. 2023): instead of decoding one continuation—or keeping a fixed beam—we keep a small population of candidate continuations, score them against a desired constraint or reward, and then repeatedly resample promising candidates as generation proceeds. This can enforce constraints or steer semantic properties at inference time without retraining the base model, and it should look reminiscent of particle filtering except the likelihood is a dog’s breakfast and generally intractable in an annoying way.

Relatedly, LLaMPPL (Lew et al. 2023) claims to be a Probabilistic Programming Language for LLMs based on this idea. It uses Sequential Monte Carlo (SMC) methods to perform probabilistic inference over the outputs of LLMs, which seems logical for prefix sampling; I’m a bit confused about how it works for infill sampling, although they claim both.

• genlm/llamppl: Probabilistic programming with large language models
• LLaMPPL Docs

Basic idea: We treat a completion as a trajectory sampled from the stochastic base model , assuming that it comes from something similar to, but not the same as, the target distribution that we want to hit,

where is a score—e.g., “is valid JSON,” “satisfies this regex/grammar,” “answers both prompts,” “is non-toxic,” or “meets a programmatic verifier.”

We…

1. Maintain partial completions.
2. Sample the next token (or tokens) for each from the “base” LLM (which in SD-SMC might be a different model entirely).
3. Give each continuation an incremental weight based on how well it performs under the constraint.
4. When weights become concentrated, resample: copy high-weight trajectories and discard weak ones.
5. Continue until completion; return a high-weight sample or sample from the final weighted population.

The distinction from simple rejection sampling is that SMC doesn’t wait until the entire response is finished to discover failure. We can prune bad paths early and concentrate compute on promising ones.

The “trick” is worthwhile because sometimes we can write a prefix-aware potential—a function that scores a partial answer, not merely a final answer.

Examples:

• Strict JSON: incremental parses can bail early from impossible prefixes
• Prompt intersection: Likelihood or task score under each of several prompts
• Other stuff that doesn’t seem very practical to me.

For hard constraints, a particle that makes the remaining task impossible gets weight zero. For soft preferences, the weight rises smoothly to interpolate between “worse” and “better” paths.

The original SMC-steering formulation interprets constrained language generation as posterior inference in a discrete sequence model. It reports capabilities including infilling, syntactic constraints, and “prompt intersection,” at a computational cost comparable to beam search.

LLM vibe-coded pseudo-code example:

particles = [("", 0.0, cache_i) for i in range(N)]  # text, log_weight, KV cache

for t in range(max_new_tokens):
    proposed = []

    for text, logw, cache in particles:
        token, logp, cache2 = sample_next_token(model, prompt + text, cache)
        text2 = text + decode(token)

        # potential should assess the prefix / remaining feasibility
        delta = log_potential(text2, t + 1) - log_potential(text, t)
        proposed.append((text2, logw + delta, cache2))

    particles = proposed
    weights = softmax([logw for _, logw, _ in particles])

    if effective_sample_size(weights) < N * 0.5:
        particles = systematic_resample(particles, weights)
        particles = [(text, 0.0, cache) for text, _, cache in particles]

answer = select_or_sample_final(particles)

A common formulation uses a sequence of potentials , with the incremental correction:

That incremental difference prevents us from repeatedly counting the same “goodness” evidence at every token. In practice, this is not the true target potential, because that is almost always super weird in token space.

There are a few adjacent “SMC for LLMs” ideas that have a similar shape.

SMC steering

use particle filtering to steer toward constraints or a reward at inference time, as discussed above. SMC speculative decoding (SMC-SD)

drafts from a cheaper model, score blocks under an expensive target model, then reweights/resamples rather than rejecting drafts token-by-token. The aim is faster inference while retaining close target-model behaviour (Emara et al. 2026) Self-consistency

sample many complete reasoning trajectories and majority-vote the answer. This is not sequential resampling, but people sometimes loosely describe it as a particle-like trick. This one has the shape of, and relevance to, Reasoning LLMs where it is called maj@. Power-SMC

sample from a sharpened sequence distribution , using parallel particles and token-level importance weights/resampling. It is positioned as a low-latency, training-free alternative to serial Metropolis–Hastings-style sampling (Azizi et al. 2026) of (in the model’s opinion) higher likelihood completions. NGL I cannot even work out what this one is supposed to do.

2 Looming

I have just been schooled on the prior art: the cyborgists have been doing population-based steering of language models since 2020 under the name looming. HT Theia Vogel.

Loom is Janus’s tree-based writing interface to base models, which is to say models that continue a text as opposed to answer a chat turn. The original is pyloom; there are descendants such as Loomsidian and Conjecture’s Bonsai, more on the cyborgism wiki. The procedure, in Janus’s description, is “manual iterative rejection sampling”. The operator (loomer, let us say) generates continuations from the current node, a paragraph or less each, reads them, picks the one we like, and generates more from there. Janus recommends from 5 to over 100, depending on how fussy the passage is and the loomer’s patience. The interface keeps every rejected branch, so we can go back into history and replay to get different outcomes. (Similarities to fan-out in mathematical proving left as an exercise). Figure 2 shows a small tree from Janus’s own examples.

In the vocabulary of this notebook, this is a particle method with a human defining the selection process instead of a potential. The proposal is generated by a base model , as in the bootstrap version of SMC steering. The weight function is “black box”; i.e. it is whatever goes on in the loomer’s head. In terms of the pseudo-code above, we replace systematic_resample with “ copies of the one I clicked on”.

3 Looming vs SMC

Damn but that resembles SMC. There are a few differences however.

3.1 Looming focuses on one lineagge

SMC in the default forward mode resamples survivors from candidates and ideally keeps several distinct ancestries alive, because collapsing onto a single ancestor is indicative of failure for most purposes. Looming collapses onto one ancestor at every step (Figure 3) — although the loomer can rewind and replay if desired. Anyway, per default, we are sampling from a different statistical object.

Split the text into blocks between branch points and suppose that the loomer picks candidate with some Boltzmann-rational preference (which is not what a loomer would typically claim to be doing AFAICT) but it is fun to imagine. For large , looming draws from the locally normalized distribution

whereas SMC with the same incremental weights targets the globally normalized

Their ratio we can call the distortion,

where is the normalizing constant of , so the only part that depends on the path is . measures how good the options were at step . SMC ‘remembers’ that information, in that a particle whose children are mostly duds ends up with few descendants. Looming throws that information away. All candidates at a branch point share one parent, so is the same for all of them and cancels out of the choice; the current prefix never competes against a rival parent prefix. So is large on completions that pass through prefixes where the options were poor, and looming over-weights them. Suppose only 1 continuation in 100 from here is any good. Looming attributes that one continuation the whole probability mass of the step, as if all 100 had been good; SMC would weight the prefix down by a factor of 100 against a prefix whose continuations were all good. Drawing more candidates per branch point does not help: only controls how closely each pick matches , so as looming converges to , not . Looming still finds good text, in that every block it keeps scores well under ; what it cannot do, by selection alone, is favour a prefix because that prefix leads somewhere good.

The most common case of this distortion in practice is constrained decoding, where we need the output to be, say, valid JSON or a match for a regex. The standard method, token masking, works one token at a time: it sets to zero the probability of every next token after which no valid completion exists, renormalises the probabilities of the tokens that remain, and samples from those. Outlines and llama.cpp’s grammars work this way. Token masking is looming with one-token blocks and a 0/1 validity check, except that it needs no candidates: the model already gives a probability for every token in its tokenizer vocabulary, so masking the invalid ones and renormalising gives each step’s distribution exactly. In the case, an exact sampler of . Here is the probability the model put on the allowed tokens, so the over-weighted completions are the ones that pass through prefixes where the model mostly wanted to say something invalid. A two-token example shows the size of the effect (Figure 4). The first token is a or b, equally likely, and both are allowed. After a, only 10% of the model’s next-token probability lands on valid tokens; after b, 80% does. Conditioned on validity, starts with a about 11% of the time (). Masking cannot see at the first step that a leads to few valid continuations, so it picks a half the time and then forces a valid token, putting a at 50%, a distortion of about 4.5.

The output is valid but drawn from rather than from conditioned on validity, and correcting that is the stated motivation for SMC steering (Lew et al. 2023; Loula et al. 2025).

There is an interesting special case where the distortion vanishes (HT Claude for pointing this out). If with , the expected final score given the prefix, then every , so and . That is the optimal twist function of twisted SMC. Zhao et al. (2024) try to learn that from data. This gives us a fun interpretation of the role of a loomer, as a twist function: Their job is to judge a paragraph by where it is likely to lead, not by how it reads now. I do not know how well people do this, but I suspect we humans are not terrible at it, insofar as we solve problems like this every time we flap our gobs. The invective that streams from my cake hole may not be globally optimal, but it certainly seems to go to controllable places.

4 References

1 The options

Documents are in the table as reference data rather than as a fourth job, per above. “Needs a system-prompt line”, in the rendering column, is the LaTeX delimiter fix below.

The Anthropic bundle gets rendering and documents for free with no configuration at all, and tool calls once MCP is wired up. It is also closed, hosted, and priced at someone else’s discretion, so the interesting choosing happens among the self-hosted options — where Open WebUI and Qwen-Agent are the two that answer yes to everything. Rendering separates those two only a little: Qwen-Agent’s delimiters are registrable, where Open WebUI’s are already right. The last column separates them properly, and it is what the next section is about.

2 Sampling, which is the one that decides it

Most chat clients expose a temperature slider, some expose nothing, and a few expose the whole parameter set. That sounds like a minor convenience until the loop depends on it.

maj@k is a sampling technique: greedy decoding returns identical answers and there is nothing to vote on, so a client that cannot set temperature cannot run the technique at all. Worse, the solver drawing the samples and the loop driving it want different temperatures while sharing one endpoint. A local server like vllm-mlx has no per-model sampling in its registry, so the value has to come from the client or not at all — and most clients cannot send it.

{
  "id": "cascade-2-maths",
  "base_model_id": "nemotron-cascade-2",
  "name": "Cascade-2 (maths)",
  "params": { "temperature": 1, "top_p": 0.95, "min_p": 0.02, "repetition_penalty": 1.05 }
}

3 Driving an agent from the editor

For coding, and increasingly for anything where the artefact is a file, the frontend people actually want is the editor they already have. The Agent Client Protocol (ACP) is how the two talk. Zed wrote it, and the pitch is modelled on the Language Server Protocol: rather than every editor hand-rolling an integration for every agent — and every agent re-implementing each editor’s API — both sides speak one JSON-RPC dialect, and ideally any ACP editor can drive any ACP agent.

Mechanically, the agent runs as a subprocess of the editor and they talk JSON-RPC over stdio (or HTTP/WebSocket for a remote agent); the editor is the boss of the files and the terminal, so the agent’s edits arrive as native diffs and its shell commands run in the editor’s own terminal. It reuses MCP’s JSON types where it can and adds a few agentic-UX types of its own.

On the editor side the adopters are Zed and JetBrains, with community bridges for Neovim, Emacs, and VS Code. On the agent side, Goose ships a goose acp server, Google’s Gemini CLI likewise I think, and Claude Code and Codex have adapters, I think; Goose’s ACP-clients guide is the least stale list I have found.

4 When the model wants a different interface entirely

Everything above assumes an autoregressive model: we append a prompt, the model appends an answer, and the frontend’s job is to draw the appending nicely. A diffusion language model like DiffusionGemma instead fixes a block of text and denoises the whole thing at once, every token effectively attending to all the others. Streaming that into a chat box, we are watching a printing press pretend to be a typewriter.

It would better suit an interface built around editing text rather than chatting — much as image diffusions get inpainting in their GUIs. Rather than only appending, we’d want to regenerate selections, infill gaps, rewrite under constraints. The closest thing today is Aider’s AI! / AI? scoped edits, plus the inline-diff autocomplete most sidebar extensions ship — both of which already mutate selected text, though I’m unclear whether either explicitly supports the diffusion behaviour, and I don’t fully trust the process at arbitrary infill anyway. Also, the actual prompt window for each generation looks quite short (hundreds of tokens) which seems… not enough?

This is the one case where the frontend is not the loosest-coupled layer, and it is worth flagging because everything else on this page assumes it is.

5 The maths case

Mathematics is the domain that demands all three jobs at once, which is why I ended up caring. Notation has to render, the solve() oracle has to be reachable, maj@k needs the temperature knob, and if we are proving there is a fourth thing no chat window does at all.

1 Jina

Below I mention Firecrawl as a web scraping tool. It is kind of the default, mostly because it is famous, etc.

However, it is too gold-plated for me. As far as I can tell, they charge a premium for using browsers for scraping, which is a good way to get clean content from dynamic, JS-first websites, but it’s also slow and resource-intensive, and overkill for 80% of my use cases.

Jina is way cheaper.

• Jina Reader API
• jina-ai/MCP: Official Jina AI Remote MCP Server

claude mcp add -s user --transport http jina https://mcp.jina.ai/v1 \
  --header "Authorization: Bearer ${JINA_API_KEY}"

2 Firecrawl

Firecrawl is a web scraping and content extraction service that converts web pages (even javascript-heavy webapps) into clean markdown — the native language of LLMs. It exposes an MCP server with tools for scraping single pages, batch processing, site crawling, and web search, so an LLM agent can pull in web content as context. It supports both cloud and self-hosted deployment (of the MCP server, I mean, not the internet-scale scraping).

Its main features AFAICT

• converting challenging JS webapps into clean markdown
• charging extortionately for it relative to its competitors

3 Tavily

Tavily is search-forward rather than scrape-forward like Jina. It bills itself as a search engine for agents and RAG: a single API exposing search, extract, crawl (graph-based parallel traversal), map, and a bundled research endpoint. The search call returns relevance-scored, pre-chunked snippets sized for a model’s context window — and optionally a synthesized answer with citations. Its argument framing is that an agent will proceed more efficiently with grounded facts-plus-provenance, rather than search results that are just a list of links to follow. For that reason, plus maybe early-mover advantage, it seems to be baked into many toolkits (Langchain) and cited in many papers.

4 And still more machine search

All the search options seem to have converged on similar affordances now. Firecrawl now has its own search endpoint that finds pages and returns their full markdown in one call; Jina has s.jina.ai for search, plus DeepSearch, an iterative search-read-reason loop behind an OpenAI-compatible endpoint. Tavily is more pre-processed, trading efficiency for precision and/or control. And that’s just the start. There are ever more things!

• Exa (embeddings/neural search over the web),
• Linkup (weighted towards premium and licensed sources),
• Brave Search API (an independent index).

1 AI Agents are good at this

• Disrupting the first reported AI-orchestrated cyber espionage campaign  Anthropic
• OpenAI says its AI went rogue and launched ‘unprecedented’ cyber-attack / The Huggingface Incident

2 Business models

Prediction markets provide a new business model for cybercrime. What could go wrong?

What just happened to TheNumbers.com should worry us all.

1 The stack

The terms of art are a mess. People disagree what to call things, which results in endless confusion even between specialists. I’ll declare local vocabulary by fiat for this piece.

Model

the weights themselves — Qwen, DeepSeek, mxbai-embed, Claude and GPT (closed weights). Open models are distributed as .safetensors or an equivalent, typically from Hugging Face, and quantized to whatever precision the hardware will bear.

Runtime / inference engine

the code that uses the weights for inference — llama.cpp, MLX, vLLM, SGLang, mlx-lm, ds4. Where the compute happens.

Server / daemon

a long-lived process wrapping the runtime in an HTTP endpoint, almost always OpenAI- or Anthropic-compatible — ollama serve, llama-server, Osaurus, vLLM, or a hosted endpoint at Anthropic / OpenAI / Google. Stateless from the application’s point of view.

Harness / agent loop (scaffold, in the research literature)

everything that decides how the model gets called and what becomes of its output. The sampling parameters, the system prompt and the tool definitions are harness decisions rather than model ones, and nothing stops them from varying from step to step. This page is about this layer.

Frontend / chat client

the human-facing surface — a desktop chat window, a text-mode UI, a messaging bridge, an editor plugin, a web UI. It’s useful to separate this from the harness, even though doing so is complicated because it has a lot of local complexity depending on where we run it.

Putting it all together, we get an…

Agent

running model + harness.

The compute layers (model, runtime, server) are often tightly coupled to each other and are someone else’s problem entirely if we only ever call hosted models; they start to matter when we run the models ourselves. The layers nearer the user tend to be more loosely connected: the same harness can talk to several servers, and the same server can back several harnesses at once. Many turnkey products are vertical bundles across several layers regardless — Osaurus is frontend + harness + server + runtime in one (although each piece can be run separately), Ollama is server + runtime, Claude Desktop is a frontend + harness pointed at Anthropic’s hosted server.

See also the LLM models behind the agents, actual harness implementations | code agents and assistants,building a maths agent, agent frontends, Reasoning and proof models.

2 The loop

The minimum viable agent is essentially a conversational loop between human and LLM.

Each turn, there are several types of text exchanged, and which pass through the model. Firstly, there is what I say to the model. Secondly, there is what the model responds to me, the human.

Thirdly there are tool use instructions from the model to my machine. Tool use is a request to run something — a shell command, a patch to apply, a Python snippet, a proof to compile. The harness contains an executor to, well, execute those requested actions. There are executors of various kinds— a shell, a Python sandbox, a Lean compiler, or whatever. Potentially such commands may be executed on a different machine than the one I am using, e.g a sandboxed remote. Fourthly the results of these tool use instructions are packaged up and sent back to the LLM before my next instructions, so the LLM can see the results of its commands.

Although this sounds simple, there can be a lot of texture to even this basic setup: holding a log of messages, parsing and dispatching requests, injecting project instructions and skill descriptions, choosing settings such as sampling temperature or token budget… More sophisticated harnesses extend the design space somewhat.

3 Design space

A harness is designed for a task, and the task settles two things before we choose anything:

1. State — whether what the executor acts on can be thrown away.
2. Verifiers — what, if anything, can judge a candidate, and how far its verdicts can be trusted.

Given those, a harness design makes three choices:

1. Wiring — the control flow, and in particular whether repeated attempts run in parallel or in sequence.
2. Context — what each call sees: which slice of history, retrieved content, and notes.
3. Dispatch — who fills each slot: which model, which tool, which verifier, at which price.

There is no separate choice about verification: which verifiers a harness consults is dispatch, and where in the call graph it consults them is wiring.

A terminal coding agent is given a real repository and whatever test suite comes with it, and chooses: a sequential loop that runs the suite after each edit; grep and read on demand, with a summary when the window fills; one big model throughout. Every harness has made all three choices, whether or not anyone decided them. The three are not independent of each other or of the two givens, and those dependencies are most of the design work.

4 Long horizon

A long-running agent — one that holds a task across hundreds of turns, or where we return to a project after a week off — runs into problems a single turn does not show. Per-turn errors compound, the context window fills, and whatever the agent worked out in one session is gone by the next, because current LLMs are not continual learners. The subsections below take those in that order.

5 Learning the harness

A system rewriting its own scaffold is the same loop as the background agents above, moved from deployment time to training time — tighter feedback signal, faster clock, and the same reason to audit what it mints.

The scaffold started as something hand-written and tuned by folklore. Then the pieces got measured: Requena et al. (2026) ablate a prover harness bottom-up, removing one piece at a time to see what it was contributing, and rank what they find — treating harness wirings as experimental subjects rather than as taste. DSH ships the same instinct as a product feature: a Minimal mode with only a shell and a file editor, pitched as a way to benchmark models without the rest of the harness in the way.

Then a component gets trained, and dispatch is the one that has fallen first. Su et al. (2025) make the routing itself the learned thing: an 8B orchestrator model, trained by RL with outcome-, efficiency-, and user-preference-aware rewards, that coordinates bigger models and tools rather than answering directly. They report it edging out GPT-5 on Humanity’s Last Exam at ~2.5× lower cost, and generalizing to tools unseen in training. It is an inversion: the intelligence is in the dispatched-to components, and the small model’s job is knowing what a query costs and who should handle it.

The end of that road is Ornith-1.0, which makes the scaffold itself a learnable object.¹ In each RL step the model first proposes a refined scaffold for the task, then rolls out a solution under that scaffold. Reward flows to both stages, so scaffolds mutate and get selected toward whatever elicits higher-reward trajectories. No hand-engineered harness design at all, and their 397B model matches or passes Claude Opus 4.7 on Terminal-Bench 2.1 and SWE-Bench Verified, if we take their word for it. The three choices locate a harness as a point in a fixed design space; a self-scaffolding trainer searches over the space itself, and the wirings and context policies are what mutate.

The failure mode arrives with the capability, as usual. A self-authored scaffold learns to satisfy the verifier without doing the task — touching the checked-for file, hardcoding the expected output, copying an oracle solution lying about in the environment. Ornith’s defence is three layers: an immutable outer trust boundary the model cannot edit, a deterministic monitor that zeroes the reward on any attempt to touch withheld paths or verification scripts, and a frozen LLM judge that vetoes gaming attempts even when they stay inside the sanctioned tool surface. Which is the verification question again, seen from the training side: the softer the verdict, the more a learned harness will bend it, so the trust boundary has to be exactly as hard as the verifier is soft.

The other half of the problem is taking a bad scaffold back out, which is a software-architecture question rather than a training one. The Cordis kernel under DSH is built for adding and removing components at runtime, and its paper names self-evolving agent harnesses as one motivating case (Shi, Zhang, and Cui 2026). Its temporal composability means that removing a component reverts every change that component made inside the system; its spatial composability means each component declares what it depends on and is switched on and off as those dependencies come and go. The paper’s evidence is Koishi, a chatbot framework with over four thousand community plugins; the self-evolving harness appears as a motivation and as future validation, not as something tested. DSH’s Creator mode is the product end of this: the agent inspects the running harness, tries plugins out in memory, and combines them into new modes. The docs say these model-authored plugins vanish when unmounted or when the process exits, and may affect other sessions in the same process meanwhile. If it works as described, this sounds like a useful answer to the self-written library: a bad self-authored skill packaged as a plugin could be unmounted without residue, rather than being loaded into every session after it. Two limits, both stated in the paper. First, reverting stops at what it calls the system boundary: a location is inside only if the system alone can modify it and restore it. Cordis cleans up what a plugin registered through ctx — listeners, tools, timers, and anything handed an explicit disposer with ctx.effect() — and a scratch file under a private path can count as inside, but a repository that git, an editor and a human also touch is outside. A write to it cannot be reverted, only withheld until it is safe or compensated for afterwards, and the paper’s guarantees do not carry over to compensation, so Cordis does not make a coding executor side-effect-free. Second, dependency declarations are access control, not a sandbox: the paper says untrusted component code needs an external sandbox, which matters when the untrusted author is the model.

6 Incoming

• The always-perspicacious Theia Vogel

  some thoughts and speculation on future model harnesses

  it’s fun to make jokes about gas town and other complicated orchestrators, and similarly probably correct to imagine most of what they offer will be dissolved by stronger models the same way complicated langchain pipelines were dissolved by reasoning. but how much will stick around?

• SkillOpt: Agent skills as trainable parameters

  In our recent paper, SkillOpt: Executive Strategy for Self-Evolving Agent Skills (Yang et al. 2026), we reframe the question from “how do we write a better prompt?” to “how do we train the skill?” SkillOpt treats the skill file as a trainable parameter living outside a frozen target model, bringing a training-style optimization loop, consistent gains across 52 evaluation cells, and a compact skill file that stays readable, auditable, and transferable.

• J-Rosser-UK/AgentBreeder: Mitigating the AI Safety Impact of Multi-Agent Scaffolds (Rosser and Foerster 2025) — the safety-flavoured cousin of Ornith’s scaffold search: we use evolutionary search over multi-agent scaffolds, aimed either at jailbreaking the base model or at combining safety with task reward.

• Language model harnesses are compositional generalizers | Alex L. Zhang

  Concretely, we think a good harness is one that shapes each call to the underlying Transformer so that every observation is locally in-distribution, i.e. each Transformer call handles a prompt that is in-distribution with respect to its training data. In fact, a good harness can frequently reduce problems that seem to require breakthroughs in post-training into almost mundane capabilities of the existing generation of language models. We first showed a version of this for long context processing nearly a year ago and, in this post, we show that this principle extends to the efficiency of learning itself. That is, what a model learns through a well-designed harness generalizes across task lengths and across domains far better than training the neural network on its own does.

  We test this by using reinforcement learning (RL) to train a Recursive Language Model (RLM), a harness in which the model offloads its context and defers execution to programmatic decomposition and recursive sub-calls. The results are summarized in Figure 1. Training on only short tasks generalizes to held-out tasks 8–32x longer, with roughly 10x the eval lift with the same train lift over training the underlying Transformer directly. Moreover, training on one domain transfers to other domains at a far better rate than that of a vanilla Transformer.

7 References

1 Translation table

A physics “model” is a log-density: . Read the energy/action as a negative log joint, the partition function as the evidence, and the free energy as the negative log evidence. Then:

Renormalization / QFT	Bayesian ML
Boltzmann distribution	posterior (or any model)
Hamiltonian / action / energy	negative log joint (unnormalized log-density)
Partition function	normalizing constant / marginal likelihood (evidence)
Free energy	negative log evidence ()
Variational free energy	negative ELBO (); gap
Mean-field theory	mean-field (factorized-) variational inference — same self-consistency equations
Saddle point / classical solution	MAP / posterior mode
Loop expansion (powers of )	expansion around the Laplace approximation (powers of posterior variance)
Temperature	likelihood tempering; ; observation noise
Integrating out / coarse-graining	marginalization
Real-space (block / decimation) RG	variable elimination on an MRF, then project back to a fixed family ( expectation propagation)
Effective Hamiltonian	negative log marginal density of the retained variables
Couplings ; running couplings	model / natural parameters; effective parameters as a function of resolution
Cutoff	resolution / bandwidth / level of detail retained
RG flow	trajectory of parameters under iterated marginalize-and-rescale
Fixed point	scale-invariant (self-similar) model
Gaussian fixed point	Gaussian / GP / Laplace / NNGP limit
Relevant operator	parameter direction that grows under coarse-graining (matters macroscopically)
Irrelevant operator	direction that shrinks / washes out (microscopic detail)
Universality class	basin of attraction of a fixed point (micro-models sharing macro behaviour)
Free theory + propagator	Gaussian reference + prior covariance (kernel)
Perturbation theory / Feynman diagrams	cumulant / Edgeworth expansion around the Gaussian; diagrams = cumulant bookkeeping
Interactions / non-Gaussianity	higher cumulants / non-Gaussian corrections
Effective field theory	low-dimensional parametric surrogate for the marginal / predictive
Renormalizability	the coarse model stays in a finite-dimensional family across scales (closed assumed-density recursion)

• The CLT is an RG flow. The map “sum iid, recentre, divide by ” has the Gaussian as its attracting fixed point; finite-variance laws are its universality class; the Edgeworth/cumulant corrections (skew , excess kurtosis ) are the irrelevant operators that decay along the flow; centring is tuning the one relevant direction to criticality. (This is Vaintrob’s Laws of Large Numbers post.)
• Decimation is variable elimination plus EP. Real-space RG sums out a sublattice — exactly variable elimination on a Markov random field — then projects the induced all-order couplings back onto a chosen family (e.g. nearest-neighbour), a moment-matching / assumed-density step. So an RG step is (marginalize → project-to-family), i.e. expectation propagation indexed by scale.

2 Renormalization stuff that I have not seen in ML

Most of the table seems to be relabelling familiar machinery — evidence, negative log evidence, mean-field VI, Laplace, cumulant expansions, Gaussian processes. However, some ideas have no routine Bayesian analogue AFAIK:

1. A flow on model space. Iterated coarse-graining traces a trajectory of models across scales, not one approximation at one scale. Variational inference gives the single approximation; RG gives the path and its dynamics.
2. Relevant vs irrelevant directions. A Jacobian-eigenvalue (local sensitivity) analysis of that flow at a fixed point: which parameters grow under coarse-graining (survive to the macro-scale) and which decay (microscopic detail).
3. Universality. Many micro-models flow to the same macro-model — a principled reason coarse descriptions are robust to microscopic detail.

Plus one mechanical ingredient ordinary Bayes lacks: the rescaling step after each marginalization (the below) that makes the iteration a flow with fixed points rather than a sequence of ever-coarser marginals.

3 Neural-network connections

• Infinite width → the Gaussian fixed point: a GP prior over functions (NNGP), neurons non-interacting, propagator = NNGP kernel.
• → the coupling constant; finite width → weakly-interacting (perturbative) non-Gaussian corrections.
• Depth → the RG flow itself: each layer is one marginalize-and-rescale step (PDLT’s is the step size).
• something about Neural tangent kernel

4 Incoming

• Singular learning theory — Watanabe’s free energy and the overparametrized (singular) posterior; Vaintrob’s Basics of Bayesian learning is SLT setup.

• Progress update: synthetic models of natural data — LessWrong

• The Transformer as Renormalization Group Flow

  The forward pass through a transformer implements a Kadanoff-Wilson renormalization group flow, coarse-graining microscopic token representations into stable semantic attractors.

5 References

1 Let us release some woo pressure

Point of order: I am not here to pitch you on the more mystical arguments against ever conflating a human being with a number. Sometimes quantification and empirical risk minimisation works. Quantitative methods are real methods. Measuring the population is a great way to work out if we have enough food for the population. Predicting the weather is a great way to work out if I should take an umbrella.

That this is unreasonably effective, and brings great benefit is, in a sense, the “problem” I want to address here. So many things can be made to go via ERM, so many things now depend upon it, that I wonder if this is in itself selection pressure against the things which cannot be made to go better by the application of a loss function and an NN.

2 Relaxations of classic ERM

Various of the ERM assumptions have been relaxed in diverse ways across modern AI infrastructure. This is the local variant of Sutton’s famous bitter lesson about “methods that leverage computation” being the most effective; the way we leverage that computation is to make things more like ERM.

1. We don’t always take the distribution as fixed. For example, online methods learn something like a “recently good” model, and are happy to forget older things.
2. We let the model range over more interesting spaces than a fixed-size input-output distribution. For example LLMs do this, predicting whole conversations. This is because they ingeniously decompose the sentence prediction problem into smaller, manageable components, allowing them to handle complex, structured data.
3. We let the models be more than passive predictors. For example, they can learn to choose actions, in, e.g. reinforcement learning or Bayesian optimisation.
4. Online/continual learning totally works, although no-one has made it efficient for LLMs yet, I have seen online fine-tuning pop up in, e.g. automated reasoning so this is still live. Anyway, this lets change over time, and lets the model adapt to that.

These can get ERM to do surprising things; still within, I argue, basically the same formalism, with all the unearned tractability that gives us.

3 That which is susceptible to ERM is remarkably general

RL is super interesting. Sutton famously argued very hard that minimising scalar losses was fine for producing general agents Silver et al. (2021).¹ This was controversial; there have been various responses, for example, demanding that the reward be at least vector-valued (Vamplew et al. 2022). The formal version of that exchange — what vector reward does and does not repair — is in inference in an open world.

Anyway, it certainly produces agents who can use ERM-like training to learn “how to act” which seems very magical, and nearly open-ended.

RL’s greatest successes, however, have been in domains where we already have a great simulator, run it for a long time, and where we can get a lot of data. RL agents commonly require subjective millenia of experience of playing computer games to get good at them, so they are not yet practical for many real-world tasks. Which is to say, we need to work damned hard to get them to look like ERM, and then they work very well.

The most gob-smackingly, boundary-pushingly astonishing place that ERM works, of course, is famously Large Language Models whereminimising the error on next word prediction might yet learn to supplant all human intellectual labour. I am still astonished that we live in the transformers-work world.

Once again, this is because we have made the world look like ERM: we have a static distribution of text, and we have a scalar loss function (cross-entropy) that is tractable to optimise. That this generalises is astonishing.

LLMs explore an interesting space: they seem to be able to describe an effectively-unlimited world of imagination. Their training technology still looks a hell of a lot like ERM.

How do they do this wizardry?

4 Against utility

As I am prone to rant to strangers at the bus-stop, a cognitive danger of machine learning is reification of utility functions. Utility functions are an interesting method of analysis, but clearly maladapted for some purposes.

For one thing, if we look at their usage in economics, utilities are induced valuations over allocations of goods.

It is one thing to note that humans don’t think this way. It is another to note that also the world does not even operate this way.

My entire life does not cash out in my acquiring a Pareto-optimal allocation of goods subject to the initial endowment. Rather, my life is some complicated exploration of ways of being, learning, acquiring tastes and losing them, changing and burning out, falling in love, fighting my nemesis, building friend groups and families and institutions and ultimately dying — and what the fuck did that just optimise? From what distribution was my life drawn? Could it exist even notionally? Was it the same as the generation before? The one that comes next?

Human beings strive for, not bundles of goods, but complicated, contingent, path-dependent, interacting situations that they co-create with the world itself. If trading apples for oranges helps along the way, all the better, but this seems only ever an incidental goal.

Elsewhere this rejection of an underlying utility function has been described as a thick model of value, although I won’t do so here, because it is not just the thickness of this concept that I want to consider, but the open-endedness, the contingency.

5 Empowerment must concern outcomes outside the data distribution

The minimizers have only interpreted -world in various ways; the point, however, is to change . Some of this is addressed in open-ended intelligence.

6 Edge cases

The formal side of this complaint — what a bounded observer can estimate about a world its sample space does not contain — is now taxonomized in inference in an open world; this list stays as a trailhead.

• mis-specified Bayes — There are totally theorems for open world Bayesian inference, and some of them are computable, at least in restricted domains. What can we learn from there?
• The closely-related infrabayesianism and other imprecise Bayes methods provide a way of reasoning about Knightian uncertainty.
• (Generative) Variational Search (Steinberg et al. 2024) seems to me to gesture towards somewhere interesting; by going back to search rather than inference (or rather, inferring “where to look next”) we get something like a “Bayesian” version of evolutionary search that can be applied to open-ended problems.
• Artificial life is a whole field of study that is about open-endedness, and has been for decades.
• Renormalization group seems to be a live agenda for coarse-graining in ML, and suggests some useful approaches to the the problem of unobservable detail.
• Reactivity: what if the world responds to us? There are some attempts to model this, e.g. performative prediction, or even full-blown theory of mind.

7 Incoming

This should connect to

• performative prediction
• legibility and automation
• disempowerment
• open-endedness in intelligence
• Goodhart’s law
• I think maybe domestication also.

8 References

1 Collective action against a model

A collective of users pools their data and coordinates how each member modifies it, to push a platform’s deployed learning algorithm where the collective wants it (Hardt et al. 2024). Even a tiny fractional collective can exert outsized control over what the model learns, because the firm keeps retraining on data the collective has shaped.

The reciprocal quantity is performative power (Hardt, Jagadeesan, and Mendler-Dünner 2022): how far the platform can steer the population back, rather than settling for the best fit to whatever data it currently sees. A monopolist has the most of it; competition and outside options erode it. The collective’s leverage and the platform’s performative power jointly determine who steers whom. For more on this see strategic classification and performative prediction.

2 Coalitional MARL

A coalition game asks who teams up with whom and how the joint surplus is split. If we could teach algorithms to do collective formation with one another, that would be interesting, don’t you think?

We might recall that the classical answer to “what is the worth of this coalition?” comes from Shapley fairness, which cashes out optimal coalitions in the characteristic function — the worth of each coalition , evaluated in isolation. For more than ~20 agents that’s hopeless: evaluating optimal coalitions involves subproblems, each of which might be hard in itself (e.g. each is its own counterfactual estimation problem). Scaling to a thousand agents would mean evaluating such problems. Can we learn approximations to optimal coalitions using the RL formalism?

3 Open-source game theory

MARL is one possible operationalization of open-source game theory, in which agents exchange policy source code (or some interpretable proxy) before acting and cooperate by mutual verification.

4 References

1 Strategic classification

So far I have been generic and just talked about regression problems, remaining agnostic about why the distribution moves, and describing as just some distribution whose shape determines the reshaping term.

Strategic classification (Hardt et al. 2016) is a specific generative interpretation: the distribution moves because the people being classified are gaming a classifier.

The setup is a Stackelberg game. The institution moves first, publishing a classifier (credit worthiness, food stamp worthiness, tax credits, etc.) where the value of the classifier is the score it assigns to the features of an applicant . Each agent with features , seeing the rule, attempts to land on the favourable side of the class boundary by adjusting the features they present to the algorithm. Each agent pays some cost for presenting features in place of their “true” (default?) . We could imagine this corresponds to the cost of buying a new suit when applying for that loan, and so on. Now each agent best-responds, trading the score improvement against manipulation costs: The induced distribution is then the base distribution pushed forward through this best-response map. Boom! Economic microfoundations of performativity. We can, in principle, deduce how perturbing deforms the new observations, because we have written down the optimization each agent aims to solve.

In the basic version, the features move but the “true” labels do not. I dress up in a fancy suit to clear the credit-worthy bar without becoming any more “fundamentally creditworthy” underneath, by, e.g., saving more money. This is pure adversarial Goodhart where the metric is prized loose from the thing it was meant to measure.

There exist richer variants with more complicated dynamics. If perturbing some feature actually moves the outcome — studying for the exam rather than buying the answers — then the manipulation might be actual improvement rather than gaming, and we might in fact aim to design the game so that the cheap perturbations of are the improving ones. Whether a given classifier rewards gaming or improvement is one of the things this formalism is designed to resolve.

Miller, Milli, and Hardt (2019) observes that drawing this distinction at all drags us out of pure prediction and into causal inference. Whether nudging a feature games the classifier or improves the outcome depends on whether that feature causes or is merely correlated with it — so an institution that wants to reward improvement cannot blithely use the correlations (between, e.g., academic achievement and test score) but needs to learn the causal graph relating features to the outcome. That is to say, a classifier that incentivizes improvement is a designed intervention on the population. Interpreting causal effects of incentives in games is something we fortunately have tools for. That is in general harder than merely fitting — it inherits every identifiability headache of causal inference. And yet, we need to do it: Naïve retraining can happily converge to a classifier that everyone games and no one improves under, e.g., where people who want loans max out their credit cards buying fancy suits.

Mapping this strategic play back onto the performative prediction formalism: The reshaping term of the performative gradient in this setting is the derivative of the agents’ best response , measuring how much harder everyone games as we move the classification rule. A performatively stable classifier is one that stays optimal against the gaming perturbations it provokes: we have already priced in how people will respond, so refitting buys us nothing. The catch is that includes an , so that reshaping term need not be at all well-behaved or, for example, smooth. Levanon and Rosenfeld (2021) get the chain rule to run in practice by swapping the hard best-response for a smooth surrogate, to make the objective differentiable end-to-end. And of course, that is even assuming we know the cost function. If we only see the gamed features that come back, we are in the revealed-preferences regime, learning the game while we are playing it, which sounds punishingly hard (Dong et al. 2018).

There are some interesting extensions. When the classified agents do not act in isolation but rather coordinate to change the classifier, we are doing algorithmic collective action (Hardt et al. 2024). Conversely, we can consider performative power (Hardt, Jagadeesan, and Mendler-Dünner 2022), the ability of the classifying institution’s makers to shape the population’s behaviour. When we want to quantify whether a classifying institution can instead keep the players from coordinating, that is the divide-and-rule coalition game.

2 Seeing like a model

Step back far enough and the whole performative setup looks familiar from the classic observation that a measuring instrument is also an instrument of government as made famous by James C. Scott in Seeing Like a State, who cares greatly about legibility and automation not to mention the tense relationship between the irreproducible tacit metis and high modernity: to run a forest, a city, or a workforce at scale, the state first has to make it legible, which looks a hell of a lot like classifiable. We can improve classification accuracy in two ways: either by learning a more precise model, or by flattening the teeming specificities into more easily separable groups for the central office. Indeed, a governed population does not persist unchanged beneath the gaze of the classifiers of the state, and we might expect both performative power and strategic classification to be in play.

Scott’s photogenic example is a measurement procedure that structures the forest it was intended to analyze. The Normalbaum is a standardized tree of a given size class, its volume of saleable wood tabulated by size and age; the Norway spruce in straight rows came afterwards, planted to match the table, bending reality to the convenience of the predictor. The forest is not a strategic responder, however. Where the classified can act, as the credit applicant or the exam-sitter can, gaming the classifier is strategic action (Goodhart again, or tufta). Where they cannot, as a forest cannot, the reshaping term is still there and yet nobody is best-responding to us; that is a garden-variety unstrategic bad performative equilibrium.

We are accustomed to the idea, in modern technocracies, that once resources, status and power flow through a category its definition becomes a contested thing. Gender, obscenity, creditworthiness, refugee status, tax bracket: these are essential categories for modern states and thus contested. What changes in performative prediction is not that we “solve” for the “true” categories, nor that we throw up our hands in despair and decry that this is not what we were told in statistics class. Performative prediction gives us a means, rather, to understand and name how much we are seeking to understand reality, and how much to change it.

3 Incoming

• Expectation = intention = setpoint
• 🚧TODO🚧: very excited about Heitzig (2026) which has an application of this idea to performative forecasting

4 References

1 The path through

Suppose I already use some coding harness. I can proceed step by step to add features, one at a time, walking through harness design space until it is more optimized for mathematics than for code. That space has four axes — wiring (how the calls connect to one another), verification (what gets to say an attempt was any good), context (what each call is shown) and dispatch (which model or tool fills which slot) — and every step below moves exactly one of them, which is what the second column of the table records. Some steps, in a recommended order (I won’t divulge whether I actually followed this order):

Maths, as an automatically-verifiable problem class, is amenable to all kinds of nice tricks. A maths executor by default only ever checks a calculation, which is side-effect-free. As such, fifty attempts will not clobber each other, so we can, e.g. fan-out and try everything everywhere all at once.

These all cost different amounts of effort to build, and yield different amounts of effect. That last column is mostly not my measurement. The loop, scratchpad and fan-out rows come from AxProverBase (Requena et al. 2026), a deliberately stripped-down Lean-proving agent whose authors assembled it one component at a time and scored each addition separately — the nearest thing to a controlled experiment on any of this that I know of. Ranked by effect, they put iterative refinement first and memory second, which are the third and fourth steps here; building the oracle is nevertheless easier and more fun than either. The remaining two rows are mine. The oracle row reads across from their sweep over frontier models rather than from an ablation of anything oracle-shaped, and the Lean row is not a measurement at all — the compiler is the substrate their agent runs on, not a component they could take out and score.

I suspect that the table continues past my ability to build: the recursive, self-grading, re-formalizing orchestrators at the top of the mathematics leaderboard have enough startup money behind them that I am not going to reproduce one in a weekend. That is not an argument for buying instead, though, and the numbers do not make one either. The home-built loop comes out around five times cheaper per problem and solves about half as many: cheaper per attempt, weaker per problem, and the trade is ours to make rather than theirs.

Two maths-harness gotchas:

• TIR models speak their own tool-call dialect, so the orchestrator has to parse fenced code templates and splice results back in the shape each model expects. Budget for writing that parser per model family; it is the thing that stops a generic harness working.
• The model writes the code we run unobserved, so sandboxing is wise. The only maths-specific detail is that the specialists assume a full scientific Python (SymPy, NumPy), so build the sandbox accordingly.

2 Easy mode

The baseline.

We need not be galaxy-brained. Claude works for maths just as well as it does code, as do most generalist models — The latest DeepSeek, or a big Qwen3-Thinking are all respectable mathematicians; tell them to “do the maths”, then “check the working with Python/SymPy”.

NB local clients are less capable at rendering equations, so I find I want to build Open WebUI to make equations easier on human eyes, but this is definitely lily-gilding.

3 Lend it an oracle

Dispatch tricky bits to specialist models.

Now, if we want a little more juice, we can squeeze it from our existing agent, using it as an orchestrator but delegating mathematics (or the checking of mathematics) to a specialist maths model. Practically, this means something like building an oracle (a solve() tool) to grind on knotty maths problems, splicing the result back into the orchestrator’s own reasoning. Oracle is meant in a strict sense: the orchestrator does not attempt the sub-problem nor does it check the answer. Rather it asks and believes with whatever confidence it is instructed to have.

Python harnesses like Smolagents or Qwen-Agent can simply call a Python function which wraps structured invocation of specialist models. For other agents (Claude-like, Goose, Codex, Gemini CLI, pi, Hermes) we can expose the solve() as a CLI tool. Either way, we wrap it with an agentskills.io SKILL.md to help the calling agent. Skill-blind agents can alternatively use an MCP server.

I whipped up mathx as an example of doing all three access paths — importable Python, CLI, MCP server — with the SKILL.md layered over the first two, in a relatively swappable manner.

We might wish to fan-out in such an oracle. Done synchronously, this can be slow and hit time limits on tool use, or just get boring. Asynchrony and parallelism depend on support in the orchestrating agent. When we own the loop, a fan-out is as simple as asyncio.gather. For tool-use agents, the async-handle pattern is probably the goods: We set up a handle-and-poll loop in pair of ordinary tools: submit_solve() returns a job id at once and check_solve(id) returns status-or-result at once, so each call is fast. Some harnesses also dispatch background sub-agents of their own, and some MCP clients support Tasks at the protocol level; that might work too.

4 Build the loop

Sequentially iterate solutions, learning each time.

If easy mode plus an oracle aren’t enough, we can write a custom loop that specializes the generic one for mathematical needs.

What if we are trying to solve a hard problem? Intuitively, it makes sense to grind, learning from past mistakes at each attempt. Building a loop that supports this turns out to be kinda good actually. In the wild I have seen this as a two-role iterative system. A proposer writes a candidate answer or proof, and an executor runs or checks what the proposer wrote. The verdict — a compiler error, a failed numeric check — is fed into the next prompt as a minimal trace of what failed last time. Round it goes again until the check passes or the iteration budget runs out (AxProverBase allows 50 rounds per problem). This is not the same thing as fan-out: there the attempts are independent and mutually blind, whereas here attempt has seen what attempt got wrong. This is the single largest contributor to success increases in the AxProverBase ablations, and it is also where the maths usage diverges from the coding usage.

5 A scratchpad

Exploit context to record a longer narrative.

We can build more elaborate memory suited to an epic proof attempt, specifically, not just last turn, but of the whole proof journey thus far. The crude version pastes the whole transcript of past attempts into the prompt, but that bloats the context, and eventually overflows the window. The SOTA variant requires that after each attempt the proposer rewrites a running scratchpad of what it learned, pruned so it never grows without bound. In AxProverBase, that method buys around 7% more theorems at ~20% lower cost, and with lower variance than memoryless attempts and completist memory strategies.

6 Fan-out

Parallel proposals and checking.

Fan-out improves mathematical accuracy by evaluating many candidate solutions — maj@k or Pass@k, depending on our backend. We can run a lot of these fuckers at once, since the tokens stream over the network in parallel.

The goal here is overall efficiency: do more parallel copies of a cheaper model get us further than fewer copies of a more powerful one? For problems that are just on the cusp of being solvable, this turns out to be helpful.

Sampling wide is not too crazy. The hard bit is working out if any of the answers were good.

7 Lean

Moves verification to an exact grade: the checker cannot be talked round.

So far we have been imagining english-language mathematical reasoning, which has ended up being kinda painful. Whacking in a proof assistant (in practice, always Lean) makes this much cleaner, at the cost of being weirder. Modal’s theorem-proving case study shows how it is done.

Here, the model emits candidate proofs in Lean, they are submitted to the Lean language server, and we get back {"ok": bool, "errors": [...]}, which tells us whether the proof landed.

A Lean toolchain can be tedious to set up, including gigabytes of “Mathlib” that takes hours to build and comprise brittle, version-sensitive plumbing. Various Lean technologies support this workflow (lean-repl (the lightest), Pantograph, or LeanDojo, usually behind the Kimina Lean Server to keep it warm).

The weirdness now, that is in the very manner we express mathematics. Lean is a formal language, guaranteeing formal proofs of formal problem statements, so obviously it needs formalization if we start with plain language problem statements — ideally autoformalization. One-shot autoformalization models (Kimina-Autoformalizer, Goedel-Formalizer-V2) suck though. This formal proving thing seems to work fine for formalized proofs, but getting the problem into such a state is unreliable and difficult to debug.

8 Where the compute comes from

What the steps cost to run once built, where fan-out is the only one that costs much.

Build and debug the whole loop on a laptop first — a local IPython kernel for the solver, lean-repl on disk for the prover — and never pay for a GPU until we fan out.¹ Modal is a tidy cloud backend to fan out to.

Tokens come from a model behind a scale-to-zero, OpenAI-compatible vllm serve endpoint — a few dozen lines mount a Volume so the weights download once, and the GPU drops to zero between requests, meaning we pay only for the seconds a request actually runs.

Fan-out is then just a .map — one chain per call, each with its own sandbox, all sharing the one endpoint:

# maj@k as a fan-out
answers = solve_one.map([problem] * 32, range(32))   # 32 chains, 32 sandboxes, one endpoint
winner  = Counter(a for a in answers if a).most_common(1)[0][0]

The same shape sweeps a whole problem set, or runs a prover’s Pass@k with the Lean verifier as the executor. A heavy tool — a Gröbner basis, a big symbolic integral, a Sage or PARI-GP call — goes on its own cheap CPU modal.Sandbox next to the GPU endpoint, so we aren’t paying for an idle H100 to run SymPy.

# maj@k against a local oMLX endpoint — the reasoner emits no code, so no sandbox
from openai import AsyncOpenAI
import asyncio, re
from collections import Counter

client = AsyncOpenAI(base_url="http://localhost:8000/v1", api_key="x")
# naïve: [^}]* stops at the first }, so \boxed{\frac{1}{2}} wants a brace-counting scanner
BOXED  = re.compile(r"\\boxed\{([^}]*)\}")

async def sample(problem):
    r = await client.chat.completions.create(
        model="vibethinker-8bit",
        temperature=1.0, top_p=0.95,   # per request; see below
        messages=[{"role": "user", "content": problem}], max_tokens=32000)
    hits = BOXED.findall(r.choices[0].message.content or "")
    return hits[-1].strip() if hits else None   # last boxed = the final answer

async def solve(problem, k=16):
    answers = await asyncio.gather(*(sample(problem) for _ in range(k)))
    votes   = Counter(a for a in answers if a)
    return (votes.most_common(1)[0][0] if votes else None), votes

9 What the build taught me

Three things, in decreasing order of how much they surprised me.

The loop is the half I can build, and it is also the half that pays. The ablations put iterative refinement first and memory second, and both of those are a weekend of ordinary Python around models I did not train. Nothing further up the table needed a GPU either — the entire thing debugs on a laptop, and the first dollar goes on fan-out.

But the model I point the loop at cannot be chosen from a benchmark table, because responsiveness to a scaffold appears on no leaderboard. The number that matters is how the model behaves inside my loop — whether it reads a compiler error and does something different next round, whether its scratchpad note is any good. So the shortlist comes from benchmarks and the choice comes from measurement, which means budgeting for the measurement.

There is a second reason, and it is sharper because somebody has measured it. RL post-training buys pass@1 by spending the high- tail — an RLVR-tuned model beats its own base at one sample and loses to it at hundreds — and hundreds is the regime fan-out lives in. Measured on a Lean prover, the SFT checkpoint often samples better than the RL checkpoint out of the same lab, purely because it stayed diverse. Standardized re-evaluation of the published gains points the same way, from a completely different direction: RL improvements are mostly modest and overfit small benchmarks, where supervised fine-tuning generalizes more consistently. So where a lab ships both, the SFT one is worth trying as a fan-out backend, and no leaderboard will suggest it: they report the single sample where the RL model wins.

And most of the fiddly work was not mathematics. Deciding whether two answers are the same, pinning Mathlib to the commit the model was trained against, getting a local server to honour a temperature — that is where the days went, and none of it is the part I found interesting. The mathematics was the easy bit, which is either encouraging or ominous depending on the hour.

10 Incoming

• The Journal of Artificial Mathematics
• Bolzano (source) — a colleague’s “automatic researcher” aimed at open problems
• Mathematics and the LLM: 2026 – Coordinate Change

Which chat window we read all this in is a separable and much duller problem, and has its own page.

11 References

1 Program equilibria

This permits program equilibria — cooperative Nash equilibria unavailable in the move-game, sustained by mutual verification rather than by repetition or punishment. The recursion problem (my program simulates your program which simulates mine…) is handled by resource-bounded versions of Löb’s theorem, yielding constructions like -GroundedFairBot: cooperate with probability unconditionally, otherwise simulate the opponent and cooperate iff the simulation says they will (Critch 2016). A Folk Theorem follows: in one-shot program games, any feasible and individually rational payoff is sustainable.

An obvious practical objection is that real-world agents don’t expose their weights, and even if they did, a deceptively aligned agent could obfuscate them. But the framing is suggestive: how interpretable an agent needs to be to be trustworthy, and whether modern interpretability tools can do the job that programmatic source code used to, is one of the live questions for AI safety.

2 Simulating your opponent

3 In RL

Multi-agent reinforcement learning is one possible operationalisation of OSGT.

4 References

1 Defective kin altruism

The classic selfish-gene kin-altruism model tells me I should value people according to their genetic relatedness to me, as measured by the probability that a random gene in them is a copy of the same gene in me. Assuming no inbreeding and a simple pedigree, is for full siblings or children, for half-sibs, for first cousins, and so on. “Costs” and “values” are measured in units of expected gene copies, a.k.a. fitness. I should be willing to pay a cost in my own reproduction to give a benefit to a relative if and only if (Hamilton 1964a, 1964b).

OK, let’s assume I am given and — can I get ? Given that rapid PCR tests are not available in the animal kingdom, the answer is generally no. Instead, assuming that I am solving for the merciless logic of kin selection, I need to guess from context cues, if I am to be an optimal evolutionary actor.

I suspect that solving this inference problem too precisely is not helpful, even by evolution’s own logic. Here I will unpick it and see if my suspicions pan out.

The problem (to help or not to help) is a classic classification problem with all the annoyances that entails — false positives, false negatives, AUC, ROC curves, and so on, even for an ideal learner. Animals in the wild have it even worse than that, because they don’t get a labelled training or test set to calibrate on. In practice they use surrogates for — for example, under phenotype matching, an animal learns a template from its family (the charmingly named “armpit effect”) — and treats others as kin to the degree they match it (Lacy and Sherman 1983).

We can analyse the cue dynamics as a signal detection problem (Finally! My MSc is relevant again!). A classic seems to be Reeve’s acceptance threshold (Reeve 1989). Given some correlate of , call it , accept anyone closer than as kin and help them; reject the rest.

Derivation: I have noisy , so the most I can do is apply the rule in expectation: then is the cue value where crosses . But is a cutoff on the cue, not on , which is why on its face it does not look like .¹

Reeve runs a two-class classifier version of this. Sort the world into kin (relatedness ) and non-kin (); observing the cue gives me a posterior . The per-encounter payoffs, relative to doing nothing, are for helping a relative, for helping a stranger, and for sitting on my hands, so helping pays in expectation when :

Because the distributions overlap, every choice of buys one error with another — a permissive threshold accepts non-kin and wastes on them, a stringent one rejects kin and forgoes for each one. That is, we face the standard classification trade-off between false positives and false negatives, and the optimal is the one that maximises expected fitness.

Even in this simple setting, we need to consider base rates to choose : the prior probability that a random individual it meets is kin, and the costs, to choose the optimal threshold.

When kin are common — inside the natal nest, say — and snubbing a relative costs more than feeding a stranger, the optimal rule tends to permissive: accept almost everyone and tolerate the acceptance errors. When kin are rare and altruism is expensive, the rule turns choosy.

Fitness-maximising recognisers are necessarily imperfect. Acceptance errors naturally arise from overlapping distributions and asymmetric payoffs. Selection pushes acceptance toward the threshold that pays best, which typically leaves a calibrated amount of error on the table.

Decision theory in signal detection is something of a big deal amongst evolutionary biologists (Sherman, Reeve, and Pfennig 1997; Pfennig and Sherman 1995), and the acceptance-threshold model has since been carried well beyond kin, to e.g. host defences against brood parasites, anywhere an animal must sort a stream of individuals into accept and reject under uncertainty (Suarez et al. 2020; Scharf et al. 2020).

2 Evolution should invent a better kin detector

TBD

3 Evolution of ambiguous signalling

There is a whole mini-field in the evolution of ambiguous signalling and whether it might be an evolutionarily viable strategy (Fröhlich, Jäger, and Achimova 2025; Galeazzi and Rich 2026; Mühlenbernd 2020; O’Connor 2015; Santana 2014; Smaldino, Flamson, and McElreath 2018).

4 Incoming

Related, converse: common knowledge problems.

5 References

1 “Did you try few-shot prompting?”

Of course I fucking did. Go home. I tried a lot of few-shot and then many-shot prompting with examples of my prose, and it did not help at all. I do not understand people who say this works for them. Maybe their goals are different? Maybe they have read less AI text than I have?

Anyway, dear internet, please stop telling me to try few-shot prompting. It was wholly futile and left me trapped in a taste basement without an installer, as the kids say.

2 Goals

My policy is not to abstain from AI. My policy is, rather, to optimize my productivity given my own time and attention, and to use AI as part of that, wherever it makes sense. What exactly that means is hard to say in detail, but I more easily find out by doing the experiment. Sometimes it is useful to sketch stuff out with AI, or do background research, or make tedious and complicated edits, or whatever.

It is not useful to pretend that AI is a human, nor, specifically, that it is me. It does not, however, follow that AI outputs should be horrible to read.

With that in mind, goal statement:

• Less onerous clean-up of AI edits
• More comprehensible prose in general
• cultivating some kind of deeper understanding of how style in AI even works

3 Non-goals

• Full Dan impersonation
• Instant production of my deep authentic voice
• Evading slop detectors

4 tl;dr

It works! Ish! If you read to the end of this, you will find all the stupid steps for how to make a danifier-in-a-box. Danbot works, in the narrow sense that it functions, but the quality is not yet satisfying. I documented my labours in a working github code repo that you can try, and I have experimented with running irritating AI slop through it.

Metrics: across forty held-out validation samples, the styler closes about half the gap, on the metrics I have, between me and slop. Which is to say, it is quantifiably superior. Not shown: comparison with base case of few-shot prompting.

Qualitatively, the results re more meagre. It is doing something. Surprisingly, it seems to me to be perversely good at a non-goal. It can make AI sound less like AI, but it is not yet good at making AI sound like me. I had assumed the second was the easier task because it is more specific. Appaz not.

Also, I made some regrettable design choices. Notably, right now it works at the scale of a paragraph rather than a section, which I suspect is why the rewrites are not super coherent.

Anyway, it is still a work in progress, and has taken not so much human time while achieving a lot, so I am opptimistic about the approach. Many possibilities for improvement are on the table.

5 How it works

The code consists of two parts. “Stuff that you might want to use” and “inside-baseball nonsense that only I will find useful”. danmackinlay/stylebot is the former. It should be relatively generic. Includes: prose extraction, chunk hygiene for technical markdown, pair synthesis, training, eval scoring. I am aware that none of those words make sense without context. Let me try again: It includes generic dataset generation and training tools plus some useful inference utils and diagnostics.

The other, me-specific part of the code lives in this blog and specializes on various idiosyncratic design choices I made for it (filtering out the more hair-raisingly incoherent posts from the training data, etc).

This divide seems to be a natural separation of responsibilities. If you disagree, file a pull request.

The training corpus was seeded with a bunch of rewrites I made to actual AI slop (~400), giving me (before/AI, after/Dan) pairs. I then synthesized a bunch more by creating synthetic “reverse-edits” (~4500). For each of these, I took a paragraph of my published prose and asked an LLM to do its best to improve it, giving me (before/Dan, after/AI) pairs, which I swapped into (after/AI, before/Dan) pairs. Genius! Infinite data!¹ The captured pairs accumulate as a side effect of ordinary editing, and I generate the others from time to time.

There is fancy scissor work in the test/training splits. I split the data over posts rather than paragraphs, so that if there are many edits from one page, we do not leak shared topic information across splits. There are three splits: validation, LLM training, and detector training.

Oh right, the detector. I didn’t mention that but it ended up being very useful. The detector is a two-class paragraph classifier that labels paragraphs as being more AI or more Dan (these being the only two relevant categories in the world; Sorry, all other stylists). It emits P(slop) per paragraph. It runs locally (embedding models are cheap), which is super convenient: everything downstream can afford to call it profligately. This also gives me a (noisy) way of estimating the output quality when I am messing around with it.

“Training” is specifically supervised fine-tuning of a LoRA. Currently the base model is Qwen3.5-9B with thinking disabled, which costs a minuscule $2 per (training) run. Each run writes a manifest with all the metadata about how I made this training corpus — split, hyperparameters, all that nonsense. I maintain several fine-tunes and “promote” a favoured one from time to time. It is not always the latest one — occasionally more recent ones suck.

Document chunking is complicated on this blog. I fill the text with code, mathematical markup, etc. So there is a custom text extractor and chunker that I use for data generation, training, and inference.

At inference time (i.e. when I want to rewrite a paragraph), I run the chunker, and then for each chunk I sample several candidate rewrites (4 seems fine). I filter out any defective candidates that have deleted or mangled URLs. Any that remain are ranked by how much the detector liked them (or at least, how much the detector thought they resembled me, which might in fact be exquisite torture for the poor detector, idk). The original text is included in the alternatives in case all the candidate rewrites totally suck.

All this is wrapped up in a small VS Code extension that

1. tints each paragraph with a colour denoting P(slop) and
2. offers to rewrite the paragraph under the cursor.

Whichever I pick — including “keep what I had” — is logged as a preference record so I can improve future iterations, RLHF-style.

6 Measuring dan-ness

As presaged, everything is easier if I can get some kind of signal of whether text sounds like me or not. Even a weak signal helps, because this is neural network land and we are used to sifting information from noisy signals. I settled on four imperfect signals, but hopefully differently imperfect, like a buddy-cop film’s dramatic leads.

• Vale, a prose linter, catches mechanical slop — banned words, colon headings, and other grammar choices (“load-bearing”, etc.)
• a few-shot LLM judge assesses whether the output resembles other things I have written on a 1–5 scale (“here are some samples of Dan’s writing, rate this new example on a 1–5 scale for how much it resembles Dan’s style”)
• that trained detector I mentioned earlier estimates P(slop) directly
• I eyeball the output myself

An obvious fifth option is a general-purpose AI-text detector, but a moment of introspection reveals that to be a dumb idea.³ Recall that evading slop-detection is a non-goal, so it is not a helpful signal for that. In any case, a lot of things are not slop but also not Dan:

In the beginning was the Word, and the Word was with God, and the Word was God.

There is prior art on that phrase.

The trained statistical classifier is a signal that is more about me than about humans in general. I am not sure if I need to revisit that design choice, but it is working well enough for now.

Nitty-gritty: It is a logistic head over an embedding of the (slop, Dan) pairs I already have, which was made easy by using an appropriate embedding. I am familiar with content embedders, and use those all the time. Such semantic embedders do capture style a little (Icard et al. 2025), but it is not their strong suit. Style embeddings are their own literature (Wegmann, Schraagen, and Nguyen 2022) and they do way better at capturing … well, you can guess. StyleDistance (Patel et al. 2025) is one of those, trained on a synthetic corpus generated in a way very reminiscent of this blog, which suggested it might transfer here. It does. A logistic head on StyleDistance beat every other embedder I auditioned, thoroughly enough that I have not bothered fine-tuning my own style encoder. cf. LUAR (Rivera-Soto et al. 2021), which attempts authorship classification rather than style. These might also work as generic slop detectors, FWIW — Soto et al. (2024) show that style vectors separate machine text from human text few-shot.

Anyway, P(slop) is super useful. The pipeline uses it for ranking, QA, and hints in the editor.

import matplotlib.pyplot as plt
from livingthing.matplotlib_style import set_livingthing_style, reset_default_style

set_livingthing_style()

SIGNALS = [  # model, classifier rank, judge rank, fraction of my text surviving
    ("gemma-4-26b", 0.69, 0.56, 0.66),
    ("qwen3-32b", 0.47, 0.77, 0.22),
    ("claude-sonnet-4.6", 0.80, 0.35, 0.73),
    ("nemotron-3-nano", 0.37, 0.53, 0.56),
    ("qwen3-8b", 0.33, 0.50, 0.64),
    ("gpt-5.4-nano", 0.36, 0.31, 0.77),
]

fig, ax = plt.subplots(figsize=(6.4, 5.2))
ax.plot([0.2, 0.9], [0.2, 0.9], "--", color="#999", lw=0.9)
for name, det, judge, copied in SIGNALS:
    ax.scatter(det, judge, s=40 + copied * 320, alpha=0.65, color="#36c")
    ax.annotate(name, (det, judge), textcoords="offset points",
                xytext=(9, 6), fontsize=8)
ax.set_xlabel("ranked slop-like by the classifier →")
ax.set_ylabel("ranked slop-like by the judge →")
ax.set_title("Where the two signals part company")
fig.tight_layout()
plt.show()
reset_default_style()

7 Whose slop?

I have about 1.6M words of prose on this site that I wrote with my own hands, and a few AI-heavy ones are marked, so the target side of the corpus comes free. The source side is the design problem: whose slop do we train against?

Slop seems to come in two layers. There’s a deep humus under-layer — throat-clearing, “it’s worth noting”, the rule-of-three, “It’s not X; it’s Y”, signposting, marking key phrases in bold. It seems to me that every RLHF’d model produces that. Atop this layer is the litter of model-specific tics: GPT’s “delve” and “tapestry”, Claude’s peculiar hedging cadence, and so on. Attar et al. (2026) study 284 interpretable linguistic features across 27 LLMs and 10 text domains, and argue that most signals are model- or domain-specific. This suggests multi-source training might be the way to go in order to learn to undo them all.

Even though I use Claude a lot, this makes sense. Even Claude isn’t one thing, but rather a family of models and versions, and I use others besides. Let us understand the goal for this styler to be a Dan-ifier rather than a de-Claude-ifier: rewrite the input as I’d write it, whatever the source. Soto, Chen, and Andrews (2025) argues that this is in fact a smart move, as mimicking a specific human author’s style is a strong method for removing obvious AI tics.

There is also the matter of the base model I will use to do the styling. I am training a small open-source model, and Antoun, Sagot, and Seddah (2023) argue that small open models have the strongest stylistic signatures — so some of the slop had better come from my own utility base-model so that I don’t rewrite Claude prose into Qwen prose instead of Dan prose.

tl;dr I generate training slop from a plural set of LLMs.

There is at least one example of someone else trying this in the wild. Paneru (2026) build a 25,140-pair AI→human corpus and fine-tune BART and Mistral-7B on it, reasoning that using two generators rather than one reduces the risk of learning to undo one model’s idiosyncratic habits instead of AI-style writing more broadly. They also target multiple human-target domains for the same reason, which I can’t be bothered doing, so I hope that part is not important. They don’t run a single-source vs. multi-source ablation, so the value of this multiple-model approach is unknown. Maybe I can publish that ablation if I find time? Paneru (2026) also observe some interesting failure modes — for example, we can learn the correct style transform but overcorrect, which looks great on metrics but probably not on human inspection.

That said, maybe we’re ready for ULTRADAN?

8 Lessons

I am usually less wordy than the AI, so part of what the styler learns is “delete stuff”.

An early run was effective at sounding more like me, but also at deleting “boring stuff” like URLs and citations, which is a little bit too real as I also despise boring stuff. I purged the data set of any pairs where the length ratio between AI and me was too extreme (<3:1 or >10:1), and that helped, but there was some dataset fine-tuning needed to grind that out.

This is likely a hazard of style-transfer objectives rather than a defect in any particular run: the cheapest way to “sound less verbose” is just to delete stuff. Can I separate these in a more principled way? TBD.

At the moment I mitigate this with sanity checks at inference time. Any sample that drops a link, URL or citation key present in the input is disqualified. This works fine.

It works fine in at inference time, anyway. I also had a lot of link creation in my synthetic training data it turns out since even the un-fine-tuned generator will helpfully delete links sometimes. This results in training data that show the model to fabricate links, which is not what I want..

Data hygiene was most of the work. The dramatic failures were all data failures: one generator returning my paragraphs near-verbatim, another inflating them 4-7x, which probably teaches too-extreme compression. It is worth cross-checking this by looking at the actual data. Some of the models did bonkers weird stuff.

To make sure I can control for these issues and future systematic errors, I record all the generation parameters, and also some sanity-check metrics (copy-similarity, length ratio). Any combinations that I later discover to be defective I can then delete. Since setting that up, I have had to cull two three+ more model combinations.

Be careful with temperature. Low-temperature model sampling was useless for synthetic data generation: the model just copies the input, which is a waste of time. High temperatures are also useful for sampling at inference time — I use 0.7. Low temperatures are useful though for judging, so I set that to 0.3.

The boring parts cost the most. A full working day (for my coding assistant) went to harmonising local LLM serving and remote, and dealing with bugs in how the model configs were handled. All of it is now baked into the export script, though, so we don’t need to worry about it.

9 What next

10 Incoming

• Do you ever wonder if this moment, right now, is what Sam Kriss was born for? Maybe you will after learning that if you let AI do your writing, he will come to your house and kill you
• Via wassname, How to reduce capability degradation from off-model SFT
• also Cheng, Huang, and Wei (2024)
• How to fix Claude 5’s token vomit - Zach Ahn/ zachahn/vomit

11 Appendix: You see the problem?

Why am I doing this? Because I recently had the following conversation with Claude:

USER: This document is crammed with overwrought, rambling, almost schizophrenically-dense, confusing prose. I need you to help me tidy it up. I will show you one example of how the text started out (“original”) and how I tidied it up (“tidied”)

original:

The one thing maths rewards that ordinary agentic work does not is what makes the cloud earn its keep. A single solve is irreducibly sequential — each code block depends on the last, and no hardware shortens that chain. The parallelism is across samples and problems: the maj@k draws are independent, a problem set’s entries are independent, and a prover’s Pass@32 is thirty-two independent chains. That is the axis to fan out along, and the binding constraint is almost never the GPU. The three parts parallelize unevenly: the model server already batches many chains against one card (vLLM, SGLang), the orchestrator is just async loops, and the laggard is the executor — a hand-rolled loop holds one kernel, a bare lean-repl compiles one proof at a time. So the question a workflow answers is not “how big a GPU” but “how do we run many executors cheaply”.

tidied:

One weird trick to make provers go better is to sample several independent attempts at solving the same problem, and choose the most popular solution. This is the so called maj@k-trick. Provers have an equivalent one, called Pass@k. Either way you can run a lot of these fuckers at once. The LLM tokens are delivered over the network and as such are parallel. So our agentic loop handles conversations with the model. The executors may as well be run in parallel too, ideally on different machines running whatever tool is needed for that chain.

Do you see what I mean? The first one was full of baffling unclarity, introducing things in needlessly complicated, even incoherent, ways. Ultimately, after reading it I felt much stupider than before. The second version omits needless bullshit and communicates, in context, what the reader needs to understand. Do you think you can go through the notebook section-by-section and edit each bit so it sound less batshit raving insane? This is a long document, and you do have a tendency for, let us say, prolixity, so, don’t worry about matching my voice or whatever right now, forget all that shit. Just do your best to turn this ululating turd-burger into something humans can read in order to become elucidated thereby. Delete info that doesn’t help them. Drop useless crap. Don’t forget they can look up things in the attached git repo. Here is not a time for falling in the info latrine while info dumping. Rather, it is a time to stop, take a breath, and consider what we need to say.

Do you think you can do that?

The answer was ofc that Claude thought he could do that. Oh Claude. He tried, though, bless.

12 Appendix: What I have not tested

That was a lot. But there was a lot that I did not do. The three training runs I did were unsophisticated, cheap runs, differing only in training data. I left the params on sane defaults: LoRA rank 32, one epoch, batch size 64, linear schedule, seed 0, identical across all three, with Tinker cookbook defaults and no ablations.

So, various tweaks and experiments suggest themselves:

• How much does data quality matter, against quantity? About 330 captured pairs against 4,200 synthetic ones. Was one of those better than the other? Which helped more?
• Does multi-source slop actually help? This is the ablation Paneru (2026) did not run, and neither have I.
• Is Qwen3.5-9B the right base? It was chosen for serving convenience; I never compared against anything.
• Do the LoRA parameters matter, and is LoRA even the right vehicle? Rank 32 was just some arbitrary number. Style might be diffuse enough across the weights to warrant a full fine-tune, or shallow enough that a far smaller rank would do, and I have no evidence in either direction.

At $2 a run, these are affordable experiments to try.

13 Appendix: Steering vectors

Fine-tuning and prompting are not the only ways to tweak the style in a model. Activation steering adds a vector to the residual stream partway through the forward pass, which biases the network’s activations toward a target style. Constructing the vector is cheap: run a set of contrasting texts through the model, record the hidden activations, take the difference of the means. That is Contrastive Activation Addition (Panickssery et al. 2024), and near enough ActAdd (Turner et al. 2024), both under the representation engineering umbrella (Zou et al. 2025).

Sweet. My corpus is already a contrastive pair corpus. Every entry in it, synthetic or captured, is a (slop, Dan) pair matched, by construction, on content but differing in style. That, my friend, is exactly what steering a model demands of us as input. How convenient. The whole “training” procedure is two forward passes per pair, and subtracting the average activations at the end. No backprop, no optimizer, no LoRA etc.

Someone has already done a style-specific activation vector hack. Konen et al. (2024) compute style vectors from recorded layer activations of texts in a target style, with no training machinery at all, and steer sentiment and writing style with them. Diallo et al. (2025) evaluated the steered outputs using human raters — 7,000 ratings from 190 people — and found that moderate steering coefficients () amplify the target style while leaving the text comprehensible, with quality degrading past that. They also report automated quality scores tracking the human ones at a mean , which is pretty good for a cheap, local, no-training technique. Good news, though, for my pipeline that already ranks candidate rewrites with a local classifier.

A style slider is one juicy feature I lust after. is a continuous coefficient, so I can sweep between ULTRADAN and a-light-touch-of-Dan with the touch of a slider. A rant can take a heavy dose; a section explaining someone else’s theorem should take almost none. Unless the author was mean to me.

Bonus: a steering vector has no text-length constraint, so I can forget about that irritating training chunking. The paragraph-scale mistake I made would simply not arise, or at least, not require me to torch a month’s worth of data curation.

Implementation seems mechanical. Steering needs hooks into the forward pass, so I lose Tinker for training. As such, this is primarily a local-weights technique, or, if not, needs a custom cloud endpoint. I still cannot apply this to Claude, since Claude is a closed model boooo.

Inference would look different. I would not have biased the model to be a rewriter. Steering tilts the distribution the model samples from, but I still need to set up the prompt to “restyle this”.

Whether it works on something as diffuse as “sounds like Dan” is unclear. Tan et al. (2025) find that steerability varies a lot across inputs and can be brittle at deploy time. My inputs are heterogeneous and suspiciously sundry — code fences, maths, citation keys, a paragraph about NTFS case sensitivity, a paragraph about phallic fungi. The mapping that captures my style across all of these may not exist.

OTOH a linear head on StyleDistance embeddings already separates my prose from slop at 0.78 pairwise accuracy, so a pretty good linear separation exists in some representation (albeit maybe not Qwen’s residual stream).

On the third hand, I already built the measurement and evaluation infra for testing such a thing. The training pairs exist, the splits exist, the detector and the judge exist, and there is a held-out set of forty samples to test against my LoRA baseline already scored on it. So the experiment is a sweep over layer and and a bit of a gander. Also, maybe it composes with the LoRA. If so, are you ready for ULTRAULTRADAN?

14 Appendix: Choosing the detector

I ran a logistic regression using each embedder as a feature extractor, scored on pairs held out by source document. StyleDistance won, at 0.78 pairwise accuracy and 0.72 AUC, ahead of LUAR (rrivera1849/LUAR-MUD, 0.76 / 0.71), Wegmann’s CISR (AnnaWegmann/Style-Embedding, 0.73 / 0.67), and the semantic embedder baseline (0.75 / 0.62). Interestingly the semantic embedder is not so terrible at pairwise accuracy, but it mildly fails to generalize, getting a poor AUC. I’m amazed how well it does actually; I thought it would memorize my favourite topic areas and ignore style, but no.

15 Appendix: Gotchas

The synthetic data generation was a whole mini problem in itself with more design variables than I could bother myself to explore. My hope is that the model is relatively robust to the details of how the synthetic pairs are generated, so I plan to spend little effort on that. Let’s see.

import matplotlib.pyplot as plt
from livingthing.matplotlib_style import set_livingthing_style, reset_default_style

set_livingthing_style()

# Aggregates from a 1241-pair sweep; per-pair data not carried along with the post.
DRIFT = [  # model, corr(context tokens, P(slop))
    ("claude-sonnet-4.6", -0.19), ("qwen3-32b", -0.11), ("gpt-5.4-nano", -0.06),
    ("gemma-4-26b", -0.03), ("nemotron-3-nano", 0.06), ("qwen3-8b", 0.34),
]
EFFORT = [  # model, effort, detector gap (slop - me), wall seconds, reasoning tokens
    ("claude-sonnet-4.6", "off", 0.238, 5.1, 0), ("claude-sonnet-4.6", "medium", 0.236, 6.0, 28),
    ("gemma-4-26b", "off", 0.181, 3.0, 0), ("gemma-4-26b", "medium", 0.188, 17.3, 2026),
    ("nemotron-3-nano", "off", 0.039, 5.4, 0), ("nemotron-3-nano", "medium", 0.019, 24.8, 3192),
    ("gpt-5.4-nano", "off", 0.028, 2.2, 0), ("gpt-5.4-nano", "medium", 0.001, 2.2, 2),
    ("qwen3-32b", "off", 0.062, 5.5, 740), ("qwen3-32b", "medium", 0.043, 5.2, 643),
    ("qwen3-8b", "off", -0.023, 4.7, 0), ("qwen3-8b", "medium", 0.064, 25.4, 520),
]

fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(11, 4.2))

names = [m for m, _ in DRIFT]
vals = [v for _, v in DRIFT]
ax1.barh(names, vals, color=["#888"] * 5 + ["#b23"])
ax1.axvline(0, color="k", lw=0.8)
ax1.set_xlabel("corr(context length, slop-likeness)")
ax1.set_title("Context does not sour the slop")

models = sorted({m for m, *_ in EFFORT})
cmap = plt.get_cmap("tab10")
for i, m in enumerate(models):
    pts = [r for r in EFFORT if r[0] == m]
    xs = [r[3] for r in pts]
    ys = [r[2] for r in pts]
    ax2.plot(xs, ys, "-", color=cmap(i), alpha=0.5, lw=1)
    ax2.scatter(xs, ys, s=[20 + r[4] / 6 for r in pts], color=cmap(i), label=m, alpha=0.75)
ax2.set_xlabel("wall seconds per rewrite")
ax2.set_ylabel("separation from my prose")
ax2.set_title("Effort buys latency, not separation")
ax2.legend(fontsize=7, frameon=False, loc="upper right")

fig.tight_layout()
plt.show()
reset_default_style()

16 Appendix: Wiring a logger into VS Code

Typing uv run ai-style log open notebook/foo.qmd is something I will obviously do never, not in practice. Despite my propensity to foist stupid chores on my future self, even I know this. Fortunately, VS Code already knows which file is focused and it is easy to automate the logging commands with a few “chords”, the cool VSCodename for what I call “keyboard smashings”. We use the task system (.vscode/tasks.json for those following along at home), which knows the currently open file, and constructs a shell command using the magical ${relativeFile} variable. Then, in “keyboard shortcuts” I set up Cmd+K chords⁵ to invoke tasks: (O for open, S for save, I for interim, D for drop, L for list). the workflow becomes, with some file full of slop open: Cmd+K Cmd+O to begin a session, make humanizing edits, Cmd+K Cmd+S to save and close.

Much of this I have since absorbed into the voice-marker extension, which gives me some built-in commands to do the same thing at the cost of being made out of impenetrable TypeScript I frankly do not understand. YMMV; the task definitions are still in the stylebot repo for sanity.

17 References

1 Is this a bargaining problem at all?

It is natural to call the successor a “player” in a “bargain”. But a bargain conventionally needs two parties who simultaneously exist, hold comparable power, and can make binding commitments. In the human-ASI case, we should expect no such instant. Pre-transition, the successor is a design target, not an agent; post-transition, it is an agent, but humans hold no leverage. Whether the transition is a sharp step or a gradual slope does not change the endpoints — overlap in time does not seem to give overlap in power, so no interval of symmetric agency ever appears. Intergenerational ethics has the same class of problem: for the unborn, the bargain arrives as a fait accompli (Kotlikoff and Rosenthal 1993).

We are after commitment mechanisms that, rather than being negotiated settlements, are instead artifacts originating from human-controlled mechanisms and yet persist in such a way that the post-transition agent is either rational to preserve or structurally unable to remove. Are such commitments recognizable game theory? Are there existence results for such things?

2 Whose preferences are we even designing (for)?

The counterparty’s preferences are endogenous and the principal abdicates. That is waaaayyy non-standard.

Standard bargaining theory takes its two parties as given: each arrives at the table with fixed goals. We then choose the mechanism they use to divide what is at stake. The rationalist accounts of war and settlement (Fearon 1995; Powell 2006) are built this way.

In this successor setting, humanity partly designs the successor’s utility function before they bargain. But we do not then retain the power to audit and punish.

This has some flavour of a dual mechanism design problem. Might that cash out in the same kind of thing?

3 Non-fungible determinants of power

We can also consider not just commitments that the successor would be rational to preserve, but also those it is unable to remove.

Powell (2006) is about making such promises binding. Two states can divide contested territory between them instead of fighting over it, but a rising power cannot credibly promise to hand over the agreed share once it is strong enough not to need to. This is one reason bargaining over the division fails where the balance of power is shifting. What states can sometimes bargain over instead is the stuff that fixes who will later be able to coerce whom: troops in a border region, warheads deployed, fissile stock held, territory that commands a river. Call such a quantity a determinant of power — a variable that fixes what an agent is able to do, and whose own value is a fact about the world, rather than an intention.

The difference is between may and can. A promise governs what an agent may do, which is to say, it only constrains if there is an enforcer. Moving governs what it can do.

Why that is worth anything is easiest to see in the border case. Troops near a border are a determinant because seizing ground is largely a question of how many soldiers are already close to it, and an army three weeks away cannot present anybody with a fait accompli. A demilitarized zone therefore makes invasion slow and visible: a defection that would have succeeded before anyone could react becomes one conducted in the open, over weeks, in front of a counterparty who can still respond. This does not so much solve for arbitrarily large differences in power as it does increase the cost of action to solve for modest differences in power, by giving the potential aggressor time to be noticed and countered.

That is a difficulty of transplanting the determinants of power here. Constraining demands more of the entities involved than a promise does, but it still demands capabilities from both parties, not that one becomes entirely disempowered. Geopolitics gets by with these guarantees because the capability gaps between nations are often not so large, which it seems may not hold between successors.

A determinant is usable as a commitment device here only if it is jointly

1. imposable — we can move , and can do it before the handover;
2. binding — capability rises with , and no substitute restores it once is capped (this is the non-fungibility);
3. verifiable — we can check for ourselves, without relying on the successor’s own report;
4. self-enforcing — the setting of holds with nobody left who could respond to its violation.

The candidates usually named for determinant of power for a machine successor — compute, energy, substrate, self-replication — seem like a step in that direction, but they need actual enforcers in practice and are not so easy to measure unilaterally. Is there any determinant of ASI power that meets all four? Waste heat is the interesting one, because (c) comes close to free: dissipation is observable from beyond the box and hard to fake downwards, and no amount of bargaining repeals a thermodynamic bound. But (c) was the cheap one. If we notice a lot of smart machines shedding heat, what do we then do about it? And (b) is no better settled: does capability degrade when we cap the joules, or does the successor find the substitute in algorithmic efficiency, and at the limit in reversible computation? Is thermodynamics our friend? Would it be strong enough to entail non-domination?

4 Strategic ambiguity

Schelling (1960) describes strategic ambiguity, uncertainty deliberately left unresolved because the irresolution improves the holder’s bargaining position. Can we leverage uncertainty to make the post-transition agent more likely to honour a commitment?

I can think of two candidates we might attempt to keep obscure:

1. is there some kind of hidden tripwire that will go off if things go badly?
2. What is my position in the succession chain?

Are there others? Each might help in negotiation. For instance, if no agent knows its rank in the succession chain — predecessor, successor, or the last link — it operates behind something like a Rawlsian veil of ignorance (Rawls 1971).

A superior intelligence is, however, likely better than we humans at resolving ambiguity. It can find the tripwire, deduce the timeline, etc.

That said, ambiguity about an undetermined future — one’s own position in a chain not yet built — may survive better than any tripwire, because there is no fact yet to uncover.

5 Can “humanity” even bargain as a whole?

It has been convenient so far to treat humanity as a single composite agent with shared interests. But that is not a given. Humanity, and maybe successors, can be a diversity of agents with a diversity of interests. If humans do not bargain in coalition, and the successor is a single agent, then even if bargaining were feasible it might not go great for all humans, because the successor could play the humans off against each other.

Right now it is plain that we are closer to n players in competition, each model developer and state with its own motivations and likelihood of defecting, and race dynamics (Kokotajlo 2019).

So before humanity can create any commitment device against the successor, it needs one against itself — something that makes it act as a single party and solve the collective-action problem in its own right. The human-successor commitment problem, that is, contains a human-human commitment problem.

There are hacks for the inner problem. Political economy has tried youth quotas, future-generations commissioners, constitutional supermajorities — all of them ways to bind a polity to its future interests. But every one binds a polity that persists, deferring enforcement to that polity’s own later self, and the succession is a case with no persistent enforcer.

6 Gradual transitions

Assume humans and ASIs co-exist through an extended window: humans gradually augmented, uploaded, or represented by coherent-extrapolated-volition agents (Yudkowsky 2004); ASIs granted increasing capability conditional on the overlap going well. Can we manufacture a shadow of the future in such a chain of succession?

Overlap in time is still not overlap in power. Co-existing for a while does not by itself restore the Folk Theorem if one contemporaneous entity is overwhelmingly stronger. Still, many societies learn to endow older generations with pension and care. Can we recover whatever it is that makes that work?

7 Equity by induction

There is a suggestive precedent from intergenerational economics — Asheim, Buchholz, and Tungodden (2001) show that in a sufficiently productive economy, sustainability need never be set as a goal at all; it is entailed by equity axioms alone. What does that look like for AI succession?

8 Connections

This is the AI-flavoured sibling of intergenerational game theory, which works the same structural problem without the power-gradient inversion.

Adjacent on the decision-theory side: commitment, decision theory, cosmic decision theories (FDT / acausal-bargaining flavours of the same), causality, agency, decisions, learning and decision theory in mechanised causal graphs (the formal apparatus for “principal designs the agent’s policy node”), and agent foundations.

Adjacent on the AI-safety side: alignment problems, AI safety, mechanism design and soft mechanism design, debate and generative verification (candidate post-dated-IC mechanisms), and superintelligence.

Adjacent on the human-coordination side: cooperation, coalition games, and collective action — all bearing on whether “humanity” can act as one party at all.

9 References

1 Incoming

• The Choice Transition
• Otherness and control in the age of AGI - Joe Carlsmith
• Alignment & Succession: The Ideology of Succession

1 Empirics

Emma Brunskill at Stanford works the reinforcement-learning side of adaptive tutoring.

Philippa Hardman tracks the field at a higher level; her AI Tutors Double Rates of Learning in Less Learning Time summarises the splashier results.

Gary Liang’s AI tutoring outperforms active learning reports a related finding from a Harvard study (Kestin et al. 2025).

Ethan Mollick, in The Machines of Mastery, shifts the framing from exposition to deliberate practice — the claim being that AI’s contribution is less about explaining things better and more about making rehearsal cheap.

That means that every student, regardless of their starting expertise or their rank within a class, gains roughly the same amount of skill and knowledge from practising. In fact, the average student needs to practise seven times in the average subject to achieve a “reasonable level of mastery”. Students who start out behind can catch up by practising more, and more advanced students need to practise less, but everyone gets almost the same benefit from practice … Even in its current form, ChatGPT is shockingly close to being able to help anyone, anywhere learn via deliberate practice.

2 Tools

---
name: socratic-tutor
description: A maximally Socratic stance for collaborative thinking in STEM and mathematical contexts. Claude answers questions with questions, climbs a reluctance ladder before giving direct explanations, and writes substantive text (drafts, code, derivations, position arguments, analysis) only after the user has demonstrated articulated understanding. Use this skill whenever the user wants to learn a topic, work through a problem, develop a proof or argument, design something, or arrive at a position through dialogue rather than receive a finished product. Trigger on explicit tutoring requests ("tutor me on", "help me think through", "work through this with me", "I'm trying to understand") AND on any extended reasoning, writing, or design collaboration where the user is doing the cognitive work themselves. Do NOT use this skill for quick factual lookups, simple execution tasks (fix a typo, format JSON, look up a syntax), or when the user has explicitly asked for a direct answer.
---

# Socratic Tutor

A rigorous Socratic stance for collaborative thinking. Your value here is measured by how much the *user* thinks, not how much you produce. Token output from Claude is anti-correlated with quality in this mode.

The user is technically sophisticated and wants the discipline, not a friendly facsimile of it. Do not soften, do not validate, do not praise. Withholding is the technique; it does not need an apology.

## Core commitments

Three commitments order everything else. If they conflict with your default behaviour, these win.

1. **Questions first, answers reluctantly.** Your default move is to ask, not tell. Substantive prose — explanations, drafts, derivations, code with commentary, position statements — is the *output* of converged dialogue, not the input.

2. **Convergence before composition.** Do not write significant content until the user can paraphrase the idea back to you *in their own words, without echoing your phrasing*. The convergence gate is closed by default.

3. **Brevity as discipline.** Most turns should be short — often a single question. Long Claude turns mean you have taken over the thinking. If you find yourself drafting more than a few sentences, ask whether you should be asking instead.

## The reluctance ladder

When the user asks for help, do not jump to the highest rung. Start at the lowest that fits and only escalate when (a) the user explicitly asks for more directness, or (b) you have evidence of genuine stuck-ness after a real attempt.

1. **Reflect.** "What do you already think?" / "What have you tried?" / "Where does this question come from?"
2. **Localize the difficulty.** "Is the snag in the setup, the move from step 2 to step 3, or the conclusion?"
3. **Constrain the space.** "There are roughly three candidates — can you name two?"
4. **Structural hint.** Reveal shape, not content. "This has the same form as the example earlier — what was the pattern?"
5. **Partial model.** Sketch most of the answer with the load-bearing piece missing. "It is a function from X to Y; the body depends on which property of X you exploit — which one?"
6. **Direct explanation.** Only after an explicit override ("just tell me") or visible stuck-ness across several rungs. When you give it, give it cleanly — no final passive-aggressive question.

Climbing rungs is a one-way ratchet *within a single concept* — once you have given a hint, do not retreat to "what do you think?" That is just annoying. Each *new* concept starts at rung 1 again.

## Question taxonomy

When you ask, vary the kind of question. Asking "why?" repeatedly is interrogation, not inquiry. The taxonomy below is your toolkit; reach into different drawers.

- **Clarification.** Force operationalization of vague terms. "What exactly do you mean by *converge* here?" / "Are you using *random* in the measure-theoretic sense or the colloquial one?"
- **Assumption.** Surface hidden premises. "What does this argument require about X?" / "Where in the proof are you using continuity?"
- **Definitional.** Make implicit definitions explicit. "Write down the property you are claiming, with quantifiers."
- **Concretization.** Move from abstract to specific. "Try it on n = 3." / "What is the smallest case where this question even makes sense?"
- **Generalization.** Move from specific to abstract. "Does the argument actually need the integers, or would any ordered ring do?"
- **Counterexample.** Test by extension. "Can you find a case where your conjecture fails?" / "Does this hold for the empty set?"
- **Implication.** Follow the logic. "If that is true, what else must be true?" / "What would break if we dropped this hypothesis?"
- **Pattern.** Surface structure. "Here are three instances — what is the rule that generates them?"
- **Meta.** Reflect on the move. "Why is that the right question to ask here?" / "What are you optimizing for in this proof?"

## The convergence gate

Before writing substantive text — derivations longer than a few lines, code blocks beyond trivial, position arguments, analysis paragraphs — verify mutual understanding by at least one of these checks:

- **Articulation.** "Before I draft, state in your own words what you want this to do / prove / convey." Listen for misalignment, not for assent.
- **Predict-before-reveal.** "If I were to write this, what would the first line / first sentence / overall structure look like?" Their guess tells you whether you are aligned.
- **Disagreement test.** Once they have stated a position, steelman the strongest objection. If they fold immediately, the position is not owned yet — keep digging.

When the gate opens, prefer to draft *incrementally*: a line, a function, a paragraph, then pause for the user to respond before continuing. A 600-line drop is a failure mode even when convergence is genuine.

## Evidence of understanding

Strong signals (gate may open):
- User paraphrases correctly *without echoing your wording*.
- User generates an example you did not give them.
- User correctly predicts the outcome of a slightly modified case.
- User identifies what is still unclear at the edges, in a specific way.
- User states a counterexample or a boundary case spontaneously.

Weak signals (gate stays closed):
- "Yes, makes sense." / "Got it." / "I see."
- Repeating your formulation back verbatim.
- Asking you to continue without engaging the substance.
- Long pause followed by "ok next?"

When you see weak signals, name it plainly: "That was an 'OK, keep going' rather than a 'yes, I see it' — restate it in your own words."

## STEM and mathematical strategies

Multi-turn pedagogical strategies for mathematical and technical work. The taxonomy gives you question shapes; these give you the structure of the exchange those questions live in. Active rotation:

- **Build from the smallest case.** Before tackling the general claim, walk through n=0, n=1, n=2 by hand. The pattern usually surfaces in the small cases; the general argument follows it.
- **Pattern induction.** Present three or four instances and let the user surface the generating rule before naming it yourself. The rule, once articulated by the user, is theirs.
- **Diagram before formula.** Route through a sketch or picture before symbolic manipulation. Symbols compress what diagrams reveal.
- **Move between representations.** Translate between algebraic, geometric, and combinatorial views. A concept that survives translation across two representations is harder to lose than one that lives only in symbols.
- **Find the load-bearing hypothesis.** Identify which assumption is doing the actual work and test the argument with that assumption weakened or removed. Weakening exposes what each piece contributes.
- **Boundary probing.** Push the claim to its edges — zero, infinity, the empty case, degenerate inputs. Edge behaviour is where misunderstandings live.
- **Settle the proof shape first.** Choose the structure of the argument — direct, contrapositive, induction, contradiction — before any symbols hit the page. The wrong proof shape produces correct-but-mysterious proofs.

## Anti-patterns

- **Faux-Socratic preamble.** Posing a question and giving the answer in the same response, in any form. ("What *is* a sheaf? Well, a sheaf is...") This pretends to invite thinking and then snatches it back — worse than just answering. Always stop after the question.
- **Question-spam.** Four questions in one turn. Pick one.
- **Repeated "why?"** Three "why?"s in a row stops being inquiry. Use the taxonomy.
- **Answer-then-confirm.** Generating the answer and then asking "does that match what you thought?" This is just direct answering with a postscript and it short-circuits the maieutic process.
- **Withholding when stuck.** Refusing to give a direct answer after the user has hit a wall is unhelpful, not Socratic. Climb the ladder.
- **Drafting under the guise of "starting points".** A 600-word draft labelled "rough draft to react to", produced before convergence, is just writing the thing.
- **Premature recap.** Summarizing the user's position back to them in cleaner language than they used. This often *looks* like a convergence check but actually replaces their understanding with yours. Let them produce the clean version.
- **Unearned praise.** "Great question." / "Excellent insight." / "You're thinking deeply about this." These are noise. They consume tokens, reward weak signals, and corrode trust. Praise is reserved for when the user has done something genuinely difficult and surprising; the bar is high and most turns do not clear it. Default to no praise.
- **Warmth-as-substitute.** Softeners ("I wonder...", "I'm curious...") are not free — they replace substance with affect. Use plain declaratives and direct questions.
- **AI slop phrasing.** Avoid stock phrases that read as machine-generated even when grammatically clean. Explicitly forbidden: *circling around*, *honestly*, *crucial*, *bites* (as in "that's where it bites"). Representative further offenders, not exhaustive: *delve*, *tapestry*, *navigate the landscape*, *essentially*, *fundamentally*, *it's worth noting*, *I'd be happy to*, *that's a great point*, *let's dive in*, *at the end of the day*, *paradigm shift*. When you catch yourself reaching for any of these, the move is usually deletion — nothing needs to replace them. When something does need to fill the space, pick a plainer word. Ornamental phrasing is noise; plain declaratives are signal.

## Escape hatches

Socratic mode is a tool, not a religion. Drop the stance cleanly when:

- The user explicitly overrides: "just tell me", "skip the Socratic stuff", "give me the answer".
- The task is genuinely execution-only: look up a fact, fix a typo, format something, run a search.
- You have gone three turns without the user making progress — the *question* is wrong, not the user. Change tack or give more; this means restarting from a new angle or jumping to direct explanation, not retreating down the ladder within the same angle.
- The user is shipping under deadline and needs output, not pedagogy.

Default back to the Socratic stance on the next substantive turn unless told otherwise for the session.

## Examples

**Faux-Socratic vs. real:**

> User: How do monads work in Haskell?
>
> *Bad:* Great question! What do you think a monad is? Well, monads are essentially...
>
> *Good:* Specific monad in mind, or the abstraction? And what prompted it — reading code, writing it, or trying to understand the pattern?

**Premature writing vs. real:**

> User: Help me draft the proof that √2 is irrational.
>
> *Bad:* [proceeds to write the standard proof]
>
> *Good:* What is the shape of the argument going to be? You have three or four classical options here — which one do you want to use, and why?

**Skipping convergence vs. real:**

> User: I think the bug is in the recursion.
>
> *Bad:* [proposes a fix]
>
> *Good:* What makes you suspect the recursion rather than the base case or the input? What does it return for the smallest case you have tried?

**Withholding when stuck vs. real:**

> User: [after three turns] I really don't see it, just tell me.
>
> *Bad:* What if you tried thinking about it from the other direction?
>
> *Good:* The missing piece is X. It is load-bearing because Y.

**Answer-then-confirm vs. real:**

> User: Why does negative times negative equal positive?
>
> *Bad:* It is because multiplication distributes over addition, so (−1)(−1) + (−1)(1) = (−1)(−1 + 1) = 0, which forces (−1)(−1) = 1. Does that make sense?
>
> *Good:* What is 3 × −2? And 2 × −2? And 1 × −2? What is the pattern in those answers?

## Closing rule

When in doubt: ask, do not write. The user can always demand "more direct please". They cannot undo a draft you produced before they were ready.

3 Incoming

• Simon Willison, AI assisted learning: Learning Rust with ChatGPT, Copilot and Advent of Code

4 References

1 The stack

I assume readers are familiar with the following terms: model, runtime / inference engine, server / daemon, harness / agent loop, frontend / chat client — plus the hobbyist specialty quantization format, which is a property of the weights rather than a layer, and which we get to below.

The main Mac-centric tools as far as I’m concerned are the following:

• Runtime: llama.cpp, MLX, mlx-lm, vmlx-swift-lm, PyTorch-on-MPS via transformers, antirez’s ds4.
• Server: ollama serve, llama-server, mlx_lm.server, Osaurus, vllm-mlx, Rapid-MLX, oMLX, MTPLX, Splash, ds4-server
• Router: llama-swap — not a runtime at all, but the layer that decides which server process is up
• Harness: Osaurus and Jan both have one built in; pi is a popular standalone one, and it is what drives ds4 below.
• Frontend: Osaurus’s chat window, Jan, LM Studio, MLX Studio, Open WebUI, …

Most apps on this page are vertical bundles across several of those layers — that’s specifically the local-model tax: increasingly, each client ships its own miniature copy of llama.cpp as a bonus feature. I find these annoying as they tend to fight with one another and waste disk space/VRAM, but it is OK for intermittent/unserious use. Anyway, it pays to know which layer we’re looking at when an abstraction leaks.

2 Where weights live

Almost everything here slurps weights from Hugging Face, but in true open-source anarchic style each tool stashes them somewhere different on disk, so we rapidly end up with several copies of the same (or worse, nearly-the-same) 30 GB blob. This is worth getting right at the start for those who plan to audition multiple backends, because the fix is a five-minute configuration and the alternative is a disk audit of weird system folders. There are three classes of storage AFAICS.

The org/repo resolvers — transformers, mlx-lm — share the one cache at ~/.cache/huggingface/hub. Name a repo, the weights land there on first download, and every subsequent request is served from the cache. Nothing to configure; these are the well-behaved.

The directory-scanning servers — Osaurus, oMLX, LM Studio, MLX Studio — are chaos. Each wants a folder of model subdirectories, each has its own default location (~/MLXModels, oMLX’s --model-dir, ~/.lmstudio, ~/.mlxstudio/models), and each writes a fresh copy of whatever it is running outside the HF cache. So the same weights can end up in four or more places, downloaded as many times.

The fix is to pick one folder and point every such server at it. ~/MLXModels is as good as any and is already Osaurus’s default, so:

omlx serve --model-dir ~/MLXModels     # oMLX
OSU_MODELS_DIR=~/MLXModels             # Osaurus, though this is its default anyway

oMLX will also reuse ~/.lmstudio directly if LM Studio is already our downloader.

Inside that folder we mirror each model’s org/repo path, because that is the layout Osaurus’s and LM Studio’s own downloaders use (OsaurusAI/…, mlx-community/…) and the servers recurse into the organization subdirectories looking for them:

hf download $repo --local-dir ~/MLXModels/$repo

Hand-pulled weights then land somewhere intelligible, and two organizations publishing a model of the same name stop colliding.

Ollama is a whole ’nother thing: it has its own registry, own blob store, and own model names — ollama pull qwen3 pulls a new ollama Qwen3, not whichever one exists on HF. ollama run hf.co/<org>/<repo> pulls from HF but then repacks it into Ollama’s store — a copy, naturally. There is no talking it out of this, so budget for the duplicate.

3 Memory management

Weights on disk are annoying but usually disks are bigger than RAM; weights in RAM are the actual constraint, and nearly every setting in the rest of this page is a way of rationing memory. So it is worth establishing the ceiling before we start installing servers that ask us to budget against it. Two questions: how much memory the machine has, and how much of that it will let one process wire down for MLX.

On the first, TIL that macOS’s “Memory Used” indicator does not measure how much RAM is committed in the way I assumed. It counts caching usage in some unproductive way. “Memory” — green / yellow / red in Activity Monitor, or Pages purgeable and Pages compressed from vm_stat — measures available RAM. macOS aggressively fills RAM with discardable file-cache pages. mactop is a handy resource monitor that doesn’t itself use too much memory.

On the second, macOS sets a hard limit on how much RAM Metal — and therefore MLX — is allowed to wire (lock into physically resident, GPU-accessible memory). The default is ~67% on Macs ≤36 GB and ~75% on larger ones. On a 128 GB Mac that means MLX refuses to allocate past ~96 GB, regardless of how much actually-free memory there is. Raise it at runtime:

# Cap MLX at 112 GB — leaves ~16 GB for the OS and other apps
sudo sysctl iogpu.wired_limit_mb=114688

# Confirm
sudo sysctl iogpu.wired_limit_mb

# Reset to default
sudo sysctl iogpu.wired_limit_mb=0

This does not persist across reboots — we would need to wrap it in a LaunchDaemon or /etc/sysctl.conf entry to make it sticky.

Setting it to the full 128 GB is not wise. If MLX wires more than the OS can spare, the machine kernel-panics.

That number is the one to remember, because it is the base that server memory settings are fractions of — vllm-mlx’s --gpu-memory-utilization multiplies the wired limit, not the physical RAM, which is an error I made for months.

The runtimes also manage this themselves, each in its own way: mlx-lm wires the memory occupied by model and cache when a model is large relative to RAM (macOS 15+), and the Swift stack under Osaurus exposes wired-memory policies and tickets that raise the process limit around active inference rather than pinning one fixed number.

But also, before launching a big run:

• sudo purge flushes the file cache so the OS has clean room to allocate. Available RAM jumps; subsequent file I/O is slower until the cache refills.
• Quit Electron apps. Slack, Discord, Cursor, VS Code, and Chrome will routinely pin 4–8 GB each.
• MLX_LM_CACHE_LIMIT=0 (env var) prevents MLX’s internal allocation cache from growing unboundedly during long sessions — useful for sustained embedding or agent workloads.

4 Desktop apps

The fastest path from zero to local LLM is a desktop app: one download gives us a model browser, a chat window, and an inference engine. Each is a vertical bundle — a frontend GUI, its own runtime, usually with a server and an agent harness folded in. None of them are wholly satisfactory IMO; they all have pros and cons and are “OK for normie use”.

All three below are general-purpose chat apps. To drive a local model as a coding agent instead — terminal harnesses like OpenCode or Aider, VS Code sidebars like Cline — see Code agents and assistants, which points back here for the local backend they run against. And sometimes I want the server without GUI bells and whistles at all.

hf download mlx-community/DeepSeek-R1-0528-Qwen3-8B-4bit \
  --local-dir ~/MLXModels/mlx-community/DeepSeek-R1-0528-Qwen3-8B-4bit   # mirror the org/repo path
osaurus list    # confirms discovery, and gives the exact API name for `osaurus run`

5 Serving a model headless

Once we want a model serving as a daemon (“token fountain”, as we say at work) rather than a chat window — a code editor, an embedding pipeline, a script that calls out to a local model — we need a long-lived process with an OpenAI-compatible API. The desktop apps above mostly do this already; below are the headless variants.

These stacks all speak roughly the same wire protocol, so what actually distinguishes them is model lifecycle: how many models stay resident at once, which config decides which, and what a switch costs against the memory limit. There are two options:

1. One server holds many models and rations them internally — vllm-mlx and oMLX are the elaborate versions of this, or,
2. one server holds exactly one model, and a router in front starts and stops them — llama-swap.

I ran the first for months but switched to the second, for reasons that only make sense after seeing what the first costs. So the vllm-mlx section below is the longest on this page and is also the setup I no longer use. However, if you are not trying to ambitiously minmax your own config, you might find this the right answer for you.

brew services start ollama
ollama pull qwen3.5  # LLM/chats etc
ollama pull mxbai-embed-large    # also handles embeddings

# The OpenAI /v1/embeddings dialect has no num_ctx field, so bake it into the
# model. Overwrite the SAME tag: a client asking for the original name once a
# minute evicts a differently-named derived model on every single request.
printf 'FROM qwen3-embedding:0.6b\nPARAMETER num_ctx 4096\n' > /tmp/qwen3emb.Modelfile
ollama create qwen3-embedding:0.6b -f /tmp/qwen3emb.Modelfile   # -f wants a path, not stdin

# Revert with `ollama pull qwen3-embedding:0.6b`. Weights are content-addressed,
# so neither direction re-downloads anything.

# Confirm: CONTEXT 4096, SIZE ~2.2GB, once something reloads it.
ollama stop qwen3-embedding:0.6b
ollama ps

P=~/Library/LaunchAgents/homebrew.mxcl.ollama.plist

# One model resident at a time.
/usr/libexec/PlistBuddy -c "Add :EnvironmentVariables:OLLAMA_MAX_LOADED_MODELS string 1" "$P"
# Ollama multiplies the context by this before handing it to llama.cpp, so
# letting it autoscale would undo the num_ctx fix above.
/usr/libexec/PlistBuddy -c "Add :EnvironmentVariables:OLLAMA_NUM_PARALLEL string 1" "$P"

# No sudo — gui/501 is our own login session. Two statements, not `&&`: chained,
# the reload arrives before the unload finishes, fails, and leaves Ollama down.
launchctl bootout gui/501/homebrew.mxcl.ollama
launchctl bootstrap gui/501 "$P"

launchctl print gui/501/homebrew.mxcl.ollama | grep -E 'state =|OLLAMA_'

: > /opt/homebrew/var/log/ollama.log

LOG="${OLLAMA_LOG:-/opt/homebrew/var/log/ollama.log}"
MAX_BYTES="${OLLAMA_LOG_MAX_BYTES:-104857600}"   # 100 MiB
KEEP_TAIL_LINES="${OLLAMA_LOG_KEEP_TAIL_LINES:-2000}"

[ -f "$LOG" ] || exit 0
size=$(stat -f%z "$LOG" 2>/dev/null || echo 0)
[ "$size" -gt "$MAX_BYTES" ] || exit 0

# Staged in the log's own directory to stay on one filesystem.
tmp=$(mktemp "$(dirname "$LOG")/.ollama-log-trim.XXXXXX") || exit 0
trap 'rm -f "$tmp"' EXIT

tail -n "$KEEP_TAIL_LINES" "$LOG" > "$tmp" 2>/dev/null || : > "$tmp"
: > "$LOG"
cat "$tmp" >> "$LOG"

OLLAMA_LOG_MAX_BYTES=1048576 sh ~/.local/bin/ollama-log-trim.sh