AesCode-8B shipped quietly: Microsoft's 8B model writes slides and dashboards as HTML

The most interesting number in Microsoft's new release is 1.00. Withhold the reference image from AesCode-8B — an 8-billion-parameter model that writes slides, posters and dashboards as editable HTML and CSS — and its visual score falls by one point out of a hundred. Withhold the same reference from Qwen3-VL-8B-Instruct, the open-weight model AesCode-8B was fine-tuned from, and the fall is 19.55 points. From GPT-5.5 it is 10.04. That one comparison is where the actual research result lives, and it sits underneath a headline Microsoft also published: on its own 300-sample rubric, AesCode-8B's overall score of 82.94 edges reference-conditioned GPT-5.5 at 81.28 and Claude Opus 4.8 at 80.39, with a larger sibling, AesCode-32B, at 85.89.

Nothing about this release was announced. Microsoft committed the weights on Hugging Face on 2026-10-07 under Apache 2.0 — AesCode-8B plus a 32B companion built the same way from Qwen3-VL-32B-Instruct — and pushed the training and evaluation code to GitHub the following day. There is no Microsoft Research blog post, no release note, no product page, and no preprint: the citation in the model card reads "Under review", year 2027, which is a placeholder rather than a date. As of 2026-10-11 the 8B repository shows two downloads and one like; the GitHub repository shows one star. Everything below that carries a number is either a timestamp you can verify yourself or a figure Microsoft reported about its own evaluation set — and that distinction matters more than usual here, because no part of this model has been measured by anyone else.

What shipped, and what is not in the box

Three dates define this release, and they are the only dates in it. The Hugging Face repository for microsoft/AesCode-8B was created on 2026-09-29, the weights were committed under the message "Release AesCode-8B" at 03:35 UTC on 2026-10-07, and the microsoft/AesCode code repository went public the next day, 2026-10-08 at 23:14 UTC. The 32B weights landed in the same commit window. Nothing in between was announced anywhere.

• Weights — four safetensors shards totalling 17,543,339,408 bytes, which works out to roughly 8.8 billion bf16 parameters. Microsoft labels the model 8B; Hugging Face's size field rounds it to 9B. That is rounding, not a discrepancy.

• Architecture — a straight fine-tune of the Qwen3-VL recipe: Qwen3VLForConditionalGeneration, 36 hidden layers, hidden size 4,096, 32 attention heads with 8 key-value heads, a 151,936-token vocabulary and interleaved mrope positions. It needs transformers 4.57 or later.

• Context and output — the reported runs used a 24,576-token context with up to 12,000 output tokens, generated at temperature 0.8 and top-p 0.95 across three rollouts per prompt with no selection. The vLLM serving command allows two images per prompt: the reference, and nothing else, because the output is text.

• Licence — Apache 2.0, described as following the Qwen3-VL backbone. Fully permissive, no gating, no acceptable-use addendum.

• Not in the box — the training and evaluation data. The repository ships the pipeline and documents the expected inputs and outputs, and mentions the split files it expects, but no dataset release is listed on either the model card or the code repo. You get the recipe, not the ingredients.

• Also not in the box — any hosted endpoint. We could not find an API serving AesCode-8B anywhere, and it is not in our own catalogue. Until a provider picks it up, evaluating it means loading weights onto your own GPUs.

The framing Microsoft uses is worth quoting because it is the whole design brief: code models "cannot see how layout, hierarchy, and color come together on the canvas," while image generators "compose visually compelling pages but often misrender text, numbers, and logical relationships." AesCode is the attempt to take the composition sense from one and the verifiability from the other.

The 1.00-point result, explained

Here is the mechanism behind the number in the first paragraph. During training, every prompt is paired with a reference image generated from that same prompt — Microsoft's own runs used GPT-Image-2 for the image and GPT-5.5 to expand a short idea into the detailed content prompt. The reference carries no content authority; the text prompt remains the source of truth. What the reference supplies is layout and style, and the reward function is built to keep those two things separate.

The consequence is that the visual prior ends up in the policy rather than in the input. AesCode-8B loses 1.00 Visual point when the reference is removed at inference. Its own backbone, evaluated reference-conditioned at 44.72 Visual, loses 19.55 points without one. GPT-5.5 loses 10.04. The distilled version of that: the model stopped needing the picture.

The second half of the result is the one that is easy to miss. Microsoft reports that reference-based rewards raised prompt-only Visual from 25.17 to 69.71 — the model that never sees a reference at inference time still benefits from having been trained against them. If you were planning to skip the reference-generation step in your own pipeline, that is the number that says you should not bother skipping it in training either.

The honest caveat on all of it: this is Microsoft's rubric, on Microsoft's 300 infographic samples, scored three times per prompt with no cherry-picking. Half of the score comes from deterministic verifiers, which anyone could reproduce; the other half, the checklist dimensions, is judged by a vision-language model whose identity the documentation does not name. You cannot reproduce the second half without knowing which judge produced it.

Where the taste gets into the weights

The training method is the part of this release with the most transferable ideas, and it is more mechanical than the output suggests.

• Everything is a graph first. Each target is represented as a design graph: nodes for text, charts, tables, cards, regions and image slots, and edges for containment, alignment, order and connection. The point of the graph is attribution — every property on the canvas belongs to a named element, so every property can be scored on its own.

• Seven reward channels. Six deterministic verifiers check the parsable things — execution, exact text, boundaries, table and chart data, semantic layout, whitespace — and a sample-specific Visual Graph Rubric, built as graph-bound yes/no questions about geometry and placement, scores the rest. The channels are execution, text, boundary, tablechart, layout, whitespace and design.

• The channels are normalized before they are combined. GDPO normalizes each channel within its rollout group, so a dense rule-based signal cannot drown out the sparse visual one. Microsoft measures this at 5.12 Visual points over plain scalar GRPO with the same setup — vendor-reported, but a concrete ablation rather than an assertion.

• Scoring happens by rendering. Candidate HTML is rendered in a sandboxed Playwright browser with external requests blocked, and the harness reads back the DOM, computed styles, bounding boxes, console status and a screenshot. Tables must be HTML tables; charts must be ECharts specs. That constraint is doing real work — it forces the output into a shape a verifier can parse.

• The recipe itself. Cold-start supervised fine-tuning on 3,000 demonstrations at a learning rate of 1e-5, then GDPO over 7,408 prompts for 400 steps on verl's FSDP-vLLM hybrid engine, with no critic and no separately trained reward model. AdamW at a constant 5e-6, no warmup, weight decay 0.01, 128 prompts per step with 8 rollouts each, KL and entropy coefficients both 0.001, prompt and response each capped at 8,192 tokens. The released runs used a single node with eight NVIDIA B200s. AesCode-32B uses the same recipe for 520 steps.

Read as a whole, this is a reward-design paper wearing a model release as a costume — and that is consistent with the citation reading "Under review" rather than pointing at a preprint.

The scoreboard, and who vouches for it

All of the following is Microsoft's own evaluation, reported in the model card, on 300 infographic samples. Rule averages the programmatic Text, Bound and Chart checks; Visual averages the Content, Layout and Style checklist dimensions; Overall is the mean of the two. Scores are percentages averaged over three generations per prompt with no selection. "Ref." marks whether the model was given a generated reference alongside the prompt.

• AesCode-8B with reference — Text 94.06, Bound 88.36, Chart 87.79, Rule 90.07; Content 86.41, Layout 87.80, Style 53.21, Visual 75.80; Overall 82.94.

• Against its own backbone — reference-conditioned Qwen3-VL-8B-Instruct scores Visual 44.72 and Overall 51.93. That is a 31.1-point Visual gain and a 31.0-point Overall gain, and it is the least surprising comparison in the table, since the whole point of the training is the visual half.

• Against GPT-5.5, reference-conditioned — Overall 81.28, Content 82.44, Layout 89.93, and Style 57.91.

• Against Claude Opus 4.8, reference-conditioned — Overall 80.39, Content 86.42, Layout 89.76.

• AesCode-32B, reference-conditioned — Text 95.34, Bound 97.27, Chart 90.37, Rule 94.33, Layout 90.58, Visual 77.44, Overall 85.89. Twenty-two point four points of Visual over its own 32B backbone.

• The Style ceiling — no model in the table clears 60, and GPT-5.5's 57.91 is the best of them. AesCode-8B sits at 53.21. Microsoft's own definition is unforgiving: Style credits a design only when it needs no further visual revision before delivery. So on the one dimension that measures whether a human would actually ship the page unedited, the 8B model is not the leader.

• Boundary failures — a severe canvas-overflow failure recurs on 4.3% of the 300 samples, against 34.7% for GPT-5.5. Overflow is the failure mode that makes generated HTML unusable rather than merely ugly.

Now the part that matters as much as the table. Every figure above is vendor-reported and unreproduced. AesCode-8B does not appear on any independent leaderboard we could find, and the comparison against GPT-5.5 and Claude Opus 4.8 is being run on Microsoft's rubric, on a task those models were not tuned for, with a definition of "Layout" that rewards producing a page at all. A 94.06 Text score does not mean this model beats GPT-5.5 at text. It means it places labels without contradicting the prompt on infographic pages, which is a much smaller claim. The Style result is the tell that the rubric is not rigged in AesCode's favour — the biggest scoreboard win comes with the biggest unflattering number sitting right next to it.

What is confirmed, and what is not

Because this shipped quietly, it is worth separating the two explicitly.

• Confirmed — the weights exist and are downloadable under Apache 2.0; the two release timestamps are in the repositories; the architecture, parameter count, context length and sampling settings are all in the published config and model card; the training recipe and reward design are documented in enough detail to argue with; the code, verifier stack and rubric builder are public; a 32B companion exists.

• Not confirmed — any of the benchmark numbers, by anyone other than the vendor. The paper, which the documentation itself describes as under review. The identity of the vision-language judge behind the visual half of the scores. Whether any provider will host it. Whether the 24,576-token context holds up on real multi-slide decks, since the reported evaluation is on single infographic pages. And anything at all about behaviour outside English — the model card's language tag is "en" alone.

If you want to run it, and what that costs

Qwen3-VL-8B-Instruct — the model AesCode-8B was fine-tuned from, and the strongest single comparison available until someone publishes an independent AesCode result — is a different matter:

The serving path for AesCode-8B itself is short, and the model card gives it directly: vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, with transformers 4.57 or newer for the non-vLLM route, and a Python snippet that accepts an optional reference image ahead of the text prompt.

The arithmetic you have to do yourself is memory. 17.5 GB of bf16 weights have to fit alongside a KV cache for a 24,576-token context and up to two images, so a single 24 GB card is technically enough for the weights and uncomfortably tight for everything else; 40-48 GB, or two 24 GB cards, is the realistic floor. The 32B companion is a different order of problem — its shards total 66.7 GB, so it needs tensor parallelism and a multi-GPU node. Budget a renderer as well: the model emits a complete HTML document, and every quality claim about it is made by rendering that document, so scoring your own outputs means standing up Playwright with external requests blocked.

You do not need to generate a reference image at inference time — that is exactly what the 1.00-point result buys you — but the documentation is clear that quality is still highest when one is supplied, so the honest setup is reference-optional rather than reference-free.

AesCode-8B is not something OrcaRouter routes, and we could not find it hosted anywhere else either, so an evaluation currently means weights on your own hardware. Its backbone is a different story. Qwen3-VL-8B-Instruct is routable through OrcaRouter today at $0.18 per million input tokens and $0.70 per million output, with a 131,072-token context — which makes it the cheap way to see what the untuned version of this architecture does on your own infographic prompts before you spend a GPU-week reproducing someone else's recipe. OrcaRouter passes provider list price through with 0% markup and fails over automatically between providers, so that comparison costs one key and no second contract; if AesCode-8B ever lands on a provider we route, it will be in the catalogue the same day. And if you do self-host it, the models you would fall back to in production are the ones already behind that one endpoint — which is the reasonable posture for a quietly released model with zero independent evaluation.

What to watch

Two things, and neither is another benchmark table.

The first is the paper. "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" is cited as under review for 2027, which reads as a placeholder typed into a BibTeX entry rather than a schedule. Until a preprint or a camera-ready appears, the reward-channel explanation above is a summary of an abstract nobody outside the lab can read — and the interesting questions, like how the Visual Graph Rubric handles a design graph that is itself wrong, only get answered in the full text.

The second is hosting. An 8.8B Apache-2.0 model that emits structured, verifiable HTML is precisely the shape a platform picks up, because the output is inspectable in a way a JPEG is not. The moment someone serves it, this stops being a self-hosting decision and becomes a routing decision — and the cost comparison stops being about GPU-hours.

The thing not to expect is a clean verdict. Style is the ceiling for every system in that table, including this one, and Style is the only dimension that asks whether a human would ship the page as-is. The defensible reading of AesCode-8B is narrow and real: it is very good at the parts of visual design that can be checked by a machine, it is middling at the part that cannot, and it is the first open-weight model in this niche where the gap between those two things is the point of the release rather than an accident of it.