OpenAI:s uppdatering den 29 september 2026 knyter ihop tre delar av utvecklarstacken: modellen GPT-6.1 Sol, fleragentkörning i Responses API och webbläsarstyrning i Agents API. Tillsammans gör de det enklare att bygga arbetsflöden där en modell planerar, fördelar och utför uppgifter i externa gränssnitt. De tre delarna har olika mognad och olika gränser. Modellen är släppt i API:et, fleragentfunktionen är beta och webbläsarstyrningen kräver aktiv hantering av webbplatsåtkomst i den egna applikationen. För driftteam är den skillnaden viktigare än en samlad lanseringsrubrik.
Nyheten påverkar främst team som redan bygger kodagenter, testautomation eller interna assistenter med verktygsåtkomst. En modell kan nu kombineras med delegering och en värdhanterad webbläsare. Samtidigt flyttar mer av exekveringen till leverantörens miljö. Därför behöver kostnad, dataplacering, nätverksåtkomst och godkännanden behandlas som delar av arkitekturen från början.
GPT-6.1 Sol: ny modell med tydlig prisgräns
Enligt OpenAI:s ändringslogg släpptes gpt-6.1-sol den 29 september för Responses API och Chat Completions. OpenAI beskriver den som avsedd för komplex programmering och professionellt arbete till lägre kostnad än GPT-6 Astra. Det är leverantörens egen positionering; den säger inte hur modellen presterar i en viss kodbas eller agentmiljö. Egna uppgifter behöver därför testas med samma verktyg, instruktioner och kvalitetskriterier som används i produktion.
Modellkortet anger ett kontextfönster på 1 050 000 token och högst 128 000 utdata-token. Det stora fönstret är tekniskt användbart för omfattande kod- och dokumentuppgifter, men det är ingen garanti för att varje lång inmatning ger bättre svar. Lång kontext kan även ändra kostnaden kraftigt. För upp till 272 000 indata-token kostar standardnivån 2 dollar per miljon indata-token och 10 dollar per miljon utdata-token. Cacheträffar kostar 0,10 dollar och cachelagring 2,50 dollar per miljon token. Över 272 000 indata-token blir indata- och cachepriserna dubbla och utdatapriset 1,5 gånger så högt för hela anropet, enligt modellkortet. Det är en tröskel i prissättningen, inte bara ett tillägg på den överskjutande delen.
Modellen tar text och bilder som indata och ger text som utdata; ljud och video stöds inte enligt modellkortet. Verktygsanrop ska använda Responses API. Chat Completions finns, men där utan verktygsanrop för denna modell. En applikation som tänker använda samma modell för en kodagent kan därför inte bara byta modellnamn i en befintlig Chat Completions-kedja. Den måste kontrollera hur verktygsanrop, samtalstillstånd och felhantering implementeras i Responses.
OpenAI uppger att GPT-6.1 Sol stöder dataresidens i USA och EU. Samma dokumentation säger att Fast-läget inte är tillgängligt med EU-residens. Välj alltså först dataplacering och tillåtet behandlingssätt, och mät sedan latens på en konfiguration som faktiskt går att använda. Att blanda siffror från global och regional behandling skulle ge en missvisande kapacitetsplan.
Fler agenter inom ett Responses-anrop
OpenAI:s fleragentdokumentation beskriver hur en huvudagent kan delegera avgränsade deluppgifter till parallella underagenter och samla resultaten. Funktionen är beta för GPT-6.1 Sol. Den använder särskilda beta-SDK:er eller HTTP-huvudet OpenAI-Beta: responses_multi_agent=v1, och dokumentationen varnar för att objektscheman kan ändras. Detta är alltså ett alternativ för pilotmiljöer, inte ett stabilt kontrakt att bygga okontrollerad produktionsautomation kring.
Den praktiska vinsten kan komma när arbetet verkligen går att dela upp: exempelvis separata undersökningar av kod, dokumentation och testfall. En agent kan då hålla varje deluppgifts kontext mer fokuserad. Däremot kan parallellisering öka total tokenförbrukning och göra felsökning svårare. Ett rimligt första test är att köra samma representativa uppgift med en agent respektive flera underagenter och jämföra kvalitet, väggtid, antal anrop och kostnad. OpenAI:s beskrivning av potentiell nytta är inte ett oberoende prestandatest för den egna miljön.
För företag är spårbarhet minst lika viktig som hastighet. Logga vilken underagent som gjorde vilket verktygsanrop, vilken data den fick och hur huvudagenten använde resultatet. Begränsa åtkomsten per deluppgift där arkitekturen tillåter det. Om allt körs med samma breda behörigheter kan en uppdelning i flera agenter annars förstora felens räckvidd utan att tillföra kontroll.
Webbläsaren blir ett verktyg i Agents API
Den andra förändringen den 29 september är computer use i Agents API. Agenten kan navigera och använda webbsidor i en webbläsare som körs i en OpenAI-värd miljö. Applikationen startar en session, följer dess händelser och skickar uppgiften. Dokumentationen visar konfiguration med verktyget computer_use och en openai_hosted-miljö där skrivbordet är aktiverat. Efter körningen bör applikationen granska aktivitet och resultat samt avsluta sessionen.
Det finns en väsentlig behörighetsgräns: webbläsaren begär godkännande för varje ny webbplatsursprung. Att nätverket är aktiverat innebär inte att ursprunget redan är godkänt. Applikationen får en händelse om åtkomstbegäran och måste fatta beslut om att godkänna, neka eller avbryta. Inloggning behöver också hanteras i applikationen. Det gör det möjligt att bygga en tydlig grind runt vilka tjänster agenten får nå.
Samtidigt säger dokumentationen uttryckligen att ett godkänt webbplatsursprung inte innebär bekräftelse före varje åtgärd på sajten. För inköp, radering eller andra betydande ändringar rekommenderar OpenAI att webbläsaren begränsas till resurser där sådana handlingar inte kan utföras, eller att man använder en egen kontrollerad webbläsarmiljö. En instruktion till agenten om att fråga först är inte en teknisk spärr om agenten kan utföra åtgärden direkt.
För en homelab- eller företagsmiljö innebär detta ett val. Den värdhanterade webbläsaren kan sänka arbetet med att driva egen browserautomation. Men den är inte lokal inferens, och data som agenten ser behöver granskas mot organisationens krav. Ett test med offentliga sidor, testkonton och läsrättigheter är lämpligare än att börja i administratörsgränssnitt. Spara sessions-ID, begärda ursprung, beslut och slutresultat så att beteendet kan granskas i efterhand.
GitHub Copilot får modellen stegvis
GitHub meddelade samma dag att GPT-6.1 Sol är generellt tillgänglig och rullas ut stegvis i Copilot. De angivna abonnemangen är Pro+, Max, Business och Enterprise. Modellen kan väljas i flera klienter, bland annat Visual Studio Code, Copilot CLI och kodagenten. Det är en separat produktdistribution från OpenAI:s API: ett API-konto och en Copilot-prenumeration har skilda åtkomst- och debiteringsmodeller.
GitHub uppger att modellen debiteras enligt leverantörens listpris i användningsbaserad debitering och att administratörer för Business och Enterprise styr åtkomst via modellpolicyn. Att modellen inte syns direkt i modellväljaren kan bero på gradvis utrullning. GitHubs uppgifter om färre steg och token i tidiga tester bör ses som leverantörens observation, inte som en oberoende jämförelse. Förvaltare bör kontrollera modellpolicyn och mäta effekten på typiska arbetsuppgifter innan standardval ändras.
Prioritera tester efter risk och kostnad
Först bör team som använder OpenAI API testa GPT-6.1 Sol på egna kod- eller analysuppgifter. Jämför med den modell som redan används, med samma prompt, verktyg, filer och bedömningskriterier. Mät både fel och tokenkostnad, särskilt om inmatningen närmar sig gränsen 272 000 token. Nästa steg är ett avgränsat fleragenttest där varje deluppgift har ett mätbart resultat. Webbläsarautomation bör komma efter att åtkomst, inloggning, revisionsspår och åtgärdsgränser har utformats.
Team med EU-residenskrav behöver kontrollera den faktiska körnivån, eftersom modellens EU-stöd inte gäller alla hastighetslägen. Copilot-administratörer bör kontrollera modellpolicy och budget separat från API-konfigurationen. För lokala AI-installationer förändrar nyheten inte hårdvarukrav eller möjligheten att köra modellen på egen server; detta är molnbaserade tjänster. Däremot ger den en tydlig jämförelsepunkt för när en lokal agent fortfarande är att föredra på grund av dataplacering eller kontroll.
LabOps IT:s bedömning
Den största förändringen är inte modellnamnet ensamt, utan att modell, delegering och webbläsarverktyg nu kan kombineras inom OpenAI:s utvecklarstack. Det kan sänka tröskeln för fungerande agenter som behöver läsa och använda webbgränssnitt. Värdet måste dock visas på riktiga uppgifter med känd kostnad och acceptabla fel. Särskilt webbläsaråtkomst bör bedömas som ett behörighets- och driftbeslut, eftersom godkännande av en webbplats inte begränsar vad agenten gör där. För produktion är en snäv resursyta och ett granskbart testflöde mer värdefullt än snabbast möjliga demo.