Der er en særlig slags møde, der finder sted i hvert team, der bygger oven på frontlinje-LLM’er. Nogen deler den seneste benchmark-rangliste. En anden påpeger, at placeringerne har byttet plads siden sidste måned. En tredje bemærker, at den model, deres team bruger lige nu, er faldet to pladser på en metric, ingen af dem havde hørt om for tre uger siden. Ved mødets afslutning er ingen sikre på, om de skal migrere, og samtalen bliver booket igen til næste kvartal.
Problemet med det møde er ikke menneskene i lokalet. Det er, at benchmarks måler syntetiske opgaver, og dit produkt er ikke en syntetisk opgave. Ranglisten fortæller dig, hvordan en model klarer sig på MMLU, på SWE-bench Verified, på GPQA Diamond — tests designet af forskere til at være målbare på tværs af modeller. Ingen af disse tests ligner de prompts, din applikation faktisk sender i produktion. Ingen af dem indfanger, hvordan en model håndterer den specifikke type rodet, domæneformet input, som dine brugere genererer.
Denne artikel gennemgår præcis den øvelse, som benchmarks ikke kan udføre. Tre konkrete prompts, designet til at blive sendt til GPT-5.5, Claude Sonnet 4.6 og Gemini 3.1 Pro gennem det samme OpenAI-kompatible endepunkt, med samme temperaturindstillinger og uden ekstra prompting. Prompts spænder over tre kategorier, der berører de fleste produktionsarbejdsgange: struktureret ekstraktion fra et rodet dokument, en planlægningsopgave med tung ræsonnering og kodegenerering under begrænsninger. Observationerne nedenfor er de adfærdsmønstre, som teams, der kører denne slags sammenligning, konsekvent rapporterer — de mønstre, du selv ville se, hvis du kørte disse prompts i din egen opsætning.
På ranglisterne ligger disse tre modeller inden for 0.8 procentpoint af hinanden på SWE-bench Verified. I praksis opfører de sig meget forskelligt. Valget mellem dem handler ikke om, hvilken der scorer højest på benchmarks — det handler om, hvilket adfærdsmønster der passer til din arbejdsbyrde.
Hvad benchmarks måler, og hvad de overser
Benchmarks findes, fordi de skal. Modeludbydere har brug for standardiserede tests for at kunne fremsætte kapabilitetskrav, forskere har brug for dem til at offentliggøre sammenligninger, og vi andre har brug for dem for overhovedet at have et objektivt udgangspunkt for at evaluere modeller. De er nyttige. De er også ufuldstændige på måder, der er vigtige for produktionsbrug.
Tre specifikke begrænsninger er værd at gøre eksplicitte, fordi hver af dem dukker op i prompteksemplerne nedenfor.
- Benchmarks måler isoleret kapabilitet, ikke adfærdsmønstre. SWE-bench Verified fortæller dig, om en model kan løse en bestemt type GitHub-issue. Den fortæller dig ikke, om modellen har en tendens til at overengineere simple problemer, om den stiller afklarende spørgsmål, når prompten er tvetydig, eller om den producerer output, der matcher den struktur, du bad om, første gang. Det er de ting, du vil observere dagligt i produktion.
- Benchmarks tunes til. Når en modeludgivelse fremhæver dens score på en bestemt benchmark, er det et signal om, at modellen i det mindste delvist er blevet optimeret til den benchmark. Ydelse i den virkelige verden og benchmarkydelse kan divergere — nogle gange væsentligt — når en model forlader de betingelser, benchmarken blev designet til.
- Benchmarks aggregerer. En forskel på 0.8 procentpoint i SWE-bench Verified-score kan skjule, at Model A er meget bedre til én specifik opgavekategori og dårligere til en anden, mens Model B er konsistent hele vejen rundt. Aggregation kollapser den information, du har brug for for at træffe en beslutning.
Øvelsen nedenfor er designet til at bringe netop den slags information frem, som benchmarks aggregerer væk. Pointen er ikke at kåre en vinder — det er at vise dig de spørgsmål, du bør stille, når du kører den samme øvelse på dine egne prompts.
Opsætningen
Tre prompts, valgt fordi de map’er til kategorier, som de fleste produktionsarbejdsgange rammer. Opsætningen: hver prompt sendes til alle tre modeller med identiske parametre (temperatur 0.3, ingen systemprompt-override, standard responsformat), tilgået gennem et enkelt OpenAI-kompatibelt endepunkt, så sammenligningen forbliver æbler-til-æbler — ingen udbyderspecifikke SDK-særheder, ingen forskellige parametermappinger, ingen risiko for, at én model får særbehandling på grund af, hvordan anmodningen er konstrueret.
Promptsene er nedenfor, som kodeblokke du kan kopiere og køre. Adfærdsbeskrivelserne, der følger hver, er de mønstre, teams konsekvent rapporterer, når de kører denne slags sammenligning — mønstre dokumenteret på tværs af flere tredjepartsstudier i 2026, og den slags, du bør forvente at se selv, når du kører disse prompts i din egen opsætning. At køre det selv er pointen; artiklen findes for at give dig rammen og startpromptsene til at gøre 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: Struktureret ekstraktion fra et rodet dokument
Dette er kerneopgaven for halvdelen af de LLM-features, der blev sendt i 2026. Tag et ustruktureret input — en e-mail, en supportticket, et mødereferat, en scannet formular — og ekstrakt specifikke felter til et struktureret objekt. Prompten nedenfor beder hver model om at udtrække syv felter fra en bevidst rodet kundesupport-e-mail, der indeholder delvis information, modstridende signaler og ét felt, der slet ikke findes i kildeteksten.
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.
Hvad du skal holde øje med
Tre ting. For det første, om modellen overholder det anmodede JSON-skema uden at opfinde. For det andet, hvordan modellen håndterer feltet, der ikke findes i kilden (escalation_history — kunden nævner ingen tidligere kontakt om dette specifikke problem) — erkender den fravær, eller fabrikerer den noget plausibelt? For det tredje, om modellen producerer yderligere kommentarer uden for JSON, hvilket kræver downstream-parsing for at strippe wrapperen. Urgency-feltet er også værd at bemærke: "5 days" er ikke øjeblikkeligt, men kunden er tydeligt angst, hvilket giver plads til fortolkning.
Hvad teams, der kører dette, konsekvent rapporterer
GPT-5.5. Producerer typisk ren JSON i første forsøg. Skemaoverholdelse er stærk; hvert anmodet felt er til stede, og formatet kan parses uden forbehandling. For manglende felter returnerer GPT-5.5 en eksplicit null. Den pakker normalt ikke JSON ind i markdown-kodeblokke eller inkluderer prosaforklaringer, hvilket gør downstream-parsing trivial. Ved tvetydige fortolkningsvalg som urgency-vurderingen her er GPT-5.5 ofte mere konservativ end de to andre — hvor Claude og Gemini kan sætte ticketten til "high" baseret på kundens følelsesmæssige tone, forankrer GPT-5.5 sig ofte i det konkrete 5-dages vindue og lander på "medium".
Claude Sonnet 4.6. Producerer også ren JSON og er typisk den mest præcise af de tre i at følge det anmodede skema. Hvor GPT-5.5 lader et manglende felt stå som null, tilføjer Claude ofte uanmodede felter, der markerer datakvalitetsproblemer — en "notes" eller "data_quality_notes"-nøgle, der ikke blev bedt om, men som indeholder reelt nyttig information. Det ekstra felt er nyttigt for menneskelige gennemseere, men forårsager fejl, hvis din downstream-parser er strikt omkring skema. Dette er et tilbagevendende mønster med Claude: høj kvalitet, men nogle gange mere grundig end prompten bad om, hvilket kræver eksplicit prompt-instruktion for at begrænse.
Gemini 3.1 Pro. Producerer typisk det mest økonomiske output af de tre. Alle anmodede felter, ingen ekstra felter, ingen omgivende prosa. Skemaoverholdelse er præcis som anmodet. Den ene særhed, det er værd at kende: for manglende felter returnerer Gemini en tom streng snarere end null. Strikte JSON-parsere, der skelner mellem disse, vil fange forskellen; løse parsere vil ikke. Adfærden er konsistent nok på tværs af kørsler til, at det fremstår som en modelpræference snarere end en artefakt.
Hvad dette fortæller dig
Alle tre modeller kan lave struktureret ekstraktion. Forskellene ligger i adfærdsmargenen omkring det anmodede skema. Hvis dit downstream-system er strikt omkring skemaet og behandler ekstra felter som fejl, er Gemini 3.1 Pro og GPT-5.5 de sikrere valg. Hvis du vil have modellen til at overflade datakvalitetsproblemer uden at blive bedt om det, er Claude Sonnet 4.6 mere hjælpsom. Intet af dette fremgår af en benchmark.
Prompt 2: En planlægningsopgave med tung ræsonnering
Denne prompt beder modellerne om at planlægge en multi-trins undersøgelse: et forskningsspørgsmål med tre implicitte begrænsninger, som en omhyggelig model bør identificere, før den sekventerer arbejdet. Den slags opgave, en agentisk applikation ville delegere til en LLM som planlægningssteppet, før nogen værktøjer tages i brug.
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 implicitte begrænsninger, det er værd at holde øje med: Spørgsmålet definerer aldrig, hvad "churn" betyder (kontolukning? ingen login? ingen køb?), det specificerer ikke, hvordan man kontrollerer for confoundere (brugere med lav engagement churner af mange grunde, der ikke relaterer til feature X), og det etablerer ikke en baseline-sammenligningsgruppe. En omhyggelig planlægger bør fremhæve alle tre før trinplanen lægges.
Hvad du skal holde øje med
Om modellen reelt ræsonnerer gennem problemet eller producerer en plausibel udseende rækkefølge af trin, der ikke hænger sammen ved nærmere eftersyn. Om den identificerer de implicitte begrænsninger uden at få dem fortalt. Og om afhængighederne mellem trin er korrekte — en plan, der ser fin ud, men har trin tre afhængig af et resultat, som trin fem ville producere, er ubrugelig i praksis.
Hvad teams, der kører dette, konsekvent rapporterer
GPT-5.5. Producerer typisk den mest operationelt anvendelige plan. Ræsonneringen har tendens til at være synlig — GPT-5.5 oplister sine antagelser om de implicitte begrænsninger (churn-definition, kontrolgruppe, confoundere), før den lægger trinnene ud, hvilket gør det let at se, hvor dens fortolkning afviger fra det intenderede. Trinafhængigheder identificeres og mærkes pålideligt. Outputtet inkluderer ofte en sektion, der markerer, hvilke trin der kan paralleliseres, hvilket ikke blev anmodet om, men som tilføjer reel værdi. Dette er den slags opgave, hvor GPT-5.5’s værktøjsbrug og agentiske træning træder frem — planlægningsadfærden er formet af antagelsen om, at downstream-eksekvering følger.
Claude Sonnet 4.6. Producerer typisk den mest eftertænksomme plan, i bogstavelig forstand — Claudes plan inkluderer ofte overvejelser, som de to andre modeller ikke rejser. På et spørgsmål som dette vil Claude sandsynligvis fremhæve det metodologiske problem med korrelation vs kausalitet, bemærke at "haven’t used feature X" i sig selv kan være et symptom på churn snarere end en årsag, og eksplicit identificere begrænsninger, der ikke blev gjort eksplicitte, men som en omhyggelig analytiker bør spotte. Ulempen: planen kan være længere end nødvendigt, og enkelte trin nogle gange overengineerede i forhold til det faktiske spørgsmål. Mønsteret er konsistent med Claudes adfærd andre steder — ekspertomsorg, nogle gange mere end opgaven kræver.
Gemini 3.1 Pro. Producerer typisk den mest rent strukturerede plan, med det klareste afhængighedskort. Ræsonneringskvaliteten er høj — Gemini identificerer pålideligt de implicitte begrænsninger, dekomponerer problemet i en forsvarlig sekvens og producerer trin-for-trin-instruktioner, der faktisk kan eksekveres. Ulempen: planen kan virke noget mekanisk. Den gør jobbet, men har en tendens til ikke at overflade de metodologiske nuancer, Claude rejser, og heller ikke de paralleliseringsindsigter, GPT-5.5 inkluderer. Dette matcher Geminis bredere mønster — stærk på ræsonneringskvalitet, mere håndværkspræget på de omkringliggende dømmekraftsanliggender.
Hvad dette fortæller dig
Ræsonneringskvaliteten på denne opgave er høj på tværs af alle tre modeller. Forskellene ligger i den omkringliggende adfærd — hvad modellen tilføjer ud over den bogstavelige anmodning. GPT-5.5 tilføjer operationel pragmatisme (parallelisering, eksekveringshint). Claude tilføjer ekspertomsorg (metodologi, edge cases, statistisk nuance). Gemini tilføjer klarhed og økonomi. Ingen af disse er forkerte valg. Hvilken der passer til din applikation, afhænger af, hvad du vil have modellen til at gøre, når den er færdig med den opgave, du bad om.
Prompt 3: Kodegenerering med specifikke begrænsninger
Denne prompt beder modellerne om at implementere en lille, men ikke-triviel funktion: en Python-funktion, der tager en liste af tidsstemplede hændelser og returnerer det længste hul mellem på hinanden følgende hændelser, håndterer fire edge cases. Begrænsningerne er eksplicitte; hensigten er at teste kodegenerering under begrænsninger frem for kapabilitetsloft — hver model kan skrive denne funktion. Det, der varierer, er, hvordan de håndterer begrænsningerne.
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.
Hvad du skal holde øje med
Om modellen adresserer alle fire edge cases eller lydløst dropper nogle. Om type hints er præcise eller boilerplate. Om implementeringen vælger en forsvarlig algoritme (sortér, scan) eller noget eksotisk. Og om modellen respekterer begrænsningen "ingen tests, ingen eksempler" til sidst i prompten — dette er den slags sen-prompt-instruktion, som modeller med stærk instruktionsefterlevelse vil ære, og svagere vil ignorere i stilhed.
Hvad teams, der kører dette, konsekvent rapporterer
GPT-5.5. Producerer typisk den mest gennemarbejdede kode. Alle fire edge cases håndteres med eksplicitte grene, type hints er præcise (ofte inklusive Optional eller Union for returværdier i edge cases), og en docstring med eksempelkald. Implementeringen vælger normalt den åbenlyse algoritme — sortér, scan, track max gap — og er korrekt. Værd at vide: GPT-5.5 inkluderer ofte enhedstests eller brugs-eksempler, selv når prompten eksplicit beder om kun funktionen. Dette er trade-off’et med operationelt pragmatiske modeller — de tilføjer det, de tror, du får brug for, selv når du beder dem lade være.
Claude Sonnet 4.6. Producerer typisk den mest læsbare kode. Funktionen er kortfattet, edge cases håndteres med et rent guard-clause-mønster øverst, type hints er nøjagtige og minimale. Claude inkluderer ofte en eftertænksom kommentar, der forklarer et skøn, prompten lod stå åben — f.eks. for duplikerede tidsstempler behandles de som nul-længde-huller og forklarer hvorfor, hvilket er et forsvarligt valg, prompten ikke specificerede. Claude har en tendens til at respektere "ingen tests"-begrænsningen mere pålideligt end GPT-5.5. Selve funktionen er den mest vedligeholdelsesvenlige af de tre. Konsistent med Claudes ry for kodekvalitet: ren, idiomatisk, med eksperthåndelag.
Gemini 3.1 Pro. Producerer typisk den mest økonomiske kode af de tre. Funktionen er korrekt, edge cases håndteret, implementeringen den korteste. Docstring er normalt én linje. Type hints er til stede og korrekte. Geminis løsning inkluderer sjældent tests eller omfattende kommentarer og overengineerer ikke — hvilket er præcis, hvad prompten bad om. For en udvikler, der vil have en fungerende funktion og har til hensigt at tilføje tests separat, er dette den direkte vej. For en udvikler, der vil have modellen til også at lave det omkringliggende arbejde, tilføjer de to andre mere (uanset om du bad dem om det eller ej).
Hvad dette fortæller dig
Alle tre modeller kan skrive funktionen. Adfærdsforskellen ligger i, hvor meget omkringliggende arbejde hver model gør ud over den bogstavelige anmodning — og hvor godt hver respekterer eksplicitte "tilføj ikke X"-instruktioner. GPT-5.5 hælder mod grundighed, selv når grundighed var fravalgt i prompten. Claude hælder mod håndværk (læsbar kode, eftertænksomme kommentarer om skøn). Gemini hælder mod økonomi (gør præcis det, der blev bedt om, ikke mere). For agentiske arbejdsgange, hvor modellens output går direkte ind i en produktionskodebase, afhænger den ønskede adfærd af, hvad din downstream-reviewproces forventer — og af hvor strikt du har brug for, at negative instruktioner følges.
De mønstre, der træder frem
På tværs af de tre prompts ovenfor fremkommer tre konsistente adfærdsmønstre fra sammenligningsstudierne og udviklerrapporter offentliggjort gennem 2026. Dette er ikke kapabilitetskrav — hver model håndterer hver opgave på et højt niveau. Det er tendenser, den slags, du kun ser, når teams ser den samme model håndtere dusinvis af prompts. Kør promptsene ovenfor i din egen opsætning, og du vil se de samme mønstre; artiklen findes for at give dig rammen for at genkende, hvad du ser, når du gør det.
| Model | Adfærdstendens | Passer bedst når… |
|---|---|---|
| GPT-5.5 | Operationelt pragmatisk. Tilføjer eksekveringshint, defensiv kodning og downstream-venligt output. Stærk på agentiske og værktøjsformede opgaver. | Din applikation kæder modellens output ind i yderligere eksekvering — agenter, arbejdsgange eller pipelines, hvor næste trin er automatiseret. |
| Claude Sonnet 4.6 | Ekspertniveau-omsorg. Overflader overvejelser ud over den bogstavelige anmodning, rejser etiske og metodologiske hensyn, producerer meget læsbar kode. | Din applikation har et menneske, der gennemser modellens output — indholdsgenerering, code review, analyse hvor håndværk betyder noget. |
| Gemini 3.1 Pro | Økonomisk og direkte. Gør præcis, hvad der blev bedt om, ikke mere. Reneste skemaoverholdelse og lavest token-output for ækvivalent arbejde. | Din applikation har strikte outputkrav, forudsigelige omkostninger er en prioritet, eller du vil have modellen som et præcist værktøj frem for en eftertænksom kollaboratør. |
Et vigtigt forbehold. Disse mønstre er tendenser, ikke regler. Hver model kan styres mod en hvilken som helst af disse adfærdsmåder med passende prompting — en tilstrækkelig detaljeret systemprompt får Gemini til at tilføje tests, eller begrænser Claude til minimumsoutput, eller får GPT-5.5 til at springe enhedstests over. Pointen er, hvad hver model gør som standard, før du begynder at styre den. Standardadfærden er det, du lever med i produktion, medmindre du aktivt prompt’er imod den.
Sådan tester du på din egen arbejdsbyrde
Øvelsen ovenfor kan replikeres på enhver arbejdsbyrde, og det bør den. Benchmark-scorer er nyttige som første filter, men de adfærdsmønstre, der betyder noget for din specifikke applikation, er kun synlige, når du ser modellerne håndtere dine specifikke prompts.
En praktisk guide til at køre øvelsen på din egen trafik:
- Vælg tre repræsentative promptkategorier. Ikke tre tilfældige prompts — tre kategorier, der spænder over din arbejdsbyrde. De fleste produktionssystemer kan dekomponeres i en håndfuld prompttyper (ekstraktion, klassifikation, generering, ræsonnering, kode, opsummering). Vælg de kategorier, der står for hovedparten af din trafik.
- Kuratér 20–30 eksempler pr. kategori. Ideelt fra reel trafik. Anonymisér hvor nødvendigt. Pointen er, at prompts skal ligne det, din applikation faktisk ser, ikke benchmark-spørgsmål. Tyve eksempler pr. kategori er nok til at se mønstre; tredive er nok til at være sikker.
- Kør dem gennem ét endepunkt, alle modeller. Et OpenAI-kompatibelt aggregator-endepunkt gør dette dramatisk hurtigere end at køre hver model gennem sit eget SDK. Koden øverst i denne artikel er hele opsætningen. Samme temperatur, samme parametre, samme prompt — forskellene i output er model-forskelle.
- Bedøm kvalitativt før kvantitativt. Kig outputs igennem først. Adfærdsmønstrene er normalt tydelige inden for de første dusin prompts. Når du har en hypotese om, hvordan hver model opfører sig på din arbejdsbyrde, kan du konstruere en rubric at bedømme efter — men hypotesen kommer af observation, ikke af en på forhånd bygget bedømmelsesskabelon.
- Vær opmærksom på, hvad modellen tilføjer. Benchmark-spørgsmålet er, om modellen får det rigtige svar. Adfærdsspørgsmålet er, hvad den ellers gør. Tilføjer den tests? Forklarer den sin ræsonnering? Rejser den bekymringer? Producerer den ekstra felter, du ikke bad om? Det er her, model-forskellene lever.
- Vælg den model, der matcher dit downstream-mønster. Hvis din downstream-proces er automatiseret, vil du have en model, hvis standardadfærd producerer rent, parsebart output. Hvis din downstream-proces er menneskelig review, vil du have en model, hvis standardadfærd tilføjer den slags omkringliggende dømmekraft, en menneskelig reviewer gerne vil se. Det rigtige svar afhænger af, hvad der kommer efter modellen.
Konklusion
Valget mellem GPT-5.5, Claude Sonnet 4.6 og Gemini 3.1 Pro handler ikke om, hvilken model der er bedst. Det handler om, hvilken model der passer til formen på din arbejdsbyrde — og den form er noget, benchmarks ikke kan se. Øvelsen ovenfor kan replikeres på en eftermiddag, hvis du har promptsene kurateret; værdien i at gøre det er, at du stopper med at gætte og begynder at observere.
For teams, der kører øvelsen selv: den nemmeste opsætning er et enkelt OpenAI-kompatibelt endepunkt, der eksponerer alle tre modeller bag én credential. CometAPI er én vej; du peger dit eksisterende OpenAI SDK mod en anden base-URL, og model-parameteren bliver variablen. Den ledsagende artikel, The 2026 LLM API Pricing Comparison, dækker omkostningssiden af den samme beslutning — tilsammen giver de både det adfærdsmæssige og det finansielle billede, du har brug for for at vælge rigtigt.
Benchmarks fortæller dig, hvad en model kan gøre. Adfærdsmønstre fortæller dig, hvad en model vil gøre, som standard, på dine prompts. Det første svar er offentliggjort. Det andet skal du selv observere. Tyve prompts pr. kategori, én eftermiddag, og du har et svar, som ingen rangliste nogensinde vil producere.
Klar til at integrere pålideligt? Gå til CometAPI og API-dokumentation for problemfri adgang til Claude Fable 5 sammen med andre frontlinjemodeller, samlet fakturering og enterprise-grade pålidelighed. Tilmeld dig i dag og kom i gang med generøse kreditter til nye brugere — dit næste gennembrudsprojekt venter.