# Reasoning Models (O1/O3) Optimization and Usage

**Last updated:** 2026-02
**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

### Azure AI Foundry

Reasoning models er tilgjengelige i Azure AI 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 mars 2025 er O1-modeller tilgjengelige i **Prompt Builder**:
- 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):**

| Modell | Input Tokens | Reasoning Tokens | Output Tokens | Bruksområde |
|--------|--------------|------------------|---------------|-------------|
| `o1` | $15 | $60 | $60 | Balansert reasoning |
| `o3` | $10-20 | $60-80 | $60-80 | Standard reasoning |
| `o3-mini` | $1-3 | $15-25 | $15-25 | Kostnadseffektivt |
| `o4-mini` | $1-3 | $15-25 | $15-25 | Rask og billig |
| `gpt-5` | $20-30 | $80-100 | $80-100 | Premium reasoning |
| `gpt-5-mini` | $3-5 | $20-30 | $20-30 | Balansert premium |
| `codex-mini` | $1-3 | $15-25 | $15-25 | Kode-spesialist |

**Merk:** Faktiske priser varierer basert på region, commitment og enterprise agreements. Reasoning tokens kan utgjøre 20-60% av total token count avhengig av effort-nivå.

### 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)
- **Limited access request** for enkelte modeller (o3-pro, gpt-5-pro, gpt-5-codex)
- Request via: https://aka.ms/oai/o3access eller https://aka.ms/oai/gpt5access

**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) i februar 2026. Alle tekniske detaljer er verifisert mot siste API-versjon.

**Primary sources:**

1. **Azure OpenAI reasoning models**
   https://learn.microsoft.com/en-us/azure/ai-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/ai-foundry/openai/concepts/models
   *Confidence: Verified (MCP fetch 2026-02)*

3. **Reasoning models with Microsoft Foundry Models**
   https://learn.microsoft.com/en-us/azure/ai-foundry/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/ai-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 search 2026-02)*

**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.
