GPT-6 Astra kontra lokal AI: Vilka delar av en agent bör köras på din hemmaserver?

GPT-6 Astra gör den lokala modellen mindre central, men kan göra den lokala infrastrukturen viktigare. OpenAI:s senaste frontiermodell är byggd för komplext resonemang, kodning, datoranvändning, research och verktygsdrivet arbete från början till slut. Det försvagar ett gammalt skäl att köpa ett stort lokalt grafikkort: att försöka återskapa resonemang på frontiernivå helt hemma.

Men en AI-agent är mycket mer än sin modell. Filer, minne, hämtningsindex, autentiseringsuppgifter, verktygsbehörigheter, uppgiftsköer, loggar, säkerhetskopior och lokala enheter finns alla utanför kontextfönstret. En hemserver behöver inte köra GPT-6 Astra för att bli centrum för en Astra-driven agent.

Vad förändras för AI-agenter med GPT-6 Astra?

GPT-6 Astra för molnmodeller längre bort från att besvara frågor och närmare att slutföra arbete i flera steg.

OpenAI positionerar Astra för svåra uppgifter från början till slut som kombinerar resonemang med verktyg, kodning, webbsurfning, datoranvändning, research, dokumentskapande och arbetsflöden i professionell programvara. Den officiella lanseringen av GPT-6 Astra betonar inte bara starkare resonemang, utan även modellens förmåga att använda programvara, granska resultat, revidera arbetet och fortsätta mot ett färdigt resultat.

Det förändrar en agents utformning:

Traditionell assistent:
Fråga → Modell → Svar

Agentsystem:
Observera → Resonera → Verktyg → Åtgärd → Granska → Fortsätt

OpenAI rapporterar att Astra fick 72,6 % i OSWorld 2.0-testet och slutförde simulerade datoranvändningsuppgifter på ungefär 47 % kortare tid än GPT-5.6 Sol. Det här är utvärderingsresultat som rapporterats av OpenAI, inte garantier för ett visst hemserverarbetsflöde, men de visar tydligt riktningen: modellen blir bättre på uthålligt agerande, inte bara på textgenerering.

Kan GPT-6 Astra köras lokalt?

Inte som en nedladdningsbar lokal modell enligt OpenAI:s nuvarande lansering.

Astra levereras via OpenAI:s hostade produkter och API:t. OpenAI har inte meddelat några nedladdningsbara GPT-6 Astra-vikter som kan läsas in i Ollama, llama.cpp, vLLM eller någon annan självhostad inferensmiljö.

Det gör den här arkitekturen omöjlig:

HEMSERVER
     |
     v
GPT-6 Astra-vikter
     |
lokal inferens

Men den kräver inte heller den här arkitekturen:

Allt
filer
minne
verktyg
autentiseringsuppgifter
automatisering
     |
     v
Moln

Modellen kan förbli hostad medan mycket av agenten runt den fortfarande står under lokal kontroll.

Om Astra är så kapabel, varför behålla något lokalt?

Eftersom modellen bara är en del av systemet.

En användbar agent kan vara beroende av:

• avancerat resonemang,
• lokala modeller eller molnmodeller,
• privata filer,
• index för informationshämtning,
• långtidsminne,
• applikationstillstånd,
• autentiseringsuppgifter,
• verktygsbehörigheter,
• godkännanderegler,
• schemalagda jobb,
• lokala enheter,
• loggar,
• och säkerhetskopior.

Det är bara den första som måste vara GPT-6 Astra.

AI-AGENT
   |
   +-- Avancerad modell
   +-- Lokal modell
   +-- Minne
   +-- Filer
   +-- RAG
   +-- Verktyg
   +-- Autentiseringsuppgifter
   +-- Behörigheter
   +-- Kö
   +-- Loggar
   +-- Säkerhetskopior

Den användbara frågan är därför inte längre ”moln-AI eller lokal AI?” utan ”vilket lager hör hemma var?”

Vilka delar av en agent bör GPT-6 Astra hantera?

Astra passar bäst där dyr avancerad intelligens ger en betydande förbättring av uppgiftsutförandet.

Bra kandidater omfattar:

• svårt resonemang,
• obekanta problem,
• komplex research,
• förståelse av stora kodbaser,
• svår felsökning,
• planering för datoranvändning,
• flerstegsarbetsflöden för yrkesbruk,
• och uppgifter som kräver upprepad granskning och korrigering.

Detta är särskilt viktigt eftersom Astra inte prissätts som en liten nytto­modell. De aktuella API-specifikationerna för GPT-6 Astra anger ett standardpris på 10 dollar per miljon inmatningstoken och 50 dollar per miljon utmatningstoken.

Det gör inte Astra ”för dyr”. Det betyder att arkitekturen bör reservera avancerat resonemang för uppgifter som drar nytta av avancerat resonemang. Det bredare beslutet mellan API:er, egen hårdvara och selektiv routing behandlas mer ingående i vår guide om kostnader för lokal och molnbaserad AI.

Vilka uppgifter är fortfarande lämpliga för en lokal modell?

En lokal modell behöver inte överträffa Astra. Den behöver bara vara tillräckligt bra för att hindra Astra från att utföra arbete som aldrig behövde Astra.

Rutinmässiga lokala arbetsbelastningar kan omfatta:

• klassificering,
• taggning,
• metadataextraktion,
• dokumenttriage,
• enkel sammanfattning,
• logganalys,
• grundläggande routingbeslut,
• privat förbehandling,
• embeddingar,
• och offline-reservlösning.

En hybridagent kan styra arbetet efter svårighetsgrad:

UPPGIFT
 |
 v
ROUTER
 |
 +---- rutin / privat ----> LOKAL MODELL
 |
 +---- svårt ----------> GPT-6 ASTRA

En liten lokal modell kan bearbeta hundratals repetitiva händelser utan att göra varje temperaturavläsning, loggrad, dokumenttagg eller filklassificering till en förfrågan till en frontier-modell. Återanvändbara lokala AI-agentfärdigheter kan också göra dessa mindre modeller mer användbara genom att ge dem uttryckliga procedurer, i stället för att förvänta sig resonemang på frontier-nivå vid varje förfrågan.

Ersätter Astras kontextfönster på 1 M lokal RAG?

Nej. Ett stort kontextfönster förändrar hur mycket modellen kan granska på en gång; det eliminerar inte behovet av att välja vilken information som ska föras in i kontexten.

GPT-6 Astra stöder för närvarande ett kontextfönster på 1 050 000 token och upp till 128 000 utdatatoken. Det är tillräckligt stort för omfattande kodarkiv och dokumentsamlingar, men en NAS kan innehålla terabyte med data och miljontals filer.

Den användbara arkitekturen är fortfarande selektiv:

NAS
 |
miljontals filer
 |
lokal sökning / metadata / inbäddningar
 |
hämta relevant material
 |
valt sammanhang
 |
GPT-6 Astra

i stället för:

NAS
 |
allt
 |
1 M kontext
 |
GPT-6 Astra

Det finns också ett ekonomiskt skäl att hämta information selektivt. OpenAI:s aktuella modellsida anger att förfrågningar med fler än 272 000 inmatningstoken debiteras med 2× de normala priserna för inmatning och cache samt 1,5× priset för utdata för hela förfrågningen.

RAG är därför inte bara en nödlösning för små kontextfönster. Det är ett kontrollager för att avgöra vilken information som förtjänar att nå modellen.

Om källmaterialet redan finns på lokal lagring visar en privat NAS AI-assistent hur hämtning kan fungera som ett mellanlager mellan ett stort dokumentarkiv och den modell som slutligen genererar svaret.

Är modellkontext samma sak som agentminne?

Nej. Kontext är arbetsinformation. Beständigt minne är systemtillstånd.

MODELLKONTEXT

arbetsinformation
för inferens
       |
       v
GPT-6 Astra


BESTÅENDE MINNE

filer
anteckningar
databas
RAG-index
uppgiftshistorik
agenttillstånd
       |
       v
Hemmaserver / NAS

OpenAI förbättrar också kontinuiteten i Codex. Med Astra kan Codex experimentellt spara anteckningar mellan kontextfönster och söka i tidigare kontextfönster efter krav, testresultat och verktygsutdata som kanske inte har överlevt en vanlig komprimering.

Det löser ett viktigt problem: att upprätthålla kontinuitet under en lång kodningssession.

Det besvarar fortfarande inte frågor som:

• Vilken projektfil är den kanoniska?
• Vilket jobb ska återupptas efter en omstart?
• Vad ändrade agenten förra månaden?
• Vilken version ska återställas?
• Vilken användare godkände en åtgärd?
• Vilken autentiseringsuppgift får det här verktyget komma åt?

Bättre modellminne eliminerar inte behovet av systemminne.

Var bör filer och agentens långsiktiga minne lagras?

För en agent som upprepade gånger arbetar med samma privata data är en lokal server eller NAS en bra plats att förvara den beständiga källan till sanningen.

Det lagret kan innehålla:

• dokument,
• projektarkiv,
• mediebibliotek,
• kunskapsbaser,
• vektorindex,
• uppgiftsregister,
• agentanteckningar,
• loggar,
• och säkerhetskopior.

Molnmodellen kan endast ta emot den delmängd som krävs för en specifik uppgift.

LOKALA DATA

Filer
Kunskapsbas
Minne
Loggar
     |
     v
Hämtare
     |
     v
Relevant kontext
     |
     v
GPT-6 Astra

Detta skiljer beständigt ägarskap från tillfällig inferens.

Agenten kan byta från Astra till en annan frontier-modell nästa år utan att bygga om filarkivet, skriva om åratal av uppgiftshistorik eller flytta alla källdokument till en ny modellleverantörs lagringslager. Samma rollfördelning syns i en praktisk AI-stack med Mac och NAS, där aktiv beräkning och långlivat minne inte behöver finnas på samma maskin.

Bör GPT-6 Astra köra verktyg direkt på din hemmaserver?

Astra kan avgöra att ett verktyg bör köras, men obegränsad åtkomst till maskinen bör inte vara standardarkitekturen.

OpenAI:s nuvarande verktygsarkitektur för Astra-agenten stöder funktionsanrop, MCP, datoranvändning, värdhanterat skal, kodtolk, applicering av patchar, filsökning och andra verktyg.

För utvecklardefinierade verktyg är det dock fortfarande applikationen som kör verktyget.

Det skapar en användbar gräns:

GPT-6 ASTRA
Resoneringsplan
      |
      v
VERKTYGSBEGÄRAN
      |
      v
LOKAL GATEWAY
      |
 +----+----+----+----+
 |    |    |    |    |
Git   NAS   HA   Appar   Skript

Modellen kan begära en åtgärd utan att få obegränsad kontroll över den underliggande maskinen.

Ett verktyg kan exponera:

restart_media_server()

read_project_files()

create_backup()

get_home_energy_state()

i stället för att exponera:

root-skal
hela filsystemet
alla API-token
alla nätverksenheter

Modellen behöver inte ha kontroll över maskinen för att kunna resonera kring vad maskinen bör göra.

När antalet verktyg växer kan ett MCP-gatewaylager hjälpa till att centralisera autentisering, routning, hastighetsbegränsningar och observerbarhet i stället för att exponera varje lokalt verktyg direkt för varje agent.

Var bör en AI-agents autentiseringsuppgifter finnas?

Ju mer kapabla datoranvändande agenter blir, desto viktigare blir behörighetsgränser.

En agent kan så småningom behöva åtkomst till:

• Git-arkiv,
• Home Assistant,
• NAS-resurser,
• databaser,
• molnapplikationer,
• e-post,
• kalendrar,
• SSH-tjänster,
• eller interna API:er.

Den svaga arkitekturen är:

AGENT
  |
alla autentiseringsuppgifter
  |
full åtkomst

En säkrare arkitektur är:

GPT-6 Astra
      |
Verktygsbegäran
      |
Behörighetslager
      |
Godkänd lokal tjänst

Till exempel:

TILLÅT

läs /projects/alpha


INTE

läs hela NAS-enheten

eller:

TILLÅT

starta om en container


INTE

obegränsad root-SSH

OpenAI säger att Astra har blivit bättre på att respektera uppgiftsgränser, hantera promptinjektioner och undvika obehöriga eller destruktiva datoråtgärder. Dess säkerhetsarkitektur för Astra återspeglar också den större risk som skapas av allt mer kapabla modeller som använder verktyg.

Bättre modellanpassning kompletterar behörighetsgränser. Det gör inte behörighetsarkitekturen onödig. En mer detaljerad modell för behörigheter för AI-agentverktyg kan begränsa behörigheten till en mapp, en tjänst eller en åtgärd i stället för att dela en huvudautentiseringsuppgift i hela agentstacken.

Varför passar asynkrona verktygsanrop för en hybridagent?

GPT-6 Astra introducerar asynkrona verktygsanrop, vilket är särskilt relevant för agenter på hemmaservrar.

Modellen kan anropa ett asynkront verktyg som definierats av utvecklaren och fortsätta resonera, anropa ett annat verktyg eller hantera en oberoende del av uppgiften medan applikationen slutför den första åtgärden.

GPT-6 Astra
     |
     +-- begär lokal säkerhetskopiering
     |
     +-- fortsätt undersökningen
     |
     +-- granska ett annat resultat
     |
     v
LOKAL SERVER
kör säkerhetskopiering
     |
     v
returnerar resultat
     |
     v
GPT-6 Astra fortsätter

OpenAI:s utvecklarvägledning påpekar uttryckligen att applikationen fortfarande kör det asynkrona verktyget och hanterar det väntande arbetet.

Den uppdelningen passar naturligt i en hybridarkitektur:

molnmodellen hanterar resonemanget medan det lokala systemet ansvarar för körningstillståndet.

Vad bör ske lokalt innan data når Astra?

Alla råbytes behöver inte lämna hemmet bara för att det slutliga resonemanget använder en molnmodell.

Ett lokalt förbehandlingslager kan:

• söka i filer,
• filtrera resultat,
• extrahera text,
• ta bort irrelevanta avsnitt,
• klassificera innehåll,
• redigera valda fält,
• skapa embeddings,
• och sammanfatta repetitivt material.

RÅ PRIVAT DATA
       |
       v
LOKAL BEARBETNING
       |
       +-- hämta
       +-- filtrera
       +-- klassificera
       +-- redigera
       |
       v
MINSTA ANVÄNDBARA KONTEXT
       |
       v
GPT-6 Astra

Detta är inte detsamma som att hävda att moln-API:er saknar integritetskontroller. OpenAI:s aktuella datakontroller för API:et anger att API-data inte används för att träna OpenAI:s modeller om kunden inte uttryckligen väljer det, medan berättigade organisationer kan använda ytterligare kontroller, såsom Zero Data Retention.

Skillnaden är arkitektonisk:

leverantörens integritetskontroller styr vad som händer efter att data har skickats; lokal dataminimering styr vad som över huvud taget behöver skickas.

För dokumentintensiva arbetsflöden kan lokala kunskapsbaserade arbetsflöden hålla tolkning, indexering och hämtning nära de lagrade uppgifterna, samtidigt som endast det underlag som behövs för det slutliga modell-anropet exponeras.

Hur ser en Astra-agent tillsammans med en hemserver ut?

En praktisk hybridstack kan separera frontmodellens intelligens från den beständiga lokala infrastrukturen:

                  GPT-6 ASTRA
                 Molnbaserat resonemang
                       |
                 valt sammanhang
                       |
                       v
                  HEMSERVER
                       |
        +--------------+---------------+
        |              |               |
   Agentkörning Verktygsgateway Lokal modell
        |              |               |
        |         +----+----+       rutinjobb
        |         |    |    |
        |        Git HA Appar
        |
        v
       RAG
        |
        v
       NAS
 +------+------+------+------+
 |      |      |      |      |
Filer Minne Loggar Tillstånd Säkerhetskopior

Arkitekturen kan förstås som fyra plan.

Hemserverns viktigaste AI-roll kanske inte är inferens. Den kan vara allt runt omkring inferensen.

Samma princip är användbar när man avgör om lokal AI och fillagring bör finnas på samma maskin eller delas upp mellan en stabil lagringsserver och en separat beräkningsnod.

Gör GPT-6 Astra lokala GPU:er mindre viktiga?

För vissa användare, ja.

Om det enda skälet till att köpa en kraftfull GPU är att återskapa det starkaste möjliga allmänna resonemanget hemma, kan en hostad frontmodell göra investeringen mindre motiverad.

Astra gör det i praktiken möjligt för användaren att hyra avancerat resonemang när det behövs.

Men lokala GPU:er är fortfarande användbara för:

• slutsats utan internetanslutning
• privat högvolymbearbetning
• upprepade förutsägbara arbetsbelastningar,
• bild- och videomodeller,
• experiment med lokala modeller,
• embeddings i hög volym,
• och arbetsbelastningar där molnfakturering per förfrågan är oönskad.

Den viktiga skillnaden är:

ATT ÄGA RESONEMANG I FRONTKLASS
          jämfört med
ATT ÄGA LOKAL INFRASTRUKTUR

Astra kan minska behovet av att äga beräkningskapacitet i frontklass utan att minska värdet av att äga lagring, lokala tjänster, minne, automatisering eller en beständig agentkörmiljö.

Om lokal inferens fortfarande ingår i designen bör modellens lämplighet kontrolleras separat från resten av servern. Aktuella hårdvarukrav för Ollama styrs främst av modellstorlek, kontext, samtidighet och tillgängligt RAM eller VRAM, snarare än av kraven från agentens kontrollplan i sig.

Behöver din hemmserver verkligen en GPU?

Inte nödvändigtvis.

En server vars huvudsakliga uppgifter är:

• agentorkestrering,
• fillagring,
• RAG-indexering,
• verktygskörning,
• Home Assistant,
• uppgiftsköer,
• loggar,
• och säkerhetskopior

kan vara användbar utan att köra en stor lokal språkmodell.

Beräkningstopologin kan vara:

GPT-6 Astra
 molnbaserat resonemang
      |
      v
Energisnål hemmserver
verktyg / minne / tillstånd
      |
      +----------+
      |          |
     NAS      Valfri GPU-dator
              lokal inferens

GPU:n blir en valfri beräkningsnod i stället för själva definitionen av AI-servern.

Detta är viktigt eftersom ett system som fungerar utmärkt som filserver ändå kan ha svårt att hantera kontinuerlig lokal inferens. De vanliga begränsningarna hos lokala AI-servrar visar sig vanligtvis när modellinläsning, växande kontext, embeddings eller GPU-arbetsbelastningar börjar konkurrera med serverns befintliga lagrings- och programuppgifter.

När räcker en Astra-agent med endast API?

En hemmserver krävs inte automatiskt för varje Astra-arbetsflöde.

En arkitektur med endast API kan vara meningsfull när agenten främst utför:

• offentlig webbresearch,
• sporadiskt dokumentskrivande,
• molnbaserad kodning,
• tillfällig analys,
• arbeta i SaaS-applikationer,
• och uppgifter med lite beständigt privat tillstånd.

Användare
 |
 v
GPT-6 Astra
 |
 v
Molnverktyg

Om det saknas ett stort privat arkiv, lokal enhetsstyrning, en beständig kö, behov av offlineanvändning och långkörande lokala tjänster, kan en hemmserver bara skapa extra driftarbete.

När är en hybrid Astra-agent mer meningsfull?

En hybridarkitektur blir mer tilltalande när agenten blir beständig och ansluten till verklig infrastruktur i hemmet eller på arbetsplatsen.

Skiljelinjen är inte huruvida användaren tycker om lokal AI.

Det avgörs av om agenten behöver varaktigt lokalt tillstånd och lokala behörigheter.

Gör GPT-6 Astra lokal AI mindre relevant?

Det förändrar var lokal AI är värdefull, snarare än att göra den irrelevant.

Lokala modeller behöver inte längre bära hela intelligensbördan. De kan specialisera sig på rutinmässigt, privat, omfattande eller offline-arbete, medan Astra hanterar svårare resonemang när en upptrappning är motiverad.

Samtidigt gör förbättrad datoranvändning infrastrukturen runt modellen viktigare.

En agent som kan resonera kring fler verktyg behöver tydligare verktygsgränser.

En agent som kan hantera längre uppgifter behöver varaktig uppgiftsstatus.

En agent med ett kontextfönster på en miljon token behöver fortfarande ett sätt att hämta information från terabytevis med filer.

En agent som kan använda programvara behöver fortfarande autentiseringsuppgifter, godkännanden, loggar och återställningsbara data.

Använd avancerad AI för bedömningar; håll varaktigt tillstånd och behörigheter nära hemmet.

Det ger en annan definition av lokal AI:

GAMMAL IDÉ

Lokal AI
=
Kör modellen lokalt


HYBRIDIDÉ

Lokal AI-infrastruktur
=
Filer
Minne
Hämtning
Verktyg
Behörigheter
Uppgiftsstatus
Loggar
Säkerhetskopior
Lokal reservlösning
+
valfria lokala modeller

Den starkaste modellen kan finnas i molnet, medan agenten fortfarande kan ha ett lokalt hem.

Hemmaservern behöver inte köra GPT-6 Astra för att bli centrum för en Astra-driven agent.

Vanliga frågor: GPT-6 Astra jämfört med lokal AI

Kan GPT-6 Astra köras lokalt på en hemmaserver?

OpenAI har inte tillkännagett nedladdningsbara GPT-6 Astra-vikter i den aktuella lanseringen. Astra levereras för närvarande via OpenAI-värdtjänster och API-åtkomst, snarare än som en lokalt självhostad modell.

Ersätter GPT-6 Astra lokal AI?

Nej. Astra kan ta över krävande avancerat resonemang, medan lokala modeller fortfarande är användbara för rutinbearbetning, privat förbehandling, embeddings, klassificering, jobb i stor skala och offline-reservlösningar.

Ersätter GPT-6 Astras kontextfönster på 1 miljon token RAG?

Nej. Det stora kontextfönstret gör att Astra kan ta hänsyn till mer information i en enda förfrågan, men hämtning är fortfarande användbar för att välja relevant material från mycket större filsaml ingar och kontrollera tokenkostnaden. Ett arbetsflöde för dokumentsökning och RAG är fortfarande användbart även när den slutliga modellen har ett mycket stort kontextfönster.

Är ett kontextfönster på 1 miljon token samma sak som långtidsminne?

Nej. Kontext är information som är tillgänglig under inferensen. Långtidsminne för agenter behöver hållbar lagring, hämtning, uppdatering, versionshantering och återställning mellan uppgifter och modelsessioner.

Var bör en AI-agents minne lagras?

Beständigt agentminne kan finnas i filer, databaser, sökindex eller annan lagring som kontrolleras av applikationen. En hemmaserver eller NAS är användbar när detta tillstånd behöver förbli lokalt, hållbart, sökbart och oberoende av en enskild modellleverantör.

Bör GPT-6 Astra ha direkt SSH-åtkomst till en hemmaserver?

Inte som standard. En säkrare arkitektur exponerar snävt avgränsade verktyg och behörigheter, så att modellen kan begära specifika åtgärder utan att automatiskt få obegränsad root-åtkomst till maskinen. Samma princip utforskas mer detaljerat genom kapacitetsbaserad agentåtkomst.

Varför är asynkrona verktygsanrop viktiga?

Asynkrona verktygsanrop låter Astra fortsätta resonera eller utföra oberoende arbete medan applikationen kör ett verktyg som tar längre tid. Detta passar hybridsystem där lokala jobb, säkerhetskopieringar, skript eller tjänster kan ta tid att slutföra.

Var bör en AI-agents inloggningsuppgifter lagras?

Inloggningsuppgifter bör hanteras av applikations- eller policy-lagret och begränsas till minsta praktiska uppsättning resurser och åtgärder. Modellen kan begära en verktygsåtgärd utan att få tillgång till alla underliggande lösenord eller token.

Behöver en hybrid Astra-agent ett lokalt GPU-kort?

Nej. En hemmaserver kan tillhandahålla filer, RAG, verktyg, automatisering, behörigheter, köer och säkerhetskopior utan att köra en stor modell. Ett GPU-kort kan läggas till separat när lokala inferensarbetslaster motiverar det.

Vad bör en lokal modell hantera i stället för Astra?

Lämpliga användningsområden är bland annat klassificering, extrahering, taggning, embeddingar, rutinmässiga sammanfattningar, lokal logganalys, privat förbehandling och offline-reservläge – uppgifter där spetsmodellens resonemang ger begränsat mervärde.

När räcker en Astra-konfiguration som endast använder API?

Det kan räcka för sporadisk research, molnbaserad kodning, dokumentarbete och uppgifter utan stora privata arkiv, lokala enheter, beständiga jobb eller betydande långsiktigt agenttillstånd.

När blir en hemmaserver användbar för GPT-6 Astra?

En hemmaserver blir användbar när agenten behöver beständiga lokala filer, RAG, scheman, aktivitetsköer, lokala verktyg, åtkomst till enheter, inloggningsuppgifter, loggar, säkerhetskopior eller andra tjänster som bör förbli tillgängliga oberoende av molnmodellen.