Teknologi blogg

Grok 4.6 i Microsoft Foundry: bygget for å fullføre arbeid, ikke bare svare raskt

06.09.2026

Microsoft var tydelige da de lanserte Grok 4.6 i Foundry: neste bølge AI-applikasjoner defineres ikke av hvor raskt modeller svarer, men av hvor mye arbeid de kan fullføre. Det er en påstand jeg kjenner igjen fra egen erfaring med agentprosjekter. Den vanskelige delen er sjelden første svar. Den vanskelige delen er å holde seg på oppgaven gjennom tjue verktøykall uten å miste tråden.

26. august 2026 ble Grok 4.6 fra xAI tilgjengelig i Microsoft Foundry Models gjennom public preview. Modellen er bygget på xAIs 1,5T-skala modellfamilie, og designet for sammenhengende resonnering og utførelse på tvers av programvareutvikling, agentiske arbeidsflyter og teknisk problemløsning. Den er altså ikke optimalisert for én enkelt benchmark-kategori, og det synes jeg er et sunnere designvalg enn å jage ett enkelt toppresultat.

Hvorfor "langvarig agent" er et eget krav

De fleste AI-systemer presterer godt på isolerte spørsmål. Reelle agenter er noe annet: de må planlegge, gjenopprette etter feil, navigere verktøy, og fortsette å gjøre fremgang over lange arbeidsflyter med minimal tilsyn. Etter min erfaring er dette akkurat der de fleste agentprosjekter faller sammen i produksjon. Modellen svarer fint på testspørsmål, men mister kontekst eller gir opp for tidlig når oppgaven strekker seg over mange runder, noe jeg har sett gjentatte ganger i piloter som aldri ble skalert videre.

Grok 4.6 er testet på tre benchmark-kategorier som treffer nøyaktig dette problemet.

Terminal-Bench 3.0 måler multi-steg terminalbasert utførelse som ligner reelle engineering-arbeidsflyter, relevant for kodingsagenter og autonome workflows. Her skårer Grok 4.6 26,0 %, bak Opus 5 (43,5 %) og GPT-5.6 Sol (34,6 %), men klart foran forgjengeren Grok 4.5 (15,7 %):

Terminal-Bench 3.0 — Task success rate (%)
Opus 5 (max)
43.5%
GPT-5.6 Sol (max)
34.6%
Fable 5 (max, with fallback)
34.1%
Grok 4.6 (high)
26.0%
Opus 4.8 (max)
21.1%
Grok 4.5 (high)
15.7%
Sonnet 5 (max)
14.6%

Kilde: xAI, Grok 4.6 model card (PDF)

3DCodeBench evaluerer agentisk prosedural 3D-modellering via kode, relevant for produksjon, robotikk og produktdesign. Her leder faktisk Grok 4.6 med 54,0 %, foran både Opus 5 (49,9 %) og forgjengeren Grok 4.5 (49,8 %):

3DCodeBench — Reward (%)
Grok 4.6 (high)
54.0%
Opus 5 (max)
49.9%
Grok 4.5 (high)
49.8%
Opus 4.8 (max)
47.0%
Fable 5 (max, with fallback)
43.7%
Sonnet 5 (max)
39.2%

Kilde: xAI, Grok 4.6 model card (PDF)

AA Briefcase (Artificial Analysis) evaluerer langvarige kunnskapsarbeid-prosjekter som ender i leveranser som regneark, presentasjoner og finansmodeller. Grok 4.6 oppnår 1577 Elo-poeng, tett bak Opus 5 (1715) og foran Fable 5 (1574):

AA Briefcase — Elo
Opus 5 (max)
1715
Grok 4.6 (high)
1577
Fable 5 (max, with fallback)
1574
Kimi K3 (max)
1541
GPT-5.6 Sol (max)
1502
Sonnet 5 (max)
1383
Opus 4.8 (max)
1340
Grok 4.5 (high)
1313
GPT-5.5 (xhigh)
1150

Kilde: xAI, Grok 4.6 model card (PDF)

Jeg synes det siste punktet er det mest interessante for norske virksomheter. Mange agentprosjekter jeg har sett stopper ved "et godt svar i chat", mens AA Briefcase-tilnærmingen tester om agenten faktisk leverer noe klart til bruk, uten at et menneske må rydde opp etterpå.

Pris og distribusjon

Grok 4.6 er priset til $2 per million input-tokens, $6 per million output-tokens, og $0,50 per million cache-tokens på Global Standard-distribusjon. Sammenlignet med prisnivået jeg tidligere har dekket for GPT-5.1 i Foundry, ligger Grok 4.6 i samme størrelsesorden. Det bekrefter et mønster jeg ser gjentatt hos flere leverandører nå: frontier-modeller konvergerer mot lignende prispunkter, mens forskjellen i praksis ligger i hvor godt de holder seg på oppgaven over tid, ikke i pris per token.

Foundry gir valg mellom Serverless (pay-as-you-go) og Provisioned Throughput Units for forutsigbar ytelse ved høyt volum. Jeg anbefaler å starte på Serverless mens du evaluerer modellen mot egne oppgaver, og først vurdere PTU når trafikkmønsteret er stabilt nok til at det faktisk lønner seg, samme prinsipp jeg beskrev i artikkelen om kostnadsspaker for AI-agenter.

Kom i gang: deploy Grok 4.6 i Foundry

Azure CLI
az cognitiveservices account deployment create \
  --name min-foundry-ressurs \
  --resource-group rg-ai-prod \
  --deployment-name grok-4-6 \
  --model-name grok-4.6 \
  --model-format xAI \
  --sku-name GlobalStandard \
  --sku-capacity 10

Autentisering skjer via Microsoft Entra ID med DefaultAzureCredential, uten behov for å håndtere API-nøkler manuelt. Det er en detalj jeg alltid insisterer på hos kunder, fordi nøkkelhåndtering er den vanligste sikkerhetsglippen jeg ser i tidlige AI-piloter:

Python
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import OpenAI

project_endpoint = "https://MIN-RESSURS.services.ai.azure.com/api/projects/MITT_PROSJEKT"
base_url = project_endpoint.rstrip("/") + "/openai/v1"

credential = DefaultAzureCredential()
token_provider = get_bearer_token_provider(
    credential,
    "https://ai.azure.com/.default",
)

client = OpenAI(base_url=base_url, api_key=token_provider)

response = client.responses.create(
    model="grok-4-6",
    input="Analyser denne kodebasen og foreslå en migreringsplan",
)

Modellen er OpenAI API-kompatibel og fungerer med LangChain, Semantic Kernel og LlamaIndex, samme integrasjonsmønster som andre Foundry-modeller.

En modell til i rekken: hvordan Grok 4.6 skiller seg fra tidligere lanseringer

Jeg husker godt da Llama 4 kom til Foundry i påsken-2025, med tre varianter fordelt etter hvor mye GPU-kraft du hadde tilgjengelig. Grok 4.6 følger ikke det mønsteret. Her er det én modell, testet mot arbeidsoppgaver som strekker seg over tid, ikke mot GPU-budsjett. Det er en forskjell jeg tror er verdt å legge merke til: leverandørene beveger seg bort fra "velg størrelse etter maskinvare" og over mot "velg modell etter hvor lenge oppgaven varer".

Sammenlignet med GPT-5.1-codex-max, som jeg tidligere har skrevet om for repo-skala refaktorering, er Grok 4.6 bredere i formålet. Codex-max er renset for kode. Grok 4.6 er bygget for kode, CAD og kunnskapsarbeid samtidig, og det gjør den til et naturlig sammenligningspunkt når du velger modell i Foundry model catalog, uansett om oppgaven din er teknisk eller administrativ.

Hva bør du faktisk bruke den til, og hva bør vente

Basert på benchmark-profilen passer Grok 4.6 best til kodingsagenter som jobber over flere filer og commits uten stadig tilsyn, engineering copilots for CAD eller teknisk analyse, og forskningsassistenter som skal levere ferdige dokumenter fremfor bare svar.

Jeg vil likevel minne om at modellen er i public preview per nå. Min anbefaling er å ikke sette den rett i skarp produksjon uten en egen evaluering mot ditt eget datasett først. Preview-status betyr typisk at SLA, prising og modelladferd kan endre seg før generell tilgjengelighet, noe jeg har sett skje med tidligere Foundry-forhåndsvisninger.

Sjekkliste før du tester Grok 4.6

  1. Sjekk om Grok 4.6 er tilgjengelig i din Foundry-region via model catalog

  2. Kjør en workload-spesifikk evaluering mot din egen agent-oppgave før produksjon

  3. Sammenlign kostnad per fullført utfall, ikke bare pris per token, mot din nåværende modell

  4. Sett opp Entra ID-autentisering fremfor API-nøkler

  5. Vurder PTU først når arbeidsmengden er stabil og volumet er høyt

Fra rask respons til vedvarende arbeid

Grok 4.6 er et tydelig tegn på hvor modellkappløpet beveger seg nå: fra rask respons til vedvarende arbeid over mange steg. Foundry gjør det enkelt å teste den mot dine egne arbeidsbelastninger før du bytter noe i produksjon, og det er nettopp den testen jeg anbefaler før noen konklusjon trekkes. Jeg tror flere norske team vil oppdage at valget mellom modeller fremover handler mindre om rå intelligens og mer om hvor lenge modellen holder seg pålitelig på oppgaven.

Trenger du hjelp til å evaluere Grok 4.6 mot dine agent-flyter, ta kontakt på kontakt@jas-azure.com.

Les også

Share