What is Macaron¶
Macaron-V1 is an open agent-model family built around two system goals: continual adaptation through a versioned recursive-improvement loop over a live production harness, and composable specialization through a Mixture-of-LoRA (MoL) architecture over a shared frozen base. Rather than consolidating every capability into one monolithic checkpoint, Macaron keeps a large base model frozen and layers a small set of specialist LoRA adapters on top, selecting one specialist per user turn through a router.
This page introduces the model family and architecture. For the hosted API surface, see Model API. For the model lineup and pricing, see Models.
Two bets¶
Macaron is built around two bets:
- Adaptation. A versioned recursive-improvement loop: experience generated by one model-harness revision is evaluated under an external contract and used to construct a successor. Adaptation is a property sought across successive revisions, not in any single checkpoint.
- Collaboration. Composition through MoL: specialists remain separable so that heterogeneous objectives do not interfere through shared parameters. A specialist trained by one team or personalized for one user can be composed with others on the same runtime.
The model family¶
Macaron-V1 is a family of open models rather than a single artifact:
| Model | Aggregate params | Base | Specialists | Serving |
|---|---|---|---|---|
| Macaron-V1-Venti | 748B | 744B GLM-5.2 (frozen) | 4 × 1B LoRA | MoL harness |
| Macaron-V1-Tall | 50B | Qwen3.6-35B-A3B (frozen) | 4 × 1B LoRA | MoL harness |
| Macaron-V1-Coding-Venti | 748B | 744B GLM-5.2 | coding LoRA merged into base | single-specialist |
Venti is the flagship: a 744B GLM-5.2 base plus four 1B LoRA specialists, exposed through one OpenAI-compatible endpoint. Tall ships the same four-adapter design on a Qwen3.6-35B-A3B base for local and lower-latency deployment, with LoRA ranks sized for the smaller base. Coding-Venti is the single-specialist exception: the coding LoRA is merged directly into the base rather than served as a MoL adapter.
Mixture-of-LoRA architecture¶
Agent workloads combine tasks with very different chain-of-thought patterns: chat, agentic tool use, coding, and generative UI each ask the model to think in a different shape. When these behaviors share one parameter space, gradients from one family push the model in directions that harm another. MoL exposes this trade-off explicitly through one rule:
Cluster tasks that share skills and thinking patterns into one LoRA, and keep tasks whose skills diverge sharply in separate LoRAs.
Two properties follow:
- The base is frozen. New capabilities are added by training and registering another adapter, not by re-training the base. Base knowledge is not overwritten by later specialization.
- Adapters are portable. Because the base is shared, a specialist trained by one team or personalized for one user can be composed with specialists from another team or user on the same runtime.
The four specialists (Venti / Tall)¶
| Adapter | Role |
|---|---|
| L0, Chat | Conversational backbone, instruction following, model identity. Also the routing entry point. |
| L1, Agent | Long-horizon, heavy tool-use tasks; personal-agent workflows and service integrations. |
| L2, Coding | Code generation, SWE-style tasks, and terminal use. |
| L3, GenUI | UI4A rendering and UI-driven action; specialized on TSX (React and SolidJS). |
The four adapters are resident in the engine under exactly the names L0-L3;
L0 is also the routing entry.
The routing loop¶
MoL does not train a separate router model. Adapter selection is decided per user turn by the entry adapter L0's own reasoning and executed by the MoL Proxy. A client request runs a three-stage lifecycle:
- Route. L0 classifies the incoming request into exactly one canonical
adapter label (
L0-L3) under a tight decode budget (24 tokens). The router prompt frames the request as quoted, untrusted text and returns a single label under a constrained-decoding grammar. If L0 selects itself, the request stays on L0; otherwise the Proxy switches to the target adapter. - Answer. The chosen specialist responds from its own conversation view, seeded with cross-adapter summaries from prior turns.
- Summary. The specialist emits a short summary of what it just did, capped at 192 output tokens. The Proxy stores this summary server-side and never returns it to the client; it becomes shared context any adapter can inherit on subsequent turns.
The route is decided entirely by L0's reasoning: there is no separate router model and no keyword-based rule library overriding the decision. This makes routing accuracy a property of the chat specialist's understanding of the request, and lets it improve with the base and the L0 adapter rather than with a separate artifact.
Routing cost and accuracy¶
Routing is not free: every user turn adds a routing hop and a summary hop on top of the specialist's own generation. Measured on Venti over 48 multi-turn requests (temperature 0):
| Hop | Venti avg | Share | Tall avg | Share |
|---|---|---|---|---|
| Route (L0 constrained-decode, 24 tok) | 0.54 s | 11% | 0.20 s | 12% |
| Answer (specialist generation) | 3.17 s | 68% | 1.24 s | 70% |
| Summary (192-tok cap) | 0.97 s | 21% | 0.32 s | 18% |
| Total | 4.68 s | 100% | 1.76 s | 100% |
The overhead share (~30%) is stable across base sizes. Routing accuracy on a 6,448-sample trace set is 99.12% (Venti) / 99.04% (Tall) with 100% canonical-label compliance and zero parse errors.
Headline benchmarks¶
Venti's reported point estimates are strongest on the two internal Personal Intelligence benchmarks, TerminalBench 2.1, and UI4A-Bench. Values are normalized to 0-100; higher is better. These are descriptive point estimates, not statistically established wins.
| Benchmark | Venti | GLM-5.2 | GPT-5.5 | Opus 4.8 |
|---|---|---|---|---|
| ChatBench | 58.3 | 54.5 | 55.5 | 52.8 |
| LivingBench | 64.0 | 60.5 | 61.9 | 63.8 |
| TerminalBench 2.1 | 87.6 | 82.7 | 83.4 | 78.9 |
| UI4A-Bench | 87.8 | 67.1 | 72.1 | 75.9 |
| SWE-Verified | 85.6 | 80.4 | 82.9 | 88.6 |
| PinchBench | 94.0 | 88.1 | 89.0 | 91.8 |
The Personal Intelligence benchmarks (ChatBench, LivingBench) overlap the target distribution used by the improvement loop, so those scores measure fit to a system-specific distribution rather than generalization. External baseline values come from public reports rather than matched reruns. See the technical report for the full comparison set and provenance.
Continual learning and collective intelligence¶
A frozen base plus a plug-in adapter registry is what makes MoL a fit for continual learning and collective intelligence:
- Additive capability. A new capability is added by training a new LoRA and registering it. The router sees one more candidate label; nothing already deployed is retrained.
- No catastrophic forgetting of the base. Gradients enter only adapters, so the base cannot drift as a side effect of specialization.
- Live harness updates. The harness layer (routing rules, tool exposure, configs) can be edited without redeploying weights.
Because the base is shared and adapters are portable, the same properties enable composition across teams and users: a team can ship a specialist for a domain Macaron does not cover in-house, and a user-specific adapter can be trained cheaply and mounted alongside the shipping specialists.
Reference¶
The facts on this page are sourced from the Macaron-V1 technical report. The serving harness is open-sourced at MindLab-Research/Mixture-of-LoRA-Harness.