# Token Optimization and Cost Efficiency

**Last updated:** 2026-06-24
**Status:** GA
**Category:** Prompt Engineering & LLM Optimization

---

## Introduksjon

Token-optimalisering er kritisk for både kostnadseffektivitet og ytelse i Azure OpenAI-løsninger. Hver API-forespørsel koster basert på antall tokens prosessert (input + output), og ineffektiv token-bruk kan raskt eskalere både kostnader og responstider. Denne guiden dekker praktiske teknikker for å redusere token-forbruk, utnytte caching-mekanismer, og balansere kostnad mot ytelse.

**Nøkkelkonsept:** Azure OpenAI-modeller prosesserer tekst ved å dele den opp i tokens. Ett token er ca. 4 tegn for vanlig engelsk tekst. Både input (prompt) og output (completion) blir målt i tokens, og prisene varierer betydelig mellom modeller og deployment-typer.

---

## Kjernekomponenter

### Token-basert prismodell

| Komponent | Beskrivelse | Kostnadsfaktor |
|-----------|-------------|----------------|
| **Input tokens** | Tokens i prompt (system message + user input + conversation history) | Lavest kostnad per token |
| **Output tokens** | Tokens generert av modellen som respons | 2-4× høyere enn input |
| **Cached tokens** | Input tokens som matcher cached content | 50-100% rabatt (avhenger av deployment-type) |
| **Reasoning tokens** | Ekstra tokens brukt av o-series modeller for resonnering | Egen prisstruktur (kun synlig i API-respons) |

**Eksempel GPT-4o-mini (standard deployment):**
- Input: ~$0.15 per 1M tokens
- Output: ~$0.60 per 1M tokens
- Cached input: ~$0.075 per 1M tokens (50% rabatt)

### Deployment-typer og token-optimalisering

| Deployment Type | Token-strategi | Best For |
|----------------|----------------|----------|
| **Standard (pay-as-you-go)** | Fokus på å redusere totale tokens; prompt caching gir moderat rabatt | Variabel last, utvikling, testing |
| **Provisioned Throughput (PTU)** | Optimalisere for throughput (tokens/min); cached tokens kan gi opptil 100% rabatt | Forutsigbar, høy last; latenskritiske workloads |
| **Global Standard** | Balansere token-effektivitet med geografisk fleksibilitet | Multi-region workloads uten data residency-krav |
| **Batch** | Maksimere token-volum; 50% kostnadsbesparing | Bulk-prosessering, ikke-sanntid (24t turnaround) |

---

## Token-optimaliserings-teknikker

### 1. Prompt Engineering for Token-effektivitet

#### Kortere prompts uten kvalitetstap

```yaml
❌ Ineffektivt (150 tokens):
"You are an extremely helpful and knowledgeable assistant with expertise
in multiple domains. Please provide a comprehensive and detailed analysis
of the following situation, ensuring that you consider all relevant factors
and provide actionable recommendations..."

✅ Effektivt (25 tokens):
"You are an expert analyst. Analyze the situation and provide actionable
recommendations."
```

**Teknikk:** Few-shot vs. Zero-shot
- Few-shot bruker flere tokens (eksempler i prompt), men gir bedre output-kvalitet
- Zero-shot sparer input-tokens, men kan kreve regenerering hvis kvalitet er dårlig
- **Trade-off:** Evaluer om ekstra input-tokens er billigere enn å regenerere output

#### Strukturerte outputs reduserer output-tokens

```python
# ❌ Ustrukturert output (400+ tokens)
"Explain the benefits of Azure OpenAI with examples and details..."

# ✅ Strukturert output (150 tokens)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "List 3 Azure OpenAI benefits"}],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "benefits",
            "schema": {
                "type": "object",
                "properties": {
                    "benefits": {
                        "type": "array",
                        "items": {"type": "string"},
                        "maxItems": 3
                    }
                }
            }
        }
    }
)
```

### 2. Prompt Caching (automatisk funksjonalitet)

**Status:** In-memory caching GA for alle Azure OpenAI-modeller GPT-4o eller nyere (chat/completion/responses/realtime-operasjoner). Extended retention (24t) støttes for GPT-5-serien (gpt-5/5.1/5.1-codex/5.2/5.3-codex/5.4 m.fl.) + gpt-4.1.

Prompt caching reduserer kostnader ved å cache de første 1024+ tokens i en prompt. Når identisk innhold gjentas, betaler du redusert pris for cached tokens.

#### Hvordan det fungerer

| Faktor | Krav |
|--------|------|
| **Minimum prompt-lengde** | 1024 tokens |
| **Cache-treff** | Første 1024 tokens må være identiske |
| **Granularitet** | Cache-treff per 128 tokens etter første 1024 |
| **Cache-levetid** | *In-memory* (default t.o.m. gpt-5.4): ryddes typisk innen 5–10 min inaktivitet, alltid innen 1 time. *Extended retention* (opptil 24t) via `prompt_cache_retention: "24h"` — default for nyere modeller |
| **Deling** | Ikke delt mellom Azure subscriptions |

> **Data-residens:** In-memory caching er kompatibel med alle data-residency-regioner. Extended retention lagrer data midlertidig på GPU-maskiner og holder data in-region kun ved Regional Standard / Regional Provisioned deployment-typer.

#### Design for cache-hits

```python
# ✅ Strukturer prompts for caching-effektivitet
system_context = """You are a Norwegian public sector AI assistant.
[... 2000 tokens med policy-dokumenter, guidelines, etc. ...]
"""  # Dette blir cached

messages = [
    {"role": "system", "content": system_context},  # Cached
    {"role": "user", "content": user_query}         # Variabel (ikke cached)
]

# Cache-nøkkel (optional) for å forbedre hit rate
response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    prompt_cache_key="public-sector-v1"  # Forbedrer routing
)

# Sjekk cache-hits i respons
cached = response.usage.prompt_tokens_details.cached_tokens
print(f"Cached tokens: {cached}/{response.usage.prompt_tokens}")
```

**Konfidensmarkør:** 🟢 **Høy** – Prompt caching er GA og godt dokumentert.

#### Best practices for caching

1. **Plasser statisk innhold først:** System messages, dokumenter, eksempler
2. **Hold variabelt innhold sist:** User queries, timestamps, session-spesifikk data
3. **Bruk `prompt_cache_key`** for workloads med mange parallelle requests (>15 req/min)
4. **Overvåk cache hit rate:** Sjekk `cached_tokens` i API-respons

**Anti-pattern:**
```python
# ❌ Variabel innhold først = ingen cache hits
messages = [
    {"role": "user", "content": f"Timestamp: {now()} - {user_query}"},  # Endres hver gang
    {"role": "system", "content": long_static_context}  # For sent i token-sekvens
]
```

### 3. Max Tokens-kontroll

`max_tokens`-parameteren begrenser output-lengde. Dette påvirker **ikke** kvalitet, men hindrer unødvendig lange svar.

```python
# ❌ Ukontrollert output (kan generere 4000+ tokens)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Explain Microsoft Foundry"}]
)

# ✅ Kontrollert output
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Explain Microsoft Foundry in 3 sentences"}],
    max_tokens=150,
    stop=["\n\n"]  # Stopp ved double line break
)
```

**Konfidensmarkør:** 🟢 **Høy** – `max_tokens` er standard API-funksjonalitet.

### 4. Streaming for opplevd ytelse

Streaming reduserer **ikke** totale tokens eller totaltid, men forbedrer brukeropplevelse ved å vise output inkrementelt.

```python
stream = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    stream=True
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end='')
```

**Når å bruke streaming:**
- Chatbots, conversational interfaces (brukeren ser respons umiddelbart)
- Lange genereringer (unngå client-side timeouts)

**Når å **ikke** bruke streaming:**
- Bulk-prosessering (sentiment analysis, oversettelse)
- Når du trenger hele responsen før videre prosessering

### 5. Batch API for massiv kostnadsbesparelse

**Status:** GA

Azure OpenAI Batch API gir 50% kostnadsrabatt for asynkrone workloads med 24-timers turnaround.

| Fordel | Detalj |
|--------|--------|
| **Kostnadsreduksjon** | 50% rabatt vs. global standard |
| **Separat quota** | Enqueued token quota påvirker ikke online workloads |
| **Turnaround** | 24 timer (target), ikke garantert |
| **Cancellation** | Cancel jobb når som helst; betal kun for completed work |

**Use cases:**
- Large-scale data analysis
- Content generation (bulk artikler, produktbeskrivelser)
- Dokumentrevidering og oppsummering
- NLP-tasks (sentiment analysis, translation på store datasett)

**Konfidensmarkør:** 🟢 **Høy** – Batch API er GA og anbefales av Microsoft for bulk-workloads.

### 6. Modellvalg for kostnad vs. ytelse

| Modell | Input Cost | Output Cost | Best For |
|--------|-----------|-------------|----------|
| **GPT-4.1-nano** | Lavest | Lavest | Enkel klassifisering, routing, strukturert output |
| **GPT-4.1-mini** | Veldig lav | Lav | De fleste use cases; beste kostnad/ytelse-balanse |
| **GPT-4.1 / GPT-4o** | Moderat | Moderat | Kompleks resonnering, kreativt innhold |
| **o3-mini** | Høy | Høy (reasoning tokens) | Matematikk, kode, logisk resonnering |
| **GPT-5** | Høyest | Høyest | Mest krevende oppgaver (sjelden nødvendig) |

**Strategi:** Start med GPT-4.1-mini, oppgrader kun hvis kvalitet er utilstrekkelig.

---

## Arkitekturmønstre

### Mønster 1: Multi-tier model cascade

Bruk billige modeller for routing/filtering, dyre modeller kun for komplekse oppgaver.

```
User Query
    ↓
[GPT-4.1-nano: Intent classification] (5 tokens output)
    ↓
    ├─→ [Simple query] → Cache lookup → Response
    └─→ [Complex query] → [GPT-4o: Full reasoning] → Response
```

**ROI:** 70-80% av queries kan håndteres av billigere modeller.

### Mønster 2: Context compression med embeddings

Erstatt lange dokumenter med semantic search + RAG.

```
❌ Direkte document injection (10 000 tokens/request):
system_message = f"Context: {full_documents}"  # Dyrt hver gang

✅ RAG med embeddings (500 tokens/request):
1. Index documents med Azure AI Search (engangs-kostnad)
2. Query → embedding → semantic search → top 3 relevante chunks
3. Inject kun relevante chunks (500 tokens) i prompt
```

**Besparelse:** 95% reduksjon i input tokens (10k → 500).

### Mønster 3: Fine-tuning for prompt-reduksjon

Fine-tune modeller for domene-spesifikke oppgaver → kortere prompts.

```
❌ Base model med lang prompt (2000 tokens instruction):
"You are a Norwegian legal expert. Follow these guidelines: [1800 tokens]"

✅ Fine-tuned model (50 tokens):
"Analyze contract" → Modellen har allerede lært domene-spesifikk kunnskap
```

**Trade-off:**
- Opfront kostnad: Training (token-basert) + hosting ($1.70/time for fine-tuned deployment)
- Løpende besparelse: 95% reduksjon i input tokens per request
- **Break-even:** Evaluer etter forventet request-volum (typisk >100k requests)

**Konfidensmarkør:** 🟡 **Moderat** – Fine-tuning kostnad/nytte varierer sterkt med use case.

---

## Beslutningsveiledning

### Når å prioritere token-optimalisering

| Scenario | Prioritet | Teknikk |
|----------|-----------|---------|
| Høyt request-volum (>1M requests/måned) | 🔴 Kritisk | Alle teknikker; vurder fine-tuning |
| Repetitive prompts (chatbot, support) | 🔴 Kritisk | Prompt caching, RAG, model cascade |
| Lange dokumenter i context | 🔴 Kritisk | RAG, context compression |
| Batch-prosessering | 🟡 Viktig | Batch API (50% rabatt) |
| Prototyping, lav last | 🟢 Lav | Fokus på funksjonalitet først |

### Decision tree: Kostnadsoptimalisering

```
Start: Høye token-kostnader?
    │
    ├─→ Høyt request-volum? (>100k/mnd)
    │   ├─→ Ja: Vurder Provisioned Throughput (PTU)
    │   └─→ Nei: Optimaliser per-request tokens
    │
    ├─→ Repetitive prompts? (>50% overlapp)
    │   └─→ Ja: Design for prompt caching (system message først)
    │
    ├─→ Lange dokumenter i context? (>5k tokens)
    │   └─→ Ja: Implementer RAG + Azure AI Search
    │
    ├─→ Bulk-prosessering? (ikke-sanntid OK)
    │   └─→ Ja: Bruk Batch API (50% rabatt)
    │
    └─→ Kompleks domene-logikk? (lang instruction prompt)
        └─→ Ja: Vurder fine-tuning (break-even >100k requests)
```

---

## Integrasjon med Microsoft-stakken

### Microsoft Foundry: Token monitoring

```python
# Overvåk token-bruk i Azure Monitor
from azure.monitor.query import MetricsQueryClient

metrics_client = MetricsQueryClient(credential)

# Hent Processed Prompt Tokens (input TPM)
response = metrics_client.query_resource(
    resource_uri=f"/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}",
    metric_names=["ProcessedPromptTokens"],
    timespan=timedelta(days=7),
    granularity=timedelta(minutes=1),
    aggregations=["Average", "Maximum"]
)

# Hent Generated Completion Tokens (output TPM)
completion_response = metrics_client.query_resource(
    resource_uri=resource_uri,
    metric_names=["GeneratedCompletionTokens"],
    timespan=timedelta(days=7),
    granularity=timedelta(minutes=1),
    aggregations=["Average", "Maximum"]
)
```

**Nøkkel-metrics:**
- `ProcessedPromptTokens`: Input TPM (inkludert cached tokens)
- `GeneratedCompletionTokens`: Output TPM
- `TokenTransaction`: Total tokens prosessert

### Azure API Management: Token rate limiting

Implementer token-baserte quotas per consumer/application.

```xml
<llm-token-limit
    counter-key="@(context.Subscription.Id)"
    tokens-per-minute="10000"
    estimate-prompt-tokens="true"
    remaining-tokens-variable-name="remainingTokens">
</llm-token-limit>
```

**Fordeler:**
- Forhindre at én app bruker all quota
- Pre-calculate prompt tokens → avvis requests før de når backend
- Rettferdig fordeling av TPM på tvers av apps

### Copilot Studio: Token-bevissthet

Copilot Studio abstraherer token-håndtering, men:
- Lange conversation histories akkumulerer tokens (automatisk summarization etter 10-15 meldinger)
- Adaptive Cards og rich content legger til tokens
- Generative answers fra data sources kan bli dyre (hele documents injectes)

**Anbefaling:** Bruk **Generative Answers** med Azure AI Search (semantic ranking) istedenfor full document injection.

---

## Offentlig sektor (Norge)

### Budsjettstyring og kostnadskontroll

Offentlige virksomheter må ha forutsigbare IT-kostnader. Token-optimalisering er kritisk for:

1. **Årsbudsjett-compliance:** Unngå overforbruk midt i budsjettåret
2. **Anbud og kontrakter:** Estimere token-kostnader for 3-5 års driftsperiode
3. **Transparens:** Kunne forklare kostnader til politisk ledelse

**Praktisk tilnærming:**
```
1. Baseline-måling (1 måned):
   - Mål faktisk token-bruk i pilot (Azure Monitor)
   - Identifiser kostnadsdrivere (store prompts? høyt volum?)

2. Optimaliser (2-4 uker):
   - Implementer prompt caching (rask win)
   - Evaluer modellvalg (GPT-4.1-mini vs. GPT-4o)
   - Vurder RAG hvis lange dokumenter brukes

3. Produksjon med budsjett-alerts:
   - Sett Azure Cost Management budgets
   - Alerts ved 80% / 100% av månedlig budsjett
   - Action groups for automatisk skalering/throttling
```

### Data residency og token-kostnader

| Krav | Deployment Type | Token-strategi |
|------|----------------|----------------|
| Data residency Norge | Standard (regional) eller Data Zone Standard | Må akseptere høyere kostnader; fokus på token-effektivitet |
| Ingen residency-krav | Global Standard | 10-30% rabatt; kan bruke mer tokens innenfor samme budsjett |

**Anbefaling:** For **ikke-personopplysninger** (FAQ, interne dokumenter), bruk Global Standard → mer rom for tokens.

### Compliance og token-logging

**GDPR/logging-krav:** API requests logges i Azure Monitor, inkludert token-bruk. Sikre at:
- PII ikke injectes i prompts (kan logges)
- Stored Completions (hvis brukt) har data retention policies
- Token-bruk kan audits for kostnadskontroll

---

## Kostnad og lisensiering

### Azure OpenAI prismodell (per 1M tokens, Feb 2026)

#### Standard deployment (pay-as-you-go)

| Modell | Input | Output | Cached Input |
|--------|-------|--------|--------------|
| GPT-4.1-nano | $0.10 | $0.40 | $0.05 |
| GPT-4.1-mini | $0.20 | $0.80 | $0.10 |
| GPT-4.1 | $2.50 | $10.00 | $1.25 |
| GPT-4o | $2.50 | $10.00 | $1.25 |
| GPT-4o-mini | $0.15 | $0.60 | $0.075 |
| o3-mini | $1.10 | $4.40 | $0.55 |

**Merk:** Reasoning tokens (o-series) har separat pricing.

#### Batch API (50% rabatt)

| Modell | Input | Output |
|--------|-------|--------|
| GPT-4.1-mini | $0.10 | $0.40 |
| GPT-4o | $1.25 | $5.00 |
| o3-mini | $0.55 | $2.20 |

#### Provisioned Throughput (PTU-basert)

PTU-prising er basert på kapasitet (PTUs), ikke tokens. Token-optimalisering påvirker:
- **Hvor mange PTUs du trenger:** Færre tokens → lavere PTU-krav
- **Cached tokens:** Opptil 100% rabatt (frigjør PTU-kapasitet)

**Eksempel:**
- Workload: 500k input TPM + 150k output TPM = 30 PTUs
- Med 50% cache hit rate: 250k input TPM (cached, gratis) + 250k input TPM + 150k output = 20 PTUs
- **Besparelse:** 33% reduksjon i PTU-kostnad

**Konfidensmarkør:** 🟢 **Høy** – Priser hentet fra offisiell Azure-dokumentasjon (Feb 2026).

### Fine-tuning kostnader

| Kostnadstype | Beregning | Eksempel (GPT-4.1) |
|--------------|-----------|-------------------|
| **Training** | Tokens × epochs × training price | 1M tokens × 2 epochs × $2/M = $4 |
| **Hosting** | $1.70/time (standard deployment) | $1,224/måned (kontinuerlig) |
| **Inference** | Input + output tokens (samme som base + hosting) | 20M input × $1.10 + 40M output × $4.40 = $198 |

**Break-even analyse:**
```
Besparelse per request (prompt-reduksjon): 1800 tokens × $0.20/1M = $0.00036
Månedlig hosting-kostnad: $1,224
Break-even requests/måned: $1,224 / $0.00036 = 3.4M requests

→ Kun lønnsomt ved **svært** høyt volum (>3M requests/måned)
```

### ROI-kalkulator for token-optimalisering

**Scenario:** Chatbot for offentlig sektor (1M requests/måned)

| Tiltak | Token-reduksjon | Månedlig besparelse (NOK) |
|--------|-----------------|---------------------------|
| Baseline (ingen optimalisering) | - | Kostnad: 15 000 kr |
| Prompt caching (50% cache hit) | 50% input | Sparer: 3 750 kr (25%) |
| Kortere prompts (-30% input) | 30% input | Sparer: 2 250 kr (15%) |
| Strukturerte outputs (-20% output) | 20% output | Sparer: 2 400 kr (16%) |
| Bytt til GPT-4.1-mini fra GPT-4o | - | Sparer: 10 500 kr (70%) |
| **Total optimalisering** | **Kombinert** | **Sparer: 12 000 kr/måned (80%)** |

**Konfidensmarkør:** 🟡 **Moderat** – Besparelser varierer med workload; disse er representative estimater.

---

## For arkitekten (Cosmo)

### Praktiske spørsmål under arkitekturrådgivning

1. **"Hvor mange requests forventer dere per måned?"**
   - <100k: Standard deployment, fokus på funksjonalitet
   - 100k-1M: Optimaliser tokens (caching, compression)
   - >1M: Vurder PTU, Batch API, fine-tuning

2. **"Har dere repetitive prompts (chatbot, FAQ, support)?"**
   - Ja → Design for prompt caching (system message først)
   - Nei → Fokus på andre optimaliseringsteknikker

3. **"Bruker dere lange dokumenter som context?"**
   - Ja → Implementer RAG + Azure AI Search (95% token-reduksjon)
   - Nei → Standard prompt engineering

4. **"Har dere budsjettbegrensninger eller årsbudsjett?"**
   - Ja → Sett Azure Cost Management budgets + alerts
   - Implementer token rate limiting i API Management

5. **"Er sanntids-respons kritisk?"**
   - Ja → Standard/PTU + streaming
   - Nei → Vurder Batch API (50% rabatt)

### Red flags for kostnadsfeller

🚩 **"Vi sender hele PDF-filer (100+ sider) som context"**
→ RAG er obligatorisk; ellers 50k+ tokens per request

🚩 **"Fine-tuned modell har vært deployed i 6 måneder uten bruk"**
→ $1.70/time × 24 × 180 dager = $7,344 hosting-kostnad uten verdi

🚩 **"Vi bruker GPT-4o for alt"**
→ 80% av use cases kan bruke GPT-4.1-mini (5× billigere)

🚩 **"Vi har ikke monitoring på token-bruk"**
→ Kostnader kan eskalere ukontrollert; sett opp Azure Monitor metrics

### Anbefalte arkitekturmønstre per scenario

| Scenario | Anbefalt mønster | Estimert besparelse |
|----------|-----------------|---------------------|
| **Kundeservice chatbot (repetitive spørsmål)** | Prompt caching + model cascade (nano for routing) | 60-70% |
| **Dokumentanalyse (lange PDF-er)** | RAG + Azure AI Search + GPT-4.1-mini | 80-90% |
| **Bulk content generation (ikke-sanntid)** | Batch API + strukturerte outputs | 50-60% |
| **Kompleks resonnering (kode, matematikk)** | o3-mini (kun når nødvendig) + caching | 30-40% |
| **Intern FAQ (lavt volum)** | Standard deployment + GPT-4.1-mini | 70% (vs. GPT-4o) |

### Validering av løsning: Token-effektivitets-checklist

✅ **Prompt design:**
- [ ] Statisk innhold (system message, dokumenter) plassert først?
- [ ] `max_tokens` satt til minimum nødvendig?
- [ ] Stop sequences definert for å hindre overgenerering?

✅ **Caching:**
- [ ] Prompts >1024 tokens har statisk prefix?
- [ ] `prompt_cache_key` brukt for high-frequency workloads?
- [ ] Cache hit rate monitores i Azure Monitor?

✅ **Modellvalg:**
- [ ] Bruker GPT-4.1-mini som default (oppgrader kun hvis nødvendig)?
- [ ] Model cascade implementert (billig modell for routing)?

✅ **Kostnadsovervåking:**
- [ ] Azure Cost Management budgets satt opp?
- [ ] Alerts ved 80%/100% av budsjett?
- [ ] Token-metrics logges og analyseres månedlig?

✅ **Arkitektur:**
- [ ] RAG implementert for lange dokumenter?
- [ ] Batch API vurdert for bulk-workloads?
- [ ] Content filtering justert (hvis lavrisiko use case)?

---

## Kilder og verifisering

**Offisiell Microsoft-dokumentasjon:**
1. [Prompt caching for Azure OpenAI](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching)
2. [Plan and manage costs for Azure OpenAI](https://learn.microsoft.com/en-us/azure/foundry/concepts/manage-costs)
3. [Performance and latency optimization](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency)
4. [Batch API for Azure OpenAI](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/batch)
5. [Azure OpenAI pricing](https://azure.microsoft.com/pricing/details/cognitive-services/openai-service/)

**Verifisert:** Februar 2026 via microsoft-learn MCP-server

**Confidence level:** 🟢 **Høy** for GA-funksjoner (prompt caching, batch API, standard pricing), 🟡 **Moderat** for ROI-estimater (workload-avhengige).

---

**Sist oppdatert av Cosmo Skyberg, Microsoft AI Solution Architect**
*For spørsmål om token-optimalisering i din løsning, start en arkitektursesjon med `/architect`.*