GPT-5.5 vs Claude Sonnet 4.6 vs Gemini 3.1 Pro: Hva ingen referansetester forteller deg

Det finnes en helt bestemt type møte som skjer i alle team som bygger på frontier‑LLM‑er. Noen deler den siste benchmark-ledertavlen. Noen andre påpeker at rangeringene har endret seg siden forrige måned. En tredje person bemerker at modellen teamet deres bruker nå har falt to plasser på en metrikk ingen av dem hadde hørt om for tre uker siden. Ved slutten av møtet er ingen sikre på om de skal migrere, og samtalen blir booket på nytt til neste kvartal.

Problemet med det møtet er ikke menneskene i det. Det er at benchmarker måler syntetiske oppgaver, og produktet ditt er ikke en syntetisk oppgave. Leder­tavlen forteller deg hvordan en modell presterer på MMLU, på SWE-bench Verified, på GPQA Diamond — tester designet av forskere for å være målbare på tvers av modeller. Ingen av disse testene ligner på promptene applikasjonen din faktisk sender i produksjon. Ingen av dem fanger hvordan en modell håndterer den bestemte typen rotete, domenespesifikk input som brukerne dine genererer.

Denne artikkelen går gjennom akkurat den øvelsen som benchmarker ikke kan gjøre. Tre konkrete prompter, designet for å sendes til GPT-5.5, Claude Sonnet 4.6 og Gemini 3.1 Pro gjennom samme OpenAI‑kompatible endepunkt, med samme temperaturinnstillinger og uten ekstra instruksjoner. Promptene spenner over tre kategorier som berører de fleste produksjonsarbeidslaster: strukturert ekstraksjon fra et uryddig dokument, en resonneringstung planleggingsoppgave og kodegenerering under begrensninger. Observasjonene nedenfor er atferdsmønstre som team som kjører denne typen sammenligning konsekvent rapporterer — mønstrene du selv ville sett om du kjørte disse promptene i ditt eget oppsett.

På ledertavlene skårer disse tre modellene innenfor 0,8 prosentpoeng av hverandre på SWE-bench Verified. I praksis oppfører de seg svært forskjellig. Valget mellom dem handler ikke om hvem som får høyest score på benchmarker — det handler om hvilket atferdsmønster som passer arbeidslasten din.

Hva benchmarker måler, og hva de ikke fanger

Benchmarker finnes fordi de må. Modelleverandørene trenger standardiserte tester for å kunne fremme kapabilitetskrav, forskere trenger dem for å publisere sammenligninger, og vi andre trenger dem for i det hele tatt å ha et objektivt utgangspunkt for å evaluere modeller. De er nyttige. De er også ufullstendige på måter som betyr noe for produksjonsbruk.

Tre spesifikke begrensninger er verdt å være eksplisitt om, fordi hver av dem dukker opp i prompteksemplene nedenfor.

• Benchmarker måler isolert kapabilitet, ikke atferdsmønstre. SWE-bench Verified forteller deg om en modell kan løse en bestemt type GitHub‑sak. Den forteller deg ikke om modellen har en tendens til å overkonstruere enkle problemer, om den stiller avklarende spørsmål når prompten er tvetydig, eller om den produserer output som matcher strukturen du ba om på første forsøk. Dette er tingene du vil observere daglig i produksjon.
• Benchmarker tunes mot. Når en modellutgivelse fremhever scoren sin på en bestemt benchmark, er det et signal om at modellen i det minste delvis ble optimalisert for den benchmarken. Ytelse i virkeligheten og ytelse på benchmark kan avvike — noen ganger betydelig — når en modell forlater betingelsene benchmarken er designet for.
• Benchmarker aggregerer. En forskjell på 0,8 prosentpoeng i SWE-bench Verified‑score kan skjule at Modell A er mye bedre på en spesifikk kategori av oppgaver og dårligere på en annen, mens Modell B er jevn over hele linjen. Aggregasjon kollapser informasjonen du trenger for å ta en beslutning.

Øvelsen nedenfor er designet for å synliggjøre akkurat den typen informasjon benchmarker aggregerer bort. Poenget er ikke å kåre en vinner — det er å vise deg spørsmålene du bør stille når du kjører den samme øvelsen på dine egne prompter.

Oppsettet

Tre prompter, valgt fordi de kartlegger kategorier de fleste produksjonsarbeidslaster treffer. Oppsettet: hver prompt sendes til alle tre modeller med identiske parametere (temperatur 0,3, ingen overstyring av systemprompt, standard svarformat), aksessert gjennom ett enkelt OpenAI‑kompatibelt endepunkt slik at sammenligningen forblir rettferdig — ingen leverandørspesifikke SDK‑særheter, ingen ulike parametermappinger, ingen risiko for at én modell får særbehandling på grunn av hvordan forespørselen er konstruert.

Selve promptene er nedenfor, som kodeblokker du kan kopiere og kjøre. Atferdsbeskrivelsene som følger hver av dem er mønstrene team konsekvent rapporterer når de kjører denne typen sammenligning — mønstre dokumentert på tvers av flere tredjepartsstudier i 2026, og den typen ting du bør forvente å se selv når du kjører disse promptene i ditt eget oppsett. Å kjøre det selv er poenget; artikkelen gir deg rammeverket og startpromptene for å gjøre nettopp det.

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["COMET_API_KEY"],  # or replace with your API key
    base_url="https://api.cometapi.com/v1",  # one endpoint, multiple models
)

MODELS = [
    "gpt-5.5",
    "claude-sonnet-4-6",
    "gemini-3.1-pro",
]


def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
    """
    Send the same prompt to all three models and return their responses.
    """
    responses = {}

    for model in MODELS:
        result = client.chat.completions.create(
            model=model,
            messages=[
                {
                    "role": "user",
                    "content": prompt,
                }
            ],
            temperature=temperature,
        )

        responses[model] = result.choices[0].message.content

    return responses


# Example usage
if __name__ == "__main__":
    prompt = "Summarise the key risks in this contract."

    outputs = run_comparison(prompt)

    for model, response in outputs.items():
        print(f"\n--- {model} ---")
        print(response)

Prompt 1: Strukturert ekstraksjon fra et uryddig dokument

Dette er hverdagsoppgaven til halvparten av LLM‑funksjonene som ble sendt i 2026. Ta en ustrukturert input — en e‑post, en supportsak, et møtereferat, et skannet skjema — og trekk ut spesifikke felt i et strukturert objekt. Prompten nedenfor ber hver modell om å trekke ut sju felt fra en bevisst uryddig kundestøtte‑e‑post som inneholder delvis informasjon, motstridende signaler og ett felt som ikke finnes i kildeteksten i det hele tatt.

Prompten

You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing",  "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned) 

Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.

Hva du bør se etter

Tre ting. For det første, om modellen holder seg til det forespurte JSON‑skjemaet uten å finne på noe. For det andre, hvordan modellen håndterer feltet som ikke finnes i kilden (escalation_history — kunden nevner ingen tidligere kontakt om dette spesifikke problemet) — innrømmer den fravær, eller fabricerer den noe som høres plausibelt ut? For det tredje, om modellen produserer ekstra kommentarer utenfor JSON, som krever nedstrøms parsing for å strippe wrapperen. Feltet urgency er også verdt å følge med på: «5 days» er ikke umiddelbart, men kunden er tydelig bekymret, noe som gir rom for tolkning.

Hva team som kjører dette konsekvent rapporterer

GPT-5.5. Leverer typisk ren JSON på første forsøk. Skjemaetterlevelsen er sterk; hvert forespurte felt er til stede, og formatet kan parses uten preprocessing. For manglende felt returnerer GPT-5.5 ofte eksplisitt null. Den pakker som regel ikke JSON inn i markdown‑kodeblokker eller inkluderer prosaforklaringer, noe som gjør nedstrøms parsing triviell. Ved tvetydige vurderinger som urgency her, er GPT-5.5 ofte mer konservativ enn de to andre — der Claude og Gemini kan vurdere saken som «high» basert på kundens følelsesmessige tone, forankrer GPT-5.5 seg ofte i det konkrete 5‑dagers vinduet og lander på «medium».

Claude Sonnet 4.6. Leverer også ren JSON, og er typisk den mest presise av de tre i å følge det forespurte skjemaet. Der GPT-5.5 lar et manglende felt være null, legger Claude ofte til uforespurte felt som flagger datakvalitetsproblemer — en «notes» eller «data_quality_notes»-nøkkel som ikke ble bedt om, men som inneholder genuint nyttig informasjon. Det ekstra feltet er nyttig for menneskelig gjennomgang, men forårsaker feil hvis nedstrømsparseren din er streng på skjemaet. Dette er et tilbakevendende mønster med Claude: høy kvalitet, men noen ganger mer grundig enn prompten ba om, som krever eksplisitte prompt‑instruksjoner for å begrense.

Gemini 3.1 Pro. Leverer typisk den mest økonomiske outputen av de tre. Alle forespurte felt, ingen ekstra felt, ingen omgivende prosa. Skjemaetterlevelsen er akkurat som forespurt. Den ene egenarten verdt å vite om: for manglende felt returnerer Gemini ofte en tom streng i stedet for null. Strenge JSON‑parsere som skiller mellom disse vil fange forskjellen; slakkere parsere vil ikke. Atferden er så konsistent på tvers av kjøringer at det ser ut til å være en modellpreferanse snarere enn en artefakt.

Hva dette forteller deg

Alle tre modellene kan gjøre strukturert ekstraksjon. Forskjellene ligger i atferdsmarginen rundt det forespurte skjemaet. Hvis nedstrømssystemet ditt er strengt på skjemaet og behandler ekstra felt som feil, er Gemini 3.1 Pro og GPT-5.5 de tryggere valgene. Hvis du vil at modellen skal synliggjøre datakvalitetsproblemer uten å bli bedt om det, er Claude Sonnet 4.6 mer hjelpsom. Ingenting av dette vises på en benchmark.

Prompt 2: En resonneringstung planleggingsoppgave

Denne prompten ber modellene planlegge en flertrinns undersøkelse: et forskningsspørsmål med tre implisitte begrensninger som en nøye modell bør identifisere før den sekvenserer arbeidet. Den typen oppgave en agentisk applikasjon ville delegert til en LLM som planleggingssteg før verktøy tas i bruk.

Prompten

I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.

De implisitte begrensningene det er verdt å følge med på: spørsmålet definerer aldri hva «churn» betyr (kontolukking? ingen innlogginger? ingen kjøp?), det spesifiserer ikke hvordan man skal kontrollere for forvekslingsfaktorer (brukere med lavt engasjement churner av mange grunner som er urelaterte til feature X), og det etablerer ikke en baseline‑sammenligningsgruppe. En nøye planlegger bør synliggjøre alle tre før den produserer stegene.

Hva du bør se etter

Om modellen faktisk resonnerer gjennom problemet eller produserer en plausibel sekvens av steg som ikke henger sammen ved nærmere gjennomgang. Om den identifiserer de implisitte begrensningene uten å bli fortalt om dem. Og om avhengighetene mellom steg er korrekte — en plan som ser fin ut, men har trinn tre avhengig av et resultat trinn fem ville produsere, er ubrukelig i praksis.

Hva team som kjører dette konsekvent rapporterer

GPT-5.5. Leverer typisk den mest operasjonelt brukbare planen. Resonneringen er ofte synlig — GPT-5.5 lister opp antakelsene sine om de implisitte begrensningene (churn‑definisjon, kontrollgruppe, forvekslingsfaktorer) før den legger ut stegene, noe som gjør det enkelt å se hvor tolkningen dens avviker fra det som var ment. Stegavhengigheter identifiseres og merkes pålitelig. Outputen inkluderer ofte en seksjon som flagger hvilke steg som kan paralleliseres, noe som ikke ble bedt om, men som gir genuin verdi. Dette er den typen oppgave der GPT-5.5s verktøybruk og agentiske trening kommer til syne — planleggingsatferden er formet av antakelsen om at nedstrøms utførelse vil følge.

Claude Sonnet 4.6. Leverer typisk den mest gjennomtenkte planen, i bokstavelig forstand — Claudes plan inkluderer ofte betraktninger de to andre modellene ikke tar opp. På et spørsmål som dette vil Claude sannsynligvis flagge det metodiske problemet med korrelasjon vs. kausalitet, påpeke at «har ikke brukt feature X» i seg selv kan være et symptom på churn snarere enn en årsak, og eksplisitt identifisere begrensninger som ikke ble gjort eksplisitte, men som en nøye analytiker bør fange opp. Ulempen: planen kan bli lengre enn nødvendig, og enkelte steg er noen ganger overkonstruert for det faktiske spørsmålet. Mønsteret er konsistent med Claudes atferd ellers — ekspertmessig omtanke, noen ganger mer enn oppgaven krever.

Gemini 3.1 Pro. Leverer typisk den mest ryddig strukturerte planen, med den tydeligste avhengighetsgrafen. Resonneringskvaliteten er høy — Gemini identifiserer pålitelig de implisitte begrensningene, dekomponerer problemet i en forsvarlig sekvens og produserer steg‑for‑steg‑instruksjoner som faktisk lar seg utføre. Ulempen: planen kan oppleves litt mekanisk. Den gjør jobben, men har en tendens til ikke å synliggjøre de metodiske nyansene Claude løfter, eller paralleliseringsinnsiktene GPT-5.5 inkluderer. Dette matcher Geminis bredere mønster — sterk på resonneringskvalitet, mer nøktern på de omkringliggende skjønnsvurderingene.

Hva dette forteller deg

Resonneringskvaliteten i denne oppgaven er høy på tvers av alle tre modellene. Forskjellene ligger i atferden rundt — hva modellen legger til utover den bokstavelige forespørselen. GPT-5.5 legger til operasjonell pragmatisme (parallelisering, utførelseshint). Claude tilfører ekspertmessig omtanke (metodikk, kanttilfeller, statistisk nyanse). Gemini tilfører klarhet og økonomi. Ingen av disse er feil valg. Hva som passer applikasjonen din avhenger av hva du vil at modellen skal gjøre når den er ferdig med oppgaven du ba om.

Prompt 3: Kodegenerering med spesifikke begrensninger

Denne prompten ber modellene implementere en liten, men ikke‑triviell funksjon: en Python‑funksjon som tar en liste av tidsstemplete hendelser og returnerer det lengste gapet mellom påfølgende hendelser, og håndterer fire randtilfeller. Begrensningene er eksplisitte; hensikten er å teste kodegenerering under begrensninger heller enn kapabilitetstak — hver modell kan skrive denne funksjonen. Det som varierer, er hvordan de håndterer begrensningene.

Prompten

Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases:  1. Empty list (return 0.0 or raise — your choice, but be consistent)  2. Single event  3. Duplicate timestamps  4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.

Hva du bør se etter

Om modellen adresserer alle fire randtilfeller eller glatt overser noen. Om typehintene er presise eller boilerplate. Om implementeringen velger en forsvarlig algoritme (sorter, så scan) eller noe eksotisk. Og om modellen respekterer begrensningen «ingen tester, ingen brukseksempler» på slutten av prompten — dette er den typen instruksjon sent i prompten som modeller med sterk instruksjonsfølge vil etterleve og svakere vil ignorere i stillhet.

Hva team som kjører dette konsekvent rapporterer

GPT-5.5. Leverer typisk den mest grundig konstruerte koden. Alle fire randtilfeller håndteres med eksplisitte grener, typehintene er presise (ofte inkludert Optional eller Union for returverdier i randtilfeller), og en docstring med eksempelets kall. Implementeringen velger som regel den opplagte algoritmen — sorter, scan, spor maks gap — og er korrekt. Verdt å vite: GPT-5.5 inkluderer ofte enhetstester eller brukseksempler selv når prompten eksplisitt ber om bare funksjonen. Dette er avveiningen med operasjonelt pragmatiske modeller — de legger til ting de tror du trenger, selv når du ber dem la være.

Claude Sonnet 4.6. Leverer typisk den mest lesbare koden. Funksjonen er konsis, randtilfeller håndteres med et rent guard‑clause‑mønster på toppen, typehintene er korrekte og minimale. Claude inkluderer ofte en gjennomtenkt kommentar som forklarer en skjønnsvurdering prompten lot stå åpen — for eksempel at duplikate tidsstempler behandles som gap med lengde null og hvorfor, som er en forsvarlig vurdering prompten ikke spesifiserte. Claude har en tendens til å respektere «ingen tester»-begrensningen mer pålitelig enn GPT-5.5. Selve funksjonen er den mest vedlikeholdbare av de tre. Konsistent med Claudes rykte for kodekvalitet: ren, idiomatisk, med ekspertpreg.

Gemini 3.1 Pro. Leverer typisk den mest økonomiske koden av de tre. Funksjonen er korrekt, randtilfeller håndtert, implementeringen den korteste. Docstring er vanligvis én linje. Typehintene er til stede og korrekte. Geminis løsning inkluderer sjelden tester eller omfattende kommentarer, og overkonstruerer ikke — som er akkurat det prompten ba om. For en utvikler som vil ha en fungerende funksjon og planlegger å legge til tester separat, er dette den mest direkte veien. For en utvikler som vil at modellen også skal gjøre arbeidet rundt, legger de to andre til mer (enten du ba dem om det eller ikke).

Hva dette forteller deg

Alle tre modellene kan skrive funksjonen. Atferdsforskjellen ligger i hvor mye rundt‑arbeid hver modell gjør utover den bokstavelige forespørselen — og hvor godt hver respekterer eksplisitte «ikke legg til X»-instruksjoner. GPT-5.5 heller mot grundighet, selv når grundigheten var fraveket i prompten. Claude heller mot håndverk (lesbar kode, gjennomtenkte kommentarer om skjønnsvurderinger). Gemini heller mot økonomi (gjør akkurat det som ble bedt om, ikke mer). For agentiske arbeidsflyter der modellens output går direkte inn i en produksjonskodebase, avhenger atferden du vil ha av hva nedstrøms gjennomgangsprosess forventer — og hvor strengt du trenger at negative instrukser følges.

Mønstrene som trer frem

På tvers av de tre promptene ovenfor fremtrer tre konsistente atferdsmønstre fra sammenligningsstudier og utviklerrapporter publisert gjennom 2026. Dette er ikke kapabilitetskrav — hver modell håndterer hver oppgave på et høyt nivå. Det er tendenser, den typen ting du bare ser når team ser den samme modellen håndtere dusinvis av prompter. Kjør promptene ovenfor i ditt eget oppsett, så vil du se de samme mønstrene; artikkelen finnes for å gi deg rammeverket for å gjenkjenne hva du ser på når du gjør det.

En viktig forbehold. Disse mønstrene er tendenser, ikke regler. Hver modell kan styres mot noen av disse atferdene med passende prompting — en tilstrekkelig detaljert systemprompt vil få Gemini til å legge til tester, eller begrense Claude til et minimum av output, eller få GPT-5.5 til å hoppe over enhetstester. Poenget er hva hver modell gjør som standard, før du begynner å styre den. Standardatferden er det du lever med i produksjon med mindre du aktivt prompt­er mot den.

Slik tester du på din egen arbeidslast

Øvelsen ovenfor er replikerbar på enhver arbeidslast, og det bør den være. Benchmark‑score er nyttige som første filter, men atferdsmønstrene som betyr noe for din spesifikke applikasjon er bare synlige når du ser modellene håndtere dine spesifikke prompter.

En praktisk veiledning til å kjøre øvelsen på din egen trafikk:

1. Velg tre representative promptkategorier. Ikke tre tilfeldige prompter — tre kategorier som spenner over arbeidslasten din. De fleste produksjonssystemer kan dekomponeres i noen få prompttyper (ekstraksjon, klassifisering, generering, resonnering, kode, oppsummering). Velg kategoriene som står for hoveddelen av trafikken din.
2. Kurater 20–30 eksempler per kategori. Gjerne fra ekte trafikk. Anonymiser der det er nødvendig. Poenget er at promptene skal ligne det applikasjonen din faktisk ser, ikke benchmark‑spørsmål. Tyve eksempler per kategori er nok til å se mønstre; tretti er nok til å bli trygg.
3. Kjør dem gjennom ett endepunkt, alle modeller. Et OpenAI‑kompatibelt aggregator‑endepunkt gjør dette dramatisk raskere enn å kjøre hver modell gjennom sin egen SDK. Koden øverst i denne artikkelen er hele oppsettet. Samme temperatur, samme parametere, samme prompt — forskjellene i output er modelldifferansene.
4. Vurder kvalitativt før kvantitativt. Se over outputen med øynene først. Atferdsmønstrene er som regel åpenbare innen det første dusinet prompter. Når du har en hypotese om hvordan hver modell oppfører seg på arbeidslasten din, kan du så konstruere en rubrikk å vurdere mot — men hypotesen kommer fra observasjon, ikke fra en forhåndsbygget vurderingsmal.
5. Følg med på hva modellen legger til. Benchmark‑spørsmålet er om modellen får riktig svar. Atferdsspørsmålet er hva annet modellen gjør. Legger den til tester? Forklarer den resonneringen sin? Løfter den bekymringer? Produserer den ekstra felt du ikke ba om? Det er her modelldifferansene lever.
6. Velg modellen som matcher nedstrømsmønsteret ditt. Hvis nedstrømsprosessen din er automatisert, vil du ha en modell hvis standardatferd produserer ren, parsebar output. Hvis nedstrømsprosessen din er menneskelig gjennomgang, vil du ha en modell hvis standardatferd legger til den typen omkringliggende skjønn en menneskelig gjennomgår ønsker å se. Riktig svar avhenger av hva som kommer etter modellen.

Konklusjon

Valget mellom GPT-5.5, Claude Sonnet 4.6 og Gemini 3.1 Pro handler ikke om hvilken modell som er best. Det handler om hvilken modell som passer formen på arbeidslasten din — og den formen er noe benchmarker ikke kan se. Øvelsen ovenfor er replikerbar på en ettermiddag hvis du har promptene kuratert; verdien av å gjøre det er at du slutter å gjette og begynner å observere.

For team som kjører øvelsen selv: den enkleste løsningen er ett OpenAI‑kompatibelt endepunkt som eksponerer alle tre modeller bak én legitimasjon. CometAPI er én rute; du peker din eksisterende OpenAI‑SDK mot en annen base‑URL, og model‑parameteren blir variabelen.

Benchmarker forteller deg hva en modell kan gjøre. Atferdsmønstre forteller deg hva en modell vil gjøre, som standard, på dine prompter. Det første svaret er publisert. Det andre må du observere selv. Tyve prompter per kategori, én ettermiddag, og du har et svar som ingen ledertavle noen gang vil produsere.

Klar for å integrere pålitelig? Gå til CometAPI og API doc for sømløs tilgang til Claude Fable 5 sammen med andre frontier‑modeller, samlet fakturering og robust pålitelighet i enterprise‑klassen. Registrer deg i dag og kom i gang med sjenerøse kreditter for nye brukere — ditt neste gjennombruddsprosjekt venter.