🎁 Novità Registrati gratis, 10 chiamate le offriamo noi. Fino a $1, senza carta.

Claude Sonnet 5 vs DeepSeek V4 Pro

vs

Quale scegliere e quando — verdetto curato, non una tabella di benchmark

Entrambi condividono una finestra da 1,000,000 token e coprono chat, codice, ragionamento e strumenti, quindi la differenza è modalità e costo: claude-sonnet-5 accetta input immagine oltre al testo ed espone una capacità di pensiero, mentre deepseek-v4-pro è solo testo ma consente fino a 393216 token di uscita contro i 128000 di Sonnet. Sul listino deepseek-v4-pro costa meno ovunque — $1.608 contro $2 in ingresso, $3.216 contro $10 in uscita (circa 3.1x in meno) e $0.0134 contro $0.2 sulle letture di cache (circa 15x in meno). Scegli claude-sonnet-5 quando ti servono immagini o un pensiero commutabile; scegli deepseek-v4-pro per generazioni testuali lunghe a spesa inferiore.

Prezzi

Claude Sonnet 5 DeepSeek V4 Pro Δ
Input / 1M token $2 $1.608 1.2×
Output / 1M token $10 $3.216 3.1×
Lettura cache / 1M token $0.2 $0.0134 15×
Scrittura in cache 1.25x (5m) / 2x (1h) nessun addebito separato

Le tariffe provengono dal catalogo live al momento della build; la pagina di ciascun modello riporta la scheda attuale.

Dove si posizionano — prezzo di input per 1M di token rispetto a tutti gli 63 modelli chat con questa unità di fatturazione (scala logaritmica)

$0.05 · Qwen3 VL Flash $30 · GPT-5.4 Pro

Capacità

Claude Sonnet 5 DeepSeek V4 Pro
Utilizzo dei tool
Controllo del ragionamento configurabile configurabile
Output strutturato
Prompt caching esplicito (contrassegni il prefisso) implicito (automatico)
Durata della cache 5m default, 1h option no fixed TTL (evicted when unused)
Prefisso minimo in cache 1024 token non pubblicato

Specifiche

Claude Sonnet 5 DeepSeek V4 Pro
Modalità di input testo immagine testo
Modalità di output testo testo
Rilascio 2026-06-30 2026-04-24
Cutoff di conoscenza 2026-01
Finestra di contesto 1M 1M
Output massimo 128K 393K
Parametro thinking
  • thinking.type "adaptive"
  • output_config.effort
  • thinking.type
  • reasoning_effort
Valori accettati
thinking.type
  • adaptive
  • disabled
effort
  • low
  • medium
  • high
  • xhigh
  • max

"enabled" returns 400

thinking.type
  • enabled
  • disabled
reasoning_effort
  • high
  • max (low and medium map to high, xhigh maps to max)
Predefinito

thinking on (adaptive)

effort
  • high

enabled, with reasoning_effort high

some complex agent requests are automatically set to max

Le specifiche sono trascritte dalla documentazione di ciascun fornitore; una riga che un fornitore non pubblica viene omessa anziché essere dedotta. Fonti complete: Claude Sonnet 5 · DeepSeek V4 Pro

Un solo prompt, entrambi i modelli — misurati attraverso il gateway

PROMPT Explain to a CFO, in exactly three sentences, why our LLM bill doubled after we enabled reasoning. VERIFICA esattamente 3 frasi

Claude Sonnet 5 superato · 3 sentences

Reasoning mode works by having the model generate extended internal "thinking" steps before producing its final answer, and since we're billed on total tokens, that hidden reasoning text adds significantly to what we pay for—even though you never see it in the output. This is different from simply getting longer visible responses; the model is essentially "showing its work" behind the scenes, and complex prompts can trigger thousands of extra reasoning tokens per request. The upside is improved accuracy on complex tasks, but if we want to control costs, we should selectively enable reasoning only for queries that truly need it, rather than applying it universally.

out 194 tok latenza 4.3 s

DeepSeek V4 Pro superato · 3 sentences

Enabling reasoning causes the model to generate a lengthy internal chain‑of‑thought before it delivers a visible answer, and we are billed for every one of those hidden reasoning tokens just as we are for the final output. In most interactions, the volume of these unseen tokens at least equals the visible response, effectively doubling the total tokens consumed per query. That doubled token consumption translates directly into a doubled per‑query cost, which is why our overall LLM bill doubled.

out 641 tok (+545 ragionamento) latenza 11.5 s

Rispetto dell'istruzione (esattamente tre frasi — contabili), adattamento al pubblico (registro da CFO), e il divario di fatturazione del pensiero nascosto che i contatori di token qui sotto rivelano.

PROMPT This function is supposed to return the longest run of consecutive equal items, but callers report it is off by one on single-element inputs and misses runs that end at the last index. Fix it and explain the bug in one paragraph. VERIFICA la correzione supera i test

Claude Sonnet 5 superato · 8/8 cases

## The Bug The function has two related off-by-one issues rooted in the same cause: `cur` and `best` are initialized to `0` instead of `1`, treating run lengths as the number of *matches* between adjacent elements rather than the number of *elements* in the run. This means a single-element input never enters the loop (since `range(1, 1)` is empty) and returns `0` instead of the correct answer of `1`. It also means that for any input, the run length is undercounted by exactly one — a run of 3 equal elements only produces 2 "match" increments, so `best` ends up as 2 instead of 3. The claim that it "misses runs that end at the last index" is actually a symptom of this same undercount: the logic does update `best` correctly on every iteration (including the last), but because it's counting matches instead of elements, the final reported value is always one less than the true longest run. […]

out 536 tok latenza 7.1 s

DeepSeek V4 Pro superato · 8/8 cases

```python def longest_run(xs): if not xs: return 0 best = 1 cur = 1 for i in range(1, len(xs)): if xs[i] == xs[i - 1]: cur += 1 best = max(best, cur) else: cur = 1 return best ``` **Explanation:** The bug stems from initializing `cur = 0` and only incrementing it when two adjacent elements match, which counts the number of *additional* equal elements rather than the actual run length (which is `cur + 1`). As a result, the returned `best` is always one less than the true longest run—most obviously returning 0 for a single-element list instead of 1. […]

out 2418 tok (+2131 ragionamento) latenza 35.6 s

Se la correzione è davvero giusta (eseguibile), la densità della spiegazione, e l'efficienza in token su un compito delimitato.

PROMPT Extract a JSON object with fields {company, quarter, revenue_usd_m, growth_pct, guidance} from this text. Use null for anything not stated; add no other fields. VERIFICA JSON valido, schema esatto

Claude Sonnet 5 superato · 5/5 fields, guidance null

```json { "company": "Meridian Robotics", "quarter": "Q3", "revenue_usd_m": 412, "growth_pct": 11.5, "guidance": null } ```

out 348 tok latenza 5.3 s

DeepSeek V4 Pro superato · 5/5 fields, guidance null

{ "company": "Meridian Robotics", "quarter": "September quarter", "revenue_usd_m": 412, "growth_pct": "eleven and change", "guidance": null }

out 1204 tok (+1153 ragionamento) latenza 19.9 s

Aderenza allo schema (nessun campo inventato), pressione di allucinazione (guidance è esplicitamente sospesa), e differenze nel percorso di output strutturato.

PROMPT Write a 120-word product announcement for an API gateway feature that caches prompts across providers. Forbidden words: "seamless", "unlock", "game-changer", "revolutionize", "empower". Exactly one sentence must be a question. VERIFICA 120 parole, 0 parole vietate

Claude Sonnet 5 superato · 123 words, 0 banned, 1 question

## Introducing Cross-Provider Prompt Caching We're rolling out a new caching layer for our API gateway that works across every major LLM provider you connect through it. Instead of resending identical prompts and paying full price each time, the gateway recognizes repeated requests and serves cached responses in milliseconds—regardless of whether you're routing to OpenAI, Anthropic, or Google. What does this mean for your bill and your latency? Both drop, often significantly, especially for teams running high-volume, repetitive workloads like customer support bots or batch content generation. The cache is configurable per route, with adjustable TTLs and invalidation rules, so you stay in control of freshness versus cost. Available now for all Pro and Enterprise plans. Check your dashboard to enable it today.

out 259 tok latenza 4.8 s

DeepSeek V4 Pro nessuna risposta da valutare · no answer text within 16,384 tokens (all of it went to thinking)

Il modello non ha restituito alcun testo di risposta — l'intero budget di token è stato speso per il ragionamento nascosto.

out 8193 tok (+8192 ragionamento) latenza 106.2 s

Rispetto dei vincoli (budget di parole, elenco di parole vietate, l'unica domanda), impronta stilistica, e controllo della lunghezza.

Passa dall'uno all'altro con una sola riga

Entrambi gli id sono presenti in ogni scheda qui sotto — la coppia di righe evidenziata è l'unica modifica. Stesso endpoint, stessa chiave, stessa struttura della richiesta.

from openai import OpenAI

client = OpenAI(
    base_url="https://synthorai.io/v1",
    api_key="sk-syn-...",
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    # model="deepseek-v4-pro",  # decommenta questa riga, commenta quella sopra
    messages=[{"role": "user", "content": "Summarize this diff"}],
    reasoning_effort="medium",
)
print(resp.choices[0].message.content)

Ottieni una chiave API →

FAQ

Qual è più economico, Claude Sonnet 5 o DeepSeek V4 Pro?

DeepSeek V4 Pro è più economico per input / 1m token ($1.608 contro $2, 1.2× di differenza). Altre righe potrebbero indicare il contrario — la tabella sopra riporta la scheda completa, e il costo reale dipende dal tuo mix.

Posso fare un A/B test di Claude Sonnet 5 contro DeepSeek V4 Pro senza due integrazioni?

Sì. Entrambi sono serviti tramite lo stesso endpoint compatibile con OpenAI con una singola chiave API — il passaggio richiede la modifica della stringa del modello in una sola riga, quindi puoi instradare una frazione del traffico verso ciascuno e confrontare direttamente le fatture.

Claude Sonnet 5 e DeepSeek V4 Pro supportano il prompt caching?

Sì — entrambi fatturano le letture in cache a un prezzo inferiore rispetto alla loro tariffa di input, quindi i carichi di lavoro con warm-prefix costano meno di quanto suggeriscano le tariffe di listino. Le righe esatte per la lettura in cache si trovano nella tabella dei prezzi qui sopra.

Confronti correlati

Dai nostri studi misurati