Model Minimalism

Kendall Clark · Pentad Labs · 28 July 2026 · PLRN-022

Abstract

Frontier models are as remarkable as they are slow. Their slowness has made the software industry consuming them careless. When inference takes seconds, another millisecond looks free. When the charge disappears inside an API bill, another model call looks harmless. Neither judgment survives production.

Model Minimalism refuses to use general intelligence where a smaller or deterministic mechanism preserves the quality that matters. It moves work from remote frontier calls toward local models, frozen artifacts, and solvers, and it treats every remaining call as COGS rather than magic.

The fuck-around phase rewarded possibility. The find-out phase rewards systems that can repeat the result without repeating the expense. WunderOS is built for the latter.

This is an origin story of sorts.

The find-out phase

The product phase changes the meaning of model choice. Except where a lower rung is named explicitly, “model” in this note means a frontier generative model. A nested frontier call may prove that a system can do a thing, but once the same system runs continuously somebody owns its cost of goods sold. The model bill is then part of the product architecture. So are the tail latency, the provider dependency, the failure rate, and the operator time spent correcting stochastic results. A model larger or more expensive than the task requires is no longer harmless excess. It is sloppiness, and often vanity, carried into COGS.

This is especially important at the knot of the AI market’s bow tie. Models, compute, data, energy, and capital enter on one side. Authorized action leaves on the other. The knot converts the first into the second, and this conversion is where value concentrates. Frontier inference already consumes most of the latency budget. The first non-stochastic pinch point after it is not, to put it negatively, also free to be slow. It is the part we control, and it is held to the standards of a high-frequency trading system: microseconds where the operation permits them, bounded allocation, explicit limits, and measurement at both p50 and p99.

The Bitter Lesson is not a serving policy

Model Minimalism appears to run counter to The Bitter Lesson. The lesson is that general methods based on search and learning eventually defeat systems built from human knowledge, because computation grows while hand-built accounts of the world plateau. A version of Model Minimalism that merely rebuilds expert systems will have run afoul of it.

However, the key distinction is between discovering competence and exercising competence already discovered. Search and learning should discover the complexity of the open world. It does not follow that every execution must repay the full cost of that discovery. A stable behavior learned through frontier inference may be distilled, compiled, recorded, or served by a smaller model without denying how it was found or, more critically, without denying the means of new findings. This is learned compilation, not a return to handcrafted AI.

WunderOS’s continuous autoresearch loop, CARL, supplies the bridge. CARL self-tunes: it modifies only itself, and those modifications improve the execution of fixed tenant-agent workloads. It observes execution rather than relying on a designer’s guess, identifies repeated question classes, proposes a cheaper mechanism for future workloads, and tests that mechanism against the required quality vector. The lower rung is promoted only if it preserves the qualities the workload requires. Drift can send the work back up the ladder. The ladder moves in both directions.

Some OS questions and services are not open-world discoveries. Signature verification, schema validation, authorization, scheduling, replay, and policy enforcement have specified semantics. A stochastic answer adds uncertainty without gaining generality. The Bitter Lesson does not require a language model to verify a signature any more than it requires one to add two integers.

The boundary can nevertheless be crossed. It is crossed when people accumulate brittle domain rules instead of allowing search and learning to discover better mechanisms; when the ladder moves only downward and cannot respond to drift; when the engineering and maintenance cost of the replacement is omitted from the cost axis; or when a current serving optimization is mistaken for a permanent fact about the Pareto frontier.

Engineering cost matters because a solver that costs more to build and maintain than it saves is not minimalist. Falling inference cost may also move the frontier. If a frontier call becomes cheaper in total than the specialized mechanism and preserves or improves the required quality, Model Minimalism chooses the frontier call. Any other answer would make frugality an aesthetic preference rather than an economically rational one.

The Bitter Lesson governs how a system discovers competence. Model Minimalism governs how economically and reliably it exercises competence once discovered. The first warns against encoding a human account of the world. The second warns against paying repeatedly to rediscover what the system can already do.

The seven design preferences that follow are consequences of the Model Minimalism rule. They are preferences rather than identities. Asynchronous work may sometimes have to be awaited, cold-path work may sometimes answer a hot-path question, and a singleton may sometimes be the only batch available. In all cases the burden remains on the more expensive arrangement.

1. A small model before a frontier model

A frontier model is the last general-purpose mechanism, not the first task-specific one.

Consider a partner agent examining a mortgage portfolio inside an Agentic Data Enclave. It must identify documents, extract fields, compare evidence with policy, find exceptions, and prepare a result for release. A frontier model may be the best mechanism for interpreting a genuinely ambiguous document. It does not follow that the same model should classify the document type, validate the output schema, detect a known identifier, or apply a rule whose terms have already been settled.

The smaller mechanism wins only after comparison on the workload’s quality vector. A task-specific classifier that is cheaper but misses the rare cases that determine credit eligibility is not cheaper in any useful sense. A model that matches the frontier model’s aggregate accuracy but abstains badly may also be unsuitable. The comparison must preserve the distinctions that matter to the action.

Once those thresholds are met, size has no residual virtue. Smaller models are generally faster and almost always cheaper to serve. They are easier to keep resident, easier to version, and easier to evaluate over the complete task distribution. If the frontier model improves no quality measure the tenant requires, calling it is pure waste.

This is an optimization problem with existing empirical support.

FrugalGPT showed that cascades across models can preserve or improve measured quality while reducing inference cost, and RouteLLM treats routing as an explicit cost-quality choice rather than a permanent attachment to one model.

WunderOS extends the comparison below the model layer. A deterministic parser, rule engine, lookup, or stored result also competes for the job. The ladder therefore begins at zero models, not at the smallest model in the catalog. It moves upward only when the next rung buys required quality.

2. A working set before a context dump

A model larger than the task requires is waste. So, too, is a context window larger than the task requires.

WunderOS treats an agent’s active context as a resident working set rather than as a transcript or a database dump. Its Virtual Memory Window selects and assembles that set. The context window is the resident set: required material is pinned, the rest is paged under a measured token budget, and references remain by which evicted material can be faulted back when the agent needs it. The agent gets the context required for this turn, not every fact that might conceivably matter to a later one.

The representation inside the window is subject to the same discipline. Wunderlog uses flat structured Pentads and Unicode operator glyphs to carry repeated meanings in fewer tokens than the equivalent prose. Glyphs compress the atoms and structured rows compress their combinations. This is the compressive concision behind the query language designed for agents: the representation remains deterministically parseable while consuming less of the context it inhabits.

Once the working set is chosen and encoded, stable material is serialized into a stable prompt prefix before volatile material. A provider prompt cache, or a KV cache where WunderOS owns the serving loop, can then reuse context already computed. A necessary new turn need not imply a complete new prefill.

The token budget does not authorize the loss of required context. Pins protect material that must remain resident, page handles make absence explicit, and the fault path restores material on reference. A smaller context wins only when it preserves the quality the workload requires.

3. Asynchronous before synchronous

The choice of mechanism settles what runs. The next question is whether the caller must wait for it. A slow operation should not own the progress of the caller merely because the implementation is convenient.

WunderOS has so far avoided asking questions that only a frontier-model API can answer. When WunderOS does own model work, the preferred arrangement is to enqueue it, record the request, continue independent work, and consume the result when it becomes available. If the next logical action depends on that result, the durable workflow suspends. The operating system does not have to hold an execution thread, an agent turn, or an unrelated task behind it.

Asynchrony earns three things at once. First, it isolates provider latency from the deterministic control path. Second, it creates a queue from which work can be scheduled and batched. Finally, it makes failure explicit: a delayed, retried, cancelled, or timed-out inference is an activity with a state, rather than an unexplained pause inside another action.

Of course this systems preference does not prohibit synchronous frontier calls by customer agents. Present-day agents rely on frontier calls for their reasoning. The agent may need the answer before it can proceed, and that dependency belongs to its program. WunderOS records and governs the call, but it does not pretend that the tenant’s reasoning step is an OS-level service.

Nor does asynchrony make an unnecessary call necessary. Moving a frontier call to a queue improves its scheduling. Replacing it with a deterministic answer removes it. The latter remains the better result when it meets the tenant’s required quality thresholds.

4. The cold path before the hot path

Asynchrony separates slow work from the caller. Path placement determines whether it delays a required action. The hot path is the sequence that determines how soon the next required action can occur. A frontier model belongs there only when the customer’s work itself requires frontier inference.

WunderOS permits two such cases. As above, a customer agent may initiate the call as part of its own execution. A tenant may also require a final frontier call at the Agentic Data Enclave’s egress gate. In both cases the call is the tenant’s computation and COGS.

WunderOS-owned inference goes to the cold path whenever the work can be done before demand, after the response, or alongside independent execution. Classification corpora can be built offline. A policy expressed in natural language can be compiled before it is applied. Summaries can be prepared when the system is idle. A model can propose a frozen artifact that a deterministic gate later reads. The common property is that stochastic latency is paid outside the path that authorizes and executes the action.

The deterministic path then has to justify its own latency. Inherently slow inference (a truism that is as unfair as it is apt) has made much of application engineering indifferent to the milliseconds around it. Agentic workflows make that indifference expensive because each task contains many steps and their latency compounds. WunderOS therefore measures both the median and the tail, builds Zig kernels for microseconds where the operation permits it, provisions hot-path memory before execution, and keeps loops and queues explicitly bounded.

Much of this discipline is adapted from systems such as TigerBeetle, which moves nonessential work off the hot path and allocates its bounded object population before entering the main loop. The point is not to imitate a financial database in every detail but to apply its same seriousness to the first deterministic component after an expensive stochastic one.

5. A batch before onesie-twosie

Asynchronous cold-path work creates the freedom to batch, and batching converts fixed boundary cost into useful throughput.

The rule applies beyond model serving. WunderOS batches across BEAM-to-Zig boundaries because a crossing has a fixed cost component that does not grow with the useful work it carries. It batches storage and network operations where the workload permits it. The same principle underlies its aggressive use of io_uring, whose shared submission and completion rings decouple the production of work from its completion and allow multiple operations to cross the kernel boundary together.

Inference has the same shape at a larger cost. Weights, accelerators, and model servers are underused when each request is admitted and completed in isolation. The vLLM work on PagedAttention begins from the fact that high-throughput model serving requires enough concurrent requests to form useful batches. A queue of cold-path work lets the serving layer choose that batch rather than accept a stream of onesie-twosie calls.

The queue does not wait without limit. A batching window trades some p50 latency for throughput and lower COGS, while its deadline protects p99. An urgent singleton runs as a singleton when waiting would move the system to a worse point on the Pareto frontier. Batch before singleton is a scheduling preference, not a ceremony.

Batching also exposes a reproducibility problem. A model server may change its numerical reduction order when the batch changes, so the same request can produce a different result under a different concurrent load. Thinking Machines Lab demonstrated this failure and the batch-invariant kernels needed to remove it.

WunderOS records production inference outputs for replay, and any model whose live re-inference is used to decide a promotion must also be tested across batch size and load. Throughput does not excuse an answer whose identity depends on which unrelated request arrived beside it.

6. The first call should make the second unnecessary

Batching reduces the fixed cost of calls that remain. Removing a later call is better still. There are three ways for one inference to remove another.

(1) Exact replay. A model call is executed once, and its inputs, model identity, parameters, and output are recorded. Replaying the workflow substitutes the recorded output rather than calling the model again. This is the distinction between re-running the workflow and asking the model to improvise its past again.

(2) Let a model produce data whose correctness is settled elsewhere. WunderOS uses this pattern in its teaching machinery. A model may supply varied surface forms for a curriculum, while a grammar supplies validity and a deterministic oracle computes the expected answers. Once the curriculum is frozen, the model has no continuing role in the gate. The first invocation did not become authoritative. It produced an artifact that a deterministic mechanism could check and reuse.

(3) Recognize a repeated class of questions. CARL, the continuous autoresearch loop in WunderOS, observes customer-agent exhaust and looks for behavior that has become stable enough to move down the ladder. A repeated frontier behavior may become a local task model. A stable learned behavior may become a low-bit model with a conformal guard. A fully settled behavior may become a deterministic WASM procedure. The point is not to cache a string. It is to learn that a family of questions now has a cheaper answer.

Zigzek, the WASM run-place in the WunderOS substrate, gives the penultimate rung its natural form. A self-hosted low-bit model can be treated as a stored procedure: content-addressed, versioned, capability-bounded, locally executed, and attached to the part of the substrate it serves. We call this form a Sprachbin. Its inference contract fixes the artifact, runtime, arithmetic, and decoding inputs so that it can be replayed and tested as part of the system. WASM is the run-place; determinism is the complete contract around it, not a property conferred by the file extension.

A proposed replacement is evaluated against the frontier behavior and available ground truth over the full quality vector. It runs in shadow before promotion, the promotion is recorded, and rollback remains available. Whether a human must approve the promotion is a TenantConfig choice. One tenant may authorize automatic promotion at a certified threshold. Another may require approval for every solver class. Closest often knows best.

The requirement is that the second call must defend its existence. If the first call has supplied a recorded answer, a checked artifact, or a certified solver, calling the frontier model again is a regression unless the workload has changed.

7. Local serving before a model API

The calls that remain should run at the closest place the operator controls.

Locality is a partial order because several advantages arrive together. A model inside the process or substrate avoids a network boundary. A model server inside the tenant’s VPC preserves data residency and provider control. Both permit the operator to pin weights, runtime, and configuration.

A remote frontier API may still provide better quality, but it begins with additional latency, variable cost, an external failure domain, and less control over the exact inference environment.

Subject to the quality test, the preferred order is:

a WunderOS-served model,
a model server in the tenant’s VPC, and
a remote model API.

COGS, latency, sovereignty, version control, replayability, and freedom from provider variance are not strictly ordered among themselves. For a regulated workload, any one of them may be decisive.

The local serving surface is becoming ordinary. Transformers.js runs models on CPU through WASM, supports quantized artifacts, permits a deployment to disable remote model loading, and allows both the models and the WASM runtime to be served from local paths (runtime, local configuration, quantization). For example, the wasmdashai/wasm-32B-Instruct-V1 model card names privacy-conscious WebAssembly edge deployment even for a 32-billion-parameter instruction model. Local WASM execution has entered the deployment vocabulary; WunderOS applies it to smaller, task-conditioned artifacts whose operating point has been measured.

Customer control remains prior to optimization. TenantConfig supports three positions. The tenant may prohibit OS interception, approve redirects only for named call classes, or trust WunderOS to redirect whenever a certified substitute is no worse on the required quality measures and cheaper on the systems axis. With no configuration, WunderOS never intercepts a customer agent’s model call.

This default is not a concession. A customer’s model call is its action and its COGS. Replacing it without cause or authority would violate the same governance rule WunderOS exists to enforce.

Status and boundaries

WunderOS is pre-release. Model Minimalism is an architectural commitment, and the components occupy different implementation states. Recorded-output replay, model-free gates, bounded Zig execution, and local task models are operative parts of the system. Automatic movement across the complete ladder, including CARL promotion and Zigzek-hosted Sprachbins, is on the near-term roadmap.

This note states the engineering standard rather than publishing a benchmark sheet before the product is ready. The standard is nevertheless concrete. Every candidate mechanism is compared on a declared quality vector, inference COGS, and p50 and p99 latency. Hot deterministic operations target microseconds where the operation permits it. On that path, allocation and concurrency are bounded. A promotion without those measurements is not a promotion.

Model Minimalism also makes no claim that frontier models are unimportant. On the contrary, they’re among humanity’s most impressive achievements. Customer agents use them because they can do work the lower rungs cannot yet do. The claim is narrower and more demanding: a frontier model should be called for that marginal capability, not as a substitute for scheduling, systems engineering, engineering discipline, or memory.

FrugalGPT and RouteLLM establish the cost-quality case for routing among models. PagedAttention establishes the systems case for batching model service. Thinking Machines Lab establishes that batching and deterministic inference must be designed together. Transformers.js establishes a practical local WASM run-place, while TigerBeetle supplies the relevant discipline for bounded, low-variance deterministic work.

Within the Pentad Labs Research Notes, Composing Determinism gives the replay foundation, Recording the Parse shows how one model contribution becomes a durable deterministic input, Extraction Before Ontology applies a deterministic-first pipeline to language processing, and PlatypusDB describes the substrate on which local solvers and stored procedures operate.

A note on method

Written in conversation with OpenAI Codex as structured interlocutor, requirements interviewer, research assistant, and prose editor. The ideas, claims, priorities, and architectural commitments are mine.