Como migrar da OpenAI para o DeepSeek V4 Pro 0813 mudando só a base URL

Fala aí, beleza? Se o teu projeto já roda com o SDK da OpenAI, ele não precisa ser reescrito pra falar com o DeepSeek V4 Pro

A API do DeepSeek é compatível com esse mesmo SDK, então a migração se resume a três coisas: base URL, chave e nome do modelo

E o timing ajuda: a build 0813 saiu do preview e virou versão de produção (GA), disponível desde 12/08/2026

Neste post eu mostro a virada linha a linha e, principalmente, o que tu precisa reconferir DEPOIS dela, que é onde mora o trabalho de verdade

O que você precisa antes de migrar

Antes de abrir qualquer arquivo, três coisas na mesa:

• Um projeto já rodando com o SDK da OpenAI (é isso que torna a troca barata)
• Uma chave de API do DeepSeek
• A decisão de qual identificador vai entrar no código: deepseek-v4-pro ou deepseek-v4-flash

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Esses dois são os únicos nomes de modelo válidos hoje na API, então não tem meio termo aqui

Se tu ainda tá na dúvida sobre qual chamar em cada parte do sistema, vale ler qual usar em cada tarefa antes de fixar o nome

Tome cuidado com um detalhe de escopo: a API do DeepSeek não oferece endpoint de embeddings

A lista oficial de modelos traz só deepseek-v4-pro e deepseek-v4-flash, nada de embeddings

Ou seja: se teu projeto gera vetor pra busca semântica ou RAG, esse pedaço continua em outro provedor

A migração é do chat, não do pipeline inteiro, beleza?

Passo a passo da migração para o DeepSeek V4 Pro 0813

São dois passos no código, e é neles que moram as três trocas prometidas

Os exemplos abaixo estão em Python com o SDK da OpenAI, mas a ideia é a mesma em qualquer linguagem: tu só reconfigura o cliente

1. Trocar a base URL e a chave

É o coração da migração. O cliente continua sendo o mesmo, só aponta pra outro endereço

from openai import OpenAI

client = OpenAI(
    api_key="SUA_CHAVE_DEEPSEEK",
    base_url="https://api.deepseek.com"
)

O erro comum deste passo: inventar sufixo de versão na URL

A documentação oficial da API usa https://api.deepseek.com desse jeito, limpo, sem sufixo

Se tu tem uma variável de ambiente antiga com a URL da OpenAI hardcoded em algum lugar esquecido, é ali que a chamada vai continuar batendo no provedor velho e tu vai jurar que a migração falhou 🙂

2. Trocar o nome do modelo

Segundo ponto, e é literalmente uma string

resposta = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "user", "content": "Resuma este changelog em 3 linhas"}
    ]
)

O identificador deepseek-v4-pro já aponta pra build DeepSeek-V4-Pro-0813, então tu não precisa escrever a data em lugar nenhum

Basta usar deepseek-v4-pro pra acessar a versão mais recente

O erro comum deste passo: copiar nome legado de tutorial antigo

deepseek-chat e deepseek-reasoner foram descontinuados em 24/07/2026 e não respondem mais

E pronto: a migração acaba aqui, base URL, chave e nome do modelo

Depois da migração: os parâmetros que só existem no DeepSeek

Nada do que vem abaixo é necessário pra virar a chave

É o que passa a estar DISPONÍVEL depois da troca, mais um detalhe de formato na resposta que engana muita gente

Ligar (ou desligar) o modo de raciocínio

Aqui aparece o primeiro parâmetro que não existe no mundo OpenAI: o thinking

Como o SDK não conhece esse campo, ele vai via extra_body

resposta = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "user", "content": "Refatore esta função e explique o porquê"}
    ],
    extra_body={
        "thinking": {"type": "enabled"}
    }
)

Pra desligar, é o tipo disabled no mesmo lugar

O erro comum aqui: continuar mandando temperature e top_p achando que ainda mandam no resultado

No modo pensante esses parâmetros não são suportados. E o pior: definir eles não gera erro, só não tem efeito nenhum

Ajustar o esforço de raciocínio (se quiser)

Existe o reasoning_effort pra controlar quanto o modelo pensa antes de responder

O padrão é high, e tem o nível max, descrito como o de maior capacidade de raciocínio

resposta = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "Analise este plano de migração"}],
    extra_body={
        "thinking": {"type": "enabled"},
        "reasoning_effort": "max"
    }
)

O erro comum aqui: mexer nisso sem necessidade

Como o padrão já é high, na maior parte dos casos tu não precisa tocar em nada. Só sobe pra max quando a tarefa realmente pede mais cabeça

Tratar o reasoning_content na resposta

Esse é o detalhe que a galera esquece e depois passa a tarde debugando, e ele só aparece se tu ligou o modo pensante

Nesse modo, o conteúdo do raciocínio vem em reasoning_content, no MESMO nível de content

msg = resposta.choices[0].message

raciocinio = getattr(msg, "reasoning_content", None)
texto = msg.content

print(raciocinio)
print(texto)

Se tu reenviar o reasoning_content de volta no histórico da conversa, ele é ignorado

O erro comum aqui: tratar a resposta como se ela tivesse só content e concluir que "o modelo não raciocinou"

Ele raciocinou, teu parser é que não olhou o campo novo 😀

O que continua igual e o que você precisa reconferir

A parte boa da compatibilidade é que a maior parte do teu código nem percebe a troca

A parte que exige atenção é curta, mas é justamente onde o silêncio engana

E tem ainda duas base URLs alternativas que valem conhecer antes de tu sair configurando:

• https://api.deepseek.com/beta pra funcionalidades beta
• https://api.deepseek.com/anthropic pro formato compatível com a API da Anthropic

Nesse endpoint da Anthropic o mapeamento é direto: nomes claude-opus viram deepseek-v4-pro, e claude-sonnet e claude-haiku viram deepseek-v4-flash

Massa pra quem tem os dois formatos convivendo no mesmo produto

Erros comuns depois da virada (e como resolver)

O modelo simplesmente não responde

Sintoma: a chamada sai, mas nada útil volta e o pipeline quebra logo depois

Causa: nome legado no código. deepseek-chat e deepseek-reasoner foram descontinuados em 24/07/2026

Solução: trocar pelo identificador explícito, deepseek-v4-pro ou deepseek-v4-flash, que são os únicos que respondem hoje

Os parâmetros de amostragem não mudam nada

Sintoma: tu mexe em temperature, mexe em top_p, e a saída continua igualzinha

Causa: no modo pensante esses parâmetros não são suportados, junto com presence_penalty e frequency_penalty

Solução: parar de calibrar o que não tem efeito ali. Como definir esses campos não gera erro, o sistema fica mudo e tu perde tempo achando que é problema de prompt

Um parâmetro foi enviado e ninguém avisou que ele sumiu

Sintoma: o cliente conectou de primeira na Responses API, tudo lindo, mas um comportamento específico não acontece

Causa: na Responses API os parâmetros não suportados são ignorados silenciosamente, sem erro. É exatamente isso que permite plugar cliente existente sem modificação

Solução: validar o comportamento pela RESPOSTA, não pela ausência de exceção. Silêncio ali não é sinal de sucesso

O trecho de embeddings quebrou

Sintoma: a parte de chat migrou lisa, e a indexação parou

Causa: não existe modelo de embeddings na API do DeepSeek

Solução: isolar o que não é chat e deixar essa chamada apontando pro provedor antigo

A prevenção pros quatro casos é a mesma receita: fixa o identificador explícito, valida a resposta em vez de confiar no silêncio, e separa no código o que é chat do que não é

Quando essa troca compensa (e quando não)

O argumento mais direto é preço somado a janela de contexto

O deepseek-v4-pro está hoje em US$ 0,435 por 1 milhão de tokens de entrada em cache miss, US$ 0,003625 por 1 milhão em cache hit e US$ 0,87 por 1 milhão de tokens de saída

Junta isso com 1.000.000 de tokens de contexto e tu tem um cenário confortável pra quem manda base de código inteira ou documento gigante na chamada

No índice de inteligência do Artificial Analysis, o DeepSeek V4 Pro 0813 (max) aparece com 53 pontos, e se tu quer entender melhor como escolher entre as variantes antes de decidir, o assunto rende post próprio

Aviso de calendário, e esse é importante: novos preços entram em vigor às 16:00 UTC de 16/08/2026

A cobrança passa a ter horário de pico e fora de pico, sendo o fora de pico pela metade do valor de pico

As janelas de pico são 01:00 às 04:00 e 06:00 às 10:00 UTC

Vale ter isso no radar se tu roda job pesado em horário fixo

Pra dar contexto do que tu tá chamando: o V4 Pro é uma arquitetura de mistura de especialistas (MoE) com 1,6 trilhão de parâmetros totais e 49 bilhões ativos por token, pré-treinado em mais de 32 trilhões de tokens

Insano, né?

Agora, quando NÃO compensa: se teu produto é basicamente um pipeline de embeddings com um chatzinho em cima, a migração te dá dor de cabeça e pouco ganho

Sem endpoint de embeddings, tu vai manter dois provedores no ar de qualquer jeito, e aí a conta muda de figura

Conclusão

A virada pro DeepSeek V4 Pro 0813 é de configuração, não de reescrita

Base URL, chave e nome do modelo, e teu código de chat já tá conversando com outro provedor

O trabalho de verdade é a reconferência: o campo reasoning_content que aparece no modo pensante, os parâmetros de amostragem que somem ali, o parâmetro ignorado sem aviso e o pedaço de embeddings que não tem pra onde ir

Próximo passo concreto: migra um ambiente de teste primeiro, roda as chamadas de tool calling, confere a resposta campo a campo, e só depois encosta em produção

E deixa a data de 16/08/2026 anotada, porque a conta muda ali…

até o próximo post! 😀