AesCode 32B vs Muse Code: A Poster Engine and a Terminal Agent Are Not Rivals

AesCode 32B and Muse Code are compared because both names contain the word "code", and that is close to the only thing they share. AesCode 32B is Microsoft's research checkpoint for emitting editable HTML and CSS — slides, posters, dashboards, reports — published under Apache 2.0 on Hugging Face, with the repository created on September 29, 2026 and the commit that carries the name "Release AesCode-32B" dated October 7, 2026. Microsoft has announced nothing about it: there is no launch post, no press release, and the model card itself states no release date. Muse Code is not a model at all. It is Meta's terminal coding agent, in beta since early August 2026, that spends its time running shell commands against a repository. One of these produces a file you open in a browser. The other runs commands until the tests pass. Choosing between them is not a model decision, and the useful thing this page can do is stop you making it as though it were.

What each one is actually for

AesCode 32B starts from Qwen3-VL-32B-Instruct and is trained, per its model card, with cold-start supervised fine-tuning on 3,000 demonstrations followed by GDPO reinforcement learning across seven reward channels — execution, text, boundary, table/chart, layout, whitespace and design. Six of those channels are deterministic verifiers; the seventh is a vision-language judge working from a per-sample rubric tied to a "design graph" of the target page. Every candidate output is rendered in a sandboxed Playwright browser with external requests blocked, then scored from the DOM, computed styles, bounding boxes and a screenshot. The intended outputs are explicitly named on the card: editable slides, posters, dashboards and reports, plus research on multimodal code generation. The model emits a complete HTML document and is trained to use real HTML table structures and ECharts specs so that its output stays inspectable.

Muse Code does something structurally different. It is a native binary for macOS and Linux with a main agent loop, asynchronous background agents that keep gathering context across a session, isolated Git worktrees so sub-agents do not collide, and a local event log that lets a crashed session be replayed or resumed. Meta's own reporting has it writing thousands of tool calls over periods measured in hours. The thing being sold is the loop, not the artifact.

Put the two side by side and the verbs do not match. AesCode 32B renders. Muse Code executes. If your problem is "our quarterly deck takes a designer three days", Muse Code is irrelevant and AesCode 32B is aimed straight at it. If your problem is "nobody wants to spend a weekend upgrading this dependency tree", AesCode 32B has nothing to say and Muse Code is the tool.

The evidence on each side is not the same kind of evidence

This is the part every comparison page gets wrong, so it is worth being slow about.

AesCode 32B's numbers come from a 300-sample infographic evaluation, three generations per prompt with no selection, and they are impressive on their own terms: an Overall score of 85.89 against 81.28 for GPT-5.5 and 80.39 for Claude Opus 4.8, both of those measured with the same reference-image setup by Microsoft's own harness. The card also reports that a severe canvas-boundary failure recurs on 4.3% of samples against 34.7% for GPT-5.5, and that AesCode 32B beats its own Qwen3-VL-32B backbone by 22.4 points on the Visual dimension and 24.8 on Overall.

Read all of that as vendor-reported and unreproduced. The benchmark, the reward channels that trained the model, and the metrics that score it are the same lab's work, and the 300 samples are Microsoft's. That is not a reason to dismiss the result — the evaluation is unusually transparent, the verifier stack is open, and the fact that the card publishes a dimension no model clears 60 on ("style", where nothing scores above 55.99) is more honesty than most vendor tables carry. It is a reason not to put 85.89 next to a number produced by a different lab on a different task and pretend a comparison happened.

Muse Code's numbers are Meta-reported in a different sense again: they measure a model plus a harness together. Meta reports 82.9% on Terminal-Bench 2.1 for Muse Code, second behind Claude Opus 5 paired with Claude Code at 86.7%, plus 59.3% on DeepSWE 1.1 and 70.6% on an internal coding bench. Because different harnesses were paired with different models across that table, you cannot read the model's contribution out of the system's score. And there is no overlap at all between what Muse Code is measured on and what AesCode 32B is measured on — one is scored on terminal tasks and software engineering, the other on whether an infographic's text is legible and its layout does not overflow.

What "one 32B checkpoint" hides

Deployment is where the two products separate hardest, and the short version fits in a bullet list.

• What it is — AesCode 32B: a 33B-parameter model checkpoint you download. Muse Code: an installable terminal agent product.

• Licence — AesCode 32B: Apache 2.0, weights included. Muse Code: proprietary; the model behind it is closed.

• What you supply — AesCode 32B: a GPU and a serving stack. Muse Code: an API key or a subscription.

• Hardware floor — AesCode 32B: the card advises planning roughly 65 GB of accelerator memory for the bf16 parameters alone, and its own serving example uses four-way tensor parallelism. Muse Code: a laptop.

• Context — AesCode 32B: 24,576 tokens in the reported configuration, with prompts and responses capped at 8,192 during RL training. Muse Code: a 1M-token window through the Muse Spark model underneath it.

• Price — AesCode 32B: the weights are free; the cost is hardware. Muse Code: billed per token, or via a monthly plan.

• Evidence — AesCode 32B: a vendor-run evaluation on its own 300 samples, with the harness published. Muse Code: Meta-reported system-level benchmarks on a coupled agent-plus-model stack.

That "hardware floor" row is the one people skip. A 32B checkpoint at bf16 is not a laptop model, and AesCode 32B is a vision-language model on top of that, so the serving path carries image inputs too. Muse Code is a binary you install in an afternoon.

Where they genuinely overlap

There is exactly one real overlap, and it is narrow: both can be pointed at a design-adjacent artifact and asked to produce something a human will refine. If your team is generating internal dashboards as code and also wants an agent that can open a pull request against the dashboard repository, both products touch that workflow.

Even there the split is clean. AesCode 32B produces the artifact. Muse Code produces the change. A pipeline that does both would call AesCode 32B to render, then hand the resulting file to an agent to place, wire up and test — and nothing about either product prevents that, because they were never competing for the same slot.

The half of this matchup you can call today

Here is a practical asymmetry worth stating plainly. AesCode 32B is not deployed by any inference provider. The Hugging Face card lists no hosted endpoint, no partner, and no API; if you want to use it you are downloading 65 GB of weights and building the serving path yourself. That is a normal state for a research release and it is also the single largest thing standing between the model and anyone who does not own eight GPUs.

Muse Code's underlying model does not have that problem. The Muse Spark family is served as a plain API model, and Muse Spark 1.2 is on the OrcaRouter catalogue where it is billable at Meta's list rates of $1.25 per million input tokens and $4.25 per million output tokens — provider list price passed through, no markup on our side, so a Meta price change lands here the same day it lands there. One key covers it alongside 200-plus other models, with automatic failover if a provider wobbles, which is the difference between "we can try this" and "we can put this on a production path". If what you actually wanted from this page was a way to use the intelligence inside Muse Code without adopting the Muse Code product, that is the route, and it exists. If what you wanted was AesCode 32B, the route is a download.

Which to pick

Pick AesCode 32B if the artifact is the point. You are producing decks, reports, posters or dashboards at volume, you have the hardware or the willingness to rent it, and the appeal of a model that emits structured, editable HTML — tables as tables, charts as ECharts specs, everything diffable in Git — is worth a research-grade serving setup. Accept that you are an early adopter of an unannounced model with a small download count, that no independent lab has reproduced its scores, and that its 24K context is a real constraint on long documents.

Pick Muse Code if the process is the point. You want an agent that runs in the terminal, survives a crash mid-session, and can hold several workstreams at once in isolated worktrees, and you are comfortable paying per token or per month for it.

Pick neither, and route to Muse Spark 1.2 directly, if what you needed was a capable reasoning model behind an API key and the terminal harness was never the part you wanted.

What would change this page

Three things. If an inference provider picks up AesCode 32B — or Microsoft publishes a hosted endpoint — the deployment column collapses and the model becomes something you can evaluate in an afternoon, which would make this a much closer question for design-heavy teams. If an independent evaluation reproduces the 85.89 Overall and the 4.3% boundary-failure rate, the evidence asymmetry narrows considerably. And if Meta opens the Muse Spark weights, the "you can download one and not the other" framing disappears entirely. Until one of those happens, the honest summary is that these two products share a word, not a job.