AesCode-32B: Microsofts stille 33B-model dat presentaties als bewerkbare HTML schrijft

De tijdstempels op AesCode-32B spreken elkaar tegen, en die tegenstrijdigheid is grotendeels alles wat er te melden valt. De Hugging Face-repository microsoft/AesCode-32B is aangemaakt op 29 september 2026, maar alles erin kwam binnen in één enkele commit van 7 oktober 2026 met als bericht simpelweg "Release AesCode-32B" — en de trainingsstack die het resultaat reproduceerbaar maakt, werd op 8 oktober naar github.com/microsoft/AesCode gepusht. Microsoft heeft niets aangekondigd: geen blogbericht, geen arXiv-preprint, geen inzending voor een leaderboard, geen modelpagina op zijn eigen site. Wat bestaat, is een vision-language-model met 33 miljard parameters dat een prompt aanneemt en een volledig, op zichzelf staand HTML-document genereert — een dia, een poster, een dashboard — plus een kleinere metgezel, microsoft/AesCode-8B. Beide zijn fine-tuned op Qwen3-VL-visionmodellen — respectievelijk Qwen3-VL-32B-Instruct en Qwen3-VL-8B-Instruct — beide zijn Apache 2.0, en beide zijn vandaag downloadbaar.

De repo-id luidt microsoft/AesCode-32B en de kaart opent met de truc: AesCode koppelt je prompt aan een afbeelding die uit diezelfde prompt is gegenereerd, gebruikt de afbeelding als esthetische referentie en volgt de tekst voor de daadwerkelijke inhoud. Beeldgeneratoren stellen een fraaie pagina samen en geven de cijfers erop verkeerd weer; codemodellen krijgen de cijfers goed en kunnen niet zien hoe de pagina eruitziet. AesCode is een poging om beide te hebben, en de eerlijke samenvatting ervan per 11 oktober 2026 is dat de gewichten echt en controleerbaar zijn, dat de benchmarkcijfers van het lab zelf zijn, op een door het lab geschreven harness, en dat niemand buiten Microsoft er tot nu toe een cijfer voor heeft gepubliceerd. Dit stuk houdt die drie categorieën tot het einde toe gescheiden.

Wat staat er eigenlijk in de repository, byte voor byte?

Begin met wat je kunt verifiëren zonder ook maar één woord van de modelkaart te vertrouwen. De 32B-repository bevat veertien safetensors-shards met een totaal van 66.714.912.704 bytes, wat bij BF16 ruwweg 33,4 miljard parameters is — in overeenstemming met de "33B params" van de kaart en de waarschuwing dat de gewichten alleen al ongeveer 65 GB aan acceleratorgeheugen nodig hebben. De config declareert Qwen3VLForConditionalGeneration als de architectuur en qwen3_vl als het modeltype, dus dit is geen nieuwe architectuur en heeft er ook geen nodig: het laadt met transformers>=4.57, en de kaart bevat een vLLM-opdracht die het over vier tensor-parallelle ranks serveert, waarbij per prompt twee afbeeldingen zijn toegestaan en het maximum 24.576 tokens is.

De engagementtellers zijn het stilste onderdeel van de release. Twee downloads en één like op de 32B-repository op het moment van schrijven. Er is geen vermelding in de inferentieprovider-mapping van Hugging Face, wat betekent dat er geen gehost endpoint achter de repo-pagina is aangesloten, en nergens wordt een GGUF-, MLX- of llama.cpp-build aangekondigd. Voor een model dat de naam van Microsoft draagt en resultaten boekt die GPT-5.5 verslaan in de eigen tabel van de leverancier, is dat een opvallend kleine voetafdruk — en het is het sterkste beschikbare bewijs dat dit online is verschenen zonder dat er een lancering achter zat.

De bijbehorende code-repository vult de andere helft van de tijdlijn in, en het is waar de vraag naar de releasedatum echt ambigu wordt. microsoft/AesCode werd aangemaakt op 23 juli 2026 — tien weken vóór de weights — en telt veertien commits, allemaal van dezelfde contributor en allemaal met een tijdstempel binnen twintig seconden van de andere op 8 oktober 2026, tussen 23:14:04 en 23:14:24 UTC. Ze bevatten de specificatie voor het genereren van prompts en verifieerbare vereisten, de datapijplijn die ontwerpgrafen en rubriekvragen bouwt, een cold-start-SFT-fase, de GDPO reinforcement-learning-lus, een op Playwright gebaseerde renderingverifier, tests, en de README die dat alles documenteert. Er zijn geen releases en geen tags, de repositorybeschrijving is leeg, en hij heeft één ster.

Dus welke datum is de release? Het record van de repository zegt 29 september. De commit die het model bevat, zegt 7 oktober. De code die uitlegt hoe het model is gemaakt, zegt 8 oktober. Drie tijdstempels binnen één periode van twee weken, en geen daarvan gaat vergezeld van een zin van Microsoft die zegt: "we leveren dit uit." Hanteer 7–8 oktober als de geldende datum voor de artefacten die de meeste mensen daadwerkelijk zullen downloaden, en 29 september als de datum waarop de repository werd gereserveerd. Iedereen die je vertelt dat AesCode-32B op een specifieke dag "is gelanceerd", kiest namens jou een van die tijdstempels.

Het mechanisme: een afbeelding als esthetische leidraad, een grafiek als beloning

De technische claim op de kaart is smal en specifiek, wat in het voordeel ervan pleit. Het model wordt getraind met cold-start supervised fine-tuning op 3.000 demonstraties met een learning rate van 1e-5, en vervolgens met GDPO — een groep-relatieve variant van policy-optimisation — gedurende 520 stappen op 7.408 prompts. Het 8B-model gebruikte hetzelfde recept en stopte bij 400 stappen. De RL-run gebruikte de FSDP-vLLM-hybride-engine van verl zonder critic en zonder apart getraind rewardmodel, AdamW met een constante 5e-6 zonder warmup, 128 prompts per stap met elk acht rollouts, en zowel de prompt als het antwoord beperkt tot 8.192 tokens.

Wat de beloning ongebruikelijk maakt, is dat deze geen enkele scalaire waarde is. Elk trainingsdoel wordt beschreven als een ontwerpgraaf die het hele canvas beslaat, zodat individuele eigenschappen afzonderlijk kunnen worden toegeschreven. Uit die graaf komen zeven kanalen — uitvoering, tekst, grens, tabelgrafiek, lay-out, witruimte en ontwerp — die elk binnen de eigen rolloutgroep worden genormaliseerd voordat ze worden geaggregeerd, zodat één dominant signaal de andere niet kan overstemmen. Deterministische verifieerders beoordelen wat uit de code en de weergave ervan kan worden geparseerd; een vision-language-beoordelaar beoordeelt wat niet kan worden geparseerd, aan de hand van een rubric die is gekoppeld aan de elementen en relaties van de graaf zelf. Kandidaat-HTML wordt beoordeeld door het te renderen in een gesandboxte Playwright-browser met externe verzoeken geblokkeerd, die de DOM, berekende stijlen, bounding boxes, consolestatus en een screenshot exporteert.

De technische consequentie is het vermelden waard, want ze komt tot uiting in de output die je ontvangt: het model is getraind om tabellen als echte HTML-tabelstructuren en grafieken als ECharts-specificaties uit te voeren, zodat beide direct te inspecteren zijn in plaats van in pixels te zijn vastgebakken. Dat is het verschil tussen een deck dat je aan een ontwerper kunt geven en een deck dat je aan een linter kunt geven. De reproductievereisten zijn navenant zwaar — de README vraagt om Python 3.10, CUDA 12.6 en een node met acht B200 GPU's, pint een specifieke verl-commit vast en stelt ronduit dat er een patch ertegen nodig is omdat de standaard verl geen Qwen3-VL-ondersteuning heeft, en waarschuwt dat zonder de Playwright-systeembibliotheken de browser bij het starten faalt en pagina's nul scoren, en dat zonder de vastgepinde OCR-stack het overeenkomstige beloningskanaal nul teruggeeft in plaats van zich te onthouden en het signaal stilletjes corrumpeert.

De benchmarktabel, en de vier om hem vast te houden.

De kerncijfers van AesCode-32B komen uit 300 infographicvoorbeelden, drie generaties per prompt bij temperatuur 0,8 en top-p 0,95, met elk maximaal 12.000 uitvoertokens, zonder selectie tussen de generaties. De scores zijn percentages. Onder referentieconditie rapporteert het 32B-model Tekst 95,34, Grens 97,27, Tabel/Grafiek 90,37 en een Rule-gemiddelde van 94,33; aan de visuele kant Inhoud 85,76, Layout 90,58, Stijl 55,99, voor een visueel gemiddelde van 77,44 en een totaal van 85,89. In dezelfde tabel scoort GPT-5.5 met een referentie 81,28 op totaal en Claude Opus 4.8 met een referentie 80,39, terwijl de Qwen3-VL-32B-Instruct-backbone waarop het model is getraind 61,10 scoort.

Vier kanttekeningen horen in één adem met die cijfers te worden genoemd, en geen ervan is een smet op het werk. Ten eerste: elke rij, inclusief de rijen voor GPT-5.5 en Claude Opus 4.8, is door Microsoft uitgevoerd op Microsofts harness met Microsofts rubric — dat zijn niet de cijfers van de andere labs, het zijn Microsofts metingen van de modellen van concurrenten, en de kaart zelf noemt de rubric 'sample-specific' voor elke ontwerpgraph. Ten tweede: de rubric wordt geproduceerd door dezelfde pipeline die de trainingsdata heeft gegenereerd, precies de opzet waarin een benchmark kan afdrijven naar de sterke punten van een model; de kaart is openhartig over de beperkingen van die rubric — Style, waarbij een ontwerp geen verdere visuele revisie mag vereisen voordat het wordt opgeleverd, wordt 'het gedeelde plafond voor elk systeem' genoemd en geen enkel model in de tabel komt boven de 60 uit. Ten derde: er is nergens een onafhankelijke meting van dit model: geen vermelding op een leaderboard van derden, geen reproductie, en met twee downloads is het vrijwel zeker nog zo dat niemand buiten het lab het draait. Ten vierde: de vergelijking is subtiel asymmetrisch op een manier die het opmerken waard is — de rijen van AesCode-32B zijn allemaal referentiegeconditioneerd, dus het model wordt gemeten in de configuratie waarvoor het is getraind, wat de kaart erkent door te laten zien dat de kwaliteit nog steeds het hoogst is wanneer een referentie wordt aangeleverd.

Het enige resultaat in de tabel dat beter overeind blijft dan het hoofresultaat, is een robuustheidsclaim en geen kwaliteitsclaim. Het achterhouden van de referentieafbeelding bij inferentie kost AesCode-8B slechts 1,00 Visual-punt, tegenover 19,55 voor zijn Qwen3-VL-8B-Instruct-backbone en 10,04 voor GPT-5.5. Het argument van de kaart is dat referentiegeconditioneerde training visuele planning internaliseert in het beleid in plaats van het model te leren kopiëren wat het ziet. Dat is door de leverancier gerapporteerd en niet gereproduceerd, en het is ook het soort claim dat één enkele onafhankelijke run zou beslechten — en het soort dat er in productie het meest toe doet, waar je niet altijd een referentieafbeelding bij de hand hebt.

Wat het kost om te runnen, en wat dat betekent voor de vergelijking.

Niets aan dit model is goedkoop om zelf te hosten. Tienduizend tot twaalfduizend outputtokens is de werkbare omvang van één artefact, en een volledig HTML-document met een ECharts-specificatie zit dichter bij de bovenkant van die bandbreedte dan bij de onderkant, dus elke generatie is een lange decode. Het eigen serveerrecept van de kaart vraagt vier GPU's bij tensor-parallelisme om ongeveer 65 GB aan BF16-parameters te huisvesten, en het trainingsrecept vraagt acht B200's. Dat is een echte machine, geen hobby-opstelling, en het bepaalt de voorwaarden van de vergelijking: de modellen waarmee AesCode-32B wordt vergeleken, worden per token gehuurd, en het model zelf wordt per GPU-uur gehuurd, of je de hardware nu bezit of niet.

De praktische vorm van die vergelijking is precies waar een routinglaag voor bestaat, en het is de moeite waard om precies te zijn over wat wij wel en niet hosten. AesCode-32B staat niet in de catalogus van OrcaRouter en wij bieden het niet aan — er is geen gehost endpoint voor te vinden, voor zover ik kan nagaan, ook niet bij Microsoft. Wat wel in de catalogus staat, is de andere kant van de tafel: de gehoste modellen waarmee je een zelfgehoste artefactgenerator zou benchmarken, waaronder GPT-5.5 en de kleinere Qwen3-VL-visiemodellen, bereikbaar via één API-sleutel tegen de lijstprijs van de provider met 0% opslag, wat betekent dat een prijswijziging van een leverancier dezelfde dag aan onze kant live gaat. Het vergelijken van een gehuurd endpoint met een model dat je zelf draait, vereist geen tweede contract of een tweede SDK, en met een routing-DSL kan een zelfgehoste aanroep naast gehoste aanroepen achter één endpoint staan. Als AesCode-32B goed blijkt te zijn in het enige dat zijn modelkaart belooft, dan zijn de kosten om erachter te komen een GPU-rekening, en de kosten van de alternatieven waarmee je het vergelijkt zijn één sleutel die je waarschijnlijk al hebt.

Wat je er vandaag mee kunt doen, en wat niet bestaat

• Download en voer het uit — de gewichten zijn Apache 2.0, gebaseerd op de Qwen3-VL-backbone, met veertien BF16-shards en een werkend transformers-pad boven versie 4.57 en een vLLM-recept in de kaart.

• De training reproduceren — de code heeft een MIT-licentie en is volledig genoeg om betekenisvol te zijn: de beloningsverificateur, de rubric-bouwer, de SFT- en GDPO-fasen, een vastgezette verl-commit plus de patch die Qwen3-VL-ondersteuning toevoegt, en een README die de faalmodi opsomt in plaats van ze te verbergen.

• Evalueer het referentievrij — het model accepteert prompts met of zonder de referentieafbeelding, en de meest toetsbare bewering van de kaart ligt in die configuratie.

• Een API ervoor krijgen — dat kan niet. Er is geen gehost endpoint, geen inference-provider-mapping in de repository, en geen GGUF- of MLX-build; dit draaien betekent de hardware draaien.

• Lees de paper — dat kan nog niet. De kaart linkt naar een paper met de titel AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, en de eigen BibTeX-vermelding geeft de venue als "Under review" en het jaar als 2027. Een zoekopdracht op arXiv levert geen paper met die titel op. Er is een andere, eerdere Microsoft-paper met een vrijwel identieke naam — Code Aesthetics with Agentic Reward Feedback uit oktober 2025, die een AesCoder-4B-model en een AesCode-358K-dataset uitbracht — en niets in de AesCode-32B-kaart citeert die of vermeldt een relatie ermee. Als je op zoek gaat naar achtergrondliteratuur en in plaats daarvan bij die ene uitkomt, lees je over een ander model dat is gebouwd door overlappende auteurs.

• Vergelijk het op een openbare ranglijst — nog niet. Geen enkele index van derden lijkt het te hebben geëvalueerd, wat niet verrassend is voor een repository met twee downloads.

Wie moeten zich zorgen maken, en wie kunnen wachten?

Het publiek hiervoor is smaller dan de tabel bovenaan doet vermoeden en specifieker dan "iedereen die met modellen bouwt." Als jouw product prompts omzet in decks, posters, rapporten of dashboards die iemand daarna nog moet bewerken, dan heb je de keuze waarop dit model is gericht al ontdekt: beeldgeneratie levert je een prachtige rechthoek op die je niet kunt wijzigen, en codegeneratie levert iets bewerkbaars op dat eruitziet alsof het door een compiler in elkaar is gezet. Een 33B open-weights-model dat een volledig HTML-document met echte tabellen en ECharts-specificaties genereert, dat binnen ongeveer één punt blijft van zijn referentiegeconditioneerde kwaliteit wanneer je geen referentie hebt om mee te geven, en dat je onder Apache 2.0 kunt fine-tunen op je eigen huisstijl, is iets oprecht nuttigs om te laten bestaan. Geen enkel ander model doet precies die taak op deze grootte met deze voorwaarden.

Daar staat tegenover: alles wat je over de kwaliteit weet, komt uit een tabel die de leverancier heeft gemaakt, de rubric erachter is geproduceerd door dezelfde pijplijn die de trainingsdata heeft gemaakt, en het enige plafond dat de kaart toegeeft — Style onder 60 voor elk getest systeem — is precies de dimensie waar een ontwerpgevoelig product het meest om zou geven. Een team met een compliance-reden om generatie intern te houden en een extra node met acht GPU's heeft genoeg om vandaag te beginnen. Een team dat volgende week een model voor productie kiest, heeft geen onafhankelijk cijfer om op te kiezen, en moet 85,89 tegenover 81,28 niet als een definitief resultaat opvatten.

Wat zou hier een verhaal van maken?

Vier dingen, waarvan er nog geen enkele bestaat. Een aankondiging — Microsoft heeft niets gezegd, en de paper waarnaar de kaart verwijst is expliciet in review, dus een technisch rapport met trainingsdetails die verder gaan dan de samenvatting op de kaart kan op elk moment verschijnen. Een onafhankelijke run — de referentievrije robuustheidsclaim en de Boundary-score, waarvan de kaart zegt dat die op 4,3% van de samples tot een ernstige fout leidt tegenover 34,7% voor GPT-5.5, zijn beide goedkoop te testen en beide het testen waard. Ondersteuning voor serving buiten het recept van de leverancier — een GGUF-build of een entry in een gangbare runtime zou het hardwareverhaal meer veranderen dan welke benchmark dan ook. En een tweede datapunt bij de groottevraag: een 8B-model dat 82,94 Overall scoort tegenover 85,89 voor het 32B-model in dezelfde tabel is een gat van twee punten voor een kwart van de parameters, wat het soort ding is dat ofwel wordt gereproduceerd ofwel stilletjes niet meer wordt genoemd.

Totdat een van die dingen zich aandient, is dit de nauwkeurige beschrijving van AesCode-32B: echte gewichten onder een permissieve licentie, een trainingsstack die gedetailleerd genoeg is om door een goed uitgerust lab te worden gereproduceerd, een benchmarktabel die de meting door één bedrijf van zijn eigen model en van twee concurrenten is, en een repositorygeschiedenis die verhindert dat je één enkele dag de lanceerdatum noemt. Het is een interessanter artefact dan de downloadteller die twee downloads aangeeft doet vermoeden, en een minder bewezen artefact dan zijn 85,89 suggereert. Beide helften van die zin zijn de eerlijke lezing op 11 oktober 2026.