# Reasoning Models (O1/O3) Optimization and Usage **Last updated:** 2026-06-19 **Status:** GA **Category:** Prompt Engineering & LLM Optimization --- ## Introduksjon Azure OpenAI sine reasoning models (O-serien og GPT-5-serien) representerer en ny generasjon språkmodeller som bruker chain-of-thought reasoning for å løse komplekse problemer. Disse modellene bruker mer tid på å "tenke" før de genererer et svar, noe som gjør dem eksepsjonelt sterke innen områder som koding, matematikk, vitenskapelig resonnering og kompleks dokumentanalyse. O-serien inkluderer modeller som `o1`, `o3`, `o3-mini`, `o3-pro`, `o4-mini` og `codex-mini`, mens GPT-5-serien inkluderer `gpt-5`, `gpt-5-mini`, `gpt-5-pro`, `gpt-5-codex` og flere varianter. Disse modellene skiller seg fra tradisjonelle completion-modeller ved at de genererer skjulte reasoning tokens som brukes til intern resonnering, men som normalt ikke returneres til brukeren (med mindre reasoning summary er aktivert). Den viktigste optimaliseringen for reasoning models er å forstå når de skal brukes, hvordan man prompter dem effektivt, og hvordan man balanserer reasoning effort mot kostnad og responstid. ## Kjernekomponenter / Nøkkelegenskaper ### Modellfamilier og kapabiliteter | Modellserie | Eksempler | Context Window | Styrker | |-------------|-----------|----------------|---------| | **O3-serien** | `o3`, `o3-mini`, `o3-pro` | 200K input / 100K output | Chain-of-thought reasoning, structured outputs, function calling | | **O4-serien** | `o4-mini`, `codex-mini` | 200K input / 100K output | Raskere reasoning, kostnadseffektivt, ideal for koding | | **O1-serien** | `o1`, `o1-preview`, `o1-mini` | 200K input / 100K output | Eldre reasoning models, fortsatt støttet | | **GPT-5-serien** | `gpt-5`, `gpt-5-mini`, `gpt-5-codex`, `gpt-5-pro` | 400K input / 128-272K output | Avansert reasoning, nye features (verbosity, preamble, lark_tool) | ### Reasoning Effort Levels Reasoning effort kontrollerer hvor mye tid modellen bruker på resonnering. Høyere effort gir bedre kvalitet, men øker responstid og antall reasoning tokens. | Level | Bruksområde | Reasoning Tokens | Responstid | |-------|-------------|------------------|------------| | `none` | Kun GPT-5.1 — ingen reasoning overhead | 0 | Raskest | | `minimal` | Enkle oppgaver, raske svar | Lavt | Veldig rask | | `low` | Standard oppgaver med litt kompleksitet | Moderat | Rask | | `medium` | Balansert kvalitet og hastighet (default) | Middels | Moderat | | `high` | Komplekse problemer, viktig presisjon | Høyt | Langsom | | `xhigh` | Kun `gpt-5.1-codex-max` — maksimal reasoning | Svært høyt | Svært langsom | ### API-støtte | Feature | O-serien | GPT-5-serien | Kommentar | |---------|----------|--------------|-----------| | **Chat Completions API** | ✅ (de fleste) | ✅ | Standard API-format | | **Responses API** | ✅ | ✅ | Nyere API med bedre reasoning-støtte | | **Developer messages** | ✅ | ✅ | Tilsvarer system messages | | **Structured outputs** | ✅ | ✅ | JSON schema validation | | **Function/tool calling** | ✅ | ✅ | Parallel tool calls varierer | | **Image input** | ✅ (unntatt o3-mini) | ✅ | Multimodal reasoning | | **Reasoning summary** | ✅ (o3, o4-mini, GPT-5) | ✅ | Innsikt i tankeprosessen | | **Streaming** | ✅ (de fleste) | ✅ | Real-time respons | ### Reasoning Summary Reasoning summary gir innsikt i modellens chain-of-thought prosess. Dette er spesielt nyttig for debugging og for å forstå hvordan modellen kom fram til et svar. ```python response = client.responses.create( model="o3", input="Beregn arealet av en sirkel med radius lik antall 'r'-er i 'strawberry'", reasoning={ "effort": "medium", "summary": "auto" # auto, concise, eller detailed } ) ``` **Tilgjengelige summary-nivåer:** - `auto` — Modellen bestemmer detaljnivå - `concise` — Kort oppsummering (ikke støttet av GPT-5) - `detailed` — Utfyllende forklaring av reasoning **Merk:** Reasoning summary genereres ikke for hvert request — dette er forventet oppførsel. ### Nye GPT-5 Features GPT-5-serien introduserer flere nye parametere for mer finmasket kontroll: | Parameter | Verdier | Beskrivelse | |-----------|---------|-------------| | `verbosity` | `low`, `medium`, `high` | Kontrollerer hvor konsist output er | | `preamble` | Object | Innsikt i planning før function calls | | `allowed_tools` | Array | Spesifiser flere tillatte tools under `tool_choice` | | `lark_tool` | Grammar definition | Strukturert output med Python Lark grammar | ### Ikke-støttede parametere Reasoning models støtter **ikke** følgende parametere som er vanlige i completion-modeller: - `temperature` - `top_p` - `presence_penalty` - `frequency_penalty` - `logprobs` - `top_logprobs` - `logit_bias` - `max_tokens` (bruk `max_completion_tokens` eller `max_output_tokens` i stedet) ## Arkitekturmønstre ### Mønster 1: Simple Zero-Shot Reasoning **Bruk når:** Du har klare, velformulerte spørsmål uten behov for eksempler. **Fordeler:** - Enklest å implementere - Ingen behov for few-shot eksempler - Reasoning models er optimalisert for zero-shot **Ulemper:** - Mindre kontroll over output-format - Kan gi lengre svar enn nødvendig ```python response = client.chat.completions.create( model="o3-mini", messages=[ {"role": "user", "content": "Hva er de viktigste sikkerhetsprinsippene for OAuth2?"} ], max_completion_tokens=2000, reasoning_effort="low" # Tilstrekkelig for faktabaserte spørsmål ) ``` **Best practice:** - Vær spesifikk i spørsmålsstillingen - Unngå chain-of-thought prompting ("tenk steg-for-steg") — reasoning models gjør dette automatisk - Bruk `reasoning_effort="low"` for enkle faktaspørsmål, `medium` for analyse ### Mønster 2: RAG med Reasoning Models **Bruk når:** Du kombinerer retrieval med kompleks resonnering over dokumenter. **Fordeler:** - Bedre kvalitet på svar ved kompleks dokumentanalyse - Reasoning models kan finne subtile sammenhenger - Reduserer hallusinasjoner ved god retrieval **Ulemper:** - Lengre responstid - Høyere kostnad pga. reasoning tokens - Kan "over-tenke" enkle dokumentoppslag ```python # Hent relevante dokumenter først retrieved_docs = vector_search(query="Azure OpenAI pricing models") # Bruk reasoning model til å analysere response = client.chat.completions.create( model="o1", messages=[ { "role": "developer", "content": "Du skal analysere dokumenter og svare presist basert kun på innholdet." }, { "role": "user", "content": f"Dokumenter:\n{retrieved_docs}\n\nSpørsmål: Hva er kostnadene for O3-modellen?" } ], max_completion_tokens=1500, reasoning_effort="medium" ) ``` **Best practice:** - Inkluder kun mest relevante dokumenter (ikke overload context) - Bruk `developer` message for instruksjoner om hvordan dokumenter skal brukes - Vurder `reasoning_effort="low"` hvis dokumentene er enkle å tolke ### Mønster 3: Complex Code Generation med Tool Calling **Bruk når:** Du skal generere kompleks kode med behov for eksterne verktøy. **Fordeler:** - Modellen kan "planlegge" før den kaller functions - GPT-5 modeller kan bruke `preamble` til å vise planning - Structured outputs sikrer korrekt JSON-format **Ulemper:** - Krever GPT-5 eller nyere O-modeller for beste tool-støtte - Reasoning overhead kan være unødvendig for simple function calls ```python tools = [ { "type": "function", "function": { "name": "execute_code", "description": "Kjør Python-kode i sandbox", "parameters": { "type": "object", "properties": { "code": {"type": "string"} }, "required": ["code"] } } } ] response = client.responses.create( model="gpt-5-codex", input="Skriv en funksjon som beregner Fibonacci-tall rekursivt og test den.", tools=tools, reasoning={ "effort": "medium" } ) # GPT-5 kan gi preamble med planning-innsikt for item in response.output: if item.type == "reasoning": print(f"Planning: {item.summary}") ``` **Best practice:** - Bruk `gpt-5-codex` eller `codex-mini` for kode-generering - Aktiver reasoning summary for å se planleggingssteg - Kombiner med structured outputs for strengere tool-validering ### Mønster 4: Background Processing for Lange Oppgaver **Bruk når:** Du har tidkrevende reasoning-oppgaver som kan kjøres asynkront. **Fordeler:** - Unngår timeout for lange reasoning-prosesser - Bedre ressursutnyttelse - Spesielt nyttig for `o3-pro` og `gpt-5-pro` **Ulemper:** - Mer kompleks arkitektur (polling eller webhooks) - Ikke real-time respons ```python # Start background task response = client.responses.create( model="o3-pro", input="Analyser alle sikkerhetsproblemer i denne 10 000 linjers kodebase.", background=True, tools=[{"type": "code_interpreter"}] ) task_id = response.id print(f"Status: {response.status}") # "queued" # Poll status senere status = client.responses.retrieve(task_id) if status.status == "completed": print(status.output_text) ``` **Best practice:** - Kombiner med webhooks for notifikasjoner når task er ferdig - Bruk for `o3-pro` som ikke støtter streaming - Sett realistiske timeouts på polling-logikk ## Beslutningsveiledning ### Velg riktig modell | Use Case | Anbefalt Modell | Reasoning Effort | Rationale | |----------|----------------|------------------|-----------| | Enkel kode-generering | `codex-mini`, `gpt-5-mini` | `low` | Rask og kostnadseffektiv | | Komplekse algoritmer | `gpt-5-codex`, `o3` | `medium` til `high` | Presisjon viktigere enn hastighet | | Matematikk og logikk | `o3`, `gpt-5` | `medium` til `high` | Chain-of-thought kritisk | | Dokumentanalyse | `o1`, `o3-mini` | `low` til `medium` | Balanse mellom kvalitet og kostnad | | Research-oppgaver | `o3-pro`, `gpt-5-pro` | `high` | Dypest mulig resonnering | | Real-time chat | `gpt-5-mini`, `gpt-5.1-chat` | `minimal` til `low` | Hastighet prioriteres | | Multi-modal (bilde+tekst) | `o3`, `o4-mini`, `gpt-5` | `medium` | Reasoning over bilder | ### Vanlige feil | Problem | Symptom | Løsning | |---------|---------|---------| | **Over-engineering prompts** | Bruker chain-of-thought teknikker manuelt | Fjern "tenk steg-for-steg" — reasoning models gjør dette automatisk | | **Feil reasoning effort** | Høy kostnad på enkle oppgaver | Bruk `low` eller `minimal` for faktabaserte spørsmål | | **Timeout på store oppgaver** | Request feiler etter 2-5 minutter | Bruk `background=True` for o3-pro og store oppgaver | | **Manglende markdown i kode** | Mister syntax highlighting | Legg til "Formatting re-enabled" i developer message (o3-mini, o1) | | **Inkonsistent output-format** | Modellen returnerer feil JSON | Bruk structured outputs med JSON schema | | **For mange reasoning tokens** | Høy kostnad, lang responstid | Senk reasoning effort eller bytt til non-reasoning modell | ### Røde flagg ⚠️ **Ikke bruk reasoning models hvis:** - Du trenger svært raske svar (<500ms responstid) - Oppgaven er triviell (enkel lookup, template-generering) - Du har streng kostnadsbudsjett og oppgaven er volume-høy - Du trenger `temperature` eller `top_p` kontroll (ikke støttet) ✅ **Bruk reasoning models når:** - Oppgaven krever multi-step resonnering - Nøyaktighet er kritisk (matematikk, kode, medisin, jus) - Du analyserer komplekse dokumenter med subtile sammenhenger - Du trenger planning før function calling - Du ønsker innsikt i tankeprosessen (reasoning summary) ## Integrasjon med Microsoft-stakken ### Microsoft Foundry Reasoning models er tilgjengelige i Microsoft Foundry (tidligere Azure AI Studio): - Deploy via **Foundry Tools resource** for full kontroll - Bruk **Playground** for testing med reasoning summary visualisering - Kombiner med **Prompt Flow** for orchestration (merk: reasoning tokens telles i cost tracking) ### Power Platform AI Builder Fra 21. mars 2025 er O1-modeller tilgjengelige i public preview i **Prompt Builder** (release-plan-siden er nå arkivert — se aktuell AI Builder-oversikt for status): - Velg "o1 reasoning model" i model selector - Ideell for store datasett-analyse, prognoser, og detaljert analyse - Kombiner med Power Automate for automatisering av reasoning-oppgaver ### Copilot Studio Reasoning models kan brukes som **custom LLM endpoints** i Copilot Studio: - Konfigurer via **Generative AI** settings - Bruk for komplekse decision trees i dialoger - Kombiner med **Dataverse** for grounded reasoning over CRM-data ### Microsoft Agent Framework Reasoning models integreres i Agent Framework: - Bruk `AzureOpenAIResponsesClient` for O-modeller - Støtte for agentic workflows med planning via `preamble` - Kombiner med MCP (Model Context Protocol) servere for external tools ```python from agent_framework.azure import AzureOpenAIResponsesClient from azure.identity import AzureCliCredential agent = AzureOpenAIResponsesClient( deployment_name="o3", credential=AzureCliCredential() ).as_agent( instructions="Du er en ekspert på kompleks resonnering.", name="ReasoningAgent" ) result = await agent.run("Løs dette logikkproblemet: Hvis A > B, B > C...") print(result.text) ``` ### Azure AI Search (RAG) Kombiner Azure AI Search med reasoning models for avansert RAG: - Bruk **vector search** for retrieval - Send resultater til reasoning model for dypere analyse - Aktiver **semantic ranking** for bedre retrieval-kvalitet - Vurder `reasoning_effort="low"` hvis retrieval allerede er høykvalitets ## Offentlig sektor (Norge) ### GDPR og datasuverenitet Reasoning tokens klassifiseres som **personopplysninger** hvis input inneholder persondata: - Reasoning tokens lagres midlertidig i Azure OpenAI-infrastruktur - **Velg Norway East eller West Europe regions** for norsk datasuverenitet - Aktiver **Customer Managed Keys (CMK)** for kryptering av reasoning data - Logg reasoning summary kun hvis nødvendig for audit-trail ### Schrems II og internasjonale dataoverføringer - **Global Standard deployments** kan rute til USA — unngå for offentlig sektor - Bruk **Regional deployments** (Norway East prioritert) - Vurder **Azure Private Link** for nettverk-isolasjon - Dokumenter data processing agreement (DPA) med Microsoft ### AI Act (EU) Reasoning models kan falle under **høyrisiko-AI** hvis brukt i kritiske beslutninger: - **Dokumenter reasoning summary** for høyrisiko-vedtak (eiendomstakst, lånegodkjenning) - Implementer **human-in-the-loop** for kritiske resonneringer - Logg reasoning effort-nivå og modellversjon for audit - Vurder **explainability krav** — reasoning summary kan oppfylle deler av dette ### Forvaltningsloven § 25 (begrunnelsesplikt) Ved bruk i offentlige vedtak: - Reasoning summary kan bidra til **begrunnelse** av AI-assisterte beslutninger - Kombiner med human review før endelig vedtak - Lagre full reasoning chain for klagesaker (vurder retention policies) ### Kostnadskontroll i offentlig sektor Reasoning tokens kan øke kostnader betydelig: - **Sett budsjetter** per use case i Azure Cost Management - **Monitor reasoning tokens** separat fra completion tokens - Vurder `reasoning_effort="low"` som default, med høyere effort kun ved behov - Bruk `gpt-5-mini` eller `codex-mini` for volume-oppgaver ## Kostnad og lisensiering ### Prismodell (foreløpig basert på global pricing) Reasoning models prises med **separate satser** for reasoning tokens og completion tokens. **Eksempel (omtrentlige priser per 1M tokens):** Reasoning-tokens faktureres til **output-raten** — de er ikke en egen prisklasse. Kolonnen «Reasoning Tokens» under viser derfor output-raten, og kostnaden skaleres med hvor mange reasoning-tokens modellen genererer. | Modell | Input (per 1M) | Reasoning/Output (per 1M) | Bruksområde | Kilde | |--------|----------------|---------------------------|-------------|-------| | `gpt-5` | $1.25 | $10.00 | Premium reasoning | Verifisert juni 2026 | | `gpt-5-mini` | $0.25 | $2.00 | Balansert | Verifisert juni 2026 | | `gpt-5-nano` | $0.05 | $0.40 | Rask, billig reasoning | Verifisert juni 2026 | | `o3-mini` | $1.10 | $4.40 | Kostnadseffektivt | Verifisert (register §1.1) | | `o1` | $15.00 | $60.00 | Legacy, balansert | Legacy-rate | | `o3` / `o4-mini` / `codex-mini` | verifiser | verifiser | Standard/rask reasoning | **Ikke re-verifisert — sjekk Azure prisside** | **Merk:** Kanonisk prissannhet er `deterministic-cost-calculation-model.md` §1.1. Reasoning-tokens kan utgjøre 20–60 % av total token-count avhengig av effort-nivå — det er den reelle kostnadsdriveren for resonneringsmodeller, ikke base-raten. ### Optimaliseringstips 1. **Start med lavt effort-nivå** — øk kun ved behov 2. **Bruk mini-varianter** for volume-oppgaver 3. **Batch-prosesser** via background mode for store jobber 4. **Monitor token usage** — reasoning tokens kan overraske 5. **Cache retrieval-resultater** når du bruker RAG 6. **Vurder non-reasoning models** for enkle oppgaver (GPT-4o, GPT-4o-mini) ### Lisensiering Reasoning models krever: - **Azure OpenAI Service** subscription (ingen spesielle lisenser) - Ingen «limited access request» lenger — tilgang til o3-pro, gpt-5-pro og gpt-5-codex er ikke lenger begrenset (verifisert mot Microsoft Learn 2026-06) **Ingen spesielle lisenskrav:** - `o1`, `o3-mini`, `o4-mini`, `codex-mini` - `gpt-5-mini`, `gpt-5-nano`, `gpt-5.1-chat`, `gpt-5.1-codex-mini` ## For arkitekten (Cosmo) ### Spørsmål å stille kunden 1. **Hva er business-verdien av bedre reasoning?** → Hvis svaret kun handler om hastighet, vurder non-reasoning models. 2. **Hva er den kritiske nøyaktigheten som kreves?** → Høy nøyaktighet (>95%) kan rettferdiggjøre `high` eller `xhigh` effort. 3. **Hva er akseptabel responstid?** → Under 2 sekunder → bruk `minimal` eller non-reasoning. → Over 10 sekunder OK → kan bruke `medium` til `high`. 4. **Hvor ofte skal denne operasjonen kjøres?** → Høy frekvens (1000+ ganger/dag) → vurder kostnadseffektive modeller (`codex-mini`, `gpt-5-mini`). 5. **Trenger dere innsikt i tankeprosessen?** → Hvis ja (debugging, audit, læring) → aktiver reasoning summary. → Hvis nei → spar tokens ved å ikke bruke summary. 6. **Vil oppgaven kombineres med external tools?** → Hvis ja → vurder GPT-5 for `preamble` og bedre tool planning. 7. **Er dette en high-stakes beslutning (medisin, jus, sikkerhet)?** → Hvis ja → dokumenter reasoning, implementer human review, vurder ekstern audit. 8. **Har dere compliance-krav (GDPR, AI Act)?** → Hvis ja → regional deployment, reasoning summary logging, DPA med Microsoft. ### Fallgruver å unngå ⚠️ **Fallgruve 1: Bruke reasoning models for alt** Mange kunder overvurderer behovet for reasoning. 80% av oppgaver kan løses med GPT-4o eller GPT-4o-mini til lavere kostnad og høyere hastighet. ⚠️ **Fallgruve 2: Sette reasoning effort for høyt** `high` og `xhigh` effort kan gi 3-10x høyere reasoning tokens uten tilsvarende kvalitetsforbedring for enkle oppgaver. ⚠️ **Fallgruve 3: Glemme markdown-formateringsproblemer** O3-mini og O1 returnerer ikke markdown som standard. Hvis kunden forventer kodeblokker med syntax highlighting, må "Formatting re-enabled" legges til. ⚠️ **Fallgruve 4: Ikke planlegge for timeouts** O3-pro og store reasoning-oppgaver kan ta >5 minutter. Uten background mode vil HTTP-timeouts inntreffe. ⚠️ **Fallgruve 5: Manuell chain-of-thought prompting** Kunder som migrerer fra GPT-4 prøver ofte å bruke "tenk steg-for-steg" teknikker. Dette er redundant og kan forvirre reasoning models. ### Anbefalinger per modenhetsnivå #### Nivå 1: Proof-of-Concept (første gang med LLMs) - **Start med:** `o3-mini` eller `gpt-5-mini` - **Reasoning effort:** `low` som default - **API:** Chat Completions API (enklere å komme i gang) - **Prompt-strategi:** Enkle zero-shot prompts - **Fokus:** Demonstrer verdi, ikke overoptimalisering - **Metrikker:** Sammenlign kvalitet vs. GPT-4o for å dokumentere ROI #### Nivå 2: Pilot / MVP (første produksjonssystem) - **Utvid til:** `o1` eller `gpt-5` for kritiske use cases - **Reasoning effort:** `low` for volume, `medium` for presisjon - **API:** Introduser Responses API for bedre reasoning-støtte - **Prompt-strategi:** Strukturerte prompts, begynn med RAG hvis nødvendig - **Fokus:** Kostnadskontroll, error handling, monitoring av reasoning tokens - **Metrikker:** Token usage per request type, responstid, feilrate #### Nivå 3: Produksjon i skala (mature AI-løsning) - **Model-strategi:** Kombiner flere modeller basert på use case → `codex-mini` for enkel koding → `o3` for kompleks analyse → `gpt-5-pro` for critical reasoning - **Reasoning effort:** Dynamisk basert på kompleksitet (low/medium/high) - **API:** Responses API med background mode for tunge oppgaver - **Prompt-strategi:** Optimaliserte prompts, A/B-testing, few-shot når nødvendig - **Fokus:** Kostnadsoptimalisering, latency-tuning, compliance, explainability - **Metrikker:** Cost per outcome, reasoning token efficiency, human override rate ## Kilder og verifisering Denne kunnskapsreferansen er basert på offisiell Microsoft Learn-dokumentasjon hentet via MCP (Model Context Protocol), sist re-verifisert 2026-06-19. Alle tekniske detaljer er verifisert mot siste API-versjon. **Primary sources:** 1. **Azure OpenAI reasoning models** https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/reasoning *Confidence: Verified (MCP fetch 2026-02)* 2. **Azure OpenAI model availability and pricing** https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure *Confidence: Verified (MCP fetch 2026-02)* 3. **Reasoning models with Foundry Models** https://learn.microsoft.com/en-us/azure/foundry-classic/foundry-models/how-to/use-chat-reasoning *Confidence: Verified (MCP search 2026-02)* 4. **Azure OpenAI function calling support** https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/function-calling *Confidence: Verified (MCP search 2026-02)* 5. **GPT-5 prompting guide (OpenAI)** https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide *Confidence: Baseline (referenced in Microsoft docs, ikke direkte verifisert)* 6. **Power Platform O1 model support** https://learn.microsoft.com/en-us/power-platform/release-plan/2024wave2/ai-builder/use-o1-reasoning-model-prompt-builder *Confidence: Verified (MCP fetch 2026-06-19) — release-plan-siden er arkivert; public preview fra 21. mars 2025* **Confidence levels per seksjon:** - **Kjernekomponenter / Nøkkelegenskaper:** Verified (MCP) - **Arkitekturmønstre:** Baseline (best practices fra modellkunnskap + MCP) - **Beslutningsveiledning:** Baseline (arkitekturerfaring + Microsoft docs) - **Integrasjon med Microsoft-stakken:** Verified (MCP + baseline) - **Offentlig sektor (Norge):** Baseline (legal/compliance-kunnskap + Azure docs) - **Kostnad og lisensiering:** Baseline (pricing estimert, lisensiering verifisert via MCP) - **For arkitekten (Cosmo):** Baseline (erfaring + Cosmo-persona) **Merk:** Priser er omtrentlige og basert på global Azure-prising. Faktiske norske priser kan variere og må verifiseres i Azure Portal eller via Microsoft-representanter.