DeepSeek V4 pareggia Opus 4.6 a un decimo del prezzo: come migrare l'80% del tuo workload Claude

Un piccolo team che fa girare un coding agent interno su Claude Opus 4.7 ha visto la bolletta Anthropic mensile superare i 1.200 dollari ad aprile 2026. L'agent faceva lavoro utile: code review, proposte di refactor, generazione di documentazione. Ma forse il 70% delle chiamate non era il tipo di lavoro che richiedesse un modello frontier. Classification, extraction, summarization, structured generation. Cose che Opus 4.6 nel 2025 gestiva senza problemi, prima che tutti facessero l'upgrade.

Il 24 aprile 2026 DeepSeek ha rilasciato V4. V4-Pro fa 80,6 su SWE-bench Verified, statisticamente alla pari con l'80,8 di Opus 4.6 [1]. Non è un frontier-killer. Opus 4.7 è ancora in testa a 87,6, e sui task agentic difficili il gap si vede [2]. Ma V4-Pro raggiunge la qualità del frontier dell'anno scorso a circa 1/10 del prezzo: 1,74 $per milione di input token contro i 15$ di Opus 4.7, 3,48 $in output contro 75$ [1][3].

Per i solo dev e i piccoli team che hanno messo tutto su Opus 4.7 perché era più semplice, è il momento di splittare il workload. Tieni il modello frontier per il 20% di chiamate che davvero hanno bisogno di ragionamento frontier. Sposta l'altro 80% su V4. La matematica ti dà gran parte della riduzione 10× sui costi senza riscrivere lo stack da zero.

Questa guida ricostruisce la migrazione: cosa tenere, cosa spostare, cosa si rompe nei prompt, e come fare l'audit del tuo traffico per trovare i candidati.

Cosa è davvero V4

DeepSeek V4 esce in due varianti, entrambe con context window da 1M token e weights aperti sotto licenza MIT [1]:

V4-Pro. 1,6T parametri totali in architettura Mixture-of-Experts, 49B attivi per token. Il flagship. Hosted a 1,74 $input / 3,48$ output per milione di token sull'API ufficiale di DeepSeek [3]. Self-hostable per team con il GPU budget.

V4-Flash. 284B totali / 13B attivi. La variante efficient-tier. 0,14 $input / 0,28$ output per milione di token. Circa 50× più economica di Opus 4.7 in input, 270× in output [3]. Disegnata per classification ed extraction ad alto volume.

Entrambe condividono tre reasoning mode che l'ecosistema Anthropic non ha in modo diretto [1]:

• Non-Think. Risposte rapide, intuitive. Equivalente a una chiamata Anthropic a low-effort. Per task di routine in cui vuoi velocità di completion e non hai bisogno di deliberazione.
• Think High. Analisi logica conscia. Il default per il lavoro non banale. Approssimativamente equivalente a effort: high di Anthropic.
• Think Max. Capacità di reasoning piena. Confrontabile con effort: xhigh di Anthropic. Richiede un'allocazione minima di context window di 384K.

Il confronto benchmark che conta per la migrazione:

V4-Pro essenzialmente pareggia Opus 4.6 su SWE-bench, il benchmark più rilevante per i team di coding, e batte GPT-5.5 su Codeforces [1]. È 7 punti sotto Opus 4.7 su SWE-bench, cosa che conta per gli agentic loop difficili ma non per il grosso del lavoro quotidiano.

L'economia

Il numero in headline è "10× più economico" ma il dettaglio è più utile. Per un workload tipico di volume medio dove l'output è circa il 30% dell'input in token:

• Opus 4.7: 15 $× 0,7 + 75$ × 0,3 = 33 $ blended per milione di token
• V4-Pro: 1,74 $× 0,7 + 3,48$ × 0,3 = 2,26 $ blended per milione di token
• V4-Flash: 0,14 $× 0,7 + 0,28$ × 0,3 = 0,18 $ blended per milione di token

È una riduzione di 14,6× passando da Opus 4.7 a V4-Pro, e una riduzione di 183× passando a V4-Flash per i workload che stanno nel ceiling di capacità di Flash.

Per un piccolo team che paga 1.200 $/mese su Opus 4.7, con l'80% del traffico che si sposta su V4-Pro e il 20% che resta su Opus 4.7, la nuova bolletta è circa:

• 20% su Opus 4.7: 240 $
• 80% su V4-Pro: 66 $
• Nuovo totale: ~306 $/mese

Una riduzione del 75% senza perdere qualità sul lavoro che conta. I risparmi si compongono quando classification o extraction ad alto volume vengono offloadati su Flash, dove la differenza di 183× rende il batch processing economicamente trasformativo.

Cosa resta su Opus 4.7 (il 20%)

Tre categorie di lavoro giustificano il modello frontier:

Agentic coding loop difficili. Refactor multi-step, cambi architetturali cross-file, debug in codebase che non conosci. Il gap di 7 punti su SWE-bench si concentra in task in cui l'agent deve pianificare, ritentare e ragionare sullo stato. Anche il literal instruction following di Opus 4.7 [2] qui conta, perché i prompt agentic codificano contratti stretti.

Decisioni con downside elevato. Codice che va in produzione, contratti che vanno ai clienti, qualunque cosa in cui una risposta sbagliata costa più della differenza di costo del modello. I 30 $ marginali risparmiati non valgono il rischio di una regressione.

Reasoning long-horizon. Task che attraversano molti step e richiedono al modello di mantenere un mental model coerente fra essi. V4 è buono ma la profondità di reasoning di Opus 4.7 sulle catene complesse è ancora lo state of the art.

Se il tuo lavoro è in queste categorie, non migrare. Il costo è reale ma anche la penalità di qualità è reale.

Cosa si sposta su V4 senza problemi (l'80%)

La maggior parte del traffico di produzione nei workflow small-team rientra in categorie dove V4-Pro o V4-Flash performa al livello del frontier o vicino:

Structured extraction. Tirare fuori JSON da documenti, normalizzare entità, parsare input semi-strutturato. V4-Flash gestisce bene questo a 0,14 $/MTok, spesso 100× più economico di Opus 4.7 sullo stesso lavoro. Struttura il prompt con schema rigoroso ed esempi e il gap rispetto al frontier si chiude.

Classification e routing. Topic classification, sentiment, intent detection, triage di support ticket. Questi task erano un cattivo uso di Opus 4.7 in partenza. V4-Flash è lo strumento giusto, e i prompt non hanno quasi bisogno di cambiare.

Summarization e templating. Bozze di email, summarization di documenti, generazione di report da input strutturato. V4-Pro gestisce templating long-form a qualità vicina al frontier. La context window 1M è la stessa.

Coding task mid-context. Generare test per una funzione, scrivere un refactor single-file, spiegare codice che non conosci, estrarre interfacce. V4-Pro su Think-High mode produce output che fa score paragonabile a Opus 4.7 su questi task delimitati.

Tool-use orchestration in cui ogni step è semplice. Se il tuo agent loop è "chiama un tool, parsi il risultato, decidi il prossimo tool", e ogni decisione individuale è poco profonda, V4-Pro gestisce l'orchestrazione senza pagare il premium frontier.

L'80/20 è approssimativo. Alcuni team troveranno che il loro split è 70/30. Pochi troveranno che è 90/10. La audit recipe qui sotto ti dice come misurare il tuo.

Cosa si rompe nella migrazione dei prompt

Cinque cose specifiche cambiano quando swappi Anthropic per DeepSeek V4. Nessuna è un dealbreaker ma tutte vanno gestite.

1. Chat template diverso

V4 usa un formato di encoding custom documentato nel modulo encoding_dsv4 distribuito col model card [1]. Non è OpenAI-compatible di default, e il formato delle tool-call diverge da Anthropic. Se usi l'API ufficiale DeepSeek, il wrapper gestisce questo. Se ti self-hosti con vLLM o SGLang, chiami gli helper di encoding direttamente:

from encoding_dsv4 import encode_messages

messages = [
    {"role": "user", "content": "Refactor this function..."},
]
prompt = encode_messages(messages, thinking_mode="thinking")

I prompt che hardcodano sintassi Anthropic-specific (per esempio tag <thinking>, blocchi cache_control) vanno puliti prima di passarli a V4.

2. I reasoning mode rimpiazzano il parametro effort

Il parametro effort di Anthropic non esiste su V4. Al suo posto scegli un reasoning mode al request time. La mappatura che funziona in pratica:

• Anthropic effort: low → V4 Non-Think
• Anthropic effort: high → V4 Think High
• Anthropic effort: xhigh → V4 Think Max

Un prompt che funzionava su effort: high molto probabilmente funzionerà su Think High. Migra il mode tag in lockstep con il prompt.

Nota che Think Max richiede un'allocazione minima di context window di 384K [1], cosa che ha implicazioni di costo anche per prompt corti. Usa Think High di default e tira fuori Max solo sul reasoning difficile.

3. Sampling settings diversi

Opus 4.7 rifiuta temperature, top_p e top_k direttamente [2]. V4 se li aspetta, con il setting raccomandato temperature=1.0, top_p=1.0 [1]. Se hai stripped i parametri di sampling dal tuo client Anthropic, devi rimetterli quando chiami V4.

Non assumere che i default di sampling di Opus 4.6 si portino dietro. Il training è diverso.

4. Niente cache-control nativo

Il campo cache_control di Anthropic è Anthropic-specific. V4 ha il suo comportamento di caching al livello di inference (l'architettura Hybrid Attention riduce il KV cache al 10% di V3.2 per 1M context [1]), ma non c'è una direttiva equivalente prompt-level per dichiarare i prefix cached.

Se il tuo workflow dipendeva dal prompt caching di Anthropic per l'ottimizzazione dei costi, la matematica della migrazione cambia. Fai i conti su V4-Pro senza caching contro Opus 4.7 con caching. V4-Pro spesso vince comunque in costo assoluto, ma il gap si stringe per workload con cache hit elevato.

5. Refusal pattern diversi

Il training RLHF di V4 produce un refusal profile diverso da Opus 4.7. Alcuni prompt che Anthropic rifiuta ottengono una risposta normale su V4. Alcuni che V4 rifiuta ottengono una risposta normale su Anthropic. La maggior parte dei prompt di produzione passa entrambi, ma se hai workflow content-sensitive, regression-test la migrazione con cura.

La audit recipe (5 step)

Questo è un workflow pratico per identificare i candidati alla migrazione senza triage manuale caso per caso.

Step 1: tagga ogni prompt per categoria. Classifica ogni prompt di produzione come una di: extraction, classification, summarization, templating, mid-context coding, hard reasoning, o agentic loop. Tagga nel tuo tool di prompt management o in uno spreadsheet.

Step 2: fai score di ogni prompt su Opus 4.7 con KMP. Esegui uno score di qualità strutturale. Annota lo score prima di qualsiasi modifica di migrazione. È la tua baseline.

Step 3: migra il tag in volume più alto su V4. Scegli la categoria con più chiamate al mese (di solito classification o extraction per i piccoli team). Riscrivi il prompt per V4: rimuovi sintassi Anthropic-specific, swappa il mode tag, aggiungi i sampling settings, usa il chat template di V4.

Step 4: fai score della versione V4 e una eval side-by-side. Usa 50 input rappresentativi e controlla l'output V4 contro l'output Opus 4.7. Se la differenza di score è entro 0,3 punti e l'eval mostra qualità accettabile, la migrazione tiene.

Step 5: ripeti per la prossima categoria. Una volta che una categoria è migrata, passa a quella di volume più alto successiva. Fermati quando le categorie rimanenti sono chiaramente nel bucket "stays on frontier".

La maggior parte dei team converge sul loro split finale entro 2-3 settimane di questo loop.

Esempio pratico: migrazione di un prompt di classification

Ecco un prompt di classification tipico prima e dopo la migrazione. Il task: classificare support ticket per urgenza.

Prima (Claude Opus 4.7):

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=200,
    system=[{
        "type": "text",
        "text": "You are a support ticket classifier. Output JSON.",
        "cache_control": {"type": "ephemeral", "ttl": "1h"}
    }],
    messages=[{"role": "user", "content": ticket}]
)

Dopo (DeepSeek V4-Flash):

from encoding_dsv4 import encode_messages

messages = [
    {"role": "system", "content": "You are a support ticket classifier. Output JSON."},
    {"role": "user", "content": ticket}
]
prompt = encode_messages(messages, thinking_mode="non-thinking")

response = deepseek_client.completions.create(
    model="deepseek-v4-flash",
    prompt=prompt,
    max_tokens=200,
    temperature=1.0,
    top_p=1.0
)

Cinque cambiamenti: rimosso cache_control, switch del chat template, set del thinking mode a non-thinking (la classification non ha bisogno di reasoning), aggiunti i parametri di sampling, e cambiato l'API client. Il contenuto del prompt è identico.

Per 100.000 ticket/mese a circa 200 input token e 20 output token ciascuno, il costo passa da circa 450 $su Opus 4.7 a 3,50$ su V4-Flash. Una riduzione di 130× su una categoria che non beneficia comunque di reasoning frontier.

Cosa significa se usi Keep My Prompts

La migrazione è per lo più meccanica una volta che sai quali prompt migrare. La parte difficile è l'audit: sapere quali prompt fanno reasoning vero contro quali fanno classification poco impegnativa vestita da wrapper di un modello frontier.

Un prompt che fa score sopra 4,0 sulla qualità strutturale è quasi sempre portabile a V4-Pro. La struttura porta il comportamento del modello, non il modello in sé. Un prompt che fa score sotto 3,0 è fragile su qualunque modello. Aggiusta la struttura prima, poi migra.

Score i tuoi prompt su keepmyprompts.com, taggali per modello target, e guarda la migrazione diventare una checklist invece di un progetto.

Fonti

[1] DeepSeek-AI, "DeepSeek-V4-Pro" model card su Hugging Face, aprile 2026. https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro

[2] What's new in Claude Opus 4.7, documentazione ufficiale Anthropic, aprile 2026. https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7

[3] Documentazione API DeepSeek, "DeepSeek V4 Preview Release," 24/04/2026. https://api-docs.deepseek.com/news/news260424