track
GPT-5.6 Sol kom till Cursor den 9 juli 2026, samma dag som OpenAI öppnade modellen för allmänt bruk, och det är nivån OpenAI prioriterar för kodning. Det som sticker ut är att den håller tråden genom en lång agentkörning utan att tappa bort vad den gör, vilket är precis vad Cursors agentläge kräver av en modell: planera, redigera flera filer samtidigt, köra dina tester, läsa utdata när något fallerar och loopa tillbaka på egen hand.
Cursor är byggt kring den loopen i stället för att vara påklistrat på en vanlig editor, så en modell som håller fokus genom hela flödet är värd att lära sig ordentligt.
Vi ska därför bygga ett litet REST-API för budgetspårning från grunden, med GPT-5.6 Sol som gör grovjobbet i agentläge vid varje väsentligt steg. På vägen ser du hur du väljer rätt modellvariant, skriver en AGENTS.md-fil som håller agenten på rätt spår, och strukturerar en validerings- och granskningscykel som fångar problem innan de når en pull request.
Om du är ny på Cursor täcker vår Software Development with Cursor-kurs grunderna som den här handledningen utgår från.
Vad är Cursor?
Cursor började som VS Code med AI-funktioner insydda, och på ytan ser det fortfarande ut så. Editorn, filträdet, terminalen, tilläggen—allt är bekant.
Det som har byggts om under ytan är antagandet att AI:n inte bara svarar på frågor vid sidan av, utan faktiskt arbetar tillsammans med dig, vilket är varför du får agentläge, kodbasindexering, en modellväljare som låter dig byta mellan frontmodeller mitt i en session, och inline-kompletteringar som förutser ditt nästa steg baserat på hela kontexten av vad du har gjort.
Om du vill utforska Cursors senaste funktioner vidare rekommenderar jag att läsa våra handledningar om Cursor Automations och Cursor SDK.
Vad är GPT-5.6?
GPT-5.6 är OpenAI:s senaste modelgeneration, och det är inte en modell utan tre: Sol, Terra och Luna. Dessa namn är tre distinkta kapacitetsnivåer som ersätter den gamla etiketten "Instant".
Här är familjen i korthet:
-
Sol är flaggskeppet och den starkaste av de tre. Det är den enda nivån som låser upp den nya
max-resoneringsinsatsen ochultra-läget, och det är där vinsterna inom kodning, biologi och cybersäkerhet är störst. -
Terra är vardagsstandarden. OpenAI positionerar den som konkurrenskraftig med GPT-5.5 till ungefär halva priset.
-
Luna är den snabba, billiga nivån för hög volym eller latenstkänsligt arbete, och den är starkare än prislappen antyder.
För en kodgenomgång är Sol nivån som spelar roll, så det är den vi använder här. Två inställningar på Sol är nya, och det är värt att veta vilken du faktiskt kommer använda. max är en resonemangsnivå över xhigh som låter en enskild agent lägga mer tid på ett svårt problem, och det är toppen av stegen du sätter i Cursor. ultra, som delar upp arbete över parallella underagenter, ger OpenAI:s bästa benchmark-siffror (91,9% på Terminal-Bench 2.1) men körs bara i Codex och API:et, så du hittar det inte i Cursors väljare.
För hela benchmark-tabellen och den tredelade prissättningen, se vår guide till GPT-5.6 Sol, Terra och Luna.
Hur du får åtkomst till och konfigurerar GPT-5.6 Sol i Cursor
GPT-5.6 Sol finns i Cursors modellväljare, och det finns en sak att veta direkt: likt Cursors andra senaste frontmodeller körs Sol endast i Cursors Max Mode. Det innebär att den använder hela kontextfönstret och alla verktyg, och debiteras efter användning snarare än per förfrågan, så håll koll på tokenförbrukningen under långa körningar.
Så här väljer du modellen:
- Öppna agentpanelen med Cmd+L (Mac) eller Ctrl+L (Windows/Linux).
- Klicka på knappen Model längst ner i inmatningsfältet (den visar det aktuella modellnamnet bredvid en liten ikon).
- Stäng av Auto om den är på.
- Hitta GPT-5.6 Sol i listan och klicka på Edit bredvid den.
- En panel öppnas till höger där du oberoende kan ställa in kontextfönster, resonemangsnivå och snabbväxling.

Välja rätt resonemangsinsats
Att välja Sol väljer modellen; resonemangsinsatsen avgör hur hårt den tänker på en given uppgift. Du kan välja mellan:
- Ingen
- Låg
- Medel
- Hög
- Extra hög
- Max
Ingen och Låg är snabbast och billigast, tillräckligt för autokompletteringar eller en mekanisk refaktorering där du i princip redan vet vad du vill ha.
Hög och Extra hög tar längre tid eftersom de faktiskt tänker igenom problemet först, och du märker den skillnaden mest när du ber agenten planera något som korsar flera filer eller felsöka ett fel där källan inte är uppenbar direkt.
Max ligger över Extra hög och ger en enskild agent mest tid att arbeta med ett svårt problem. Sols ultra-multigentläge finns bara i Codex och API:et, så du ser det inte i Cursors väljare.
En varning om du kommer från GPT-5.5: nivåerna mappar inte över. OpenAI:s egen vägledning är att börja en nivå lägre än du är van vid på en bekant uppgift och bara skruva upp den om resultatet behöver det. Jag har följt det nedan, så några av stegen körs på en lägre insats än motsvarande 5.5-handledning skulle ha gjort.
Genom de praktiska stegen nedan föreslår jag vilken resonemangsnivå som är mest rimlig för varje uppgift, men känn dig fri att experimentera med olika inställningar och se hur resultatet förändras.
Välja storlek på kontextfönster och hastighetsläge
Du kan också välja mellan ett 272K- och 1M-kontextfönster, och slå på läget Fast för att generera token ungefär 1,5x snabbare till cirka 2,5x kreditkostnad. För interaktivt fram-och-tillbaka när du väntar på svar är Fast ofta värt det. För en längre bakgrundsuppgift där du har lämnat över något och gör annat under tiden går det bra att lämna det av.
Konfigurera Cursor
Låt oss ställa in projektet i Cursor.
Förutsättningar och initial konfiguration
En betald Cursor-plan (Pro eller högre) krävs för GPT-5.6 Sol, och eftersom Sol körs i Max Mode behöver användningsbaserad prissättning vara aktiverad på ditt konto. Python 3.11+ är det enda övriga lokala beroendet du behöver för det här projektet. Om Cursor inte är installerat ännu, hämta det på cursor.com, logga in och kör sedan från en terminal:
mkdir budget-api && cd budget-api
git init
cursor .

Agentpanelen är till höger, och filutforskaren till vänster visar inga filer ännu, precis där du vill börja innan du låter agenten bygga strukturen.
Navigera Cursors AI-ytor
Innan vi går in i själva bygget är det värt att veta vilka de tre huvudsakliga interaktionslägena är och när varje passar, för att använda fel läge skapar friktion som är lätt att undvika.
Inline-komplettering är bakgrundslagret för autokomplettering. När du skriver visas grå förslag baserat på vad du skriver och omgivande kontext i filen, och du accepterar dem med Tab. Du anropar det inte; det dyker bara upp. Det här är rätt läge när du skriver kod för hand och vill att modellen ska minska antalet tangenttryck utan att avbryta flödet.
Ask-läge är där du kan låta modellen läsa dina filer och svara på frågor utan att göra några ändringar. Tänk på det som att be en kollega titta på koden och berätta vad de ser. Det är särskilt användbart när du är i en obekant kodbas, försöker förstå varför något skrevs på ett visst sätt, eller bara tänker igenom ett angreppssätt innan du kommitterar till det.
Agentläge driver hela den här handledningen. I en agentsession redigerar modellen filer, kör terminalkommandon, installerar paket, kör din testsuite, läser utdata och loopar tillbaka på fel, allt i en sammanhängande tråd. Det här är läget där du lämnar över en uppgift snarare än bara frågar om den, och kvaliteten på det du får tillbaka skalar direkt med hur mycket kontext du ger från början. Du ser väljaren för Agentläge längst ner till vänster i panelen i skärmdumpen ovan.
Etablera projektspecifik vägledning med AGENTS.md
Du skriver den här filen själv, så ingen modell ännu. Växla till Hög först, eftersom nästa prompt är när agenten läser den. De flesta agentsessioner går snett, inte för att modellen gör fel, utan för att den inte visste något projektspecifikt och gissade: ditt ramverk, dina namngivningskonventioner, vilka filer som är off-limits, hur man verifierar ändringar.
Det är vad AGENTS.md är till för: en README för agenten, där du skriver ner vad som är uppenbart för dig men osynligt för modellen. AGENTS.md började som ett OpenAI-initiativ 2025 och är nu standarden över verktyg för agentinstruktionsfiler (del av Linux Foundations Agentic AI Foundation, tillsammans med Anthropics MCP), så det är värt att lära sig en gång och använda överallt.
Skapa en fil som heter AGENTS.md i projektroten med följande för att sätta din projektstack, kodningskonventioner och gränser:
# AGENTS.md
## Stack
Python 3.11, FastAPI, SQLModel, SQLite (via aiosqlite), pytest, httpx
## Conventions
- All endpoints under /api/v1/
- Pydantic models in app/models.py
- Database logic in app/database.py
- Route handlers in app/routers/
- Type hints required on all function signatures
- Explicit imports only, no wildcards
## Boundaries
- Do not delete or modify any file in tests/ without asking first
- Do not change the DATABASE_URL; it reads from .env
- Never touch pyproject.toml dependencies without showing the diff first
## Verification
Before considering any task complete:
pytest tests/ -v
ruff check .
Both must pass.
Avsnittet om gränser är det som folk oftast hoppar över, och det är också det viktigaste. Utan det bestämmer sig agenter ibland för att "hjälpa till" genom att organisera om eller städa upp saker du inte bad dem röra. Att berätta för modellen vad som är förbjudet är minst lika användbart som att berätta vad den ska göra.
AGENTS.md är standard över verktyg, men om du vill ha den Cursor-inhemska motsvarigheten som gör samma jobb via avgränsade .mdc-filer, går vår handledning Cursor Rules igenom att bygga ett set för ett Python-webbprojekt.
Bygga ett Budget Tracker-API med GPT-5.5
Projektet är ett REST-API för att spåra personliga budgetposter. Du kan skapa poster, lista dem med valfri kategorifiltrering, ta bort dem och hämta en månatlig utgiftssammanställning.
Det är tillräckligt enkelt för att följa utan att gå vilse i domänlogik, men implementeringen involverar ett databaslager, inmatningsvalidering, typade svarmodeller och flera routhanterare som arbetar tillsammans, vilket räcker för att visa vad agenten faktiskt gör i en verklig session över flera filer.
Steg 1: Skapa projektets stomme
Öppna agentpanelen och ställ in resonemangsinsatsen på Hög innan du skickar något. Planen som agenten producerar innan den skriver någon kod är bara så användbar som resonemanget bakom, och ett ytligt svar i det här skedet innebär strukturella beslut du kommer att behöva reda ut senare. Fortsätt genom att skicka detta som din första prompt:
Set up a FastAPI project for a budget tracker API using SQLModel with
async SQLite. Structure it with separate files for models, database, and
routes under an app/ directory. Set up pyproject.toml with uv, install
dependencies, and create a main.py that starts the app.
Before writing any code, show me the planned directory structure
and wait for my approval.
Den sista raden är värd att ha med i alla dina icke-triviala agentprompter. Att be om planen innan utförande kostar dig kanske 15 sekunders läsning, men låter dig fånga strukturella beslut innan de har spridit sig över ett dussin filer.
GPT-5.6 Sol på Hög resonemang ger planer som är tillräckligt specifika för att faktiskt vara användbara, inte vaga sammanfattningar, och att granska strukturen nu går mycket snabbare än att organisera om senare.

Agenten föreslår projektlayouten och väntar på godkännande innan den skriver en enda fil.
När du svarar med något i stil med "Ser bra ut, kör på" börjar agenten bygga. Du kan se filträdet till vänster fyllas på i realtid när den skapar filer, medan terminalen längst ner visar uv installera paket.

Agenten skapade en pyproject.toml som en del av stommen, med filinnehållet visat som en ny tilläggning.
Efter att stommen är klar, ta en minut att öppna app/models.py och app/database.py innan du går vidare. Bekräfta att BudgetEntry-modellen har åtminstone följande fält id, amount, description, category och date, och att database.py sätter upp den asynkrona SQLite-motorn utan något ovanligt.
Om något ser fel ut, säg det i nästa meddelande i stället för att fortsätta. Rättelser i det här skedet är billiga; efter att tjugo filer har ändrats är de det inte.
Steg 2: Implementera kärnendpunkterna
Behåll insatsen på Hög, eller testa Medel först, eftersom Sol på Medel hanterar koordinerat multifilsarbete som skulle ha behövt Hög på GPT-5.5. Skicka implementeringspromten:
Implement endpoints for budget entries under /api/v1/entries/. Include:
- POST /api/v1/entries/ to create a new entry, returning 201
- GET /api/v1/entries/ to list all entries, with an optional ?category= filter
- DELETE /api/v1/entries/{id} to delete an entry, returning 404 if not found
Use typed Pydantic response models and dependency injection for the DB session.
After implementing, start the app and confirm the /docs endpoint loads.
Agenten rör models.py, database.py, routers/entries.py och main.py i en enda koordinerad pass. När den slutför varje fil visar Cursor det nya innehållet markerat i editorn så att du kan granska innan du accepterar. Du ser Undo/Keep-kontrollerna längst ner i varje ändrad fil.

Skärmdumpen visar routern entries.py efter att agenten har implementerat den, tillsammans med agentens bekräftelse på att servern startades och att /docs-endpunkten laddades korrekt.
När implementeringen har accepterats och servern körs, öppna http://localhost:8000/docs i din webbläsare för att bekräfta att allt är korrekt ihopkopplat.
De FastAPI-autogenererade dokumenten på /docs som visar att alla tre endpunkter är korrekt registrerade.
Steg 3: Lägg till kategorivalidering
För det här tredje steget kan du sänka modellens resonemang till Låg eller Medel. Att lägga till ett enum och två tester är tillräckligt avgränsat och förutsägbart för att du inte behöver att modellen bränner extra överväganden på det.
För närvarande accepterar API:et vilken sträng som helst som kategori, vilket innebär att du snabbt får inkonsekventa data. Låt oss åtgärda det:
Budget entries should only accept these categories:
food, transport, housing, entertainment, health, other.
Reject any entry with an invalid category using a 422 status and a clear
error message. Use a Python Enum for the category type.
Add tests for both a valid category submission and an invalid one in tests/test_entries.py.
Agenten kommer att lägga till ett kategori-enum i models.py och uppdatera Pydantic-modellen så att den använder den. Eftersom Pydantic automatiskt validerar mot enum:et avvisas ogiltiga kategorier innan routhanteraren ens körs.
Den bör skriva två tester vid sidan av: ett som bekräftar att en giltig kategori sparas korrekt, ett annat som bekräftar att en ogiltig ger 422.
Använda @-referensen
Efter att ha accepterat de ändringarna, testa Cursors @-kontextfunktion för att ställa en snabb verifieringsfråga:
@app/models.py Does the CategoryEnum cover all six categories I listed?
Att skriva @ i agentpanelen öppnar en filväljare, och när du väljer app/models.py dras filens innehåll direkt in i prompten utan att agenten behöver söka efter den eller göra antaganden om sökvägen.

Steg 4: Bygg endpunkten för månadssammanfattning
Växla tillbaka till Hög här. Aggregeringsfrågan kräver att agenten resonerar om filtrering, gruppering och svarmodellering tillsammans, och om något av dessa blir fel kräver det ändringar i alla tre filerna igen. Med kärn-CRUD på plats, lägg till sammanfattningsendpunkten:
Add a GET /api/v1/entries/summary endpoint that accepts month (1-12) and year as query parameters.
It should return total spending per category for that month and an overall total.
Use a typed Pydantic response model.
If no entries exist for the requested month, return an empty summary with zero totals rather than a 404.
Det här är en mer intressant databasuppgift eftersom den kräver en filtrerad fråga med aggregering snarare än ett rent select-all. Titta på hur agenten strukturerar frågan i database.py; den bör använda SQLModels frågegränssnitt i stället för rå SQL, och resultatet ska mappa rent till svarmodellen som definieras i models.py.
Efter att ha accepterat ändringarna, skriv ett test för den här endpunkten själv i test_entries.py. Skapa två poster i en specifik månad, anropa sammanfattningsendpunkten för den månaden och kontrollera att totalerna stämmer. Att skriva det här manuellt i stället för att be agenten är ett bra sätt att bli bekant med hur testklienten och fixtures är strukturerade.

Filen test_entries.py visar de agent-skrivna kategorivalideringstesterna tillsammans med den manuellt skrivna funktionen test_monthly_summary.
Steg 5: Kör valideringsloopen
Låg eller Medel resonemang fungerar utmärkt här; att köra tester och fixa lintproblem är reaktivt arbete—agenten läser felutdata och tillämpar riktade fixar snarare än att fatta några verkliga arkitekturbeslut. Lämna tillbaka testningen till agenten:
Run pytest tests/ -v and fix any failing tests.
Do not modify test assertions to make them pass, fix the implementation instead.
Once all tests pass, run ruff check . and fix any linting issues.
Följ agentpanelen när den strömmar pytest-utdata.
Om något fallerar läser agenten tracebacken, identifierar vilken fil som introducerade problemet och tillämpar fixen, allt inom samma session. Du kopierar inte in felet i ett nytt meddelande; hela felsöknings- och fixloopen sker i en sammanhängande tråd.

Skärmdumpen visar att agenten återrapporterar efter hela valideringsloopen. I det här fallet stötte ruff-kontrollen på ett tolkupplösningsproblem orsakat av en pyenv/.python-version-mismatch på den lokala maskinen, inte ett kodproblem.
Det är värt att notera vad som hände här: agenten stötte på ett miljöproblem orelaterat till koden vi skrev, resonerade kring orsaken och hittade en workaround utan att bli uppmanad. Den typen av kontextuellt problemlösande över verktygsfel är precis där GPT-5.6 Sol drar ifrån tidigare modeller.
Det är också värt att ta med "ändra inte testassertioner för att få dem att gå igenom" i varje valideringsprompt du skriver. Utan den instruktionen tar agenter ibland den enklaste vägen och försvagar vad ett test kontrollerar i stället för att fixa det faktiska beteendet.
Steg 6: Kodgranskning
Ställ tillbaka resonemanget till Hög innan du skickar detta, eller Extra hög/Max om du vill att Sol ska gnugga igenom edge cases som en enskild Hög-pass kan skumma förbi. I det här steget skapar grunt resonemang en falsk trygghet; du vill att modellen faktiskt ska arbeta igenom alla potentiella problem, inte bara mönstermatcha mot de mest uppenbara.
Innan du kallar projektet klart, använd agenten för en granskning:
Review the current codebase and report on:
1. Query params or path params that are missing validation
2. Database sessions that might not be closing properly
3. Endpoints returning incorrect HTTP status codes
4. Any places where user input reaches the database without going
through the ORM
Do not make any changes yet. List each issue with file and line number.

Agenten fann att DELETE /api/v1/entries/{entry_id} korrekt returnerar koderna 204 och 404 (med fil:rad-referenser), att GET-rutter förlitar sig på korrekta 200-standarder och bekräftade att ingen användarinmatning når databasen utanför ORM:en.
När du har granskat listan, skicka uppföljningen för att tillämpa fixarna:
Apply the fixes for the status code issues and the session handling.
Skip any rate-limiting suggestions, that's out of scope for this version.
Run the tests again after applying.
Steg 7: README och CI-arbetsflöde
Två sista detaljer för att knyta ihop projektet ordentligt. Du kan sänka modellens resonemang till Låg för båda dessa. README-strukturen är förutsägbar, och CI-YAML:en är i princip boilerplate, så det finns inget att resonera om, och att betala för högt resonemang här är bara bortkastade krediter.
Write a README.md with setup instructions, a table of all endpoints (method, path, description), and example curl commands for each endpoint.
Och sedan:
Create a .github/workflows/ci.yml that runs pytest and ruff on Python 3.11 for every push and pull request to main.
Efter alla sju steg ser projektstrukturen ut så här:

Avslutande tankar
Det vi byggde här är ett litet API, men arbetsflödet skalar till vad som helst.
Få på plats AGENTS.md innan agenten rör en enda fil. Be om planen före utförande för allt icke-trivialt. Stega dina prompter så att du har naturliga kontrollpunkter i stället för en gigantisk diff att granska på en gång. Använd @filnamn när du vill fråga något riktat om en specifik fil. Och kör en granskningspass innan du anser en uppgift klar, för du kommer nästan alltid att hitta något.
GPT-5.6 Sol i Cursor är märkbart bättre än tidigare kombinationer på att hålla fokus över långa sessioner, fånga inkonsekvenser mellan filer och veta när den ska pausa och stämma av i stället för att rusa fram med något destruktivt. Men modellen är bara en del av bilden. Kontexten du ger i början, valideringslooparna du kör och granskningspasset på slutet—det är där den verkliga förbättringen i utdatakvalitet kommer från.
En bra tumregel för resonemangsnivåer: använd Hög för arkitekturbeslut, koordinering över flera filer och felsökning av något icke-uppenbart; använd Medel eller Låg för dokumentation, boilerplate och enkelfilsändringar där du bara ber modellen göra skrivjobbet. Överväg Extra hög eller Max för kodgranskningar och där misstag är dyrare än en grundlig agentkörning.
Vanliga frågor
Vem kan använda GPT-5.6 Sol i Cursor idag?
Endast betalda planer. Användare på gratisnivån har inte åtkomst, och eftersom Sol körs i Max Mode behöver du ha användningsbaserad prissättning aktiverad på ditt konto. Utrullningen har skett kontovis, så om du inte ser den i din modellväljare ännu är GPT-5.5 ett rimligt alternativ, och arbetsflödet i den här handledningen fungerar i princip identiskt med den.
Vad ändrar resonemangsnivåerna i GPT-5.6 Sol egentligen?
Hur mycket modellen överväger innan den svarar. Låg ger dig ett snabbt, ganska ytligt svar, vilket räcker för en snabb enkelfilsändring eller en "vad gör den här funktionen"-fråga. Hög och Extra hög tar märkbart längre tid men arbetar faktiskt igenom problemet först, och Max ligger en nivå över det för de svåraste en-agent-problemen, där skillnaden märks på arkitekturbeslut, koordinering över flera filer eller felsökning där grundorsaken inte ligger på ytan.
Behöver jag ett separat OpenAI-konto för att använda GPT-5.6 Sol i Cursor?
Nej. Cursor hanterar modellåtkomst via sin egen debitering.
Vad exakt ska ingå i en AGENTS.md-fil?
Din stack, dina namngivningskonventioner, vilka filer eller kataloger agenten inte ska röra och hur man kör och verifierar tester. Agenten är bra på mjukvara i allmänhet, men vet ingenting om ditt specifika projekt utan detta. Du ser ett komplett exempel i avsnittet om uppsättning.
Hur mycket bättre är GPT-5.6 Sol jämfört med GPT-5.5 på verkliga kodningsuppgifter?
På rå benchmark-poäng, mindre än du kanske tror: på Terminal-Bench 2.1, som testar verkliga kommandoradsarbetsflöden snarare än syntetiska problem, får Sol 88,8% mot 88,0% för GPT-5.5. Vinsterna handlar mer om effektivitet och uthållighet än om en rubriksiffra, eftersom Sol slutför arbete med färre token och håller uppgiftsfokus bättre över långa körningar, vilket är precis vad multifilsarbetet i den här handledningen bygger på. Cursor kallar den en av de starkaste modellerna de testat på CursorBench, där Sol får 67,2% på Max-insats.
