DeepSeek V4.1 Flash i OpenCode: Konfiguration, kostnad och ansträngningsratten som ingen nämner

DeepSeek V4.1 Flash har legat i OpenCode Go sedan den 10 september, och multiplikatorn som OpenCode kopplade till den har ett publicerat slutdatum: den 20 september. Det är fyra dagar kvar. Det intressanta är inte tidsfristen – det är att inställningen som avgör om den här modellen är behaglig att koda med saknas i alla uppsättningsguider på första resultatsidan, och att den i minst två harnessar tyst utelämnas. Det här är en spelbok för att rikta en kodagent mot DeepSeek V4.1 Flash: de exakta modell-id:na, de tre integrationer som verifierats i dag, den community-rapporterade kontrollen för reasoning-effort och övertänkningsfelläget med de åtgärder som faktiskt fungerar.

Vad du faktiskt riktar din agent mot

DeepSeek V4.1 Flash släpptes 2026-09-10 – versionsinformationen i DeepSeeks egen API-dokumentation är daterad den dagen, och det är den minsta modellen i leverantörens nya arkitekturfamilj. DeepSeek rapporterar ett stamnät av mixture-of-experts-typ med 552B parametrar, byggt på vad företaget kallar en Causal Encoder–Decoder-design, som aktiverar ungefär 8B parametrar per token under prefill och 16B under decode. Den tar text och bilder som indata och returnerar text, erbjuder ett kontextfönster på upp till en miljon tokens och genererar upp till 384 000 tokens i ett enda svar – både kontext- och utdatataken kommer från OrcaRouters egen modellsida för modellen, som listar 1 048 576 respektive 384 000.

Leverantörens benchmarks, från diagrammet på DeepSeeks utgivningssida och därmed leverantörsrapporterade och ogranskade: 30,0 på Terminal-Bench 3.0, 74,2 på DeepSWE v1.1, 88,1 på CyberGym, 54,8 på Automation-Bench och 90,9 på GPQA Diamond. Oberoende poängsättning är tunnare men finns – Artificial Analysis, läst direkt idag, placerar DeepSeek V4.1 Flash på 40 i sitt Intelligence Index, rankad 6:a av 113 i sin jämförelseklass. En rad från samma sida betyder mer för en läsare av kodningsagenter än placeringen gör: Artificial Analysis betecknar modellen som very verbose, då den har förbrukat 250 miljoner output-tokens för att slutföra sin Intelligence Index-körning, jämfört med en median på 140 miljoner. Vi återkommer till det.

Två fakta om namngivning sparar verklig felsökningstid. DeepSeeks kanoniska API-modell-id är nu code>deepseek-flash/code>. De äldre strängarna code>deepseek-v4-flash/code> och code>deepseek-v4-flash-vision-exp/code> accepteras fortfarande, men modellerna bakom dem har tagits ur bruk och förfrågningar hanteras av V4.1 Flash till Flash-priset. Separat är DeepSeek V4 Pro inte borta: DeepSeeks dokumentation anger att V4 Pro API-tjänsten fortsätter efter 2026-09-14 med oförändrad fakturering. Om du har fått höra att flaggskeppet stängdes av, är det inte vad leverantörens egna dokument säger.

OpenCode: två vägar in, och id:t som du faktiskt ska skriva

Det finns två sätt att sätta DeepSeek V4.1 Flash bakom OpenCode, och de har olika ekonomiska förutsättningar.

Prenumerationsvägen är OpenCode Go, en plan för 10 USD/månad som OpenCode beskriver som en kurerad uppsättning öppna kodningsmodeller som OpenCode har testat och benchmarkat. Installationen består av fyra steg och det finns ingen konfigurationsfil att redigera manuellt: logga in på OpenCode Zen, prenumerera på Go, kopiera API-nyckeln och kör sedan code>/connect/code> i TUI:n, välj OpenCode Go och klistra in nyckeln. Efter det code>/models/code> listar vad som är tillgängligt. Modellreferenser i konfigurationen har formen code>opencode-go/<model-id>/code>.

Vilket modell-id? Båda. Go-gatewayens egen modellista, hämtad idag från code>https://opencode.ai/zen/go/v1/models/code>, returnerar code>deepseek-flash/code> och code>deepseek-v4.1-flash/code> som två separata poster, vid sidan av de äldre code>deepseek-v4-flash/code> och code>deepseek-v4-pro/code>. Vilken som helst av de två första motsvarar modellen du vill ha; code>deepseek-flash/code> är det kanoniska namnet och det säkrare valet för allt du tänker fortsätta köra.

Direktvägen hoppar helt över prenumerationen: kör code>/connect/code>, sök efter DeepSeek och klistra in en DeepSeek-plattformsnyckel. Du faktureras då av DeepSeek till listpris i stället för att ta av en Go-kvot. DeepSeek publicerar listpriset som $0,15 per 1 miljon indatatoken under lågtrafik och $0,60 per 1 miljon utdatatoken, med cachade läsningar till $0,003 per 1 miljon – och exakt det dubbla under högtrafik. Både OpenCode Gos dokumentation och OrcaRouters modellsida, lästa idag, stämmer överens om dessa siffror.

Det som OpenCode Go tillför är kvotstrukturen, och här är siffrorna värda att läsa noggrant, eftersom de är anledningen till att tidsfristen har betydelse. OpenCodes egen dokumentation listar DeepSeek V4.1 Flash med en månadsgräns på $15, för närvarande multiplicerad 4× till $60 under en kampanj som OpenCode markerar "Slutar 20 sep". Uppskattade förfrågningsantal publiceras i två kolumner: 6 500 per 5 timmar / 16 250 per vecka / 32 500 per månad till standardtaxan, eller 26 000 / 65 000 / 130 000 med 4×-multiplikatorn tillämpad. Kvotens form är konsekvent mellan modellerna – 5-timmarsgränsen är 20 % av månadssiffran, veckogränsen är 50 %, och månadsgränsen är hela beloppet.

Det där är OpenCode publicerade siffror, lästa ur deras Go-dokumentation i dag. Kampanjen är deras att avsluta, och den är daterad.

Command Code: fortfarande live, och en buggrapport värd att känna till

Command Code har fortfarande modellen listad i sin egen katalog i dag, under id:t code>deepseek-v4-1-flash/code>, med ett kontextfönster på 1M tokens och samma vidarebefordrade prissättning: $0.15 / $0.60 utanför högtrafik, $0.30 / $1.20 i högtrafik, $0.003 för cachad läsning. Att priserna matchar mellan två oberoende ramverk är ingen slump – båda vidarebefordrar DeepSeeks listpris i stället för att sätta sina egna.

Mekaniken är enkel. Installera med code>npm i -g command-code/code>, kör det från din projektkatalog, autentisera med code>/login/code>, och använd code>/connect/code> om du vill använda din egen leverantörsnyckel. code>/model <id>/code> tillämpar ett modellbyte direkt, medan enbart code>/model/code> öppnar en väljare, och code>/effort/code> ställer in resonemangsansträngning för den aktuella modellen — flaggan som spelar störst roll här.

En community-buggrapport är värd att lägga på minnet innan du felsöker fel lager. Ett öppet issue mot ett tredjepartsroutningslager beskriver en reasoning-replay-cache som aldrig aktiveras för code>command-code/deepseek-v4.1-flash/code> id:t, eftersom mönstret som routningslagret matchar mot förväntar sig ett code>v4./code> eller code>v4-/code>-segment och strängen är code>v4.1/code>. Det rapporterade symptomet är 400-fel uppströms som klagar på att resonemangsinnehåll som producerats i tankeläge måste skickas tillbaka till API:et. Det är en community-buggrapport om en matchare på klientsidan, inte leverantörsvägledning och inte ett problem med modellen — men det är precis den typen av sak som ser ut som ett modellfel klockan 2 på natten.

Claude Code, Codex och de klienter som OpenCode själv har validerat

OpenCode Go är inte bara för OpenCode, och det står uttryckligen i deras dokumentation: det är utformat för OpenCode och andra kodningsagenter som producerar liknande förfrågningsmönster, med en publicerad lista över klienter som verifierats fungera. På den listan finns för närvarande Hermes, Claude Code, Codex, ZCode och Pi — och för Claude Code lyder noteringen att den "känner igen sin inbyggda session-header. Ingen omslutning med anpassad header behövs." Två krav följer med detta: identifiera din klient med dess egen user agent i stället för ett generiskt SDK-namn, och skicka en stabil sessionsidentifierare i code>x-opencode-session/code>-headern i varje konversation, vilket är det som gör att deras routning och prompt-cachning fungerar. För Hermes spelar den validerade byggversionen roll — header-rättelsen slogs samman efter v0.21.0, så enbart den utgåvan innehåller den inte.

Det finns också en väg helt utan prenumeration, som använder DeepSeeks Anthropic-kompatibla endpoint direkt. Ställ in code>ANTHROPIC_BASE_URL/code> till code>https://api.deepseek.com/anthropic/code>, code>ANTHROPIC_AUTH_TOKEN/code> till din DeepSeek-nyckel och peka modellvariablerna mot modellen. Claudes modellnamn mappas om på vägen in: allt som börjar med code>claude-opus/code> går till DeepSeek V4 Pro och faktureras till V4 Pro-priset, medan code>claude-sonnet/code> och code>claude-haiku/code>-namn går till Flash-modellen. Suffixet code>[1m]/code> på modellsträngen begär varianten med en miljon tokens kontext. DeepSeeks egen guide för den här konfigurationen sätter också code>CLAUDE_CODE_EFFORT_LEVEL=max/code> och låser fönstret för automatisk komprimering till 786432 tokens.

Den sista variabeln är där en community-fix finns.code>thinking: {"type": "disabled"}/code> vid subagentförfrågningar medan code>CLAUDE_CODE_EFFORT_LEVEL=max/code> lägger till en reasoning-effort-parameter, och DeepSeeks Anthropic-format-endpoint avvisar den kombinationen med ett meddelande om att tänkandealternativ inte kan inaktiveras när reasoning effort är inställt. Den rapporterade workarounden är snäv – ta bort effort-parametern endast från subagentförfrågningar och lämna huvudagenten orörd. Behandla det som en community-upptäckt om en bristande överensstämmelse i klient/server-kontraktet, och räkna med att den exakta versionsgränsen flyttas.

Ansträngningsratten: 1–100, och varför ”låg” betyder 50

Allt i det här avsnittet är ett community-fynd snarare än leverantörsvägledning. DeepSeek publicerar ingen förinställning-till-nummer-mappning som vi skulle kunna verifiera, och siffrorna nedan kommer från praktikers nedteckningar och dokumentation för tredjeparts testriggar. De är tillräckligt konsekventa mellan källor för att vara användbara, och tillräckligt obekräftade för att du bör testa dem i ditt eget arbete.

DeepSeek V4.1 Flash tränas med en kontinuerlig skalär för resonemangsansträngning från 1 till 100. Det är inte ett tak för antal tokens — det flyttar var modellen befinner sig på en kurva som träningsprocessen har lärt sig, där lägre ansträngning lägger mer press på att vara koncis och högre ansträngning gör ytterligare resonemang billigare. Tre offentliga förinställningar mappar mot den skalan:

• Låg — 50, den kortaste vägen och förinställningen som ger reglaget dess rykte om att vara billigt.

• Hög — 75, och den nivå som de flesta communitykällor beskriver som det förnuftiga taket för agentarbete.

• Max — 100, där straffet för resonemangslängden tas bort helt.

Det reglaget ger är verkligt men med kraftigt avtagande avkastning. En benchmark-svepning i communityn rapporterade att en höjning av effort från 25 till 100 flyttade Terminal-Bench 2.1 från 82,4 till 90,6 samtidigt som antalet utdatatoken totalt ökade med ungefär 2,5×. Rapporterna pekar samstämmigt på att effort någonstans mellan 60 och 80 fångar större delen av den tillgängliga noggrannheten för mindre än halva tokenbudgeten, medan max tillför ytterligare 1,6–1,8× till agenttrajektorierna för en marginell vinst.

Standardvärdet är den del som ingen är överens om. Viss dokumentation om harness och rapporter från utövare säger att ett oinställt effort-värde faller tillbaka på high; andra beskriver serverns standardvärde som helt enkelt okänt. Det som är dokumenterat snarare än omdiskuterat är att två harness-integrationer visade sig inte skicka parametern alls — OpenCode Go-leverantörsprofilen och en inbyggd DeepSeek-profil hoppade båda över att skicka code>reasoning_effort/code> för code>deepseek-flash/code>-slugen, eftersom deras matchningsvakt förväntade sig ett code>deepseek-v…/code>-prefix som det kanoniska id:t inte har. I båda fallen ersattes användarens valda inställning tyst av leverantörens standardvärde. Om din klient visar en effort-kontroll är det inte bevis för att den finns i överföringen. Logga en begärandekropp och titta.

Ytterligare en egenhet från samma rapporter: OpenCode Go-endpointen accepterar code>low/code>, code>medium/code>, code>high/code> och code>max/code>, men avvisar ett heltalsvärde för effort — ett värde på 80 har rapporterats returnera HTTP 400. 1–100-skalan finns i modellen, men den exponeras inte som ett rått tal överallt, så "ställ in effort på 65" kanske inte går att uttrycka i din klient.

Övertänkandets felmod, och vad som faktiskt åtgärdar den

Det här är felsättet som avgör om du behåller modellen i din loop. Gemenskapsrapporter beskriver att DeepSeek V4.1 Flash fortsätter att resonera efter att arbetet är klart: argumenterar om en punkt som den redan har svarat korrekt på, berättar om korrigeringen av sina egna felaktiga antaganden och producerar långa resonemangskedjor med låg informationstäthet. En utövare rapporterade att resonemangsutdata fortsatte i över en timme i en kodnings-CLI-session. En annan rapporterade att den inte alls gick att få att slutföra en lång benchmarkkörning.

En källnot om den andra rapporten, eftersom det är den typ av påstående som tvättas. Den kommer från en communitytråd om att köra modellen tillförlitligt, och Reddit blockerar vår hämtare, så vi kunde inte läsa tråden direkt — vi vidarebefordrar rapporten i stället för att citera en sida vi har öppnat. Vad vi kunde verifiera oberoende är problemets form, och där är de externa bevisen ovanligt rena: Artificial Analysis flaggar på sin egen sida modellen som mycket mångordig, och den förbrukar 250M utdatatokens för att slutföra en körning som dess medianjämförelsemodell klarar på 140M. Det är ungefär 1,8×, mätt av en tredje part, på en fast uppgiftsuppsättning. Foruminläggen och det oberoende måttet beskriver samma beteende.

De åtgärder som kommer ut ur dessa rapporter, alla från communityn:

• Lås ansträngningen vid hög eller lägre och tillåt inte att den trappas upp. Den tydligaste fixen som setts i verkligheten är en routing-plugin skriven specifikt för att stoppa eskalering av ansträngning: turens djup bidrar inte alls till eskaleringspoängen, endast ett misslyckat verktygsresultat eller ett identiskt nytt försök räknas, eskaleringen har ett tak, och max är ett tillval och nedprioriteras som standard. Om din harness låter en agent höja sin egen ansträngning när en körning blir längre, är det mekanismen som ska stängas av.

• Kör inte max som standard. Flera utövare rapporterar att max snurrar i stället för att konvergera vid rutinarbete, och att växla tillbaka till high löser det.

• Begränsa code>max_tokens/code> på interaktiva vägar. Ett utdatatak på 384 000 token är en gräns, inte ett mål, och en loop som inte terminerar är dyr vid det taket.

• Verifiera att parametern skickas. Med tanke på att två testriggar visade sig tyst utelämna den, är "jag ställde in den på high" och "high nådde API:et" olika påståenden.

• Harnesket spelar större roll än man kan tro. Utövare som kör samma vikter rapporterar kraftigt olika beteende mellan olika skal – samma modell som argumenterar med sig själv och begraver signalen i ett harnesk väcker inga av dessa klagomål i ett annat. Det är en observation från communityn om harneskets beteende, inte ett leverantörspåstående om modellen, men det är det mest upprepade rådet i rapporterna.

Vad en kodloop faktiskt kostar vid dessa priser

DeepSeeks listpris är 0,15 USD per 1 miljon indatatokens och 0,60 USD per 1 miljon utdatatokens utanför högtrafik — utdata är fyra gånger indata, vilket är det första man bör ta till sig om en agent som genererar både resonemang och kod.

Ta en realistisk agenttur: 60 000 token kontext (systemprompt, verktygsscheman, en repo-slice, konversationshistorik) in, och 3 000 token resonemang plus en patch ut. Det är 60 000 × 0,15 $/1M = 0,009 $ in, plus 3 000 × 0,60 $/1M = 0,0018 $ ut, så ungefär 1,1 cent per tur. Tvåhundra sådana turer under en arbetsdag är ungefär 2,16 $, eller omkring 47 $ under en månad med vardagar till off-peak-priset. Det är aritmetiken som får en månadsbudget på 15 $ med en 4×-kampanj ovanpå att verka generös — och aritmetiken som gör att verbositet är det man bör hålla koll på.

För här är hävstången som gömmer sig i den siffran från Artificial Analysis. Att modellen använder 1,8× medianen för output-tokens på en fast uppsättning uppgifter innebär att en output-bunden loop kostar 1,8× vad enbart tokenpriset antyder. Och effort-reglaget är kontrollen för just det. Rapporter från communityt säger att steget från max ned till high ungefär halverar output-tokens – en långt större skillnad än vad peak/off-peak-schemat någonsin kan åstadkomma för dig. Effort-inställningen är den stora hävstången; schemat är den kostnadsfria.

Vilket är värt att känna till innan du schemalägger något: högtrafiktimmar är 01:00–04:00 och 06:00–10:00 UTC, måndag till fredag, och allt annat, inklusive helger, är lågtrafik. Ett europeiskt team som arbetar 09:00–18:00 CET når aldrig högtrafik. Ett team i Beijing som arbetar samma lokala tider hamnar i högtrafik från 09:00–12:00 och 14:00–18:00 — sju av nio arbetstimmar till dubbelt pris. Samma modell, samma kod, dubbelt så hög räkning, helt avgjort av tidszonen.

Den andra kostnadsfria besparingen är avgiften för cachad läsning, $0.003 per 1M mot $0.15 för ny indata — en femtiodel. Prompten för en kodagent är mestadels ett stabilt prefix: systeminstruktioner, verktygsdefinitioner, de delar av repot som inte ändras. Håll det stabila materialet först och låt det variabla innehållet följa efter, så sköter cachen på leverantörssidan resten. Om rabatterad cachad indata gäller, och på vilka villkor, bestäms av DeepSeek snarare än av klienten, så bekräfta det i aktuell dokumentation innan du bygger en budget på det — vår egen modellsida för code>deepseek/deepseek-v4.1-flash/code> säger samma sak, att avgiften för cachad indata följer leverantörens villkor.

Om du hellre vill slippa lägga till en andra prenumeration för att utvärdera modellen, finns samma id tillgängligt via en OpenAI-kompatibel endpoint framför hela vårt sortiment, till leverantörens pris med 0 % påslag — så en prisändring på DeepSeeks sida slår igenom här samma dag i stället för vid nästa omprissättning. Det spelar störst roll för precis den situation som den här artikeln beskriver: en modell med en dokumenterad benägenhet att fortsätta, på en väg som du inte har utvärderat färdigt. En fallback-kedja innebär att ett varv som går fel hamnar på en annan modell innan svaret börjar, i stället för att begäran misslyckas.

552B, 748B eller 763B – frågan om storleken är verkligen öppen

Upprepa inte ett parameterantal för den här modellen som fastställt, eftersom tre olika siffror är i omlopp och ingen av dem är helt enkelt fel.

DeepSeeks eget modellkort beskriver en modell med "552B ryggradsparametrar", och det är den leverantörsrapporterade siffran – den är också den siffra som anges i specpanelen på vår egen modellsida. Samma kort listar separat en "Engram conditional memory"-modul med 196B parametrar, "sparsamt åtkomlig via tokenbaserad uppslagning". Lägger man ihop de två får man 748B, vilket är den aritmetik som communityanalysen landade på inom timmar efter lanseringen. Och filmetadata i samma modellarkiv anger en modellstorlek på 763B parametrar, vilket är ännu en tredje siffra.

Den skenbara tvisten är en definitionsfråga snarare än en motsägelse. Uppslagsbaserade Engram-parametrar kostar minne men nästan ingen aritmetik per token, medan beräknade backbone-parametrar kostar tid för varje token — vilket är precis varför leverantören redovisar dem separat och varför en jämförelse av rubriksiffrorna för två modeller med olika arkitekturer säger dig väldigt lite.

Det som inte på allvar ifrågasätts är antalet aktiva parametrar: ungefär 8B per token under prefill och 16B under decode, vilket är det tal som faktiskt styr inferenskostnaden. Vikterna är öppna under en MIT-licens om du själv vill kontrollera något av detta. Betrakta 552B som leverantörsrapporterat, 748B som en trovärdig community-summering, och alla påståenden om att storleksfrågan är avgjord som förhastade.

Vad man ska göra före den 20:e

Om du ska prova DeepSeek V4.1 Flash i en kodagent är ordningen som slösar minst tid: välj ramverket först, lås sedan ansträngningen, mät sedan.

På harnessen är den ärliga sammanfattningen av dagens verifiering att alla tre vägarna fungerar och att de skiljer sig åt i vad de kräver av dig. OpenCode Go är en prenumeration på $10/månad med en kampanjmultiplikator som löper ut den 20 september, och uppsättningen är code>/connect/code> plus code>/models/code> utan någon fil att redigera. Command Code listar modellen live i sin egen katalog, byter med code>/model <id>/code>, och exponerar effort som ett förstklassigt kommando. Claude Code når det antingen via OpenCode Gos väg för validerade klienter – där ingen anpassad header-wrapper behövs – eller direkt mot DeepSeeks slutpunkt i Anthropic-format, där konflikten kring subagent-effort är den kända skavande kanten.

När det gäller effort: ange den uttryckligen och sätt den ganska lågt: high, eller modellens standardvärde om det visar sig vara high – och inte max. Bekräfta sedan att den lämnade din maskin, eftersom två harnessar visade sig tappa bort den.

Vid mätning: håll koll på utdatatokens i stället för väggklockan. Utförligheten är kostnaden, ansträngningsratten är kontrollen, och toppschemat är en tidszonsolycka som du kan undvika gratis.

Och vad gäller storlekspåståendena som du kommer att få se citerade för dig den här veckan – 552B, 748B, 763B – så är det användbara svaret att leverantören rapporterar sin backbone, communityn lägger till minnesmodulen och repository-metadatan säger något annat igen. Den som presenterar ett av dessa som det fastställda svaret har valt ett nummer i stället för att kontrollera ett.