SWE-2 Flash vs AesCode 32B: Two Models, One Word, No Shared Benchmark

The question arrives in every "coding model" comparison thread eventually: which is better, SWE-2 Flash or AesCode 32B? The honest answer is that they are not in the same competition, and the fact that both get filed under "code generation" is a taxonomy problem rather than a buying decision. SWE-2 Flash, released by Cognition on 4 November 2026, is a software-engineering agent model: it reads a repository, plans a change, runs tools and edits files. AesCode 32B, published by Microsoft in October 2026, is an aesthetic code model: it takes a specification and emits HTML and CSS for slides, posters, dashboards and infographics. One closes tickets. The other makes things that look designed.

That distinction is worth more than a benchmark table, because picking the wrong one is not a matter of a few points — it is a matter of the model having no mechanism to do the job at all.

What AesCode 32B is actually for

AesCode 32B is a 33.4B-parameter vision-language model built on Qwen3-VL-32B-Instruct, released under Apache 2.0 with a 32,000-token context window. It ships in 8B and 32B variants and was introduced alongside a paper, "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards", which describes the training approach: separate reward signals for programmatic correctness and for visual quality, so the model is not forced to trade one against the other.

The intended input is a design brief. The intended output is markup that renders. Microsoft's own examples are infographics, slide decks, posters and dashboards — artefacts where the pass condition is partly mechanical (does the table have the right numbers, does the chart encode the right series?) and partly perceptual (does it look like a human designed it?).

• Parameters — 33.4B, vision-language, Apache 2.0

• Context — 32,000 tokens

• Output — HTML/CSS artefacts; no shell, no repo traversal, no test execution in the reported evaluation

• Memory footprint — roughly 65 GB at BF16, less at FP8

What its 85.89 does and does not mean

AesCode's headline is an overall score of 85.89 on a 300-instance infographic benchmark the authors built for the paper. That decomposes into 94.33 on rule-based checks (text, boundaries, tables and charts) and 77.44 on visual quality, where a vision-language judge scores content, layout and style. The same benchmark puts the Qwen3-VL-32B backbone at 48.61 overall, so the post-training is doing enormous work: plus 22.4 points on the visual half alone.

For context, the paper reports GPT-5.5 at 81.28 overall and Claude Opus 4.8 at 80.39 on the same 300 instances. Those are strong numbers to sit beside, and they are also the reason to read the table carefully: this is a purpose-built infographic benchmark, not a general capability index. Every figure in that paragraph is vendor-reported and has not been independently reproduced. There is no arena ranking and no third-party rerun.

The failure modes the paper does disclose are more useful than the headline. Canvas overflow recurs at about 4.3% of generations — dramatically better than GPT-5.5's 34.7%, which is a real win — but broken relational structures appear in 23.9% of outputs and distorted icons or semantically wrong elements in 23.3%. Style remains a shared bottleneck: no model in the comparison clears 60% on that sub-score. If you are generating production dashboards, a one-in-four chance of a broken relational structure is the number that should drive your review process, not the 85.89.

What SWE-2 Flash reports — and why none of it overlaps

SWE-2 Flash reports eight rows, all of them agentic or security evaluations: FrontierCode 2.0 at 24.0, FrontierCode 1.1 Main at 45.5, DeepSWE 1.1 at 60.1, Terminal-Bench 4.0 at 20.0, Terminal-Bench 2.1 at 89.2, SWE-Atlas QA at 50.0, SWE-Bench Pro v2 Hard at 89.9 and ExploitBench at 34.8. Every one is Cognition's own figure, run on a harness the launch post does not name.

There is no visual-quality row. No layout score, no render check, no design judge. Whatever SWE-2 Flash is good at, it has not been measured on the axis AesCode was built around, and AesCode has never been measured on an agentic software-engineering axis. The two tables share a column header and nothing else.

The same is true of the practical inputs. SWE-2 Flash runs inside Devin Desktop and the Devin CLI, free until 30 November 2026, with no API, no model ID and no published context window. AesCode 32B runs wherever you can load 65 GB of weights, or on whichever inference provider serves it, with a published 32,000-token context and an Apache 2.0 licence. One is a product you subscribe to and cannot inspect. The other is an artefact you can download and quantise.

The narrow place where they meet

There is one real overlap, and it is worth naming because it is where teams actually get this wrong. If your agent produces user-facing output — a report page, a status dashboard, a generated slide — then somewhere in that pipeline a model has to decide layout. A repository-editing model will happily emit HTML that works and looks like 2009. A design model will happily emit a beautiful dashboard with the wrong numbers in it, because it has no access to your test suite or your data layer.

That is a pipeline with two jobs, not a comparison with one winner. The genuine decision is whether the design step is a separate call with its own model and its own review gate, or whether you accept mediocre layout from a single general model. Teams that care about the visual result end up splitting the step; teams that do not care should not buy a design model at all.

Cost, access and what you would actually spend

• AesCode 32B — open weights under Apache 2.0, so the marginal cost is your GPU or your provider's per-token rate; no vendor subscription.

• SWE-2 Flash — free inside Devin through 30 November 2026, then unpriced, because Cognition published no per-token rate at launch.

• Hidden cost of AesCode — the review gate. A 23.9% relational-structure failure rate means human or programmatic verification of every artefact.

• Hidden cost of SWE-2 Flash — the lock-in. There is no endpoint to fall back to if the free window closes on terms you do not like.

Neither of these models is callable through OrcaRouter today: SWE-2 Flash has no endpoint at all, and AesCode 32B is not in the catalogue. What the comparison does argue for is the shape of the routing layer around it. OrcaRouter exposes more than 200 models behind one key, and its routing DSL lets you pin different models to different steps of a single composed call — which is exactly the "design step here, engineering step there" split described above. You do not get either of these two models from us. You get a single place to put whatever pair you end up choosing, and automatic failover when one of them is unavailable at 2am.

The rule of thumb

If the artefact your user sees is a pull request, SWE-2 Flash is in scope and AesCode 32B is not. If the artefact is a slide, a poster, a dashboard or an infographic, AesCode 32B is in scope and SWE-2 Flash cannot do the job — not badly, not slowly, but at all. If you need both, you need two calls and a review gate on the design one.

The comparison that would actually be useful does not exist yet: nobody has run AesCode 32B inside an agent loop that can check its own rendered output against a test suite, and nobody has run SWE-2 Flash on a layout benchmark. Until one of those happens, the only defensible claim is the boring one. These models are not substitutes, and any table that puts their scores in adjacent columns is measuring two different things with one ruler.