A hero title card for 'AesCode 32B vs Qoder Cantus' subtitled 'inspect one, run the other, never both', drawn as a two-way split: on the left an open repository card labelled 'AesCode 32B — weights, verifiers, recipe published' with a padlock-shaped gap marked 'nobody serves it', on the right a single closed sentence card labelled 'Qoder Cantus — one published line' with a live IDE picker marked 'runs today'; the OrcaRouter logo sits in the bottom-right corner.
Guides & Insights

AesCode 32B vs Qoder Cantus: You Can Inspect One and Run the Other, Never Both

Author

Magnus Corvin

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

Here is an inversion worth sitting with. AesCode 32B, Microsoft's HTML-and-CSS generation checkpoint, is the most inspectable model in its class: Apache 2.0 weights on Hugging Face, an open repository containing the reward verifiers, the rubric builder and the training loop, a 300-sample evaluation printed in full, and a training recipe detailed down to the learning rate and the number of rollout steps. Its Hugging Face repository dates to September 29, 2026; the commit titled "Release AesCode-32B" landed October 7, 2026; Microsoft has announced none of it. And almost nobody can run it, because it is a 33B checkpoint asking for roughly 65 GB of accelerator memory and no provider serves it. Qoder Cantus is the exact inverse. It runs today, inside Qoder, for anyone with a subscription — and you cannot inspect it at all. Qoder's entire published description of the model is one sentence, there are no parameters, no context window, no benchmark table and no weights, and because there is no API there never will be a third-party number. One model tells you everything and lets you do nothing. The other lets you do everything and tells you nothing. The interesting question is which failure mode costs you more.

What the documentation says, in full

The asymmetry is easiest to see by simply quoting what exists.

On AesCode 32B, the public record includes: the base model (Qwen3-VL-32B-Instruct), the parameter count, the licence, the intended use, the training data volume, the SFT learning rate, the RL optimiser settings, the reward channel names, the number of prompts and steps, the evaluation sample size, the number of generations per prompt, the decoding temperature and top-p, the context length used for scoring, three separate published tables of results, and a citation for a paper listed as under review. It stops short of a release date and a download count in the double digits — and the model card's note that it needs transformers>=4.57 and that the auto-generated usage snippet on the page disagrees with the card's own example is the kind of detail that only survives when the artifact is real.

On Qoder Cantus, the public record is: "Qoder's built-in top-tier intelligent model, excelling at extended autonomous task execution." That is the description. There is no model card because there is no model to download, no benchmark table because Qoder published no launch post or technical report, and no arena listing because an arena needs an endpoint to call. What else is known is structural rather than technical: Cantus appears in the model picker across Qoder Desktop, the JetBrains plugin, the CLI, Cloud Agents and the web client, and it bills through Qoder's credit system with a coefficient applied to the model's usage.

That is not a knock on the model. It is a description of what can be checked, and for Cantus the answer is nothing.

Where each one is genuinely strong

AesCode 32B's strength is verifiability, and it is unusual enough to be worth explaining rather than asserting. The training signal is not one score — it is seven channels, six of them deterministic verifiers that read properties out of the emitted code and its rendering, plus a vision-language judge scoring the non-parsable properties against a rubric tied to a per-sample design graph. Every candidate is rendered in a sandboxed Playwright browser with external requests blocked, exporting the DOM, computed styles, bounding boxes, console status and a screenshot. Because each property is attributable, the lab can report that it improved the Visual component by 22.4 points over its own Qwen3-VL-32B backbone and tell you which channels were still climbing at the end of training. That is a release you can argue with, reproduce, or extend.

The cost is equally specific. The card advises planning roughly 65 GB for the bf16 parameters alone; its serving example uses four-way tensor parallelism; the reported numbers use a 24,576-token context; during reinforcement learning the prompts and responses were capped at 8,192 tokens. Batch that against the fact that no inference provider deploys the checkpoint and the barrier is not philosophical. You either own the hardware or you rent it, and you build the multimodal serving path yourself.

Cantus's strength is the opposite: it is simply there. No download, no GPU, no serving stack, no harness to choose. It appears in the model picker of the IDE you are already in, and it is positioned for exactly the thing agentic coding tools are sold on — long autonomous task execution. Whatever else is uncertain about it, the deployment problem has been solved for you, and Qoder presumably knows more about the model it built than it has published.

The three questions you cannot answer about Cantus

It is worth being precise about what the missing documentation costs, because "no benchmarks" undersells it.

• How big is it — unknown. Parameter count is not disclosed. On a credit-metered model this is not trivia: it is the main input to whether a task that costs you $2 elsewhere can only be done for $6 here.

• How much context does it hold — undisclosed, with third-party discussion hinting at something in the 200K range and no source for it. Long-horizon agentic work lives and dies on this number, and it is not published.

• Is it any good — unanswerable in the strict sense. Qoder's argument, implicit in the positioning, is that long autonomous execution is better measured by how a model handles context, recovery and hundreds of tool calls than by single-turn coding scores. That is a fair argument. It would land harder if the model were testable, and it cannot be, because nothing outside Qoder can call it.

Compare that with the third question's mirror image on the AesCode side: the numbers exist and are detailed, but they are Microsoft's numbers, produced by Microsoft's harness, on Microsoft's 300 samples, and no outside lab has reproduced any of them. AesCode 32B has a documented ceiling of 55.99 on its own style dimension and a 4.3% severe canvas-boundary failure rate — both published by the vendor — and no independent confirmation that either figure is right. So the two failure modes are: numbers you cannot trust, and no numbers. That is a worse choice than "one is good, one is bad", and it is the choice this matchup actually presents.

A two-column comparison scoreboard for AesCode 32B and Qoder Cantus: the AesCode 32B column reads 'Published record: weights, verifiers, full recipe', 'Parameter count: 33B dense', 'Context: 24,576 tokens', 'How you get it: a Hugging Face download', 'Cost shape: GPU hours', 'External evaluation: none - no provider serves it'; the Qoder Cantus column reads 'Published record: one sentence', 'Parameter count: not disclosed', 'Context: not disclosed', 'How you get it: built into Qoder', 'Cost shape: Qoder credits (1.6x-3.2x coefficient)', 'External evaluation: impossible - no endpoint'; a footer line reads 'AesCode 32B figures Microsoft-reported; Qoder has published no parameter count, context window or benchmark for Cantus.' and the OrcaRouter logo sits in the bottom-right corner.

What it costs you on each side

Cantus bills through Qoder's credit system rather than a published token rate. Qoder applies a coefficient to a model's usage, and Cantus went live with a 3.2× multiplier, reduced to 1.6× under a 50%-off promotion that ran to July 31, 2026. Reconstructing from Qoder's own published credit estimates rather than any per-token figure — Qoder has never published one for Cantus — that works out to roughly $0.38 per editor-mode turn, $1.60 per Quest task, and $2.40 per Quest in Experts mode. Those are reconstructions, labelled as such because there is no primary source that says otherwise.

AesCode 32B's cost is a capital number instead of a per-unit one. The weights are free under Apache 2.0, and the bill arrives as GPU hours — 65 GB of accelerator memory to hold the parameters, plus the vision tower, plus whatever throughput you need. If you already run a B200-class node for other work, the marginal cost is close to zero. If you do not, the honest comparison is not "$0 per million tokens" against Qoder's credits; it is a hardware decision against a subscription.

The composability difference

There is one more consequence of the access model, and it is the one a routing platform notices first.

Cantus cannot be composed with anything. No API means no fallback, no A/B against another model on the same task, no cascading from a cheap model to an expensive one mid-request, no way to include it in an evaluation harness you wrote. It is one option inside one product, and the only lever you hold is the picker. That is a deliberate design choice on Qoder's part and a perfectly reasonable one if the IDE is where you want to live — but it means your architecture inherits Qoder's roadmap.

AesCode 32B has the opposite property in theory and a gap in practice. Weights mean it can go anywhere: your cluster, a rented instance, your own tooling, your own evaluation. What it cannot do today is be called, because no provider serves it — Microsoft published a checkpoint and stopped there. So the model that is structurally composable is not yet practically composable, and the model that is practically available is structurally locked.

Where that leaves the routing argument is narrower than usual, and worth stating honestly: neither model in this matchup is on our catalogue, and this page is not going to pretend otherwise. What a single endpoint with 200-plus models at provider list price actually buys you here is the surrounding layer — the ability to build the workflow that consumes AesCode 32B's output and to route the parts of it that a general model should handle, without standing up a second contract for each. If you want to test that layer before committing to a self-hosted vision-language deployment, the cheapest way is a callable model in the same family: AesCode 32B is a fine-tune of Qwen3-VL-32B-Instruct, and Qwen3-VL 235B A22B Instruct is available at $0.40 per million input tokens and $1.60 output, with the smaller Qwen3-VL 8B Instruct at $0.18 and $0.70. Those are different models, not substitutes for the fine-tune — but they answer "can a hosted VLM read this screenshot and write code well enough for our pipeline" for cents instead of 65 GB, and failover across providers sits underneath the same key if the answer is yes and the traffic gets real.

A screenshot of the Hugging Face model page for microsoft/AesCode-32B, showing the model card header, the Apache 2.0 licence tag and the start of the published evaluation tables and configuration detail (captured October 11, 2026).

How to choose

Choose Cantus if you are already inside Qoder, you value the absence of infrastructure work, and the unverifiability is a price you are willing to pay for it. Be clear-eyed that you are buying a capability, not a model: you cannot benchmark it before adopting it, you cannot compare its price to anything on a per-token basis, and you cannot take it with you if Qoder changes its pricing or its roadmap.

Choose AesCode 32B if you need the artifact and you can afford the deployment — and specifically if you need a model that emits editable HTML you can diff, review and ship. Be equally clear-eyed: it is unannounced, unreproduced, too large for most hardware, and documented for a 24K context that will constrain long documents.

If you want neither the lock-in of the first nor the capital cost of the second, the honest move is to get the same capability from a model you can call. A vision-language model behind an API key will read a screenshot and write structured markup. It will not be trained with seven reward channels tuned for design quality, and it will not match AesCode 32B on the infographic benchmark Microsoft built. But it will cost you a card on file rather than a GPU procurement, and you will be able to measure it yourself — which is the one thing this entire matchup is about.

A screenshot of the companion GitHub repository for AesCode 32B, showing the repository name, the README opening and the directory listing that includes the reward verifiers, rubric builder and training loop (captured October 11, 2026).

What to watch

Cantus becomes a normal model the day Qoder exposes an endpoint or ships weights; until then, every claim about it is a claim about Qoder's product rather than a claim about a model, and the evidence gap is structural rather than a documentation oversight. AesCode 32B becomes a normal model the day an inference provider picks up the checkpoint or an outside lab reproduces the 85.89 — and if that happens alongside Microsoft actually announcing the thing, the 65 GB barrier is the only one left. Whichever lands first tells you which of the two failure modes this industry has decided to stop tolerating.