Google lancerer Gemini 4 Argon – og sætter outputloftet i vejret
Google DeepMind har lanceret Gemini 4 Argon, den første model i Gemini 4-familien, med én markant ændring: op til 1.000.000 output-tokens i et enkelt svar. Det skriver MarkTechPost, der også gennemgår prisstrukturen og Googles plan for en gradvis udrulning under USA’s frivillige præ-release-proces for modeladgang. TechCrunch beskriver Argon som en arbejdshest til kodning og cybersikkerhed – en positionering, der peger direkte ind i enterprise-brug.
Konsekvensen er håndgribelig: Du kan køre en stor, flerhundredetusind-linjers refaktorering eller få en lang juridisk gennemgang med bilag, tabeller og noter i ét sammenhængende forløb – uden at klippe teksten i bidder.
Fakta først – pris, loft og den uafklarede detalje
Ifølge MarkTechPost kan Argon levere op til 1.000.000 output-tokens, hvor tidligere Gemini-modeller lå omkring 64.000. Google har offentliggjort introduktionspriser på 2 dollar pr. 1 mio. input-tokens og 10 dollar pr. 1 mio. output-tokens. Cached input-tokens får 95 procent rabat (0,10 dollar pr. 1 mio.). Efter introduktionsperioden fordobles priserne til 4 og 20 dollar. Enkelt at læse – men det kræver regneark i praksis.
En vigtig brik mangler dog. Google har ikke oplyst Argons input context window – altså hvor meget tekst/kontekst man kan give modellen i ét hug. Det gør en reel forskel. Et langt output uden tilsvarende langt inputvindue betyder, at man skal arbejde klogt med streaming, buffer og ekstern hukommelse for at holde tråden. Det er ikke en fodnote; det er arkitektur.
Hvad betyder 1 mio. output-tokens teknisk?
Outputloft er ikke det samme som input-kontekst. Output handler om, hvor lang en sammenhængende generering modellen kan producere, før den stopper. Input-kontekst er, hvor meget materiale du kan lægge ind på én gang for at styre outputtet. Uden et oplyst inputvindue må udviklere planlægge konservativt og supplere med ekstern dokumentlager, retrieval og caches.
Ofte står valget mellem to mønstre: 1) streaming af et langt svar, der valideres løbende og kan afbrydes, eller 2) batchet generering i segmenter med checkpointing og kontrol mellem segmenterne. Begge kræver state management, detaljeret logning og muligheden for at genoptage, hvis forbindelsen knækker eller et mellemtrin fejler. Ved kodegenerering er mellem-checkpoints afgørende; en fejl sent i forløbet må ikke gøre alt tidligere arbejde værdiløst.
Hvad koster det – og hvornår?
Et fuldt 1 mio.-tokens output koster 10 dollar i introduktionsperioden og 20 dollar efter. Input koster 2/4 dollar pr. mio. tokens, men cached input – når samme input genbruges – koster 0,10 dollar pr. mio. tokens. Det er et klart incitament til at bygge cache-strategier ind fra dag ét. Den store besparelse ligger i at undgå at betale fuld pris for den samme kontekst igen og igen.
Hurtigt regneeksempel (antagelser markeret): En stor refaktorering med 200.000 input-tokens og 800.000 output-tokens vil koste ca. 0,4 dollar for input og 8 dollar for output i introperioden, i alt 8,4 dollar; efter introperioden ca. 0,8 + 16 = 16,8 dollar. Har man 80 procent af inputtet i cache, falder input-delen til næsten nul (0,04 dollar intro). Kører du det 10.000 gange på en uge, bliver regnestykket pludselig afgørende for sprintbudgettet.
Benchmarks – stærk på lange forløb, ikke suveræn overalt
MarkTechPost refererer, at Google sammenlignede Argon på 18 benchmarks. Argon ligger først på 12 og delt først på 1. På DeepSWE v1.1, der tester langtidshorisont i software engineering, scorer Argon 77,9 procent – nyt state of the art ifølge artiklen – mod 74,2 procent for Opus 5.5 og 74,1 procent for GPT‑6 Astra. På Vals Index, der måler økonomisk effekt på tværs af finans, kodning, jura og skat, ligger Argon først med 68,9 procent. På AutomationBench, der tester ende‑til‑ende forretningsudførelse (via Zapier‑lignende flows), scorer Argon 51,3 procent mod 42,5 for Opus 5.5.
Der er også svagere punkter. På FrontierSWE v2 scorer Argon 55,0 procent mod 65,5 for GPT‑6 Astra. På Terminal‑Bench 4.0 ligger Argon på 57,4 mod 66,4 for Opus 5.5. OSWorld‑2.0 viser et tilsvarende billede: 69,2 for Argon mod 72,6 for GPT‑6 Astra. Konklusionen: Modellen ser stærk ud på flere lange, komplekse workflows, men er ikke dominerende på alle praktiske opgaver. Det er nyttig viden, så man ikke bruger den samme hammer til alle søm.
Hvad betyder 3–4 procentpoints løft i praksis?
Det handler ikke kun om placering, men om robusthed på tværs af agent-rammer og værktøjsbrug. MarkTechPost bemærker bl.a., at resultater på CWE-bench v1 er målt i forskellige agent-opsætninger. Små forskelle i værktøjstilladelser eller timeout kan give store udsving – direkte sammenligninger kræver omhu.
Cyberforsvar – finde, validere, patche
Google fremhæver, at Argon er trænet til at finde, validere og patche kritiske sårbarheder. På CWE-bench v1 skulle Argon ligge delt først på 68 procent, ifølge MarkTechPost. Artiklen beskriver også en case fra Wiz’ Scan for Good-initiativ, hvor Argon fandt en kritisk sårbarhed i hospitalssoftware, som tidligere frontmodeller angiveligt missede. Det er en markant påstand og bør bekræftes uafhængigt af Wiz og eventuelt leverandøren bag den ramte software. Indtil da er casen et stærkt signal – ikke en ny norm.
En detalje, der stikker ud: “trusted defenders” og interne Google-teams får adgang uden cyber-guardrails, ifølge MarkTechPost. Det peger på en bevidst afvejning af ydeevne og risiko efter brugerens rolle og modenhed. For de fleste virksomheder giver en mellemvej mening: strenge sandkasser, tokens-lofter, værktøjs-whitelists, revisionslogs og krav om menneske-i-loop, før patches rulles ud.
USA’s frivillige præ-release-proces – hvad betyder det?
MarkTechPost skriver, at Google deltager i den amerikanske regerings frivillige proces for tidlig modeladgang. Formålet er at få feedback, styrke guardrails og sikre dokumenterede sikkerhedstests før bred frigivelse. For indkøbere betyder det, at der i en periode vil være skiftende konfigurationer og hurtige iterationer. Stabilitet og “change windows” bør derfor skrives ind i kontrakter og drift.
Der følger også et ansvarsspørgsmål med. Hvis leverandøren tilbyder mindre restriktive profiler til “betroede” miljøer, hvem bærer så ansvaret, hvis en model foretager en skadelig handling? Praktisk set: Hvem godkender? Hvem rollback’er? Hvem ejer auditsporet?
Økonomi i virkeligheden – tre scenarier
Antagelser: 750 tokens per side prosa; 1.000 tokens per side med tunge bilag; 1 token ~ 0,75 ord. Grove tommelfingerregler til størrelsesorden, ikke decimaler.
- Stor codebase-refaktor: 200.000 input-tokens, 800.000 output-tokens. Intro: ca. 0,4 + 8,0 = 8,4 dollar. Efter intro: ca. 0,8 + 16,0 = 16,8 dollar. Med 80 procent input-cache: input falder til ~0,04/0,08 dollar.
- Kontraktssammenfatning af 1.000 sider med bilag: 1 mio. input-tokens, 300.000 output-tokens. Intro: 2,0 + 3,0 = 5,0 dollar (med fuld pris). Med 50 procent cache: input ~1,05 dollar. Efter intro: 4,0 + 6,0 = 10,0 dollar (eller ~5,05 med 50 procent cache på input).
- Cyberscan med automatiske patch-forslag: 300.000 input-tokens, 1 mio. output-tokens (worst case). Intro: 0,6 + 10,0 = 10,6 dollar. Efter intro: 1,2 + 20,0 = 21,2 dollar. Med 70 procent cache på baseline-kontekst: input ~0,18/0,36 dollar.
Konklusionen er ikke, at det er dyrt eller billigt – men at det er forudsigeligt, hvis man måler. Omkostningen følger outputtet. Arkitekturen bør derfor minimere spild-output: afbryd tidligt, stream og valider, brug kontrollerede skabeloner og dedupliker. Del lange svar op i sektioner, som kan godkendes og stoppes.
Arkitektur og drift – hvad skal ændres?
Med lange outputs flytter flaskehalsen sig fra “kan modellen holde tråden?” til “kan systemet holde til tråden?”. Det taler for session-styring med checkpointing, så store svar kan genoptages ved fejl; ekstern dokument-hukommelse, så inputvinduet ikke bliver en skjult begrænsning; samt cost-limiting på både tid og tokens for at undgå løbske kørsler.
Dertil kommer en robust retry-strategi med idempotens. Hvis et langt svar fejler ved 780.000 tokens, skal man kunne genoptage derfra uden at trigge en helt ny, dyr tur. Logs skal være detaljerede nok til at forklare, hvorfor sektion 4 afviger fra sektion 1. Og output bør være maskinvenligt struktureret, så automatisk validering og test kan køre løbende – ellers ender man med at læse 600.000 tokens manuelt.
Sikkerhedsgovernance – før produktion
Minimumskrav tegner sig: revisionslog på prompts, værktøjsbrug og beslutninger; staging-miljøer med regressionstests; menneske-i-loop ved høj risiko; og isolerede sandkasser for modelkørsler med system-adgang. Hvis leverandørprofilen tillader færre guardrails for “betroede” brugere, bør det fremgå eksplicit, hvornår og hvordan de aktiveres – og hvem der godkender det.
Konkurrencebilledet – længere svar ændrer spillet, men ikke alt
TechCrunchs “workhorse for coding and cybersecurity” rammer et marked, hvor OpenAI, Anthropic og andre har hævet både kontekst og pålidelighed det seneste år. 1 mio. output-tokens skubber grænsen for, hvad der kan køre i ét stræk, men resultaterne på fx FrontierSWE v2 og Terminal-Bench viser, at opgaven ikke er afgjort. Hvis prisen per opgave ender lavere via caching og færre genkørsler, kan Argon være attraktivt selv dér, hvor råscore ikke er i top.
Det oversete punkt: Økosystemet omkring modellen – IDE-integration, eval-rammer, testdata, sandkasser – afgør driftsoplevelsen. Den model, der giver færrest “kan ikke lige nu”-øjeblikke i drift, vinder. Det er sjældent én benchmark, der afgør det.
De åbne spørgsmål, der stadig mangler svar
For at rykke fra hype til drift skal flere huller lukkes med officielle dokumenter og tal:
- Input context window for Argon – uden det er arkitekturvalg halvt blinde.
- Dokumentation af benchmark-opsætninger (DeepSWE v1.1, Vals, AutomationBench, Harvey Legal Agent, CWE-bench v1) – så implementeringsdetaljer kan forstås og resultater gentages.
- Uafhængig bekræftelse fra Wiz af den nævnte sårbarhedscase i hospitalssoftware – samt omfang og afhjælpning.
- Gennemsigtighed i guardrails-profiler, herunder “trusted defenders” kontra standardkunder – hvordan ser kontrakter og ansvarsregler ud?
- Ydelsesdata for meget lange genereringer: throughput, latenstid, varians og fejlrater – nødvendigt til kapacitetsplanlægning.
Når de brikker falder på plads, bliver det tydeligere, om 1 mio. tokens er et dagligt værktøj eller primært en “escape hatch” til særligt lange jobs.
Hvad betyder det i hverdagen – tre konkrete implikationer
For softwareteams: længere, sammenhængende refaktoreringer og migreringer kan samles til færre runs, men kræver stærk testautomatisering og semantisk diff, så man kan validere i fart. Benchmarks peger på reel kapabilitet i lange forløb, men ikke total dominans. Der vil være opgaver, hvor andre modeller stadig er bedre.
For juridisk/finans: store dokumentpakker kan produceres i ét forløb, men input-vinduets ukendte størrelse gør retrieval-design afgørende. Caching er penge værd. Kvalitetssikring skal være en sporbar tjekliste med stikprøver – ikke ren tillid til outputtet. En halv sætning, der glider, kan vælte en konklusion.
For sikkerhedsdrift: sårbarhedsopdagelse og patch-forslag kan skaleres, hvis man har sandkasser, rollbacks og compliance-venlige revisionsspor. Uden det bliver gevinsten teoretisk. Latens og kø-styring under hændelser er afgørende – et værktøj, der er langsomt på dårlige dage, bliver ikke brugt.
Bundlinjen
Gemini 4 Argon løfter loftet for, hvor langt ét svar kan række. Det åbner for nye typer af sammenhængende workflows i kodning, dokumentarbejde og cyberforsvar. Priserne er klare nok til, at økonomer kan modellere TCO – især med caching som nøglegreb. Men uden oplyst inputvindue og uden uafhængig verifikation af flere nøgleresultater er det klogt at designe med margin: cache, checkpoint, sandbox, mål.
Forskellen mærkes, når man bruger det.
