Cursor har i årevis solgt sig selv på hurtig autocomplete og en agent, der kan løse én opgave ad gangen i en chat. Den 10. september 2026 ændrede det sig, da firmaet lancerede Projects, en ny arbejdsform, hvor en koordinator-agent tager imod en større opgave, som en hel funktion eller en migrering, og selv fordeler arbejdet ud til flere subagenter. Du chatter ikke længere med agenten, der skriver koden. Du chatter med lederen, der uddelegerer den.
Denne guide viser dig, hvordan du kommer i gang med Cursor Projects fra bunden: fra at oprette dit første Project og forbinde et repository, til at sætte automatiske triggere op via Slack og pull requests, og hvordan du styrer forbrug, når koordinatoren begynder at oprette flere agenter samtidig. Vi gennemgår tretten konkrete trin, bygger et komplet eksempel undervejs, og runder af med fem faldgruber, otte fejlfindingscases og en liste med ofte stillede spørgsmål.
Guiden henvender sig til udviklere og teamledere, der allerede bruger Cursor i det daglige, men endnu ikke har afprøvet den nye koordinator-model. Du behøver ikke forstå detaljerne bag store sprogmodeller for at følge trinene. Du skal blot have et repository at pege koordinatoren mod og en plan for, hvor meget ansvar I er villige til at lægge over til den, før I lader den arbejde uden opsyn. Er du ny til AI-kodeværktøjer generelt, kan du også kigge forbi vores samlede dækning af udviklerværktøjer for en bredere introduktion.
Hvad er Cursor Projects?
Ifølge Cursors officielle dokumentation er et Project beregnet til en større mængde arbejde end en enkelt chatbesked, for eksempel en ny feature, en større migrering eller en hel app. I stedet for at åbne en ny samtale for hver opgave, holder du én vedvarende tråd åben med en koordinator-agent, som kan leve videre i dagevis eller måneder. Koordinatoren planlægger arbejdet, opretter de agenter, der skal udføre det, og samler resultatet, når det er klar til din gennemgang.
Det centrale skift er, at koordinatoren selv ikke rører ved koden. Den fungerer som en slags projektleder, der læser din opgave, laver en plan, og sender delopgaver videre til andre agenter, som gør det faktiske arbejde: skriver kode, kører tests, undersøger fejl. Cursor formulerer det sådan:
“The coordinator doesn’t write code itself but directs other agents that do.”
Cursor, officiel blog (cursor.com/blog/projects)
På dansk: koordinatoren skriver ikke selv kode, men dirigerer andre agenter, der gør det. Funktionen kom i beta og rulles ud til alle brugere fra lanceringsdagen, ifølge Cursors eget changelog. Det er altså ikke en lukket enterprise-funktion forbeholdt de dyreste planer, men noget alle med en Cursor-konto kan afprøve, mens Cursor stadig finpudser detaljerne.
Timingen er ikke tilfældig. Cursors moderselskab Anysphere har været i søgelyset hele efteråret, blandt andet i forbindelse med det opkøb fra SpaceX, som vi har dækket tidligere på Shattered, og konkurrencen fra GitHub Copilot, JetBrains og en række nyere agent-værktøjer er hård. En funktion, der lover at fordele arbejde ud til “så mange agenter, som opgaven kræver”, som det hedder i dokumentationen, er et forsøg på at gøre Cursor til mere end en editor med god autocomplete. Det er et forsøg på at gøre Cursor til den, der styrer hele arbejdsprocessen.
For danske og nordiske teams er der en ekstra dimension at forholde sig til. Fordi koordinatoren som udgangspunkt kører i Cursors sky, bør I overveje, hvilken kode og hvilke kommentarer der reelt sendes ud af jeres eget netværk, når et Project får adgang til et repository. Det gælder især, hvis kodebasen indeholder kundedata i testfiler, konfigurationsnøgler eller andet, der falder ind under GDPR. Vi kommer tilbage til, hvordan selvhostet udførelse kan afhjælpe en del af det, men ikke det hele, senere i guiden.
Cursor Projects vs. Composer og agent-tilstand
Hvis du allerede kender Cursor fra vores guide til Composer og MCP, er det oplagt at spørge, hvad Projects egentlig tilføjer. Forskellen ligger i, hvor meget ansvar du lægger over til værktøjet, og hvor længe konteksten holder mellem sessioner.
| Egenskab | Composer / agent-tilstand | Cursor Projects |
|---|---|---|
| Hovedformål | Løs én konkret opgave i en aktiv session | Håndter en større, vedvarende opgave over flere dage eller måneder |
| Hvem skriver koden | Den aktive agent selv | Subagenter, som koordinatoren opretter og styrer |
| Kontekst mellem sessioner | Typisk bundet til én chat eller ét vindue | Bevares i tråden, så koordinatoren husker tidligere beslutninger |
| Parallelitet | Én arbejdsgang ad gangen som standard | Flere agenter kan arbejde samtidig på forskellige dele |
| Eksterne triggere | Starter typisk ved en prompt fra dig | Kan reagere på tidsplaner, Slack-beskeder og pull requests |
| Udførelsessted | Lokalt i editoren eller som cloud-agent | Cloud som standard, med mulighed for selvhostet udførelse |
| Bedst til | Fokuseret implementering, debugging, refaktorering | Store, tilbagevendende eller asynkrone opgaver |
Hvornår skal du vælge hvad
Tommelfingerreglen er enkel. Skal du rette en bug, refaktorere en funktion eller svare på et spørgsmål om koden lige nu, er en almindelig agent-session eller Composer stadig det hurtigste valg. Skal du derimod bede Cursor om at bygge en hel feature fra bunden, migrere et helt modul til et nyt bibliotek, eller holde øje med indkommende pull requests over en uge, er det Projects, der giver mening. Mange teams ender med at bruge begge dele side om side: Composer til det daglige, og et enkelt Project til den store opgave, der ellers ville kræve et helt sprint at holde styr på manuelt.
Et konkret eksempel: skal en udvikler i morgen tidlig lave en hurtig rettelse af en valideringsfejl i et formular-felt, er det en Composer-opgave, der er løst på ti minutter. Skal teamet derimod bruge de næste to uger på at udskifte hele frontend-rammeværket fra en ældre version til en nyere, med hundredvis af berørte filer, er det langt mere naturligt at lade et Project holde styr på fremdriften, mens flere subagenter arbejder på forskellige moduler samtidig.
Der er også en praktisk grund til at holde de to arbejdsformer adskilt i starten. Fordi et Project kan sætte flere agenter i gang parallelt, er fejlretning sværere, hvis du blander en hurtig Composer-session ind i samme repository, mens koordinatoren allerede har uddelegeret arbejde der. Lad Projects få sit eget rum, indtil I har opbygget en fornemmelse for, hvor lang tid koordinatoren typisk bruger på en given opgavetype.
Forudsætninger: dette skal du have klar
Før du kaster dig ud i det første Project, bør følgende være på plads. Listen er kort, men den sparer dig for en del frustration, når koordinatoren begynder at oprette agenter, du ikke havde forventet.
- Cursor version 2.x eller nyere: Projects ligger i Agent-vinduet, som kræver en opdateret klient. Ældre versioner viser slet ikke menupunktet.
- En aktiv Cursor-konto: Hobby, Pro, Pro+ eller Ultra. Funktionen ruller ud til alle planer i beta, men forbrugsgrænserne varierer markant, som vi kommer tilbage til.
- Et GitHub- eller GitLab-repository: koordinatoren skal have adgang til en kodebase for at kunne uddelegere arbejde meningsfuldt.
- Klare rettigheder på repositoriet: skal agenterne kunne oprette branches og pull requests, kræver det skriveadgang, ikke kun læseadgang.
- Forbindelse til Slack, hvis du vil bruge den trigger: kræver en separat godkendelse af Cursors Slack-app i dit workspace.
- Et realistisk billede af jeres forbrug: cloud-udførelse afregnes efter model og tokens, så en stor, uovervåget opgave kan blive dyrere end forventet, hvis ingen holder øje.
Har I allerede sat MCP-servere op til Cursor, som beskrevet i vores guide til MCP-serveropsætning, genbruger Projects de samme forbindelser. Du behøver ikke konfigurere adgang til værktøjer og datakilder to gange.
Endelig bør I afklare internt, hvem der har mandat til at oprette nye Projects. Fordi et Project kan trække et betydeligt forbrug og røre ved produktionskode, bør det ikke stå åbent for hele udviklingsteamet uden nogen form for aftale om, hvilke repositories og opgavetyper der er i spil. En kort intern retningslinje, gerne skrevet ned et sted alle kan finde den, sparer jer for overraskelser senere.
Det er også en god idé at udpege én person som ansvarlig for at følge op på Cursors changelog i de første måneder efter lancering. Fordi Projects stadig er i beta, ændrer detaljer i brugerfladen, triggere og prissætning sig oftere end i en færdigmodnet funktion, og det er lettere at holde styr på ændringerne, når ansvaret ligger ét sted frem for at være spredt ud på hele teamet.
Trin 1-4: Opret adgang og dit første Project
Trin 1: Opdater Cursor og find Agent-vinduet
Start med at sikre, at du kører en opdateret klient. Åbn Cursor, gå til opdateringsmenuen, og genstart, hvis der findes en nyere version.
# macOS/Linux: tjek installeret version fra terminalen, hvis CLI er installeret
cursor --version
# Alternativt: Cursor > Check for Updates i menuenNår klienten er opdateret, åbner du Agent-vinduet fra sidepanelet. Her finder du et nyt menupunkt kaldet Projects, placeret ved siden af dine almindelige agent-samtaler.
Trin 2: Opret et nyt Project
Klik på “New Project” og giv det et beskrivende navn. Et godt navn gør det lettere at genkende tråden senere, især hvis du ender med flere kørende Projects samtidig.
Project-navn: "Migrer betalingsmodul til Stripe SDK v18"
Repository: [email protected]:dinorg/betalings-app.git
Gren: mainTrin 3: Forbind repository og giv adgang
Vælg det repository, koordinatoren skal arbejde i. Hvis det er første gang, skal du godkende Cursors GitHub-app og give den adgang til det specifikke repository, ikke hele organisationen, medmindre I bevidst ønsker det. En detaljeret adgang begrænser skaden, hvis noget går galt i en tidlig test.
Trin 4: Beskriv opgaven til koordinatoren
Skriv en beskrivelse, der ligner en opgave, du ville give en ny udvikler på teamet, ikke en enkelt kodeliniekommando. Jo mere kontekst om mål og afgrænsning, jo bedre plan får du tilbage.
Opgave: Migrer vores betalingsintegration fra Stripe SDK v11 til v18.
Omfang: src/billing/ og alle tests under tests/billing/.
Krav: Alle eksisterende tests skal stadig bestå. Opret en separat
branch pr. delopgave. Ingen ændringer i produktionskonfiguration
uden eksplicit godkendelse fra mig.Trin 5-6: Fra beskrivelse til plan
Trin 5: Lad koordinatoren undersøge og lave en plan
Koordinatoren bruger typisk et par minutter på at læse relevante filer, finde afhængigheder og identificere risici, før den præsenterer en plan. I modsætning til en almindelig agent-session, der ofte går direkte i gang med at skrive kode, er hele pointen med koordinatoren, at den planlægger, før noget uddelegeres.
“You direct it by chatting with its coordinator agent.”
Cursor, officiel dokumentation (cursor.com/docs/agent/projects)
På dansk: du styrer det ved at chatte med dens koordinator-agent. I praksis betyder det, at hvis planen ser forkert ud, retter du den ved at svare i tråden, ligesom du ville forhandle en opgave med en kollega, i stedet for at omformulere hele din oprindelige prompt fra bunden.
Selve planen bliver typisk vist som en punktopstilling af delopgaver, hver med et kort formål. Et realistisk eksempel fra en Stripe-migrering kunne se sådan ud:
Plan fra koordinator:
1. Opdater afhængigheden stripe fra v11 til v18 i package.json
2. Ret alle kald til det udgåede Charges-API i stripeClient.ts
3. Migrer webhook-signaturvalidering til den nye SDK-metode
4. Opdater eksisterende tests til de nye typer og fejlkoder
5. Kør fuld testsuite og rapportér resultat før pull request
Estimeret antal subagenter: 3
Afventer din godkendelse for at fortsætteTrin 6: Godkend eller juster planen
Gennemgå de delopgaver, koordinatoren foreslår. Er der en opgave, der lyder for bred, eller en fil, du ikke ønsker rørt, så sig det direkte i chatten, før du godkender. Denne gennemgang er det vigtigste kontrolpunkt i hele processen, fordi det er her, du fanger misforståelser, mens de stadig er billige at rette.
Vær konkret, når du beder om ændringer til planen. I stedet for at skrive “det ser fint ud, men vær forsigtig”, er det mere brugbart at pege på det specifikke punkt: “spring delopgave 3 over, jeg vil selv håndtere webhook-valideringen manuelt”. Koordinatoren opdaterer planen med det samme og fjerner den delopgave fra listen over ting, subagenterne skal røre ved. Jo mere præcist du retter planen her, jo mindre efterarbejde venter dig, når resultatet lander som en pull request.
Trin 7-8: Uddelegering og gennemgang af resultatet
Trin 7: Følg subagenternes arbejde
Når planen er godkendt, opretter koordinatoren de nødvendige subagenter. Ifølge Cursors dokumentation om subagenter fungerer de som specialiserede assistenter, koordinatoren kan sende afgrænsede opgaver videre til.
“Subagents are specialized AI assistants that Cursor’s agent can delegate tasks to.”
Cursor, officiel dokumentation (cursor.com/docs/subagents.md)
På dansk: subagenter er specialiserede AI-assistenter, som Cursors agent kan uddelegere opgaver til. Hver subagent arbejder isoleret fra de andre, med sit eget kontekstvindue, hvilket gør, at fejl i én delopgave ikke automatisk forurener resten af arbejdet.
“Each subagent operates in its own context window, handles specific types of work, and returns its result to the parent agent.”
Cursor, officiel dokumentation (cursor.com/docs/subagents.md)
På dansk: hver subagent arbejder i sit eget kontekstvindue, håndterer en bestemt type opgave, og afleverer resultatet tilbage til den overordnede agent. Dokumentationen sætter ikke noget fast loft for, hvor mange subagenter koordinatoren kan oprette, og enkelte omtaler af funktionen har nævnt en kapacitet i tusindtal. Det tal beskriver dog systemets teoretiske skala, ikke hvad en typisk opgave reelt bruger. I praksis opretter koordinatoren sjældent mere end nogle få til et dusin subagenter til en almindelig feature eller migrering.
Du kan åbne en enkelt subagent for at følge dens fremgang i detaljer, eller skrive direkte til den, hvis du opdager, at den er ved at løse noget forkert. De fleste brugere lader dog koordinatoren styre kommunikationen og kigger kun ind hos en subagent, når noget ser mistænkeligt ud, som for eksempel unormalt lang kørselstid.
Trin 8: Gennemgå og merge det færdige arbejde
Når subagenterne er færdige, samler koordinatoren resultatet og præsenterer det til din gennemgang. Her skal du selv tage stilling til, hvem der faktisk merger ændringerne. Cursor lader dig vælge, om koordinatoren må merge automatisk efter en godkendt gennemgang, eller om hver pull request skal godkendes manuelt af et menneske, før den rammer main. For kritisk kode som betalingslogik anbefaler vi klart den manuelle model, uanset hvor godt koordinatoren har præsteret indtil videre.
Behandl den første pull request fra et nyt Project, som du ville behandle kode fra en ny kollega. Læs den grundigt, kør testene lokalt hvis det er muligt, og vær ekstra opmærksom på ændringer i konfiguration, miljøvariabler og afhængigheder. Efter et par runder med solide resultater kan I løsne kontrollen for de mindre kritiske dele af kodebasen, men det bør være en bevidst beslutning, ikke noget der bare sker, fordi ingen har haft tid til at stramme op igen.
Trin 9-10: Automatiser med tidsplaner, Slack og pull requests
Trin 9: Sæt en tidsplan op
Et Project kan konfigureres til at vågne op efter en tidsplan i stedet for kun at reagere, når du skriver noget. Det bruges typisk til tilbagevendende vedligeholdelse, som oprydning i forældede afhængigheder eller generering af manglende tests.
Trigger: Tidsplan
Frekvens: Hver mandag kl. 07:00
Opgave: Scan for forældede npm-pakker i package.json,
opret en pull request pr. opdatering, der ikke bryder
eksisterende tests.Trin 10: Forbind Slack og pull requests
Ud over tidsplaner kan et Project konfigureres til at holde øje med Slack-beskeder, for eksempel når nogen rapporterer en bug i en support-kanal, eller til at følge pull requests og reagere, hvis CI-tjek fejler. Begge dele kræver, at du godkender den relevante integration under Projectets indstillinger, og at du er præcis i, hvilke kanaler og repositories den må se og handle i.
Trigger: Slack
Workspace: dinorg.slack.com
Kanal: #support-bugs
Nøgleord: "fejl", "virker ikke", "crash"
Handling: Opret et udkast til en fejlrettelse og
tag den oprindelige besked-forfatter i pull requestenEn for bredt konfigureret trigger kan ende med at oprette pull requests på baggrund af beskeder, der aldrig var ment som en opgave, for eksempel en kollega, der bare brokker sig over en dårlig dag i en uformel kanal. Start derfor med et smalt kanal- og nøgleordsfilter, og udvid det gradvist, efter I har set, hvordan koordinatoren tolker beskederne i praksis.
Kombinationen af tidsplaner og Slack-triggere er der, hvor Projects for alvor adskiller sig fra en almindelig agent-session. I stedet for at nogen skal huske at bede om en ugentlig oprydning, eller manuelt oprette en sag, når en bug bliver rapporteret, kører koordinatoren i baggrunden og reagerer, når betingelserne er opfyldt. Det flytter en del af det administrative arbejde, der ellers ville falde på en teamlead eller senior-udvikler, over på noget, der kører automatisk, så længe rammerne er sat rigtigt op fra starten.
Trin 11: Selvhostet udførelse med My Machines
Som standard kører koordinatoren og dens subagenter i skyen, så arbejdet fortsætter, selv når din bærbare er lukket. Har I dog behov for, at kode aldrig forlader jeres eget netværk, af compliance-hensyn eller fordi jeres build-værktøjer kun findes lokalt, kan I forbinde en selvhostet maskine under Cloud Agents, undermenuen Self-Hosted eller My Machines. Det flytter selve udførelsen over på jeres egen hardware, mens koordinatoren fortsat styres fra Cursors cloud.
Det er værd at være opmærksom på, at selvhostning ikke fjerner cloud-afhængigheden helt. En bruger dokumenterede i Cursors eget forum, at der endnu ikke findes en rent lokal koordinator-tilstand. Koordinatoren forbliver cloud-først, selv når selve arbejdet udføres på en maskine, I selv styrer. For teams med strenge krav til datahåndtering bør det afklares konkret, hvilke data der reelt passerer gennem Cursors servere, før man sætter et Project op på følsom kode.
En anden rapporteret hændelse fra samme forumtråd er værd at kende, før I stoler blindt på repository-afgrænsningen. En bruger testede, hvad der skete, når en lokal agent under et Project fik adgang til en oprettet testfil, og observerede, at agenten i første omgang rørte ved et andet lokalt repository end det, der var valgt til Projectet. Sagen blev fulgt op i forummet, men den er en god påmindelse om, at I selv bør verificere adgangsgrænserne med en harmløs testfil, før I peger et Project mod noget forretningskritisk.
Trin 12: Styr forbrug, kvoter og priser
Fordi et Project kan oprette flere agenter samtidig, er det let at undervurdere, hvor hurtigt forbruget stiger sammenlignet med en enkelt chat-session. Cursors overordnede prisstruktur, som også gælder for Projects, ser sådan ud ifølge tredjeparts prisgennemgange af Cursors offentlige planer:
| Plan | Pris pr. måned | Agent-grænser i forhold til Pro |
|---|---|---|
| Hobby | Gratis | Begrænsede agent-forespørgsler, adgang til Composer |
| Pro | 20 dollar | Basisniveau for udvidede agent-grænser |
| Pro+ | 60 dollar | Cirka 3x Pro-niveauets agent-grænser |
| Ultra | 200 dollar | Cirka 20x Pro-niveauets agent-grænser |
Årlig betaling giver ifølge samme kilder en rabat på omkring 20 procent i forhold til månedlig fakturering. Bemærk, at dette er Cursors generelle abonnementsstruktur, ikke en officielt bekræftet prisliste specifikt for Projects. Cursor har ikke offentliggjort en separat tabel over, præcis hvordan koordinator-kald, subagent-kald og planlagte eller Slack-udløste kørsler trækkes fra jeres kvote, så det sikreste er at overvåge forbruget aktivt de første uger, i stedet for at stole blindt på et estimat.
For cloud-agenter specifikt har en sekundær kilde rapporteret priser omkring 2 dollar pr. million input-tokens og 6 dollar pr. million output-tokens, med en hurtigere modelvariant til omkring dobbelt pris. Disse tal er ikke bekræftet direkte af Cursor i en officiel prisside for Projects, så brug dem som et fingerpeg om størrelsesordenen frem for en garanteret regning. Kør et par testkørsler, og sammenlign den faktiske regning med jeres forventning, før I lader et Project køre ubevogtet over flere uger.
En praktisk vane er at starte med et lille, afgrænset Project, se hvor meget forbrug det trækker over en uge, og først derefter skalere op til mere ambitiøse, tilbagevendende opgaver. Det er billigere at lære grænserne at kende på en lille opgave end at opdage dem midt i en stor migrering.
Trin 13: Afslut og ryd op i et Project
Når opgaven er løst, og alle pull requests er merget, bør du arkivere eller lukke Projectet, i stedet for at lade det ligge åbent på ubestemt tid. Et åbent Project med en tidsplans-trigger fortsætter med at køre og forbruge kvote, selv efter den oprindelige opgave er afsluttet, hvis du glemmer at deaktivere triggeren. Gennemgå derfor indstillingerne en sidste gang, fjern eventuelle Slack- og pull request-integrationer, I ikke længere har brug for, og noter i teamets dokumentation, hvilke Projects der stadig er aktive, og hvorfor.
Et simpelt trick er at holde en delt liste, for eksempel i README.md eller i et internt wiki, over alle aktive Projects, deres formål og hvem der ejer dem. Det lyder som overkill for et enkelt Project, men bliver hurtigt nødvendigt, så snart flere teams begynder at bruge funktionen samtidig på tværs af flere repositories.
Sådan kan et typisk statusoutput se ud, når et Project er afsluttet korrekt:
Project: "Migrer betalingsmodul til Stripe SDK v18"
Status: Afsluttet
Subagenter oprettet: 6
Pull requests mergeret: 4
Pull requests afvist: 1 (dobbeltarbejde med eksisterende PR)
Aktive triggere: Ingen
Samlet varighed: 3 dage, 4 timer5 almindelige faldgruber med Cursor Projects
- At lade koordinatoren merge automatisk fra dag ét. Uden en indkøringsperiode med manuel gennemgang risikerer du, at fejlagtige antagelser i planen ender direkte i main, før nogen opdager mønsteret.
- At give adgang til hele organisationens repositories. Det er fristende at godkende bred adgang for at spare tid, men det øger skadesomfanget markant, hvis en enkelt subagent misforstår en opgave og rører ved kode, den ikke burde.
- At overse, at tidsplaner og Slack-triggere fortsætter med at trække forbrug. Et glemt, aktivt Project kan stille og roligt opbruge en måneds kvote på opgaver, ingen længere har brug for løst.
- At skrive for vage opgavebeskrivelser. “Forbedre betalingsmodulet” giver en langt ringere plan end en beskrivelse med konkret omfang, krav og afgrænsning, fordi koordinatoren så selv skal gætte, hvor grænserne går.
- At forveksle selvhostet udførelse med fuld lokal drift. Som beskrevet i trin 11 forbliver koordinatoren cloud-først, selv når arbejdet udføres på jeres egen maskine, hvilket kan overraske teams med strenge compliance-krav.
Fejlfinding: 8 problemer og løsninger
Her er de problemer, der oftest dukker op, når teams sætter deres første Projects op, sammen med den mest sandsynlige årsag og løsning. Listen bygger på de samme typer fejl, som gik igen i forummet og i de tidlige brugerrapporter fra september 2026, hvor funktionen stadig var helt ny for de fleste.
| Problem | Sandsynlig årsag | Løsning |
|---|---|---|
| “Projects” vises ikke i Agent-vinduet | Forældet Cursor-klient | Opdater til nyeste version 2.x via Check for Updates |
| Koordinatoren kan ikke se repositoriet | GitHub/GitLab-app mangler adgang til det specifikke repo | Gå til appens indstillinger og tilføj repositoriet eksplicit |
| Subagenter opretter for mange branches | Opgavebeskrivelsen var for bredt formuleret | Del opgaven op i mindre, klart afgrænsede Projects |
| Slack-trigger reagerer på irrelevante beskeder | Kanal-filter er sat for bredt | Indsnævr triggeren til specifikke kanaler eller nøgleord |
| Uventet højt forbrug midt i ugen | Flere subagenter kørte parallelt uden overvågning | Gennemgå forbrugslog og sæt en øvre grænse for parallelle agenter |
| Pull request fra koordinatoren mangler kontekst | Den oprindelige opgavebeskrivelse manglede baggrund | Tilføj mere kontekst i tråden, og bed koordinatoren lave PR’en igen |
| Selvhostet maskine bruges ikke til udførelse | Forkert konfiguration under Cloud Agents-indstillinger | Bekræft forbindelsen under Self-Hosted / My Machines igen |
| Project fortsætter med at køre efter afsluttet opgave | Aktiv tidsplan blev ikke deaktiveret | Gå ind i Projectets indstillinger og fjern eller sæt triggeren på pause |
De fleste af disse problemer stammer ikke fra selve AI-modellen, men fra utydelige rammer omkring den. Hvad må koordinatoren se, hvor bredt er dens mandat, og hvem holder øje med, hvornår et Project reelt er færdigt. Løs de spørgsmål eksplicit, før I skalerer op til flere samtidige Projects, og gør det til en fast del af onboardingen for nye teammedlemmer, der skal bruge funktionen.
Avancerede tips til erfarne brugere
Når de første Projects kører stabilt, er det de små vaner, der afgør, om funktionen bliver en fast del af teamets arbejdsgang, eller noget der bliver glemt efter et par ugers nyhedens interesse. Her er fem vaner, vi ser hos teams, der har brugt Cursor Projects siden lanceringen i september.
- Start med gardening-opgaver, før du stoler på Projects med kritisk kode. Lint-oprydning, generering af manglende tests eller dokumentation er lavrisiko-opgaver, der lader jer lære koordinatorens adfærd at kende, uden at en fejl koster meget.
- Sæt en fast navnekonvention for Projects. Med flere aktive Projects kørende samtidig bliver det hurtigt uoverskueligt uden en konsekvent navngivning, der viser formål og ejer ved et enkelt blik.
- Brug separate Projects til separate ansvarsområder. Et Project pr. modul eller team giver bedre overblik over forbrug og ansvar end ét stort Project, der dækker hele kodebasen.
- Gennemgå subagenternes individuelle logs stikprøvevis. Selv når koordinatorens samlede rapport ser fin ud, kan en enkelt subagent have taget en genvej, der kun opdages ved at åbne dens fulde historik.
- Kombiner Projects med jeres eksisterende CI-pipeline i stedet for at erstatte den. Lad Projects foreslå ændringer via pull requests, men behold jeres almindelige test- og deploy-gates som den sidste kontrol, før noget rammer produktion.
Ingen af disse vaner kræver særlig teknisk indsigt at indføre. De fleste er organisatoriske beslutninger, teamet kan tage på et enkelt møde, men de er netop den slags detaljer, der afgør, om Cursor Projects ender som et værktøj, alle stoler på, eller et forsøg, der stille og roligt bliver skruet ned for, fordi ingen fik styr på rammerne fra starten.
Byg et komplet eksempel-projekt
Som et samlet eksempel, her er, hvordan du kan strukturere et lille Node.js-projekt, der bruger Cursor Projects til at holde en tilbagevendende opgave kørende: automatisk opdatering af forældede afhængigheder med tilhørende tests.
betalings-app/
├── .cursor/
│ └── projects/
│ └── dependency-watch.md
├── src/
│ ├── billing/
│ │ ├── stripeClient.ts
│ │ └── invoice.ts
│ └── server.ts
├── tests/
│ └── billing/
│ └── stripeClient.test.ts
├── package.json
└── README.mdIndholdet af .cursor/projects/dependency-watch.md, som beskriver Projectets tilbagevendende opgave, kan se sådan ud:
---
navn: Ugentligt afhaengighedstjek
trigger: tidsplan
frekvens: mandag 07:00
---
Scan package.json for forældede afhængigheder i src/billing/.
Opdater én pakke ad gangen i en separat branch. Kør den fulde
testsuite under tests/billing/ efter hver opdatering. Opret kun
en pull request, hvis alle tests består. Ret ikke eksisterende
forretningslogik, kun versionsnumre og eventuelle nødvendige
API-tilpasninger som følge af opdateringen.Med den opsætning på plads kan en ny udvikler klone repositoriet, se den aktive Project-konfiguration direkte i versionsstyringen, og forstå, hvilke tilbagevendende opgaver koordinatoren allerede tager sig af, uden at nogen skal forklare det mundtligt. README.md bør kort beskrive, hvilket Cursor-abonnement Projectet kører under, og hvem i teamet der er ansvarlig for at godkende dets pull requests.
Et uddrag af den eksisterende test, som koordinatoren skal holde grøn gennem hele migreringen, kan se sådan ud. Det giver subagenterne et konkret succeskriterium at arbejde efter, i stedet for kun en beskrivelse i ord.
import { describe, it, expect } from "vitest";
import { createCharge } from "../../src/billing/stripeClient";
describe("stripeClient", () => {
it("opretter en betaling med korrekt beløb og valuta", async () => {
const result = await createCharge({ amount: 4999, currency: "dkk" });
expect(result.status).toBe("succeeded");
expect(result.amount).toBe(4999);
});
});Når koordinatoren har fået både mappestrukturen, opgavebeskrivelsen og den eksisterende test at arbejde ud fra, har den alt, hvad den behøver for at planlægge migreringen uden at skulle spørge dig om afklaringer undervejs. Det er netop denne kombination af klar kontekst og konkrete succeskriterier, der adskiller et Project, der kører gnidningsfrit, fra et, der ender med gentagne spørgsmål midt i en travl arbejdsdag.
Efter de tretten trin i denne guide har du en fungerende opsætning: et Project med forbundet repository, en klar opgavebeskrivelse, en tidsplans-trigger, og en proces for, hvordan pull requests fra koordinatoren gennemgås og merges. Herfra handler det mest om at justere opgavebeskrivelserne til jeres eget kodebase og holde et vågent øje med forbruget, mens teamet vænner sig til at have en koordinator med i arbejdsgangen.
Cursor har i samme periode lanceret flere andre agent-relaterede funktioner, blandt andet de to sikkerhedsbots Rollouts og Security Review, som vi har beskrevet i en separat artikel. Kombinerer I Projects med den slags automatiserede gennemgange, får I et setup, hvor koordinatoren planlægger og uddelegerer arbejdet, mens en separat bot dobbelttjekker resultatet for sikkerhedsproblemer, før det når frem til jer som endelig godkender. Hold øje med Cursors offentlige changelog løbende, da funktionen stadig er i beta og ændrer sig fra uge til uge.
Ofte stillede spørgsmål
Er Cursor Projects gratis at bruge?
Selve funktionen er tilgængelig i beta på tværs af planer, inklusive den gratis Hobby-plan, men cloud-udførelsen trækker på jeres almindelige agent-kvote, så reelt forbrug afhænger af planen og opgavens størrelse.
Hvor mange subagenter kan et Project oprette?
Cursors dokumentation angiver, at koordinatoren kan køre så mange agenter parallelt, som opgaven kræver, uden et fast loft. Sekundære kilder har omtalt kapacitet i tusindtal, men det beskriver systemets tilgængelige skala, ikke et garanteret antal for hver opgave.
Kan Cursor Projects køre helt lokalt uden sky?
Nej, ikke per september 2026. Koordinatoren er cloud-først, og selv med en selvhostet maskine tilkoblet under My Machines forbliver den overordnede styring i Cursors sky.
Erstatter Projects Composer og almindelig agent-tilstand?
Nej. Composer og agent-tilstand er fortsat det rigtige valg til afgrænsede, øjeblikkelige opgaver. Projects er et supplement til større, vedvarende arbejde, ikke en erstatning for den daglige, interaktive brug.
Kan et Project automatisk merge kode til main uden godkendelse?
Det kan konfigureres til det, men vi anbefaler manuel gennemgang af pull requests, i hvert fald indtil teamet har set koordinatorens adfærd over en længere periode, især på forretningskritisk kode.
Hvordan undgår jeg et uventet stort forbrug?
Start i lille skala, overvåg forbruget efter den første uge, sæt tydelige grænser for parallelle agenter, og deaktiver tidsplaner og triggere for Projects, der ikke længere er aktive. Hold især øje med planer på Pro-niveau, hvor grænserne er lavere end på Pro+ og Ultra, så en enkelt stor migrering hurtigere kan spise en hel måneds kvote.
Virker Projects med både GitHub og GitLab?
Ja, forudsat at I har godkendt den relevante integration med adgang til det specifikke repository, koordinatoren skal arbejde i.
Er Cursor Projects den samme funktion som Cursor Origin?
Nej. Cursor Origin, som vi har dækket separat, handler om kodehosting i skyen. Projects handler om, hvordan arbejdet i et eksisterende repository planlægges og uddelegeres af en koordinator-agent.
Bør danske virksomheder tænke over GDPR, før de bruger Cursor Projects?
Ja. Fordi koordinatoren som standard kører i skyen, bør I kortlægge, hvilke data der reelt sendes til Cursors servere, før I peger et Project mod kode med personoplysninger eller kundedata i testfiler. Selvhostet udførelse flytter en del af arbejdet lokalt, men fjerner ikke cloud-afhængigheden for selve koordinatoren.
Skal jeg bruge Cursor Projects til et lille solo-projekt?
Sandsynligvis ikke. Værdien af en koordinator, der planlægger og uddelegerer til flere subagenter, viser sig først, når opgaven er stor nok til reelt at kunne deles op. Til et lille script eller en enkelt bugfix er en almindelig agent-session hurtigere og enklere.