DeepSeeks V4-Pro-modell har flyttat in i praktiskt API-planeringsområde. Företagets nuvarande API-prisdokumentation listar DeepSeek-V4-Pro tillsammans med DeepSeek-V4-Flash, exponerad genom en bas-URL i OpenAI-format och en separat bas-URL i antropiskt format. Community-inlägg som citerar DeepSeeks ändringslogg säger att V4-Pro 0813-versionen rullades ut till app-, webb- och API-användare den 13 augusti.
Modellistan är känd för mer än tillgänglighet. DeepSeek-V4-Pro annonseras med en 1M-token kontextlängd och en maximal utdata på 384K tokens, plus JSON-utdata, verktygsanrop, chatprefix-kompletterande beta och FIM-kompletterande beta i icke-tänkande läge. För utvecklare som bygger agenter, kodverktyg, långa dokumentarbetsflöden eller hämtningstunga system, sätter dessa begränsningar V4-Pro i kategorin modeller som kan omforma snabb arkitektur snarare än att bara ersätta en mindre chattmodell.
Prissättningen är dock den verkliga operativa historien. DeepSeeks sida listar V4-Pro för $0,003625 per 1M cache-hit input tokens, $0.435 per 1M cache-miss input tokens och $0.87 per 1M output tokens. Den spridningen innebär att kostnaden för en förfrågan beror mycket på om upprepad kontext faktiskt träffar leverantörens cache. En arbetsbelastning som ser billig ut under optimistiska cache-antaganden kan bli mycket dyrare om uppmaningar är mycket varierande, dåligt segmenterade eller dirigeras genom verktyg som förhindrar återanvändning av cache.
Vad förändrades för API-användare
DeepSeeks dokumentation presenterar nu V4-Pro som en förstklassig API-modell med två utgångspunkter för Open AI-base-style och Open AI-URL: en slutpunkt i antropisk stil under en separat väg. Det är viktigt eftersom det sänker integrationsbarriären för team som redan använder OpenAI-kompatibla klienter samtidigt som det ger Claude-liknande klienter ett mer direkt formatalternativ.
För en AI API-gateway är det omedelbara arbetet vardagligt men viktigt: uppdatera modellkatalogen, uppdatera kontextfönster och metadata för maximal utdata, markera vilka funktioner som stöds, och bestäm hur de ska representera de två formaten. Att behandla ytan i OpenAI-format och Antropic-format som samma sak kan vara praktiskt för marknadsföringssidor, men det kan skapa förvirring i SDK:er, loggar och policykontroller. Utvecklare behöver veta vilket förfrågningsschema, verktygsanropsbeteende och streamingantaganden som gäller.
Den mycket stora utmatningsgränsen för annonsering förtjänar också uppmärksamhet. En maximal utgång på 384K-token är inte bara ett större antal i en tabell. Det ändrar fellägen. Team kan behöva strängare svarsgränser, faktureringsvarningar och skyddsräcken på applikationsnivå för att förhindra skenande generationer eller oavsiktliga dumpningar i långa former från att förvandla ett enda agentsteg till en materialkostnadshändelse.
Varför cache-hit-prissättning nu är viktigare
DeepSeek har länge förknippats med aggressiva API-priser. V4-Pro komplicerar den uppfattningen. Det angivna priset för cache-hit-inmatning är extremt lågt jämfört med dess cache-miss-ingångspris, men den skillnaden hjälper bara om en arbetsbelastning är utformad för cacheåteranvändning.
I praktiken beror cacheeffektiviteten på snabb stabilitet. Långa systemuppmaningar, policyblock, dokumentationspaket och arkivkontext kan gynnas när de återanvänds konsekvent. Men agentsystem muterar ofta uppmaningar i varje steg: lägger till loggar, verktygsutdata, tidsstämplar, mellanliggande planer och användarspecifikt tillstånd. Om dessa ändringar flyttar cachegränser eller gör att stora prefix missas, kan den effektiva kostnaden flytta sig närmare cache-miss-frekvensen.
Det är därför routingpolicyer inte bör rangordna V4-Pro med ett enda blandat indatapris. Kostnadssimulering bör separera cache-hit-inmatning, cache-miss-ingång och utmatningstoken och sedan testa representativa arbetsbelastningar. En kodningsagent som återanvänder en stor förvarssammanfattning kan bete sig mycket annorlunda än en kundsupportassistent som injicerar nytt kontotillstånd i varje förfrågan.
Det är också här Model Gate och liknande routinglager för flera modeller har en praktisk roll. Gateways som spårar tokenanvändning efter modell, team och API-nyckel kan hjälpa operatörer att se om en förment billig rutt faktiskt är billig i produktion. Det relevanta måttet är inte längre bara tokens per begäran; det är blandningen av cache-hit-indata, uncachad indata och genererad utdata över verklig trafik.
Vem påverkas
Utvecklare som använder DeepSeek direkt bör verifiera modellidentifierare, slutpunktsformat och kapacitetsflaggor innan de byter produktionstrafik. JSON-utdata och verktygsanrop är listade, men appbeteendet behöver fortfarande testas, särskilt om befintlig kod förlitar sig på en annan leverantörs edge-case-hantering.
Gateway-operatörer och plattformsteam har en bredare checklista.De behöver uppdaterade pristabeller, kontextgränser, maximala output-gränser, per-modell funktionsmetadata, budgetkontroller och dokumentation för både OpenAI-kompatibel och Anthropic-kompatibel åtkomst. Om de exponerar V4-Pro som en drop-in-modell, bör de fortfarande varna kunderna att likvärdig syntax för begäranden inte garanterar likvärdigt beteende eller kostnad.
Företag som kör automatisering med stora volymer bör se över antaganden om standardmodeller. En modell med ett 1M-token kontextfönster kan vara attraktiv för juridisk granskning, forskningssyntes, kodbasanalys och långvariga agenter. Men modeller med långa sammanhang tenderar att uppmuntra större uppmaningar, och större uppmaningar förstorar varje misstag i cachedesign och utdatakontroll.
Vad som förblir osäkert
Prissidan ger de aktuella listade priserna och funktionerna, men det finns fortfarande osäkerhet kring rapporterade framtida prisändringar. Community-inlägg säger att DeepSeek har varnat för en betydande API-prishöjning och att nya topp- och lågtrafikpriser kan träda i kraft den 16 augusti. Dessa påståenden är relevanta för budgetplanering, men den framtida tarifftabellen verifierades inte från ett direkt tillgängligt officiellt meddelande under forskningen.
Den osäkerhet borde göra teamen försiktiga snarare än frysta. Det vettiga svaret är att lägga till V4-Pro i utvärderingspooler, testa verkliga arbetsbelastningar, mäta cachebeteende och undvika att hårdkoda det som den permanenta standardinställningen för lägsta kostnad tills prissättningen har bekräftats. För vissa arbetsbelastningar kan V4-Pro vara ett utmärkt alternativ för långa sammanhang. För andra, särskilt utdatatunga agenter eller meddelanden med dålig cacheåteranvändning, kan ekonomin vara mindre gynnsam än rubrikens cacheträfffrekvens antyder.
Den bredare lärdomen är att modelltillgänglighet nu bara är den första routingfrågan. De svårare frågorna handlar om formatkompatibilitet, funktionstillförlitlighet, cachemekanik, utdatatak och kostnadsobserverbarhet. DeepSeek V4-Pro ger utvecklare ytterligare ett kraftfullt API-alternativ, men det klargör också att "billigt" har blivit en arbetsbelastningsspecifik slutsats, inte en leverantörsetikett.