DeepSeek V4 Flash har i uger domineret brugslister og benchmarks. Den bliver kaldt et “monster” af udviklere, og trafikken på OpenRouter peger i samme retning. Alligevel klarede den kun 53,8% af en pakke komplekse agent-opgaver i en ny serie real-world tests. Oven i det kommer kraftige prisstigninger og et nyt peak/off-peak-system, som ændrer økonomien for mange teams natten over. Det overraskede mig, indrømmet.
Hvis det lyder som to modstridende historier, er det fordi, det er det. På papiret flyver V4 Flash. I praksis snubler den, når værktøjer, kontekst og genkørsler rammer hverdagen. Og så bliver prisskruen drejet op imens.
Hovedfundene fra Composio
Composio kørte V4 Flash igennem otte forskellige agent-harnesses på 30 bevidst svære, flertrins opgaver med rigtige værktøjer som Gmail, GitHub, Slack og Google Sheets. I alt 240 kørsler. 129 pass. Det giver en succesrate på 53,8%, ifølge VentureBeat, der gennemgår metoden og tallene.
Det mest sigende: Kun seks ud af de 30 workflows blev løst af alle harnesses. Det er ikke bare en model-historie, men en orkestrerings-historie. Samme model. Meget forskellige resultater, afhængigt af pipeline, caching, retries, timeouts og værktøjsbindinger.
Leaderboardet siger ikke alt
V4 Flash har tronet øverst på usage-leaderboardet hos OpenRouter og er ifølge VentureBeat den mest brugte model målt på ugentlig token-volume. ML-forskeren Nathan Lambert kaldte de tidlige adoptionstal “insane” og noterede, at den nye version “scorede det samme som GLM 5.2” – et “total monster”.
Modelstørrelserne imponerer også på papir: V4 Flash beskrives som en 284-milliarders-parameter-model, mens V4 Pro ligger på 1,6 billioner parametre. Men parametre er ikke et SLA. Popularitet og råkapacitet omsætter sig ikke automatisk til robuste agent-forløb, når man dykker ned i værktøjsintegration, state og fejlretning undervejs.
Hvorfor samme model fejler forskelligt
Baggrund fra AWS’ Nova Forge-arbejde med multi-turn RL peger på netop det: I flertrins agentik er reward-funktionen og orkestreringen afgørende. Belønner man delmål på de forkerte tidspunkter, lærer modellen stille og roligt det forkerte – selv når kurverne på papiret ser sunde ud. Overført til drift betyder det, at en stærk base-model ikke er nok; man skal designe hele forløbet, inklusive værktøjskald, genforsøg og rullende evaluering.
Hvad Composio-testsene faktisk måler – og hvad de ikke gør
Opgaverne var udvalgt til at være besværlige. Live-integrationer, flere trin, flere fejlmuligheder. 240 runs er til at føle på, men uden fuld adgang til opgavespecifikationer, konfigurationsfiler for harnesses og pass\/fail-logikker kan graden af sværhed ikke krydstjekkes i dybden. Det er en mangel, også på reproducerbarhed. Her er en blind vinkel, som bør lukkes, før nogen drager endelige konklusioner.
Samtidig viser spændet mellem harnesses, at tooling- og pipelinevalg alene kan flytte udfaldet markant. Derfor er resultatet stadig værdifuldt: Det bekræfter, at robusthed i agent-workflows ikke kan aflæses fra et enkelt benchmark eller en enkelt succesrate.
Prisændringen rammer driften
Midt i opmærksomheden ændrer DeepSeek prissætningen for både V4 Flash og V4 Pro. Ifølge VentureBeat og Engadget kommer prisstigningerne i størrelsesordenen 57–371% for Flash og 51–355% for Pro, afhængigt af peak\/off-peak og input\/output. Samtidig introduceres et peak\/off-peak-system, hvor 17 ud af 24 timer er til halv pris.
De konkrete satser, som VentureBeat angiver: Flash til 0,22 USD pr. million input-tokens og 0,66 USD pr. million output-tokens off-peak – og det dobbelte på peak. Pro på 0,66\/1,98 USD off-peak, også fordoblet på peak. Cache-hits bliver også dyrere, med stigninger mellem 52% og 1.100%. En praktisk detalje: Hvis jeres applikation rammer cache ofte, kan stigningen bide sig ekstra fast netop dér, hvor man forventede besparelsen.
Hvad det betyder for SLA og TCO
En succesrate på 53,8% i komplekse agent-forløb er ikke kompatibel med høje SLA’er uden et massivt sikkerhedsnet. Det lægger pres på fallback-ruter, manuel review i kritiske trin og et logisk lag, der måler succes per workflow – ikke bare per svar. Uden det eksploderer fejlbudgettet.
Prisstrukturen med peak\/off-peak skubber til planlægningen. Batch-jobs kan flyttes til off-peak. Interaktive agenter kan ikke. For mange virksomheder betyder det to niveauer af arkitektur: én for tidsfleksible opgaver, én for realtid. Og ja, der er tidszone-krøller. Hvordan “peak” mappes til globale brugere, er stadig uklart i detaljen og bør verificeres før større udrulninger.
Hvorfor benchmarks stadig betyder noget – men ikke nok
Benchmarks driver adoption. De giver en hurtig temperaturmåling på kapabilitet. Men når opgaven skifter fra én prompt til ti skridt med værktøjsopkald, tidsgrænser og recovery fra fejl, flytter signalet sig. Det er ikke en kritik af benchmark-kulturen; det er en påmindelse om opgavetypen. Agent-workflows måles bedst i end-to-end succes over tid, ikke i enkeltstående svar.
Det er også her, man mærker forskel på “bedre model” og “bedre orkestrering”. Den første kan være let at købe sig til. Den anden kræver det kedelige håndværk: state management, værktøjskontrakter, backoff-strategier, sporbarhed. Ikke prangende – men det virker.
Implementering i den virkelige verden
Hvad gør man nu? Start med egne tests, ikke screenshots fra et leaderboard. Byg en lille, men skarp suite af flertrins-arbejdsgange, der ligner jeres faktiske brug: GitHub PR-kommentarer med labels, Slack-håndtering af incident-opsummeringer, Sheets-opdateringer med validering. Kør dem på tværs af to-tre harnesses og log alt.
Indfør målepunkter, der giver mening: succes per workflow, tid til fuldførsel, antal retries, antal værktøjskald og en fejl-taksonomi, som faktisk kan bruges til bugfixing. Gem kontekst og tool-traces, så man kan reproducere en fejlsituation. Det lyder tørt. Det er det, der rykker.
Fallback, overvågning og hybrid
Ingen agent-løsning uden fallback. Det kan være et menneske i loopet i ét kritisk trin eller en simpel regelmotor, der tager over, hvis tre forsøg fejler. Overvågning skal ikke kun være latency og 500-fejl; det skal være domænespecifikke fejlkoder, tool-misuse og detektering af fastlåste stier i samtalen.
Overvej hybridisering: små, lokale regler til formalia og validering; LLM til åbne opgaver. Det dæmper mængden af dyre calls og kan hæve succesraten, fordi modellen ikke skal gætte på trivielle ting, der kan slås op eller regnes ud deterministisk.
Prisrisiko og planlægning
Med de nye tariffer bliver timing en økonomisk variabel. Flyt alt, der kan vente, til off-peak. Planlæg cache-strategier bevidst, for cache-hits er ikke længere en gratis omgang. Overvåg faktiske cache-rater og regn baglæns: hvor betaler det sig, og hvor gør det ikke.
Indbyg elastik i leverandørstakken. En prisændring på 200–300% i peak-timer kan vælte et budget, hvis man er låst fast. Et simpelt routing-lag, der kan skifte mellem to-tre modeller, kan være forskellen på grøn og rød bundlinje en travl tirsdag kl. 11.
Hvad driver Deep
Seeks prisbeslutning
Motivationen er ikke eksplicit fuldt forklaret, men signalerne peger på kapacitetsstyring og monetisering af den pludselige efterspørgsel. VentureBeat citerer også vurderinger om, at off-peak-rabatten skal lokke fleksible workloads væk fra myldretiden. Det giver mening ud fra et ressourceperspektiv og minder om klassiske cloud-prismodeller.
Handelsvilkår ændrer sig ikke i et vakuum. Jo mere prisforskellen til konkurrenter udlignes, jo mere tæller andre faktorer: dataops, compliance, regional performance, support. Det er her, mange vil se nærmere på alternativer – også fordi Composio-resultaterne viser, at robusthed ikke løses med prisskiltet alene.
Brancheperspektiv og konkurrence
Der er en tendens lige nu: orkestrering stjæler overskrifter fra rå modelkraft. Amazon peger på multi-turn belønning og BYOO-orkestrering i Nova Forge. Andre leverandører satser på bedre tool-use og kontrolleret state. Samtidig presser open usage-platforme på for volumen og lave priser.
I den sammenligning bliver V4 Flash stadig interessant. Selv efter stigninger er prispunktet lavere end frontier-modeller fra de største udbydere, ifølge analyser citeret i VentureBeat. Men hvis halvdelen af komplekse forløb fejler uden et stærkt orkestreringslag, flyttes slaget til arkitektur og drift – ikke til måden, man scorer på Arena-benchmarks.
Usikkerheder der bør afklares
Tre åbne spørgsmål står tilbage. Ét: fuld adgang til Composio’s opgavespecifikationer og pass\/fail-kriterier, så tallene kan reproduceres og nuanceres. To: præcis mapning af peak\/off-peak på tværs af tidszoner og hvordan cache-hits opgøres i praksis. Tre: uafhængig verifikation af OpenRouter-brugsdata og volumenmønstre over tid.
Indtil da giver det mening at kalibrere forventningerne. Benchmarks er nyttige, men ikke et løfte om robust drift. Agent-tests i egen kontekst er der, hvor sandheden ligger gemt. Det er mindre flot på en slide, mere brugbart på en tirsdag.
De næste skridt for beslutningstagere
I de næste 7–30 dage: 1) Opsæt en snæver, repræsentativ test-suite med 8–12 flertrins workflows, inklusive live værktøjer. 2) Kør på tværs af mindst to harnesses og log tool-traces, retries og tidsforbrug. 3) Implementér et enkelt fallback-lag på ét kritisk punkt. 4) Kortlæg jeres jobmix mod peak\/off-peak og planlæg flytning af batch til billigere vinduer.
Og vigtigst: mål succes per workflow, ikke per svar. Det er den måleenhed, der afgør, om en agent hjælper eller spænder ben. Man opdager først forskellen, når man sidder med det i hænderne.
