DeepSeek V4 Pro 0813 è comparso sui listini di OpenRouter e nella documentazione dell’azienda cinese senza un comunicato, senza un post, senza nulla che assomigli a un lancio vero e proprio. Almeno al momento in cui scriviamo il pezzo. È la versione GA (general availability) del modello di punta della casa di Hangzhou, che con questa build esce definitivamente dalla fase di anteprima. La sigla nel nome segue la convenzione ormai consueta con cui DeepSeek etichetta le build in base alla data di compilazione, la stessa usata per le precedenti versioni della famiglia V3 e R1.
Sotto il cofano resta l’architettura mixture-of-experts su larga scala che DeepSeek ha scelto per l’intera famiglia V4: un design che attiva solo una parte dei parametri per ogni richiesta, tenendo bassi i costi di calcolo pur mantenendo un modello enorme sulla carta.
I numeri parlano chiaro: 1 milione di token di contesto, prezzo di 0,435 dollari per milione di token in input e 0,87 dollari per milione in output secondo la scheda tecnica pubblicata su OpenRouter. Il modello è ospitato da un unico provider, che inoltra le richieste in modo diretto senza dover scegliere fra alternative di routing. Nessuna cerimonia, nessun evento di lancio: solo una riga in più nei listini e una pagina di documentazione aggiornata.
Il vero salto è nelle API, non nel modello: DeepSeek V4 Pro esce dalla beta
In parallelo al rilascio di V4 Pro, DeepSeek ha aggiornato la propria Responses API per allinearla al formato usato da OpenAI, estendendo il supporto sia a deepseek-v4-flash sia a deepseek-v4-pro. Il motivo, dichiarato senza troppi giri di parole nella documentazione, è uno solo: intercettare la domanda generata da Codex, lo strumento di sviluppo agentico con cui OpenAI fa scrivere ed eseguire codice ai propri modelli direttamente da riga di comando o da editor.
In pratica basta puntare l’SDK OpenAI verso il base_url https://api.deepseek.com e sostituire lo slug del modello per far girare Codex CLI, l’app desktop di ChatGPT o l’estensione per VS Code sui server DeepSeek invece che su quelli di OpenAI. Lo streaming funziona con eventi tipizzati via SSE (response.output_text.delta, response.completed e simili) invece del classico messaggio di chiusura “[DONE]”.
Non tutto però è stato replicato: l’API resta stateless, quindi parametri come previous_response_id, conversation o store non sono supportati e ogni richiesta va costruita da zero lato client. Sono invece disponibili il function calling, la ricerca web eseguita lato server e il controllo dello sforzo di ragionamento. Fra gli strumenti personalizzati, DeepSeek ha scelto di abilitare solo apply_patch, il tool con cui Codex applica le modifiche al codice: una scelta che rivela quanto l’integrazione sia stata cucita su misura per quel singolo caso d’uso, più che per la compatibilità generale con le Responses API.
Non sappiamo quanto durerà la libertà di spostare Codex su un backend diverso da quello per cui è stato pensato: OpenAI non ha alcun obbligo di mantenere aperta questa porta, e la compatibilità di oggi potrebbe restringersi con un aggiornamento futuro. Per ora, però, il messaggio implicito è netto: DeepSeek non punta più solo a competere sui benchmark, ma a infilarsi negli strumenti di sviluppo costruiti da OpenAI stessa, presentandosi come backend alternativo a un clic dopo il cambio di un indirizzo API.