En titelskylt för en playbook med titeln 'Planera i ChatGPT Pro, exekvera i Codex', som visar ett diagram med två paneler: en repository-ikon som matar ett designdokumentkort på vänster sida, och en pil från det dokumentet in i ett terminalfönster på höger sida.
Guides & Insights

Planera i ChatGPT Pro, utför i Codex: Spelboken för överlämning av designdokument

Författare

Magnus Corvin

Publiceringsdatum

Senaste modellerna · 20Visa alla modeller
Benchmarks: Artificial Analysis · uppdateras dagligen
Tillbaka till alla inlägg

Arbetsflödet som är värt att stjäla den här månaden är inte en modell, det är en arbetsfördelning. Du ger GPT-6 Pro i ChatGPT en repository-URL, be den om ett designdokument i stället för en patch, och ge dokumentet till Codex eller Claude Code att implementera. Planeraren körs på GPT-6 Astra — GPT-6 Pro är namnet som ChatGPTs användningsgränser använder för den — och Astra är en modell från 3 september 2026, så inget här är lanseringsbevakning eller ett utgivningspåstående. Det som förändrades under de senaste sju dagarna är snävare, och värt att säga exakt: den 17 september 2026 rapporterade yrkesverksamma att det officiella GitHub-tillägget i vanliga ChatGPT Chat, inte ChatGPT Work och inte Codex, kan redigera repository-filer, committa och öppna pull requests utan att ta av Codex/Work-kvoten. Det är ett påstående från communityn, inte leverantörsdokumentation — de officiella hjälpsidorna beskriver fortfarande GitHub-appen som skrivskyddad och dirigerar allt skrivande genom Codex — och förbehållen som hör till det är lika viktiga som påståendet. Allt nedan är märkt som leverantörsrapporterat, community-rapporterat eller avläst från de officiella sidorna den 19 september 2026.

Arbetsflödet, i ett svep

Utövare beskriver samma slinga med små variationer. Den som återkommer: klistra in en GitHub-adress i ChatGPT, be den läsa koden och ta fram ett designdokument, ladda sedan ner dokumentet och mata det till en exekverande agent. Vissa ber också om en pull request; andra stannar vid dokumentet och låter exekutorn sköta skrivandet. Hur som helst är formen identisk – planera i chattprodukten, bygg i agentprodukten – och anledningen till att den är värd att kopiera är att de två halvorna mäts separat.

• Planeringsartefakt — ett designdokument: gränssnitten som ska läggas till, filerna som ska ändras angivna med sökväg, migreringsordningen, acceptanstesterna och vad man gör om det går fel.

• Exekveringsartefakt — en gren och en pull request, producerad av en agent som kan köra testerna den just skrev.

• Granskningsartefakt — diffen, som är det enda som någonsin bör nå en granskare.

Design­dokumentet är den bärande delen, och det förtjänar sin plats av två skäl. För det första är ett dokument portabelt: samma text fungerar oavsett om utföraren är Codex, Claude Code eller en skriptad agent som du själv har skrivit, så planeringen du betalade för är inte bunden till en leverantörs verktyg. För det andra är det den granskningsyta som finns innan något skrivs till ditt kodförråd – vilket spelar stor roll med tanke på att skrivvägen i chattprodukten är den minst dokumenterade delen av hela upplägget.

An infographic titled 'The design-document handoff', showing four connected steps: Repository URL, Design document, Local file in the repo, and Executing agent, with output chips reading 'Branch and pull request' and 'Acceptance tests', and a footer line 'Workflow as described by practitioners; not vendor guidance.'

Varför tvåhinksstrukturen är hela grejen

ChatGPT fakturerar inte detta arbetsflöde från en och samma pott. Chat, ChatGPT Work och Codex har separata kvoter, där Work och Codex delar en enda pott mellan sig; en OpenAI API-nyckel är återigen separat fakturering. Det är den strukturen som gör överlämningen ekonomisk: tänkandet sker i Chat-potten, görandet sker i agent-potten, och ett designdokument kostar ett Chat-meddelande medan implementeringen kostar agentanvändning.

Siffrorna, så som OpenAI publicerar dem för Chat-sidan – leverantörsrapporterade siffror i leverantörens egen plandokumentation, inte mätningar:

• ChatGPT Pro för $200 i månaden — 200 GPT-6 Pro-meddelanden i veckan; GPT-5.6 Sol Pro har dessutom 170 per dag, där båda modellerna tillsammans har ett tak på 200 per dag.

• ChatGPT Pro för 100 USD i månaden — 50 GPT-6 Pro-meddelanden i veckan, som tas från en kvot som delas med GPT-5.6 Sol Pro.

• Business Standard – 15 GPT-6 Pro-meddelanden per månad, som delas med Sol Pro; Business Premium – 50 per vecka enligt samma delningsprincip.

• ChatGPT Plus — ingen GPT-6 Pro i Chat över huvud taget. Astra når Plus endast via ChatGPT Work och Codex, vilket är precis den kategori som den här spelboken försöker skydda.

På Work/Codex-sidan publicerar OpenAI uppskattningar i stället för gränser, och säger det uttryckligen: ungefär 5 till 45 Astra-meddelanden per femtimmarfönster på Plus, 25 till 225 på Pro 5x och 100 till 900 på Pro 20x, och samma sida noterar att den faktiska förbrukningen varierar med uppgiftens komplexitet, kontext, utdata och verktygsanvändning, samt att veckogränser kan tillkomma ovanpå. Dessa intervall ligger på ungefär hälften av motsvarande Sol-siffror, vilket är det aritmetiska skälet till att en frontiermodell överhuvudtaget är överkomlig att köra som en agent.

A graphic summarising OpenAI's published ChatGPT plan documentation, headed 'GPT-6 Pro in Chat: messages by plan', with four plan cards reading ChatGPT Pro $200 — 200 messages a week, ChatGPT Pro $100 — 50 messages a week, Business Standard — 15 messages a month and Business Premium — 50 messages a week, plus a note that ChatGPT Work and Codex hold a separate allowance from Chat.

Den praktiska konsekvensen är en budgetregel som du kan skriva på ett kort. Använd Chat-meddelanden till beslut och agentanvändning till kod. En planeringssession som argumenterar om ett gränssnitt i tjugo minuter kostar en handfull Chat-meddelanden och producerar ett dokument som sparar en timmes utforskande redigeringar åt en agent — vilket är den avvägning som utövarna i tråden faktiskt gör.

Skrivvägen: vad konnektorn gör och vad folk påstår att den gör

Här går källorna isär, och oenigheten är den intressanta delen.

OpenAI:s egen hjälpdokumentation är entydig: GitHub-appen i ChatGPT läser dina repositorier för analys och sökning, och att generera kod, redigera den och pusha den till GitHub är vad Codex är till för. Det är den skrivskyddade positionen, och det är den man bör planera utifrån om man inför detta i en teamprocess, eftersom det är den som har en leverantör bakom sig.

Community-positionen, daterad 2026-09-17, är att webbversionens GitHub-plugin i Chat-läge kommer att redigera kod, göra commits och öppna pull requests, och att den, eftersom den är en officiell plugin i stället för en MCP-server från tredje part, inte förbrukar Codex- eller Work-kvot. Samma tråd är noga med omfattningen: små verktyg, mindre ändringar, små buggar — stora refaktoreringar och svår felsökning hör fortfarande hemma i Codex. Dess egna kommentatorer lägger till förbehållen som är värda att upprepa, eftersom det är de som biter:

• Normala hastighetsbegränsningar för ChatGPT gäller fortfarande. "Inte Codex-kvot" är inte "gratis".

• Kvaliteten kan försämras efter flera omgångar utan förvarning, där sessionen byter till en mindre modell mitt i en uppgift.

• Trådens skribenter avråder från att byta till Work när gränssnittet erbjuder det, och varnar för att hamra på anonyma chattsidor försämrar webbupplevelsen för alla.

En oberoende japansk redogörelse för samma mönster kommer fram till en kompatibel slutsats utan kvotpåståendet: om en GitHub-integration stöder skrivåtgärder kan vanlig chatt läsa ett repository, ändra filer, skapa en gren och öppna en pull request; vanliga frekvensgränser för chatt gäller; och Codex och Work använder den delade agentpoolen, så vanlig chatt är för redigering av några få filer och Codex är för långa mjukvaruuppgifter. Där de två redogörelserna stämmer överens är överensstämmelsen den användbara delen: chatt är en kanal för små ändringar, Codex är kanalen för långa sessioner, och poolerna är separata.

Det finns tredjeparts-MCP-servrar som exponerar ett riktigt git-arbetsflöde – branch, diff, commit, push, öppna en pull request – med behörigheter som du kan nivåindela från endast läsning upp till push. Om du vill att skrivvägen ska vara deterministisk och granskningsbar i stället för ett beteende som du hoppas på, är det vägen; om du vill hålla dig inom det som OpenAI dokumenterar, planera i Chat och skriv i Codex.

Hur som helst är överlämningen av design­dokumentet det som gör chattens skrivväg försvarbar. En chattsession med skrivbehörighet mot ett repository är ett större beviljande av behörighet än en chattsession med läsbehörighet, och dokumentet är den artefakt du granskar innan den behörigheten utnyttjas.

Överlämningen, steg för steg

• Rikta planeraren mot repositoriet – en offentlig URL inklistrad i prompten, eller GitHub-anslutningen om du har auktoriserat den – och be den läsa koden innan den föreslår något.

• Be om ett designdokument, inte en patch. Kräv filsökvägar, de gränssnitt som läggs till eller ändras, i vilken ordning ändringarna måste landa, och de tester som bevisar varje steg.

• Be den citera filerna som den faktiskt läste. Ett designdokument som beskriver ett gränssnitt som repositoryt inte har är det vanligaste sättet som det här arbetsflödet misslyckas på, och citaten är hur du upptäcker det på en minut i stället för en sprint.

• Spara dokumentet i repositoriet i stället för att klistra in det i nästa verktyg. En utförare som läser en fil kan läsa om den; en utförare som har tagit emot en inklistring har bara ett försök.

• Starta executorn med dokumentet som dess instruktion och avgränsa en pull request till ett avsnitt av det. Det är i långa sessioner som agentkvaliteten tyst försämras.

• Behåll planeraren i en enbart granskande roll efteråt. När dokumentet är fel, planera om och uppdatera dokumentet — låt inte utföraren improvisera sig förbi det, eftersom improviserat arbete är just det som dokumentet fanns för att förhindra.

Där det går sönder

• Inaktuellt repository-tillstånd — planeraren läste standardgrenen medan du arbetar på en funktionsgren, så filsökvägarna i dokumentet ligger en version efter. Ange vilken gren som ska läsas, eller klistra in grenträdet.

• Designdokumentdrift — dokumentet och koden stämmer inte överens, och exekveraren följer dokumentet. Steget ovan med citerade filer är den billiga försäkringen.

• Kvotöverraskning i fel riktning — en tjugominuters planeringskonversation är billig i chattmeddelanden och dyr i uppmärksamhet; en lång agentkörning är det omvända. Budgetera den pott du faktiskt gör av med.

• Tyst nedgradering – en chattsession som efter flera rundor degraderas till en mindre modell kommer fortfarande att producera ett självsäkert designdokument. Granska dokumentet utifrån dess egna meriter, inte utifrån antagandet att flaggskeppet skrev det.

• Behörighetsglidning — skrivvägen, oavsett om den går via ett plugin eller en MCP-server, ger en chattsession möjligheten att ändra din kod. Nivåindela behörigheterna och återkalla dem när ändringen har landat.

Kör executor-halvan genom en slutpunkt

Planeringshalvan av det här arbetsflödet ligger i en prenumerationsprodukt, och den delen är vad den är. Den exekverande halvan är ett API-anrop, och det är den halvan som är värd att äga. Om du skriptar exekveraren — en liten agentloop, ett CI-jobb som omvandlar ett godkänt designdokument till en branch — är modellanropet den enda delen som måste kunna bytas ut, eftersom modellen du vill ha nästa kvartal inte är modellen du planerar kring idag.

Det är vad ett routinglager är till för. openai/gpt-6-astraligger bakom samma OpenAI-kompatibla endpoint som 200+ andra modeller, med leverantörens listpris vidarebefordrat med 0 % påslag – så när en leverantör ändrar ett pris ändras priset på vår sida samma dag i stället för vid nästa avtalsförnyelse. Automatisk redundansväxling gör att du kan sätta en obeprövad modell på en del av trafiken med en beprövad modell under, vilket är det ärliga sättet att ta reda på om en billig exekutor är tillräckligt bra för dina tester. Och routing-DSL:en komponerar flera modeller till ett enda anrop, så en granskningsmodell kan kontrollera exekutorns diff med samma nyckel, i samma anropsväg, utan en andra integration.

A capture of OrcaRouter's model page for openai/gpt-6-astra, showing the model identifier, a 1M-token context window, 128K maximum output, input and output pricing per million tokens, and an OpenAI-compatible base URL.

Inget av detta förändrar överlämningens struktur. Det förändrar kostnaden för att experimentera med den hälft av den som du kontrollerar: en nyckel, en slutpunkt och en modellsträng som du kan ändra utan att röra pipeline.

Vem ska köra detta nu, och vem ska vänta

Om du redan betalar för en ChatGPT-plan på Pro-nivån och redan kör Codex eller Claude Code är överlämningen värd att införa den här veckan, eftersom de två potterna redan är separata på din faktura och designdokumentet är det billigaste i loopen. Börja med en ändring som du förstår tillräckligt väl för att kunna upptäcka en dålig plan: be om dokumentet, läs de citerade filerna och lämna sedan över det.

Om du är på Plus bör du dämpa förväntningarna. Astra når dig via Work och Codex men inte via Chat, så planeringshalvan av den här spelboken är inte tillgänglig för dig i den beskrivna formen – du skulle planera och utföra ur samma pool, vilket tar bort det ekonomiska argumentet och lämnar bara disciplinen att skriva dokumentet först. Den disciplinen är fortfarande värd att ha. Rabatten är det inte.

Och om anledningen till att du vill ha detta är skrivvägen i Chat snarare än överlämningen, vänta tills OpenAIs dokumentation har kommit i kapp forumtråden. En funktion som leverantörens egna hjälpsidor säger emot är en funktion att behålla i ett scratch-repositorium tills sidorna ändras.

Samma nyckel når resten av katalogen, och du kan bläddra i hela modellkatalogen för att se vad mer som finns bakom en OpenAI-kompatibel endpoint.