Der er en særlig type spørgsmål, der lyder teknisk, men i virkeligheden mest afslører, hvor mange penge man har lyst til at sætte ild til.
“Hvilken AI-model er bedst i Cursor?”
Jeg forstår godt spørgsmålet. Jeg har selv stillet det. Flere gange. Som regel lige efter en model har ændret seks filer, rettet tre bugs, introduceret to nye og forklaret det hele med en selvtillid, man normalt kun ser hos folk, der siger “det tager lige fem minutter”.
Men spørgsmålet er forkert.
Der findes ikke længere én bedste AI-model til at bygge software i Cursor. Ikke på en måde, der er praktisk brugbar, i hvert fald. Der findes modeller, der er bedst på bestemte tidspunkter i processen. Og det er dér, færdigheden ligger nu: ikke i at finde én model og gifte sig med den, men i at vide hvornår du skal skifte gear.
Jeg hedder Halfdan Harring, og jeg bygger produkter fra én React-codebase, der ender som web, iOS og Android via Vite, Tailwind, Capacitor, Firestore, TypeScript og Node.js. Det er en fin lille cirkusforestilling. Jeg bygger i Cursor med AI-agenter hver dag, fra et skrivebord i Aarhus, ofte med en baby i huset og derfor en meget lav tolerance for maskiner, der “næsten” har forstået opgaven. Lidt mere om mig ligger på om-siden.
Pr. slutningen af maj 2026 viser Cursor selv modeller fra OpenAI, Anthropic, Gemini, xAI og Cursor, blandt andet Composer 2.5, GPT-5.5, Opus 4.8, Gemini 3.1 Pro og Grok 4.3. Det er ikke et modelvalg. Det er en routing-menu.
Min grundregel: billig standard, dyr eskalering
Min standard er enkel:
Jeg bruger ikke den dyreste model til rutinearbejde. Og jeg bruger ikke den billigste model til beslutninger, jeg skal leve med i seks måneder.
Det lyder banalt, men det er præcis dér, mange Cursor-workflows går galt. Man sætter Opus på alt, fordi den føles klogest. Så bruger man frontier-penge på at omdøbe komponenter, rette Tailwind-klasser og flytte en helper fra én mappe til en anden. Det er lidt som at hyre en hjernekirurg til at skifte pære i bryggerset. Sikkert imponerende. Muligvis dyrt.
Omvendt kan man også køre alt gennem en billig, hurtig model og ende med kode, der teknisk set virker, men kun fordi universet endnu ikke har fået tid til at protestere.
Mit workflow i Cursor handler derfor om at starte lavt og eskalere bevidst.
Cursor Composer: min 80-procents-model
Composer er min default i Cursor.
Ikke fordi den altid er klogest. Det er den ikke. Men fordi den er hurtig, billig nok til lange sessioner og bygget til den måde Cursor faktisk bruges på: multi-file edits, agent loops, refactors, “find alle steder hvor den her type lækker ind i UI’et”, og den slags arbejde, der fylder mest på en almindelig byggedag.
Cursor introducerede Composer 2.5 den 18. maj 2026 og beskriver den som bedre til lange opgaver, mere stabil på komplekse instruktioner og bygget på samme open-source checkpoint som Moonshots Kimi K2.5. Den officielle pris er $0.50 pr. million input tokens og $2.50 pr. million output tokens, mens en hurtigere variant har samme intelligens til $3.00/$15.00.
Det vigtige ord dér er ikke “frontier”. Det er “samme intelligens”.
Jeg bruger Composer til det, jeg kalder produktionshverdagen. En ny indstillingsside i TaskMondo. En consistency-pass på components. Oprydning i props. Små Firestore-regler, der skal tilpasses. En listevisning, der skal opføre sig ens på web og i Capacitor. Ikke fordi det er ligegyldigt arbejde, men fordi det sjældent kræver den dybeste arkitektoniske dom.
Composer er god, når jeg allerede ved, hvad der skal ske.
Den skal ikke nødvendigvis beslutte, hvordan en ny del af produktet skal designes. Men den må gerne udføre planen. Det er lidt som en effektiv juniorudvikler, der ikke brokker sig over at ændre 19 filer. En kvalitet, man undervurderer, indtil man selv har ændret 19 filer.
Claude Opus: når fundamentet skal ligge rigtigt
Opus bruger jeg, når det er dyrt at tage fejl.
Det er arkitektur. Det er svære bugs. Det er situationer, hvor Cursor-agenten har været rundt i ring to gange, og jeg begynder at få den der stille fornemmelse af, at jeg selv er en del af problemet.
Anthropic beskriver Claude Opus 4.8 som deres mest kapable model til kompleks ræsonnering, long-horizon agentic coding og høj-autonomi-arbejde. Samme oversigt viser også Sonnet 4.6 som modellen med den bedste kombination af hastighed og intelligens, med lavere pris end Opus. Det passer meget godt med min brug i Cursor.
Når jeg bygger noget som LostLead eller en ny mekanik i HeadToHead, bruger jeg Opus til at tænke først. Ikke nødvendigvis til at skrive alle linjerne. Jeg giver den spec, constraints, databaseform, frontend-flow, mobilhensyn og de ting, der ikke må gå i stykker. Så beder jeg den om at finde hullerne.
Opus er bedst, når prompten er seriøs.
Ikke “lav det her”. Mere:
“Her er produktmålet. Her er min eksisterende React/Firestore-struktur. Her er de edge cases, jeg forventer. Her er de filer, jeg tror er relevante. Lav en implementeringsplan, og peg på de risici, før du rører koden.”
Det er her, Opus betaler sig selv hjem. Ikke fordi den er magisk. Den kan stadig finde på ting. Det er jo en AI-model, ikke en ældre dansk VVS’er med 38 års erfaring og en instinktiv mistillid til alt nyt. Men den er markant bedre til at holde mange hensyn i hovedet og følge en ordentlig plan.
Claude Sonnet: mellemgearet, jeg burde bruge oftere
Sonnet er den model, jeg bruger, når Composer føles lidt for let, men Opus føles som at tage taxa fra Aarhus til Vejle for at købe mælk.
Det er mellemgearet.
Jeg bruger Sonnet til mellemstore features, refactors med lidt judgment, debugging hvor problemet nok er forståeligt, men ikke trivielt, og kodegennemgang hvor jeg vil have mere kvalitet end default uden at betale toppris for hver tanke.
Hvis Opus er “læg fundamentet”, er Sonnet “byg væggene pænt”.
Den er også god, når jeg arbejder i længere tråde og vil undgå, at modellen begynder at blive for kreativ med min kodebase. Kreativitet er dejligt i et konceptoplæg. Mindre dejligt i auth-flowet.
Gemini: når hele codebasen skal med ind i rummet
Gemini bruger jeg, når problemet ikke er dybt, men bredt.
Google beskriver Gemini 3.1 Pro som en model, der kan arbejde med tekst, lyd, billeder, video, PDF’er og hele code repositories med et context window på 1 million tokens. Det er præcis dens plads i mit Cursor-flow.
Nogle opgaver kræver ikke, at modellen er den bedste filosof i lokalet. De kræver, at den kan læse meget uden at blive væk.
Eksempel: Jeg har én React-codebase, der skal fungere på web, iOS og Android. Det betyder, at en lille ændring i routing, storage, permissions eller UI-state kan have konsekvenser tre steder. Når jeg vil lave en stor consistency-pass, finde duplikeret logik eller forstå hvordan en type bruges på tværs af appen, er Gemini ofte stærk.
Jeg bruger den til spørgsmål som:
“Hvor i codebasen håndterer vi denne status?”
“Find alle steder, hvor denne Firestore-struktur antages.”
“Er der forskel på web- og native-flowet her?”
Det er ikke altid den model, jeg lader udføre hele ændringen. Men den er fremragende til at lave kortet, før jeg begynder at køre bilen.
Jeg har skrevet mere om mit praktiske AI-agent workflow i Cursor i Vibe coding i virkeligheden.
GPT-5.5 i Codex: terminalen, builds og alt det beskidte arbejde
GPT i Codex bruger jeg især, når arbejdet lugter af terminal.
Build-fejl. Deploy. Scripts. Package-problemer. Node/TypeScript/ESM-konflikter. Capacitor, der har besluttet sig for at være en gåde pakket ind i en native build-folder.
OpenAI beskriver GPT-5.5’s styrker i Codex som engineering work fra implementation og refactors til debugging, testing og validation, og deres egne evalueringer viser blandt andet en høj score på Terminal-Bench 2.0 sammenlignet med Opus 4.7 og Gemini 3.1 Pro.
Det matcher min erfaring: Når der skal køres kommandoer, læses output, justeres, køres igen og forstås hvorfor npm run build lyver på en anden måde end vite build, så er Codex ofte den klareste.
Jeg stoler mere på Codex til at arbejde iterativt i shellen end Composer. Ikke fordi Composer ikke kan. Men Codex virker mere hjemmevant i “kør, læs fejl, korrigér, test igen”-sløjfen. Den har en praktisk sans for værktøjer, der er rar, når man ikke selv gider være CI-whisperer klokken 22.47.
Grok: hurtig, billig og ikke min chefarkitekt
Grok er min skitseblok.
xAI lister Grok 4.3 med 1 million tokens i context og priser på $1.25 pr. million input tokens og $2.50 pr. million output tokens, mens Grok Build 0.1 beskrives som en hurtig coding-model til agentic coding workflows.
Jeg bruger Grok til throwaway scripts, idéer, navngivning, hurtige helper-funktioner, “giv mig fem måder at angribe det her på”, og små ting, hvor konsekvensen af fejl er lav.
Jeg bruger den ikke til seriøs produktionsarkitektur.
Det er ikke en fornærmelse. Jeg bruger heller ikke en lommekniv til at bygge et køkken. Den kan være praktisk. Den skal bare ikke have ansvaret for bærende konstruktioner.
Grok er fin, når jeg vil hurtigt videre. Hvis den laver noget dumt, sletter jeg det. Det er en sund relation.
Min faktiske routing i Cursor
Når jeg starter en ny opgave, vælger jeg ikke model ud fra prestige. Jeg vælger ud fra risiko.
Hvis opgaven er rutine og veldefineret, starter jeg med Composer. “Tilføj den her UI-state”, “ret de her komponenter”, “opdatér typerne”, “flyt logikken ind i en hook”. Den slags.
Hvis opgaven kræver en plan, starter jeg med Opus. Især før større features. Jeg vil hellere betale for god tænkning i starten end for oprydning senere. Oprydning senere har en særlig duft. Lidt som varm printer.
Hvis opgaven er mellemstor, bruger jeg Sonnet. Den er fornuftig. Man skal ikke undervurdere fornuft. Det er sjældent trendy, men det overlever ofte deploy.
Hvis opgaven kræver overblik over mange filer, bruger jeg Gemini. Den får lov til at læse bredt, finde mønstre og pege på konsekvenser.
Hvis terminalen er centrum, går jeg til Codex. Builds, scripts, deployment og fejloutput. Alt det, der føles som at diskutere med en meget formel kælder.
Hvis opgaven er billig at smide væk, bruger jeg Grok. Brainstorm. Små scripts. Dummy-data. Første version af noget, jeg alligevel forventer at kassere.
Det er mit system. Ikke perfekt. Men det gør én ting godt: Det forhindrer mig i at overbetale for trivielle ændringer og underbetale for beslutninger, der betyder noget.
Den rigtige model er et tidspunkt, ikke et logo
Den største fejl i AI-kodning lige nu er at behandle modeller som religioner.
“Jeg er Opus-person.”
“Jeg bruger kun GPT.”
“Gemini har størst context.”
“Composer er billigst.”
Når du bygger rigtige produkter, er modellen kun én del af arbejdet. Spec’en betyder noget. Context betyder noget. Tests betyder noget. Din evne til at stoppe agenten, før den bliver for hjælpsom, betyder meget.
Det gode Cursor-workflow er ikke at finde én model og lade den køre hele vejen fra idé til App Store. Det gode workflow er orchestration: start billigt, eskalér når risikoen stiger, brug lang context når bredden er problemet, brug terminalstærke modeller når værktøjerne er problemet, og brug de dyre modeller dér, hvor deres dømmekraft faktisk kan mærkes.
Det er mindre romantisk end “AI bygger min app for mig”.
Til gengæld virker det bedre. Og der er jo også en vis charme i software, der ikke kun fungerer i demoen.