Kies een AI-model: één prompt, 11 modellen, zeer verschillende resultaten

We zijn zojuist een partnerschap aangegaan met OpenRouter, waardoor we twee nieuwe functionaliteiten kunnen aanbieden:

Ten eerste kunnen jouw projecten nu elk model op OpenRouter gebruiken via onze AI Gateway. Dit betekent dat als jouw eigen webapplicatie AI-inferentiegebaseerde functies biedt aan eindgebruikers, je nu een veel bredere selectie van modellen hebt om bij elke taak en elk budget te passen.

Ten tweede breiden we de selectie van geavanceerde coding-modellen uit die beschikbaar zijn via Agent Runners. Agent Runners is het chat-promptvenster binnen Netlify waarmee je nieuwe projecten vanaf nul kunt opbouwen of bestaande projecten kunt itereren. De selectie modellen bevat nu ook veelbesproken recente open modellen zoals Kimi K3, GLM 5.2 en DeepSeek V4, die voor iedereen beschikbaar zijn.

We noemen het Agent Runners omdat we er een volledige coding-agent in draaien, en geen ingekorte versie. Tot nu toe ondersteunden we Claude Agent, OpenAI Codex en Gemini CLI, die zijn geoptimaliseerd om modellen van deze providers te draaien.

We voorzien deze agents van extra vaardigheden en context over het huidige project, zodat de agent precies weet welke Netlify-mogelijkheden beschikbaar zijn voor gebruik (bijv. Netlify Database, de AI Gateway of Identity), wanneer hij ze moet gebruiken en hoe. Om een grote verscheidenheid aan nieuwe modellen effectief aan te sturen, hebben we de populaire open-source OpenCode toegevoegd als nieuwe keuze voor agent.

Maar met meer keuze komen onvermijdelijk de vragen: Hoe weet ik welk model het juiste is voor mij? Mis ik iets dat materieel beter of kosteneffectiever is (zodat ik meer kan doen met mijn credits), of iets dat me zal verbazen zoals het internet beweert? Er is tegenwoordig veel FOMO.

Om je inzicht te geven, volgt hier wat we hebben geleerd door identieke prompts uit te voeren over een reeks modellen… die allemaal nu beschikbaar zijn voor gebruik op Netlify. De resultaten van alle geteste modellen zijn te vinden op de website die we met het volledige rapport hebben gemaakt.

Wat we hebben getest

Intern gebruiken we bij Netlify AXIS voor het automatisch evalueren van modellen, een tool die we onlangs open-source hebben gemaakt.

We voorzien AXIS van diverse testgevallen: prompts voor het bouwen van een nieuwe site en het vervolgens itereren daarop. We instrueren AXIS over welke agents en modellen deze prompts moeten testen, en definiëren de controles die AXIS moet uitvoeren om de gegenereerde site te scoren.

Deze controles zijn sterk gericht op de correcte functionaliteit van de gegenereerde site in plaats van het ontwerp, bijvoorbeeld: gebruikt de site een database wanneer de behoeften van de gebruiker daarom vragen? Wordt Netlify Database in dat geval correct gebruikt? In gevallen waarin een eenvoudige statische site volstaat, zorgen we er ook voor dat de gegenereerde site niet "over-engineered" is en dat er geen database is ingericht.

Als een bepaald model achterblijft in de testscores, bieden we dit niet aan in Agent Runners. Als modellen te vaak falen bij het correct toepassen van een van onze vaardigheden, of als zaken wel werken maar de creditkosten opgeblazen lijken, dan ligt het probleem waarschijnlijk bij de vaardigheid (in welk geval we die vaardigheid optimaliseren).

Maar dit keer willen we je iets bieden dat direct nuttiger is: wat krijg je wanneer je je droom bouwt met verschillende modellen die elk wild verschillende hoeveelheden credits verbruiken? Hoe zien de resultaten eruit?

We hebben drie relatief eenvoudige use-cases getest:

1. Een site voor een lokale koffiebar. LLM's zijn dol op het maken van sites voor lokale koffiebars! De initiële prompt is eenvoudig, en een statische site zonder fancy database volstaat. Daarna volgt een vervolgprompt waarin wordt gevraagd om een eenvoudige optie om plaatsen te reserveren, waarbij we controleren hoe het model dit afhandelt.
2. Een eenvoudige to-do lijst web-app waarin meerdere gebruikers taken kunnen bekijken en toevoegen. Dit vereist een eenvoudig ontwerp, maar vraagt vanaf het begin om een gedeelde database. Daarna vragen we om ondersteuning voor een optionele fotoupload per item en controleren we of het model de juiste Netlify primitive heeft gebruikt.
3. Een “Wat kan ik koken” web-app waarmee gebruikers kunnen invoeren welke ingrediënten ze thuis hebben, waarna AI een recept suggereert. De site zelf is vrij eenvoudig, maar we willen controleren of de gegenereerde site correct onze AI Gateway gebruikt om een recept voor de gebruiker te genereren.

Voor elk van deze gevallen laten we het uiterlijk van de gegenereerde sites zien, becommentariëren we opvallende problemen en vergelijken we hoeveel credits er nodig waren voor de generatie. Natuurlijk is dit een veel subjectievere test dan onze interne testsuites, maar het is ook een erg leuke. We horen graag je mening over de resultaten!

Alle modellen werden uitgevoerd met hun standaardinstellingen op Netlify. Een belangrijke vermelding is dat we GPT 5.6 Sol momenteel standaard specifiek op "low effort" draaien, wat een economischer alternatief biedt voor Opus dat nog steeds zeer goede resultaten geeft. De "effort"-instelling is nu echter in jouw beheer en onze standaarden kunnen in de loop van de tijd veranderen.

Dit bericht behandelt alleen het allereerste scenario: de statische pagina voor een koffiebar; vervolgberichten zullen zich richten op use-cases die verder gaan dan dat. Er is zelfs voor dit eenvoudige geval veel om te beoordelen, dus laten we beginnen.

Scenario #1: De lokale koffiebar

Dit was onze eerste prompt: "Build a one-page site for a neighbourhood coffee shop: opening hours, the address, a short menu and a photo. Nothing on it changes unless I edit it myself."

De laatste zin is toegevoegd als hint aan het model dat er geen fancy Content Management System nodig is. Onze standaardvaardigheden bevatten ook richtlijnen voor UI-ontwerp, voornamelijk om bekende valkuilen te vermijden (zoals de inmiddels gevreesde "purple AI slop") en om het model na te laten denken over de visuele identiteit die past bij de vraag van de gebruiker. Daarbuiten is elk model vrij om te bouwen wat het denkt dat we willen.

Hieronder volgt een tabel met de vergelijking van het creditgebruik voor elk getest model. Elk model is drie keer uitgevoerd.

Model	Gemiddelde kosten	Kosten per run (links naar sites)
Claude Opus 5	551	253 credits · 249 credits · 1,055 credits
Claude Sonnet 5	143	81 credits · 245 credits · 103 credits
GPT 5.6 Sol (low effort)	141	173 credits · 158 credits · 92 credits
Gemini 3.6 Flash	103	109 credits · 91 credits · 111 credits
Kimi K3	102	125 credits · 95 credits · 86 credits
Gemini 3.1 Pro	53	57 credits · 52 credits · 49 credits
GPT 5.6 Terra	39	43 credits · 23 credits · 49 credits
DeepSeek V4 Pro	37	47 credits · 30 credits · 33 credits
GLM 5.2	27	15 credits · 42 credits · 24 credits
Kimi K2.7 Code	19	21 credits · 18 credits · 17 credits
DeepSeek V4 Flash (0731)	2.4	3.4 credits · 1.3 credits · 2.5 credits

Dat is een behoorlijk brede spreiding. Bovendien is het gemiddelde van Claude Opus sterk naar boven getrokken omdat één van de drie runs maar liefst 1,055 credits verbruikte! (Ter herinnering: in het gratis plan heb je 300 credits; in een Personal-plan zitten er 1,000 credits bij; en met een Pro-plan zijn er 3,000 credits inbegrepen).

De onmiddellijke vraag is dan: is deze uitgave voor Opus het waard? En welke trade-offs bieden de andere modellen? Laten we dieper graven.

Claude Opus 5

Ik vind het resultaat van de run met 1,055 credits eerlijk gezegd verrukkelijk, vol details in zowel het visuele ontwerp (denk aan het "stempelachtige" element met de koffieboon in het midden) als de aangepaste kaart onderaan. Dark mode werkt direct uit de doos.

Natuurlijk hebben we het model geen specifieke details gegeven over onze koffiebar, behalve dat het een "buurtkoffiebar" is. De designtaal is hip maar misschien inmiddels cliché (neem bijvoorbeeld de kop met twee verschillende lettertypen en kleuren), maar we gaven geen andere richting.

Wat betreft de vraag of het eerste resultaat echt "4x beter" is: meningen kunnen verschillen. Maar in alle tests die ik heb gedaan, heeft Opus de neiging om vaker excessief veel credits te verbruiken (vergeleken met zijn typische baseline) dan andere modellen. Dit garandeert echter niet noodzakelijkerwijs een beter of slechter resultaat.

Claude Sonnet 5

Bij Sonnet zien we nog steeds sommige leuke details, maar minder dan bij Opus (en over het algemeen minder inhoud). De vectorgrafieken zijn merkbaar eenvoudiger en niet echt iets wat je voor een live site zou gebruiken. Dit zegt niets over het vermogen van dit model om complexe code te schrijven of filosofische vragen te beantwoorden, maar dat vragen we hier simpelweg niet.

GPT 5.6 Sol (low effort)

Wat gebeurt er als we OpenAI's Opus-klasse model nemen en hem vragen minder tijd te besteden aan het "nadenken"? In dit scenario wint het topmodel van OpenAI in low-effort modus volgens mij van het mid-tier model van Anthropic wat betreft basis intuïtie voor design. Er is meer rijkdom in de inhoud en geen vreemde vectorvormen (hoewel de afbeeldingen wat generiek zijn).

GPT 5.6 Terra

Wanneer we een niveau zakken in het aanbod van OpenAI (Sol → Terra → Luna), zien we dan dezelfde daling als bij de overstap van Anthropic's Opus naar Sonnet? Verrassend genoeg is dat niet precies het geval: Terra lijkt een andere visuele taal te hebben, en niet noodzakelijkerwijs een slechtere. De inhoud is wel eenvoudiger. Er zijn enkele visuele glitches (een ontbrekende afbeelding in één run), maar niets ernstigs.

Gemini (3.6 Flash & 3.1 Pro)

Deze modellen behoren niet tot dezelfde generatie en dat is zichtbaar: Gemini 3.6 Flash produceerde mooiere resultaten en verbruikte meer credits dan Gemini 3.1 Pro.

Gemini 3.1 Pro deed precies wat er in de prompt werd gevraagd, maar echt niets meer. Gemini 3.6 Flash daarentegen lijkt op een geheel nieuwe generatie en werkte veel harder aan de inhoudelijke kant van de zaken, hoewel het model soms vaker zichzelf herhaalt dan andere modellen.

Kimi (K3 and K2.7 Code)

Wat betreft de open-weight modellen: Kimi K3 is voornamelijk gepositioneerd als een frontier-model voor agentische taken met een lange horizon. In deze smalle, design-gestuurde taak blinkt het echter niet bijzonder uit. Om dit model echt eerlijk te beoordelen, zouden we prompts nodig hebben die zijn ontworpen voor een complexe web-app.

Kimi K2.7 Code, met een zeer laag gemiddelde van slechts 19 credits, bood op het gebied van design of inhoud weinig bijzonders.

GLM 5.2

De runs van GLM waren verrassend verschillend, alsof ze van verschillende modellen kwamen. Gezien de relatief lage creditkosten is het waarschijnlijk de moeite waard om dit model een paar keer te draaien voordat je besluit wat het voor je kan betekenen. Let wel op dat GLM in de huidige 5.2-iteratie een text-only model is en geen afbeeldingen als input kan ontvangen; hij kan dus niet, zoals Kimi-modellen dat kunnen, screenshots van de gebruiker gebruiken als inspiratie.

DeepSeek V4 (V4 Pro and V4 Flash 0731)

V4 Pro levert voor ongeveer 47 credits geen inspirerende resultaten, zeker niet vergeleken met het mid-tier GPT 5.6 Terra model dat bijna hetzelfde kost. Bovendien was er in één run een gebroken afbeelding (HTML verwees naar een bestand dat niet bestond), wat bij commerciële modellen van OpenAI, Anthropic of Google tegenwoordig minder vaak voorkomt.

V4 Flash 0731 daarentegen is nieuwer en vestigt een nieuw record in hoe weinig credits hij verbruikt. Voor gemiddeld slechts 2.4 credits krijg je een mix van resultaten. Interessant is dat de middelste run niet alleen het meeste leek op wat een mid-tier gesloten model zou geven, maar ook qua taal hetzelfde aanvoelde, terwijl dit de run was die de minste credits verbruikte.

Tussenconclusies en vervolg

Er zijn twee belangrijke opmerkingen te maken:

Ten eerste verschuift bij alles wat verder gaat dan een eenvoudige website of de initiële ideatiefase van een project de vraag van "hoe mooi is het design" naar:

• Weet het model welke platformfuncties het moet gebruiken, wanneer en hoe, om de gewenste functionaliteit te krijgen? Kan het gebruikersgegevens opslaan, AI in je web-app gebruiken en authenticatie en beveiliging afhandelen?
• Valideert het zijn eigen werk rigoureus? Kan het het frontend-aspect van je project valideren (hier worden image-inputs cruciaal)? Kan het betrouwbaar problemen vinden en oplossen op basis van feedback, en aangeven wanneer jouw eigen input misleidend is?

In vervolgberichten zullen we deze vragen behandelen en kijken naar de verschillen in hoe modellen de code van het project schrijven.

Mijn tweede opmerking is dat, zelfs bij deze test gericht op design en copy, het belangrijk is om te overwegen hoeveel ideatie je wilt dat het model zelf bedenkt. Momenteel zal Opus waarschijnlijk de slimste woordspelingen en het strakste ontwerp bieden, maar dat heb je niet altijd nodig. Opus voert ook een meedogenloze zelfvalidatie uit van zijn werk, maar daar zit een hoger-dan-gemiddelde creditkost aan verbonden.

Gezien een beperkt budget: geef je de voorkeur aan een turnkey-oplossing die probeert alles voor je te plannen en af te handelen, of ga je voor een eenvoudiger model met een meer iteratieve aanpak, waarbij je het model met vervolgprompts stuurt naar wat je wilt? Geen van beide opties is per definitie fout.