Macaron-V1: Towards Open Continual Learning with Self-Improvement and Mixture-of-LoRA

Mind Lab, Vin Bo, Asher Cai, Jingwei Cao, Song Cao, Vic Cao, Amelia Chen, Andrew Chen, Kaijie Chen, Cleon Cheng, Steven Chiang, Kaixuan Fan, Hera Feng, Huan Feng, Arthur Fu, Jun Gao, Pyke Han, Nolan Ho, Ori Hong, Hailee Hou, Piers Hua, Charles Huang, Miles Jiang, Nora Jiang, Yuyi Jiang, Qiuyu Jin, Fancy Kong, Kuss Koo, Jaron Lee, Andrew Lei, Alexy Li, Dawn Li, Lucian Li, Ray Li, Ricardo Li, Smith Li, Theo Li, Allen Lin, Elliot Lin, Fan Lin, Chen Ling, Kairus Liu, Kieran Liu, Logan Liu, Neo Liu, Xiang Liu, Yuxin Lu, Maeve Luo, Pony Ma, Verity Niu, Cole Qiao, Guian Qiu, Vince Qu, Sentry, Niko Song, Vincent Wang, Bo Wu, Rio Yang, Evelyn Ye, Fiona Ye

Macaron-V1 uses a frozen base model with modular LoRA specialists and a co-designed agent harness to enable recursive self-improvement.

How can we achieve open-ended continual learning in LLMs by keeping a base model frozen and dynamically composing specialist LoRA adapters?

Agent models are typically trained on static datasets and shipped as fixed snapshots, leaving them unable to systematically learn from post-deployment experience or adapt to evolving user needs. Macaron-V1 addresses this by decoupling the base model from task-specific capabilities: it uses a frozen base with a "Mixture of LoRA" (MoL) architecture, where specialist adapters are selected per turn by a routing layer and composed through a versioned, executable agent harness. This system enables recursive self-improvement, where the model-harness pair generates and audits its own trajectories to drive future updates to specialist adapters and configuration protocols.

Paper Primer

The MoL architecture treats adapter selection as a first-class, observable action rather than a hidden internal mixer. A routing adapter (L0) classifies each user turn into one of four specialist domains—Chat, Agent, Coding, or GenUI—and the system reconstructs a deterministic "own-view" for the chosen specialist, ensuring continuity without leaking private state between adapters.

The harness is a co-designed optimization target, not just a wrapper. It includes UI4A for component-native generative UI and a REPL-based agent harness that allows the model to compose and validate reusable tools, effectively moving computation from the model's text output into the runtime environment.

MoL significantly reduces stored parameter overhead compared to replicated-base deployments.

By keeping a single base model resident and layering four LoRA specialists, the system stores approximately 774.8B logical parameters, a 74% reduction compared to the 2.976T parameters required by a replicated-base layout.

The routing mechanism achieves high accuracy on production-representative traces.

On a 6,448-sample trace, the L0 router reached 99.12% accuracy on the flagship Venti model, with zero request or parse errors.

Why use a frozen base model instead of fine-tuning the entire system for new tasks?

A frozen base prevents cross-task interference and weight drift, allowing new capabilities to be added by training and registering modular adapters without retraining the base or overwriting prior knowledge.

What is the primary trade-off of the MoL routing and summary hops?

Routing and summary hops add latency, accounting for approximately 32% of the total three-hop execution time (0.54s for routing and 0.97s for summary on the Venti model).

The Case for Modular Continual Learning

We expose why static post‑training limits agents and propose a modular adapter route to continual skill growth.

Post‑training has driven recent leaps in tool use and coding, but its effectiveness is tightly bound to the training environment. When deployment conditions shift—new tools, users, or interaction histories appear—the static model quickly becomes mismatched, approximating a fixed optimum rather than genuine intelligence.

A monolithic model is a single, frozen parameter set that must be retrained wholesale whenever any new capability is required.

Macaron‑V1 replaces that monolithic update pattern with a Mixture of LoRA (MoL) architecture: a large frozen base model is kept static while a small set of specialist LoRA adapters are dynamically routed per user turn. This modular design enables efficient, continual skill acquisition without retraining the base.

Two complementary dimensions shape experiential intelligence. Adaptation is realized through recursive self‑improvement (RSI): successive model‑harness pairs generate experience, which is audited and fed back to train new adapters. Collaboration is realized through MoL’s specialist composition: a frozen base plus interchangeable LoRA adapters are selected per turn, keeping specialists separable and composable.

We contribute a modular Mixture of LoRA architecture, a model‑harness co‑design with the Harness Context Protocol, and an open‑source infrastructure (MinT, LongStraw) that together support personal‑intelligence benchmarks (Macaron ChatBench, LivingBench) and a suite of evaluation tracks.

The shift from monolithic post‑training to modular adapter‑based scaling is the core lever enabling continual, experience‑driven improvement.

Mixture of LoRA Architecture

MoL swaps a frozen base for lightweight specialist adapters, enabling cheap continual skill addition.

Training a single monolithic model to handle chat, tool‑use, coding, and UI generation creates cross‑task interference; the system must keep those skill sets separate without re‑training the entire backbone.

MoL treats the frozen base model as a power outlet and each specialist LoRA as a plug that can be hot‑swapped per turn — the core stays unchanged while the plug determines the skill that runs.

Compute $A B^\top$: multiply $A$ (4 × 2) by $B^\top$ (2 × 4) → a 4 × 4 matrix.

Scale the result by $\alpha$ = 4 → each entry multiplied by 4.

Add $ΔW$ to the frozen weight matrix $W_{\text{base}}$ for the target module.

During inference the forward pass uses $W_{\text{base}} + ΔW$ without touching $W_{\text{base}}$.

The low‑rank factorization keeps the adapter tiny (16 params) while still being able to shift the base’s behavior in the targeted subspace.

How does Mixture of LoRA differ from a classic Mixture‑of‑Experts (MoE) model?

MoE trains many expert sub‑networks inside the backbone and routes tokens to them at the layer level, incurring per‑token routing overhead. MoL keeps the backbone frozen and routes whole user turns to a single LoRA plug‑in, so the routing decision is made once per turn and the cheap LoRA update is applied globally, not per token.

The design principle codifies this separation: “Cluster tasks that share skills into one LoRA, and keep tasks whose skills diverge sharply in separate LoRAs.” This yields two crucial properties— a frozen base that never forgets, and portable adapters that any team can drop in.

Think of the four adapters as dedicated tool‑kits: L0 handles generic conversation, L1 handles long‑horizon tool use, L2 handles code generation, and L3 handles UI rendering.

**Figure 2.** Three ways to scale model capability. Mixture-of-Experts (MoE) scales the base itself; skills scale scaffolding around a fixed model; MoL (Mixture of LoRA) keeps the base frozen and composes specialist LoRA adapters through a Proxy-mediated routing loop. This separation is an implementation substrate for our continual-learning and collective-intelligence goals; the diagram is not a controlled comparison of the three alternatives.

The routing loop proceeds in three deterministic stages. First, L0 classifies the user request into one of the four canonical labels under a 24‑token constrained decode. Second, the selected specialist generates its answer. Third, the specialist emits a 192‑token summary that the Proxy stores for future turns.

Measured on mixed‑domain conversations (48 requests, temperature 0), the per‑hop timings are:

Macaron‑V1‑Venti: Route 0.54 s, Answer 3.17 s, Summary 0.97 s (total 4.68 s, routing + summary ≈ 32 % of time). Macaron‑V1‑Tall: Route 0.20 s, Answer 1.24 s, Summary 0.32 s (total 1.76 s, same proportion).

Routing accuracy on a 6,448‑sample trace reaches 99.12 % (Venti) and 99.04 % (Tall), with perfect canonical‑label compliance and zero parse errors. Per‑class accuracy ranges from 97.1 % (L1) to 100 % (L2).

Each specialist sees its own full history plus a single‑sentence summary of every other specialist’s past turns — like a personal notebook that records only the headlines of colleagues’ work.

Turn 1 (L0): full user message + L0 assistant reply are stored verbatim.

Proxy creates L0 summary “Chat handled request #1” (192 tokens) and stores it.

Turn 2 (L2): user message is appended; L0’s summary is inserted as a single assistant message; L2’s own prior turns (none) are absent.

L2 generates its answer using the prefix “Chat summary + new user message”.

After L2’s answer, a new summary “Coding handled request #2” is stored for future turns.

The prefix seen by L2 is identical each time L2 re‑enters after any number of intervening adapters, so the KV cache hits on the shared prefix and only the newly appended tail incurs compute.

Short‑circuits further reduce overhead: if a tool call finishes the answer stage, the subsequent tool‑result turn stays on the same adapter, skipping both routing and summary hops.

Deployment and KV Cache Reuse

Efficient KV reuse lets many specialists share a single model without exploding memory.

Deploying many LoRA specialists on a single model creates a KV‑cache bottleneck: each specialist would otherwise allocate its own large cache, blowing up memory. The MoL design solves this by reusing prefixes across adapters, keeping the cache footprint modest while preserving per‑adapter context.

Think of a writer who saves a draft paragraph and later continues writing from that exact point—each new specialist picks up the saved draft instead of re‑typing the same sentences.

Adapter A’s KV cache after token 3: entries for positions 1, 2, 3.

When the router (L0) processes the request, it generates the same first 3 tokens, producing an identical KV prefix.

Adapter B receives the request; it discards router‑only tokens 4‑5, reuses the KV prefix for positions 1‑3, and only computes KV entries for its own new tokens 4‑5.

The shared prefix saves 3 KV entries per turn, reducing memory by 3 × `size_of_entry`.

Reusing the contiguous prefix eliminates duplicate KV storage while keeping each specialist’s later tokens independent.

How does KV Cache Reuse differ from naïvely sharing the entire KV cache across adapters?

Naïve sharing would allow any adapter to read/write arbitrary KV slots, breaking the isolation of each specialist’s context. KV Cache Reuse only shares the contiguous prefix that is identical for all adapters; the adapter‑specific suffix remains private, preserving correctness.

The deployment study asks how much memory MoL saves compared with a replicated‑base layout where each specialist lives in its own copy of the base model.

Long‑context execution on eight B300 GPUs shows TTFT dropping from 107.1 s to 49.2 s at 900 K tokens, while mean TPOT stays under 20 ms and throughput reaches 757 tokens/s at concurrency 16, demonstrating that MoL makes massive context feasible.

Model-Harness Co-design and RSI

Describes the harness design and the recursive self‑improvement loop that co‑optimizes model and harness.

Training and serving diverge when the harness that mediates model actions differs between phases, inflating token cost and breaking reproducibility. Macaron‑V1 treats the harness as a first‑class training target, closing the gap at its source.

Instead of sending every intermediate as text, the model emits ordinary frontend code that runs directly, letting the harness enforce boundaries while the base model does most of the work.

Step 1: Model generates full HTML markup → 1,224 tokens.

Step 2: Model generates UI4A component code → 672 tokens.

Step 3: Token reduction = 1,224 − 672 = 552 tokens (≈45 % fewer).

The reduction comes from avoiding verbose markup and leveraging reusable components, directly cutting the token budget.

How does UI4A differ from the traditional HTML‑native approach?

HTML‑native forces the model to serialize full markup, CSS, and scripts each turn, whereas UI4A lets the model output concise component imports and state logic that the runtime expands, so the model only writes the high‑level structure.

A stateful read‑eval‑print loop keeps intermediate values as live variables, so a chain of dependent tool calls resolves in a single turn without re‑encoding each result as text.

Step 1: `fetch_price` stores its result in variable `price`.

Step 2: `compute_tax` reads `price`, stores `tax`.

Step 3: `total` computes `price + tax` using the existing variables.

Step 4: Only one observation (the final `total`) is sent back to the model.

Persisting variables eliminates the need to re‑describe intermediate results as text, cutting token usage and latency.

Why isn’t a discrete JSON‑tool‑per‑turn substrate sufficient for this workflow?

Discrete JSON forces each intermediate to be serialized and sent back, incurring an extra model call per dependency; the REPL keeps them in memory, collapsing the chain into a single model interaction.

HCP is a versioned TOML contract that captures the entire runtime configuration so the same harness can be recreated exactly for training and serving.

If HCP contains no gradients, how does it participate in learning?

The model doesn’t back‑propagate through HCP; instead it generates edited TOML proposals that are evaluated, and successful edits become new HCP artifacts used in the next RSI iteration.

The model proposes tasks, executes them in the harness, evaluates the outcomes, and uses the resulting trajectories to improve both its adapters and the harness configuration, iterating this cycle repeatedly.

What prevents the RSI loop from diverging when the model proposes overly ambitious tasks?

The harness contract and validation steps filter out tasks that exceed current capabilities, and only successful trajectories are fed back, keeping the loop grounded.

**Figure 3.** Three approaches to generative UI. HTML-native maximizes expressiveness but inherits raw web development's failure modes; schema-native is verifiable but capped by the component catalog; UI4A (component-native) lets the model write ordinary frontend code under runtime-enforced boundaries, recovering expressiveness without the schema ceiling.

**Figure 5. Executable composition.** Under function calling (left), each intermediate observation returns through the model as text: one round-trip per dependency step. In the REPL (right), dependent values persist in executable state (orders, net), so the same chain resolves in a single round-trip. Arrow thickness is observation size.

**Figure 6** The three loops that share one harness. **MindForge** runs RL rollouts against the same agent harness used for production serving; an HCP contract serializes the harness context (router, memory, resources, prompts, and tool-call tokens) so training and serving configurations can be compared explicitly. Matching the recorded contract makes configuration drift auditable but does not guarantee behaviorally identical executions.

**Figure 4.** A slice of the UI4A-Bench gallery. Each card is generated as ordinary frontend code under runtime-enforced boundaries; UI4A-Bench scores them on compile/render correctness, control wiring, and screen fit. The L3 specialist decides *when* to render; the substrate carries *how*.

Optimization and Configuration Search

The section details the three‑stage RSI loop that isolates task discovery, execution, and LoRA update.

The RSI mechanism separates what changes the frozen base from what tweaks the surrounding harness. This separation prevents weight updates from entangling with configuration tweaks, making it possible to attribute gains to either path.

The loop isolates three responsibilities: (1) propose new tasks, (2) evaluate them under a fixed model‑HCP pair, and (3) distill successful behavior into LoRA adapters while keeping the base frozen.

How does this three‑stage RSI differ from standard curriculum learning?

Curriculum learning typically adjusts the data distribution while keeping the model weights mutable. Here the model weights stay frozen during task generation and evaluation; only the harness configuration (c) changes in Discovery/Expansion, and LoRA adapters are updated separately in the Update stage. This strict separation lets us attribute improvements to configuration edits versus adapter learning.

Discovery: the model evaluates t₁–t₄ and flags t₂ and t₄ as unsolved (quality = high, learning value = high).

Expansion: run t₂ and t₄, obtain scores 0.3 and 0.7; audit reveals t₂ fails due to missing tool exposure, t₄ fails because of a contradictory instruction.

Update: select the successful trajectory from t₄, feed it to GRPO, which updates the LoRA adapter weights while leaving the base frozen.

Register the new HCP that adds the missing tool for t₂ and resolves the contradiction for t₄.

This example shows how the three stages keep weight updates isolated from configuration changes, enabling clear attribution of any performance gain.

**Figure 7.** Expansion over a base-failure set. 122 simulation tasks from 29 TerminalBench 2.1 source families the frozen GLM-5.2 base fails under the official reward. **Top:** cumulative unique coverage, reaching 122/122 at job 69. **Bottom:** each job's pass rate on the tasks it attempted, with the pooled rate per phase in blue. The model is frozen throughout; only the HCP-carried harness changes. Jobs 11–12 sweep the full set under one configuration each; later jobs target the families still uncovered.

Deployment Controls and Compatibility

This section details the rollout controls and memory limits governing adapter deployment and LongStraw execution.

The adapter registry can hold up to one million adapters in GPU memory, but this does not mean each entry corresponds to an independently trained policy. The catalog boundary assumes adapters are interchangeable placeholders rather than distinct behaviors.

For models that require distributed placement, MinT retains model‑parallel trainer groups and inference actors while adapter tensors, optimizer state, and exported revisions migrate between workers. This design keeps the core model resident and moves only the lightweight LoRA components during updates.

The companion report includes a Kimi K2 countdown‑task LoRA reinforcement‑learning run on a 1.04 T‑total/32.6 B‑active‑parameter base using 64 H800 GPUs. While this proves the adapter lifecycle can operate at that scale, it does not imply Macaron‑V1 itself was trained on Kimi K2 or that the run is reproducible from the paper alone.

LongStraw addresses the memory bottleneck of full‑sequence autograd by capturing prompt state without gradients and replaying responses one at a time under autograd. This response‑only approach bounds the live computation graph by the longest response rather than the combined prompt‑and‑response size.

The update has three stages: (1) the current policy evaluates the shared prompt without autograd, keeping only the conditioning state; (2) old‑policy scores are computed without a graph, then each response is replayed serially under autograd, releasing its graph immediately; (3) rank‑local gradients are aggregated and the optimizer steps after all $G$ members, so gradients never propagate through prompt tokens.

On the hybrid recurrent/full‑attention Qwen3.6‑27B path, LongStraw retains recurrent boundary state and context‑parallel KV pages; on GLM‑5.2 it retains sharded multi‑head latent‑attention pages and DSA indexer‑key pages, combines sparse selection across CP ranks, and routes response tokens across expert‑parallel ranks. An exact repeated update must recapture the prefix after parameters change, while the resident‑prefix mode reuses captured state across optimizer steps to measure capacity and amortization.

**Figure 8. Infrastructure inside the Macaron revision loop.** This is a conceptual artifact and control flow, not a claim that all components are co-located or invoked for every update. MindForge supplies selected trajectories and identifies the current policy; MinT resolves its policy record, manages the update, and exports an immutable LoRA adapter revision for the MoL runtime. LongStraw is selected for long-context response-only updates; sparse-base consistency controls are selected according to the model architecture. The dashed feedback arrow denotes experience collected after deployment, not an automatic online weight update (Lu et al., 2026; Zhou et al., 2026a).

Table 5 lists fixed‑hardware LongStraw execution receipts drawn from the companion report; the rows confirm that the specified response‑only and resident‑prefix operations complete on the given hardware configurations. These checks are not intended as throughput comparisons across systems.

Because the receipts only verify that the operations finish, they do not provide cross‑system throughput data, learning‑curve trends, or evidence that Macaron‑V1‑Venti or Macaron‑V1‑Tall were trained at these context lengths. Consequently, the table does not support claims about overall performance or scalability.

Benchmark Suite

Benchmark Suite quantifies Macaron‑V1’s gains across personal, UI, and general tasks.

The authors evaluate Macaron‑V1 on a curated suite that stresses personal interaction, UI generation, and general capability transfer.

R3 rollout‑routing replay cuts the out‑of‑route scoring ratio from 0.0097 % to 0.0013 %.

Measured over 87 Qwen3‑30B steps, the ratio drops by roughly an order of magnitude compared to 50 steps without R3.

Scaling the parallelism factor G from 2 to 8 adds only a modest 0.208 GB to peak memory during eight‑step optimizer replay.

Increasing G from 2 to 8 raises peak allocation by just 0.208 GB.

Peak memory was measured during a full transaction that reuses a captured prefix across eight optimizer steps.

The table lists six axioms and their corresponding definitions: - **Felt Understanding**: The user senses that their intent, state, and unspoken needs are grasped. - **Honest Counsel**: The model holds its own position rather than bending to please. - **Authentic Voice**: Expression comes from engaging with this person in this moment, not from a template. - **Forward Motion**: Each turn moves understanding, emotion, task, or relationship forward. - **Calibrated Closeness**: Intimacy tracks the relationship stage, neither too far nor too close. - **Growing Autonomy**: The user leaves the conversation more capable of acting on their own.

Persona Conditioning and Evaluation

Evaluation quantifies Macaron’s multi‑agent performance across persona, scenario, and UI benchmarks.

The final benchmark score is a weighted sum of need (70 %) and process (30 %) scaled to a 0–100 range.

Described in the evaluation pipeline: “deterministic engine then combines the five Layer Scores with fixed weights into a Composite Score; the benchmark aggregate then passes through fixed, versioned affine normalization to produce the Final Score.”

**Figure 9.** Macaron LivingBench system architecture. Top: data synthesis from product failures to a case package. Bottom left: user, world, and noise construction. Bottom center: six-component interaction in the dynamic multi-agent sandbox. Bottom right: need-fulfillment and process-quality evaluation.

Comparative Performance Summary

Macaron‑V1‑Venti dominates every benchmark, topping all ten scores.

Macaron‑V1‑Venti leads on all ten benchmarks, achieving the highest score in each.

Table 8 shows Macaron‑V1‑Venti outperforms every baseline across Personal Intelligence, Agent, Coding, Terminal, and GenUI benchmarks.

The evaluation spans four domains—Personal Intelligence, Agent, Coding & Terminal, and GenUI—using ten established benchmarks. Models compared include the six leading 2026 LLMs and the two Macaron‑V1 variants. All scores follow the benchmark‑specific protocols detailed in Appendix B.

**Figure 1.** Macaron-V1-Venti main results.

**Figure 10** UI4A-Bench evaluation loop. Each case combines the request with relevant user context. The model generates a complete React card, which is compiled and rendered before the benchmark collects build, rendered, and browser-driven interaction evidence. Deterministic checks and evidence-based judges score the five reported Layer Scores.

Case Studies and Evidence

Ablation evidence quantifies how each component impacts benchmark scores and interaction efficiency.

Macaron‑V1‑Tall exceeds Qwen3.6 on every benchmark, with the largest gap of 25.4 points on UI4A‑Bench.

All seven rows show higher scores for the Tall system; the UI4A‑Bench final score difference is 52.5 – 33.9 = 18.6 points, which translates to a 25.4‑point advantage after normalization.

Tall MoL improves OCRBench, MMBench‑EN, MMMU, and MME cognition, while MME perception drops.

Improvements are +0.80, +0.60, +1.33, and +66.43 respectively; the only negative delta is –52.99 on perception.

REPL composition reduces model‑call turns from 48 to 6, an 87.5 % decrease.

Both arms return the same answer (8208); the REPL version collapses 48 discrete calls into six batched operations.

In a correction‑integration test, the base model restates the user’s revised sequence without deeper reasoning, whereas Macaron‑V1‑Venti separates the initial frustration from the later comfort attempt and attributes the four‑hour sleep as the cause of the final relief.

Figure 12 illustrates the same diagnostic task executed with 48 discrete tool calls versus a six‑turn REPL composition; the latter retains intermediate results in a persistent namespace, enabling batch mapping and a dramatic turn‑count reduction.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers