Today's Overview
- A fuzzy function no longer needs a live API call. Program-as-Weights compiles a natural-language spec straight into a local weight file. A 0.6B interpreter matches a 32B model prompted directly, at 1/50th the VRAM, with a 10M-sample FuzzyBench released alongside.
- Training-free image generation, 10x faster, 1% quality drop. MrFlow fixes the artifacts that have dogged multi-resolution acceleration. No custom kernels, stacks on existing distilled models, near-zero adoption cost.
- An agent's memory should be an auditable contract. AgenticSTS builds a clean context for each decision through typed retrieval, so any memory component can be ablated on its own.
- Denser self-distillation is easier to break, not harder. SDPO throws cold water: the denser the self-distillation signal, the larger the drift, and out-of-distribution it forgets worse than GRPO. Stop treating it as the default stabilizer for continual training.
Featured
01 One-Line Specs Compiled Into Local Weights
Compilation just moved to tasks you can describe but can't write rules for — flagging important log lines, repairing broken JSON, ranking search results by intent. That kind of work used to mean either a pile of brittle regex or a call out to a large-model API. Program-as-Weights (PAW) does it differently: a 4B "compiler" reads your natural-language spec and emits a parameter-efficient adapter, which mounts onto a frozen lightweight interpreter to run.
The results hold up. A 0.6B Qwen3 interpreter running the compiled program matches a 32B model prompted directly, at roughly 1/50th the inference VRAM, hitting 30 tokens/s on a MacBook M3. The authors also released FuzzyBench, the 10M-sample training set, so others can reproduce the compiler or train their own.
What matters here isn't another small model. It redefines the large model from a solver that runs once per input into a maker of tools — one call produces a reusable weight file, and every function call afterward is cheap, offline, and versionable. That redraws the line between what you call a large model for in real time and what you compile into a local component.
Key takeaways: - Fuzzy functions drop from "call the API every time" to "compile once into a local weight file," which comes with reproducibility and cost control for free. - The 0.6B interpreter matches a 32B model prompted directly at 1/50th the VRAM — a real option for cost-sensitive production systems. - FuzzyBench (10M samples) is open, so the bar to reproduce is low. Worth a real test if you run production pipelines.
Source: Program-as-Weights: A Programming Paradigm for Fuzzy Functions
02 Training-Free 10x Faster Image Generation, 1% Quality Loss
Multi-resolution generation is an old idea: run most sampling steps at low resolution, upscale and refine only at the end. Last year that already bought 5x training-free acceleration. The problem was that older methods upsampled in latent space and only touched local regions, so the enlarged output often came out blurry or full of artifacts. The speedup cost visible quality.
MrFlow takes a dumber but steadier path. It fixes structure fast at low resolution, runs a lightweight GAN for super-resolution in pixel space, injects low-strength noise to resample high-frequency detail, then does one high-resolution refinement pass. On FLUX.1-dev and Qwen-Image it reaches 10x end-to-end acceleration with the quality metric (OneIG) dropping under 1%. Stack it on existing step distillation and it pushes to 25x.
None of this needs training, custom kernels, or runtime decisions about which region to fix. That's what makes it easy to adopt.
Key takeaways: - Training-free, no custom kernels, stacks directly on existing distilled models — an existing inference pipeline barely changes to take it. - The old failure mode of multi-resolution speedup is post-upscale artifacts. The value here is holding quality loss under 1%, not chasing a higher speedup number. - If you run your own FLUX/Qwen-Image service and want to cut inference cost without sacrificing quality, you can try it now.
Source: Multi-Resolution Flow Matching: Training-Free Diffusion Acceleration via Staged Sampling
03 A Long-Horizon Agent's Memory Should Be an Auditable Contract
The laziest memory scheme for a long-horizon agent is to append every observation, tool call, and reflection into the prompt. You can query anything, but it's a soup — you can't tell how much any single memory component actually contributed. AgenticSTS proposes a bounded contract instead: each decision starts from a freshly assembled clean user message, selected by typed retrieval, carrying no raw history. Prompt length stops growing with the run, and any memory layer can be pulled out for ablation.
They test on Slay the Spire 2, a card game that needs hundreds of decisions per run. Turning on a triggered strategy-skill layer moved win rate from 3/10 to 6/10. The authors themselves flag this as directional — at that sample size, Fisher's test gives p≈0.37, nowhere near significant.
The number isn't the point. The contribution is turning "what should each decision see" into a design variable you can take apart and audit.
Key takeaways: - More memory isn't better. Append-everything context makes it impossible to isolate what any single component does. - Design memory as an explicit contract over "what each decision sees" and controlled ablation becomes possible. - The win-rate number is only directional (p≈0.37). The contribution is the method and a reproducible testbed, not a SOTA score.
Source: AgenticSTS: A Bounded-Memory Testbed for Long-Horizon LLM Agents
04 Denser Self-Distillation Breaks Easier in Continual Training
Intuition says on-policy self-distillation — the model uses its own output as teacher, supervising itself token by token — gets steadier as the signal grows denser. Lately it's been the default answer for fighting forgetting in continual post-training. This paper finds the opposite. Their SDPO does speed up in-domain specialization when the teacher signal is stable and well-aligned, but out of distribution it forgets worse than GRPO, sometimes collapsing outright.
The reason is the counterintuitive part. Denser self-distillation means larger drift in both parameter space and output space, and the teacher-student loop keeps amplifying high-frequency format habits like a fixed turn of phrase. Dense self-supervision isn't a free stabilizer. It pulls the model hard in one direction: acceleration when conditions are good, accelerated derailment when they aren't. Plain on-policy RL like GRPO adapts more conservatively and holds onto old capabilities better.
Key takeaways: - On-policy data alone isn't enough for continual learning. Self-distillation shouldn't be the default stabilizer. - Dense self-distillation suits in-domain specialization with a stable teacher signal. Out-of-distribution, watch closely for forgetting and collapse. - If you use self-distillation for continual post-training, compare against a more conservative baseline like GRPO.
Source: Denser ≠ Better: Limits of On-Policy Self-Distillation for Continual Post-Training
Also Worth Noting
Today's Observation
The cluster of papers today looks like a few more benchmarks. Dig down and they're pulling apart the same thing: the "run it and give me one score" paradigm in agent evaluation. It's being pried from two unrelated directions at once — one side finds it too expensive, the other too coarse.
Too expensive because the more autonomous an agent gets, the more one end-to-end eval looks like running a real task. PACE stops running it and predicts that expensive score from cheap single-capability probes instead. Too coarse because a final score flattens everything that happened in between. EvoPolicyGym wants to separate "the policy repeatedly improving itself" from software-engineering progress. SkillCoach scores every step of a skill call with a rubric. Even featured AgenticSTS shares the motive — it instruments the memory contract precisely so a single component can be isolated.
Why now? Because once agents get longer and more autonomous, the causal chain between the final result and "which step, which component mattered" stretches too far. The total score is both expensive and no longer attributable. Predict its cost or instrument its process — those become the two roads you can't avoid.
For your own work: if you still rank agents by one end-to-end win rate or pass rate, ask first whether that number can be attributed to a specific component. If it can't, pick one key link and start instrumenting it. Even a single typed log per step beats running the total score one more time.