The Inference-Time Learning Gap

etude labs is building inference endpoints for open-weight models that improve from verified usage. Customers call one API; we are building the inference, evaluation, and update-promotion system behind it.

The endpoint connects a serving model with a separately trained weight updater. Our Ballade-1 technical report demonstrates the first capability behind that product: training the updater to make better edits. In the reported experiments, post-training takes Qwen 3.8 Max from approximately 0.01 to 0.330 on IWIBench while editing Gemma 3 4B. Across three independent training seeds, scores range from 0.312 to 0.348.

Our thesis is that, for a useful class of recurring failures, learning to update model weights can be more efficient than repeatedly optimizing the serving model itself. The test is whether an update produces a verified, persistent improvement at a cost its future use can repay.

The technical result establishes improved editing capability. The business question is where those improvements can make inference more reliable and cost-effective for a customer with recurring failures.

The score above measures weight-editing performance on IWIBench; 0.330 is not a 33% production task-success rate. It establishes an improvement over the same updater before post-training within the reported setup. It does not by itself measure serving latency, cost per successful correction, or performance over a full agent run.

Introducing Ballade-1 documents the implementation and experiments. This essay connects those results to the wider literature and the inference product: what we have built, what the measurements show, and where the next comparison matters.

---

1. Where we expect to win first

Our initial customer is a team running an agent that repeatedly encounters the same costly, testable failure. The opportunity is strongest when that failure is repeatable, localized, consequential, and cheaply verifiable.

Examples include a model repeatedly using a disallowed token in a structured workflow, selecting the wrong tool under a stable condition, or failing to follow a company-specific terminology mapping. Those issues may admit a compact intervention and objective tests. A failure requiring a genuinely new algorithm or extensive domain knowledge may need conventional SFT or RL instead.

A useful production system should select among several responses to failure:

• Do nothing if the observation is noisy or does not demonstrate a stable problem.
• Change memory or context when the issue is a transient fact or readily retrievable information.
• Attempt a native direct edit when a small, targeted behavioral repair is likely and sufficiently testable.
• Use supervised training or RL when the required change spans a broad distribution or the editor repeatedly fails.
• Escalate to human review when impact or uncertainty is high.

etude's technical bet does not require direct editing to win everywhere. It requires a useful and measurable region of advantage where direct editing reaches a verified improvement earlier or with fewer resources than the alternatives.

The economic test is straightforward: a verified correction must arrive soon enough, survive long enough, and benefit enough future requests to repay its full cost. Editing fewer parameters is not a substitute for measuring that outcome.

The economics of an update

The commercial unit is dollars and seconds per accepted improvement that survives on unseen tasks. A patch can be small and still be expensive to discover, verify, and serve. Avoiding target gradients does not eliminate updater inference, unsuccessful candidates, or regression evaluation.

Candidate generation and evaluation include every attempt, including rejected patches. Failure recovery counts additional rollback and repair work, not those attempts a second time. Deployment includes checkpoint loading, cache rebuilding, routing, and incremental serving capacity. Across a workload, divide all of these costs by the number of accepted updates that still pass the durability evaluation; a run with no such updates has no finite cost per durable success.

Report the median and p95 as well as the mean. A correction that arrives after the relevant work ends has little value to that run, even if it eventually passes evaluation.

Does the correction pay for itself?

For an approximately stable workload, the break-even number of affected requests is the full update cost divided by expected net benefit per affected request. That benefit must include any extra serving cost and can come from fewer retries, fewer tool calls, or less human review. The estimate only applies while the correction remains useful—before later edits, a model replacement, or a change in the workload removes its value.

This makes recurring, verifiable failures our initial focus. A correction reused thousands of times has a different economic profile from a one-off answer. When recurrence or benefit is too low, the right decision may be memory, a batch training job, or no update.

GPU-seconds are only comparable with hardware and utilization specified. Ballade-1’s current report establishes editing performance; it does not yet report this full economic accounting.

2. Autoresearch exposes the problem—but does not define the whole market

Andrej Karpathy's autoresearch offers a simple picture of how much machine-generated feedback can accumulate during a single job. An agent edits a training program, runs a bounded experiment, evaluates the result, and keeps or discards the change. The repository describes the loop plainly: “It modifies the code, trains for 5 minutes, checks if the result improved, keeps or discards, and repeats.” [1]

The process matters more than any one benchmark number. A single session can create a dense sequence of hypotheses, outcomes, failures, and decisions. The agent's external artifacts—its code and experiment logs—improve throughout the run. But the language model selecting the next hypothesis may remain the same frozen parameter set, even after repeatedly encountering a failure mode.

That is a missed opportunity when the experience contains a reusable lesson that a parameter change could encode. Suppose a coding agent repeatedly calls the wrong tool for a particular environment, or an experimental agent reliably makes a bad choice under a recurring condition. A correction available after attempt 10 might be valuable for attempts 11 through 500, not only for tomorrow's training cycle.

The original etude thesis emphasized this temporal asymmetry: the longer a task lasts, the more chances there are for an early lesson to affect later decisions. We still think that is the right intuition. But it needs two qualifications.

First, the policy is not the entire agent. Notes, code edits, retrieved documents, scratchpads, and tool state can themselves preserve useful learning. A strong agent with memory may outperform a poorly edited model. Second, online parameter learning already exists. The comparison is not between etude and a world where every competitor waits until the end of the week.

Our broader claim is narrower and stronger: long-running agents make update latency unusually important. They provide a demanding setting in which to test whether a direct parameter update beats the best nonparametric and gradient-based alternatives at equal quality and cost.

3. What does “learning during inference” actually mean?

The phrase continual learning now covers several different mechanisms. They should not be conflated.

GRPO and LoRA are not alternatives at the same level. GRPO is an optimization algorithm. LoRA is a parameterization that allows a training procedure to update low-rank factors rather than all the weights. GRPO can be used with LoRA; supervised fine-tuning can be used with LoRA; and online adaptation can use LoRA as well.

That distinction is essential for fair experiments. “Direct editing versus LoRA” usually means direct editing versus a specified fine-tuning procedure implemented using LoRA. “Direct editing versus GRPO” means direct editing versus a specified RL objective, rollout budget, and parameter-update configuration. Without those details, comparing costs or quality is nearly meaningless.

SFT and LoRA: strong, inexpensive baselines

Hu and colleagues introduced LoRA by freezing pretrained parameters and injecting trainable low-rank matrices. Their original study reported up to a 10,000-fold reduction in the number of trainable parameters relative to full fine-tuning for one large-model setting—not a 10,000-fold reduction in total training cost. LoRA is an enormous practical improvement, and for a small target model a LoRA run may be cheap and fast [2].

A case for direct editing should therefore never be built on an artificially slow fine-tuning job. The real question is whether a targeted correction can be discovered, checked, and deployed with less total expenditure than a good online SFT/LoRA procedure, including the cost of generating its training examples.

RL and GRPO: broad improvement from verified experience

DeepSeekMath introduced Group Relative Policy Optimization (GRPO) as a PPO variant designed to improve mathematical reasoning with reduced memory overhead [3]. A policy samples candidate outputs, obtains rewards, and changes its parameters through gradient-based optimization. This is powerful precisely because it can improve a broad behavior distribution, not merely repair one lexical association.

But training from outcomes involves more than generating a single answer. It involves repeated sampled behavior, reward estimation, parameter optimization, and downstream validation. How expensive that is depends on the task, batch size, model, infrastructure, and whether deployment feedback can be reused. It is not automatically a weeks-long process.

Cursor provides a concrete counterexample to the claim that contemporary RL is necessarily slow. Its March 2026 engineering report describes production-derived rewards, evaluation gates, and improved Composer checkpoints shipping as often as every five hours. Its own account also describes reward hacking and the difficulty of training on noisy user signals [4]. That is sophisticated online learning. etude must compete with it, not dismiss it as static retraining.

In-context learning: the indispensable control

A good autoresearch agent can store a failed hypothesis in a notebook, record a tool call as a cautionary example, and retrieve it on the next relevant step. Sometimes that is sufficient, cheaper, safer, and easier to reverse than changing model weights. This baseline should be tested seriously.

Parameter updates become compelling when lessons recur frequently, memory retrieval is unreliable, context growth becomes burdensome, or a failure reflects a stable decision rule that the model systematically misapplies even when reminded. Those are hypotheses about when to edit, not universal properties of memory systems.

4. The old boundary between training and inference is already moving

Test-time learning is not new, and describing it as something only etude attempts would be inaccurate.

The In-Place Test-Time Training paper, published at ICLR 2026, adapts MLP projection weights while processing a sequence, with objectives aligned to language modeling. Its authors report benefits on long-context tasks and explicitly position it as a way to endow existing LLMs with test-time adaptation [5]. NVIDIA's technical discussion of TTT-E2E likewise describes compressing incoming context into weights through next-token prediction [6]. These are gradient-based or model-architecture-specific test-time mechanisms, not a second LLM reasoning about targeted native patches.

A more direct challenge to our original “between-session learning” framing comes from No Time Like the Present: Agentic Test-Time Training for LLM Agents (July 2026). It studies updates inside active, multi-turn episodes, uses concurrent serving with runtime LoRA, and reports improvements of up to 5.0 points on ALFWorld and 4.9 points on SWE-bench Lite, with up to 1.9× the no-TTT cost in its tested setup [7]. The paper also shows how repeatedly training on redundant trajectory text can cause drift.

ASCENT: persistent online learning is already a baseline

ASCENT (October 2026) takes another route: it turns verified trajectories into persistent LoRA updates across a stream of agent tasks, with a frozen copy of the model supplying hindsight distributions. Its authors report improvement on ALFWorld, WebShop, and AppWorld [8]. That matters because even single-attempt verified experience can sometimes support online learning with gradients.

Our comparison must therefore be against a capable online learner, not only periodic offline training. The question is whether direct edits reach a given quality sooner, with less feedback or lower total cost. Persistent parameter learning alone is not our distinction.

The correct state-of-the-art observation is therefore:

Online learning can already alter a model's behavior and parameters during deployment. The open question is whether a learned direct-weight editor offers a better update mechanism for some important class of failures.

This is a better competitive thesis. It recognizes the strength of existing methods while identifying the additional capability etude wants to develop.

5. What changed in November 2026: direct weight editing became harder to dismiss

The strongest recent evidence is not that all model adaptation can dispense with gradients. It is that highly capable models can sometimes identify and manipulate the numerical parameters of another network to produce a durable behavioral correction.

The MIT result: a spectacular localized repair, not a general math-training result

In Sparks of Weight-Space Programming (November 2, 2026), Takehi, Teoh, Zhang, and Khattab report a frontier model inspecting and directly modifying other neural networks [9]. One widely discussed experiment targeted Qwen3.5-0.8B, which was spending much of its generation budget in reasoning loops. The editor changed approximately 0.016% of the target's parameters. With the reported 50-forward-pass intervention, the authors measured:

These changes are striking. But the mechanism matters: the intervention removed a debilitating looping behavior, allowing latent competence to appear. The authors explicitly distinguish fixing a bottleneck from teaching an absent capability; they also report failing to improve the smaller Gemma 3 270M math model with the same general strategy [9]. A rigorous replication should compare against disabling thinking, alternative decoding configurations, small targeted steering edits, and a matched LoRA update—rather than interpreting a dramatic benchmark gain as general-purpose learning.

Still, this result makes a serious research question possible: can a model learn, rather than merely discover ad hoc, which small parameter changes remove a target model's recurring failure modes?

IWIBench: the capability is real, highly uneven, and measurable

IWIBench (November 2026) formalizes gradient-free edits. An editor accesses a smaller target, typically Gemma 3 4B IT, through bounded reading, writing, inspection, and generation tools. Patches are applied in a fresh process. Evaluation asks whether the requested behavior persists while the target retains previously correct behavior [10]. The authors released a qualified set of 1,000 tasks—850 training and 150 test tasks, specific to a pinned Gemma 3 4B model [11].

In the 30-episode published evaluation, the pristine target got 104 of 551 target items correct. GPT-6.1 Sol at medium reasoning reached 284 of 551, and its combined equal-family reward was 0.4601. GPT-6 Astra's reward was 0.4356; GPT-6.1 Terra scored 0.2928; GLM 5.3 scored 0.0135. The large gap suggests that useful native editing is an unusual, task-sensitive capability—not yet a commodity tool available in every open model [10].

Equally important are the failures. The authors found no positive results for structured-response defaults in the selected configurations. Performance varied sharply across alias acquisition, response recoding, factual edits, inhibition, and other families. More reasoning effort did not yield a monotonic gain: GPT-6.1 Sol's macro reward went from 0.4250 (low) to 0.4601 (medium), then 0.4551 (high), at substantially higher reasoning-token usage [10].

That is an argument for specialized training, not proof that it will succeed. A useful learned editor might improve technique selection, patch sizing, diagnostic testing, and the decision to abstain when the failure is not safely editable. But the data also warns that transfer across edit families is hard.

Replications and adjacent systems narrow the novelty claim

Other very recent studies have already pushed beyond the initial MIT experiment. Exploring Weight-Space Programming reports large but inconsistent gains across 16 editing trajectories and multiple Qwen model sizes; six trajectories retained the original weights because suitable improvements could not be validated [12]. A separate audit argues that apparent weight-reading success can depend heavily on known dataset priors, rather than deep reconstruction of hidden network computations [13].

WeightLoop (November 2026) is particularly relevant. It uses a frontier model to write a reusable editing program and then incorporates sequential experimental feedback into the weights of a deployed predictor. In offline replay, it reports improvements in seven of eight endpoint-budget settings compared with baseline comparisons, while holding the editor itself fixed [14]. This is a close conceptual neighbor, not something we can ignore.

The thesis therefore must not be “nobody has ever used an AI to change another model's weights.” That was already false in 2026. The differentiating hypothesis is that an editor can itself be systematically post-trained to generate reliable, generalizable, and economically favorable direct updates, then operated as part of a multi-tenant inference product.

6. From model editing to an optimizer that learns

The intellectual lineage predates 2026. ROME showed how targeted feed-forward weight interventions could change factual associations [15]. MEMIT scaled direct editing to thousands of factual associations in specific larger models [16]. MEND introduced auxiliary editing networks that learned transformations of gradients to make targeted changes efficiently [17]. These systems demonstrated that model editing is not identical to full fine-tuning and that the editing algorithm itself can be learned or engineered.

Parametric Skills: generating parameters is not unique

Parametric Skills (June 2026) is a particularly strong modern adjacent idea: it trains a hypernetwork to turn text-based skills into LoRA adapters at test time and reports advantages over in-context skill use on software-engineering subtasks [18]. The difference from etude's intended approach is one of representation, action space, and training objective—not the simple fact that a separate network can generate parameters.

For this alternative, compare the feedback preparation, parameter-generation cost, held-out quality, and adapter-serving cost with the full direct-edit path. Ballade-1’s current benchmark does not establish superiority over that system.

Self-Adapting Language Models (SEAL) offers a related training recipe. The model generates update instructions or training material, and its outer learning loop evaluates “the downstream performance of the updated model as the reward signal.” [19] SEAL's inner adaptation uses gradient-based supervised fine-tuning; etude's direct-editing hypothesis seeks native target-weight changes without a target-gradient step for each correction.

There are therefore three distinct questions:

1. Can parameters be edited? Prior work and IWIBench demonstrate that, on selected tasks, yes.
2. Can an editor be trained to edit better? Ballade-1 provides evidence in our bounded editing setup: the post-trained updater scores 0.330 versus approximately 0.01 before training. Generalization to broader patch types and other targets remains a separate question.
3. Can such an editor improve production agents at a better quality-cost-latency point than online training or strong memory? That is the product question, and literature results do not answer it for etude.

The third question is the one that makes a research capability worth selling through inference.

7. What we built: two models, two learning loops

Ballade-1 implements two model roles: Qwen 3.8 Max is the updater, and Gemma 3 4B is the target. The inference product builds on this separation. A serving model produces responses and tool actions for the customer's agents. A separate weight-updating model examines trusted failures, feedback, and bounded target-model state, then proposes a change to the serving model's parameters.

This architecture has two feedback loops that should not be confused.

The deployment loop uses the updater as an inference-time optimizer. For a target with parameters θ, feedback e, and a learned updater with parameters φ, the updater proposes a bounded edit:

Proposed edit: Δθ = Uφ(e, θ, tools). Updated target: θ′ = θ + Δθ.

The system then evaluates θ′ in an isolated copy of the target. Only edits that meet predeclared quality, retention, safety, and cost gates can be promoted. A production implementation can switch a stable API route to a new version between requests or agent turns. This is test-time improvement of the served model, but it need not mean mutating tensor memory in the middle of token generation.

The updater-training loop improves φ, not θ, through separate supervised or reinforcement-learning jobs. Ballade-1 uses 2,000 successful edit traces for supervised bootstrap, then group-relative reinforcement learning on 1,000 training tasks. The updater uses rank-32 adapters; the target receives bounded row edits, with no target backpropagation. Its training reward is:

Candidate reward = clipped log error ratio − λ × retention loss − μ × normalized cost.

Here the feedback evaluation set is an evaluation set used for training rewards—not the locked final benchmark. The reward should also support abstention: if no candidate patch passes a minimum standard, doing nothing is the correct action. Repeated evaluations on the same examples can overfit those examples, so independently generated holdouts and unseen task families remain essential.

In practice, direct edits can be proposed after a tool call, between agent turns, or after a task finishes, depending on available verification and latency. Updates that alter a shared model's behavior should be tenant-isolated by default. One company's proprietary customer feedback must not silently modify the shared model used by an unrelated customer.

The customer product is a stable inference endpoint. The trained updater works behind it, alongside conventional post-training and evaluation, to turn verified feedback into useful changes.

8. The experiments so far

Ballade-1 reports a trained editor, a held-out benchmark, three training seeds, and a comparison of reward functions. These measurements answer several of the questions that originally motivated the work.

The updater improves during training

After supervised bootstrap, mean log-gain reward rises from 0.06 to 0.27 over 500 training steps. Retention on originally correct controls moves from 99.7% to 99.2%. Read these together: the updater learns to produce more useful changes, with a small decline in measured retention.

This is a training-task curve averaged over seeds, not a production learning curve. The held-out IWIBench comparison at the start of this article is the separate benchmark result.

The reward comparison is already measured

Under identical reported training budgets, normalizing improvement by the remaining errors raises the benchmark score from 0.300 to 0.325. The logarithmic form reaches 0.330.

A single edit on unseen queries

The report also gives a held-out example: one patch takes the target from 8/40 correct to 28/40 correct (20% to 70%), retaining 256/256 originally correct controls. That removes 62.5% of the remaining errors on this task. It is one worked example, not an average across tasks.

What the current report lets us compare

The report specifies 1,000 training tasks, 200 separate development tasks, a locked benchmark, and three training seeds. It lists 32,000 candidate edits per seed and the per-candidate query budgets. Those are useful reproducibility details, but candidate counts are not measured compute costs.

The before/after benchmark scores are aggregate rewards, not raw success counts. The report does not provide the full per-task outcome distribution, an exact benchmark task manifest, or measured wall-clock and dollar costs for each comparator. Until those artifacts are available, we use the absolute reported scores rather than an exact multiplicative improvement claim. The 8/40 → 28/40 example is not the denominator for the aggregate benchmark.

Where the evidence stops

The present results support training a useful updater within a bounded action space: copying, scaling, and interpolating at most 32 rows of the target’s tied embedding/output matrix. They do not establish that arbitrary model failures are editable.

The next product comparison is end-to-end: a frozen model with strong memory, online fine-tuning, and gated direct edits on the same agent workload. The quantities that matter are time to a verified correction, total cost including rejected candidates and evaluation, and retention after sequential updates. The current report does not contain that comparison or a measured long-horizon agent learning curve.

The comparison that establishes product value

Use one pinned 4B-class target, the same feedback stream, the same held-out queries, and identical preservation rules. Compare four arms: a frozen model with strong memory; online supervised fine-tuning with adapters; reward-based adapter training where the task supports it; and the learned direct editor. Allocate tuning budgets fairly and include data preparation, failed attempts, evaluation, and promotion for every arm.

Evaluate both fixed total compute and fixed target quality. Report held-out performance versus cumulative compute, plus retention of earlier gains versus accepted-update count. Those plots need measured traces; the current score and training charts cannot stand in for them. Finally, test whether corrections improve later decisions within a long-running agent task under equal total budgets.

9. What would change our interpretation

The benchmark result is a starting point. These are the failure modes that would limit its value in a serving product:

Memory wins. A strong notes-and-retrieval baseline prevents the relevant mistakes at lower cost than edits. Then the market for direct edits is smaller or more specialized than expected.

LoRA is cheaper end-to-end. After counting editor tokens, search, verification, and serving overhead, online SFT or GRPO reaches the same quality faster or at lower total cost. Then the editing product must target another niche, or the economics need a much stronger updater.

The updater memorizes task templates. Gains disappear on new edit families, model checkpoints, or task parameterizations. Then the trained model learned recipes rather than general editing competence.

Reliability has to survive repeated edits

Gupta, Rao, and Anumanchipalli’s ACL 2024 study found gradual and catastrophic forgetting under sequential ROME and MEMIT edits [20]. That is evidence about those methods, not a measured failure of Ballade-1, but it makes single-edit retention insufficient evidence of continual learning.

Anand’s 2026 preprint reports degraded evidence arbitration after sequential editing even when a conventional accuracy metric remains stable [21]. Retention tests should therefore include whether the model trusts relevant evidence, rejects misleading retrieved material, and knows when to abstain—not just whether familiar answers remain correct.

He and colleagues’ knowledge-editing benchmark finds selective contextual reasoning stronger than the tested parameter-editing methods in their evaluation [22]. This supports a serious memory-and-context baseline; it does not establish how Ballade-1 would perform under the same conditions.

Updates interfere. Ten local fixes look good independently but degrade global competence after sequential application. Then update scheduling, consolidation, revertability, and cumulative regression checks are first-order research challenges.

The evaluator is easy to exploit. A patch improves the reward while making real user tasks worse, or unsafe feedback poisons the shared model. Then the system is unfit for automatic deployment even if benchmark scores rise.

Model replacement erases gains. Customer changes to a new open-weight base model and the edits no longer transfer. Then etude needs a persistent store of verified failure cases and a way to re-derive changes on the new base; patch files alone are not sufficient.

The training gain does not transfer. Ballade-1 improves over its pretrained baseline on the reported benchmark. If that improvement disappears on new target models or customer workloads, the result remains specific to the current editing setup.

These outcomes determine where direct edits belong within our inference service. The product remains a stable endpoint; the choice of update mechanism should follow the evidence.

10. Safety, privacy, and operational realities

Any product that allows production feedback to induce weight changes creates an unusually serious attack surface. A malicious actor might craft examples that appear to be corrections but are actually attempts to insert a backdoor, induce a refusal failure, or degrade a competitor's workflow. Reward hacking can produce the same result without an adversary: the editor learns to satisfy the narrow verifier while breaking unmeasured behavior.

For that reason, the safety loop is part of the definition of the product, not a later compliance feature. A plausible deployment system requires immutable versioned checkpoints, isolated trial copies, trusted provenance for feedback, frozen acceptance rules, broad regression tests, audit logs, rollback, and tenant isolation. Editing privileges should be separated from the public inference API. Sensitive customer traces should be retained only under explicit agreements, and improvements derived from one tenant should not silently propagate into another tenant's model.

A production operator also needs to handle conflicting updates. The same task may produce inconsistent feedback across users, and a fresh edit may invalidate an earlier one. This means a working updater must reason not only about how to change weights but also about when not to.

There is a further operational distinction between a generated native patch and a trainable LoRA adapter. Online serving systems already support some dynamic adapters; arbitrary modifications to dense model weights may require an isolated patched checkpoint and a controlled worker swap. The stable API endpoint can stay the same even if the underlying weights change only between requests.

One endpoint does not require one dedicated updater

The serving architecture we are targeting separates response generation from asynchronous editing. Trusted feedback enters an update queue; a shared updater proposes a tenant-scoped patch; isolated workers evaluate it; a version router promotes a passing checkpoint between requests. The previous version remains available for rollback. Logical pairing of a serving model and an updater does not require a continuously resident updater beside every customer endpoint.

This is an architecture direction, not a production-throughput result in the Ballade-1 report. Shared updater capacity can reduce idle compute, but it adds queueing. Specialized target versions still consume memory and may fragment batching. The economic accounting must include that residency and routing cost.

Serving runtimes also impose coordination costs. SGLang, for example, documents pause/retract modes that allow cache flushing before weights change, followed by recomputation when generation resumes [23]. This illustrates why a small patch is not automatically a cheap deployment; it is not a claim that this repository establishes etude’s serving stack.

Compare in-memory patching with loading versioned checkpoints under live request load. Include throughput loss, cache rebuilds, p95 time to promotion, rollback time, and extra resident model copies. Tenant-derived weights and feedback need explicit access and ownership boundaries; a shared updater must not silently propagate one customer’s changes into another customer’s model.

11. From a trained editor to an inference product

Ballade-1 shows that training improves the updater’s editing capability in the reported setup. That gives us a concrete starting point. The company depends on three narrower bets:

• Recurrence creates value. A correction is useful across enough future requests to repay its full cost.
• A learned updater can win on selected failures. For those corrections, it reaches verified quality with less feedback, compute, or delay than the strongest practical alternatives.
• The service removes operational work. Customers keep calling the same endpoint while evaluation, checkpoint promotion, and rollback happen behind it.

The next decisive result is a customer workload with recurring failures and a measurable cost when they occur. On that workload, compare the editor with online training and strong memory using the same target, feedback, and evaluation rules. Measure time to a verified improvement, compute per useful update, held-out quality, and retention after repeated edits.

A benchmark gain is evidence of capability, not evidence of customer demand or an economic advantage. Those require a design partner’s workload and measured outcomes. Autoresearch remains a compelling demonstration: a correction made early in a long run should improve later decisions enough to justify its overhead.

We are building an inference service that turns recurring failures into durable improvements—when the improvement is worth its cost.

That is the bridge between the two posts: Ballade-1 reports what we have trained; this thesis explains where that capability could earn its place in production.

Bring us a recurring agent failure ↗

---

References and research notes

This article draws on peer-reviewed work, preprints, engineering reports, and primary research blogs. Publication status differs across sources. etude measurements in the opening chart and Section 8 come from Introducing Ballade-1. Literature measurements elsewhere are attributed to their respective sources.

1. Andrej Karpathy. autoresearch project and README. March 2026. Source ↗
2. Hu et al. “LoRA: Low-Rank Adaptation of Large Language Models.” 2021. Source ↗
3. Shao et al. “DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models.” 2024. Source ↗
4. Cursor Engineering. “Improving Composer through real-time RL.” March 26, 2026. Source ↗
5. In-Place Test-Time Training. ICLR 2026 paper. Source ↗
6. NVIDIA / Sun and Choi. “Reimagining LLM Memory: Using Context as Training Data Unlocks Models That Learn at Test-Time.” January 9, 2026. Source ↗
7. Wang et al. “No Time Like the Present: Agentic Test-Time Training for LLM Agents.” July 2026, preprint. Source ↗
8. Lu and Gong. “ASCENT: Online Test-Time Training of Long-Horizon Agents via Self-Distillation of Verified Experience.” October 2026, preprint. Source ↗
9. Takehi, Teoh, Zhang, Khattab. “Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights.” MIT CSAIL research blog, November 2, 2026. Source ↗
10. von Csefalvay et al. “IWIBench: Evaluating Gradient-Free Model Driven Intra-weight Injection.” November 2026, preprint. Source ↗
11. IWIBench dataset. Qualified task catalogue and benchmark metadata. Source ↗
12. Hu et al. “Exploring Weight-Space Programming: Capabilities, Generalization, and Limitations.” November 2026, preprint. Source ↗
13. Ahmed. “Can an LLM Actually Reason and Program about Neural Network's Weights or is it just memorization on steroids?” November 2026, preprint. Source ↗
14. Li et al. “WeightLoop: Weight-Space Programming with Experimental Feedback.” November 2026, preprint. Source ↗
15. Meng et al. “Locating and Editing Factual Associations in GPT” (ROME). NeurIPS 2022. Source ↗
16. Meng et al. “Mass-Editing Memory in a Transformer” (MEMIT). ICLR 2023. Source ↗
17. Mitchell et al. “Fast Model Editing at Scale” (MEND). ICLR 2022. Source ↗
18. Zhao et al. “Parametric Skills.” June 2026, preprint. Source ↗
19. Zweiger et al. “Self-Adapting Language Models” (SEAL). NeurIPS 2025. Source ↗
20. Gupta, Rao, and Anumanchipalli. “Model Editing at Scale leads to Gradual and Catastrophic Forgetting.” Findings of ACL, 2024. Source ↗
21. Anand. “Sequential knowledge editing breaks a model’s ability to tell good evidence from bad, without costing it accuracy.” 2026, preprint. Source ↗
22. He et al. “Benchmarking and Rethinking Knowledge Editing for Large Language Models.” 2025, preprint. Source ↗
23. SGLang. Generation pause/resume contract and cache handling in the serving runtime. Living source documentation, consulted November 10, 2026. Source ↗

Research cutoff: November 10, 2026. Technical claims and commercial comparisons should be updated as newer benchmarks or independent replications become available.