# O que muda ao migrar solicitações do OpenRouter para outra API compatível com OpenAI? > Trocar a URL base e a chave é apenas o primeiro passo ao sair do OpenRouter. Campos padrão costumam migrar, mas IDs de modelos, headers e extensões de roteamento do OpenRouter, fallbacks, streaming, contabilidade, entradas multimodais, erros e limites devem ser testados por um adaptador. # O que muda ao migrar solicitações do OpenRouter para outra API compatível com OpenAI? Para chat básico, a migração pode começar com nova URL base, chave e ID do modelo. Produção envolve mais: roteamento, headers, slugs, fallbacks, metadados e seleção de provedor do OpenRouter exigem substitutos, e streaming e ferramentas precisam de testes de contrato. Compatibilidade com OpenAI é um dialeto de transporte, não promessa de catálogos, extensões, faturamento ou operação idênticos. ## Inventarie o contrato real Procure no código, configuração e logs cada campo enviado ao OpenRouter. Sua configuração documentada usa `https://openrouter.ai/api/v1`, bearer auth e headers opcionais de atribuição, além de possíveis extensões de rota. Crie o inventário: | Superfície | Geralmente portátil | Exige revisão | |---|---|---| | Chat | `messages`, temperature, limite de saída | Parâmetros e padrões | | Modelos | Intenção do app | Slug específico | | Ferramentas | Nome e schema JSON | Paralelismo, strict e streaming de argumentos | | Roteamento | Nenhum | Preferências, fallbacks, transforms | | Headers | Autorização | Atribuição e metadados do OpenRouter | | Uso | Tokens | Custo, cache e consulta da solicitação | | Operação | Famílias HTTP | Limites, tentativas, tempo e erros | ## Introduza primeiro um adaptador Não espalhe URL e slugs pelo código. Encapsule diferenças e exponha aliases do aplicativo. ```python from openai import OpenAI def make_client(base_url: str, api_key: str) -> OpenAI: return OpenAI(base_url=base_url, api_key=api_key) MODEL_MAP = { "coding_default": { "openrouter": "provider/model-slug", "target": "target-model-id", } } ``` O adaptador deve traduzir campos, normalizar erros e emitir eventos comuns. ## Substitua semântica de modelos e rotas IDs não são padronizados. Mapeie cada alias ao modelo de destino e verifique contexto, ferramentas, saída estruturada, modalidades e preço no catálogo atual. O destino pode expressar rotas e fallbacks de outro modo. Decida se os recria no orquestrador, usa o roteador de destino ou remove. Mudança silenciosa altera custo e qualidade. ## Remova ou traduza extensões do OpenRouter Revise headers e campos específicos. Headers opcionais de atribuição geralmente podem sair; preferências, arrays de fallback, plugins, transforms e metadados precisam de mapeamento explícito. Nos testes, rejeite extensões desconhecidas. Ignorá-las silenciosamente esconde mudanças. ## Teste ferramentas e streaming por contrato Teste: * aceitação de nome e JSON schema; * modos de tool choice e paralelismo; * eventos incrementais de argumentos; * motivos de término e recusas; * argumentos inválidos e novas tentativas. Compare eventos analisados, não chunks brutos. Inclua cancelamento, erros no meio, uso final, deltas vazios e reconexão. ## Reconstrua a contabilidade O OpenRouter documenta metadados com modelo, provedor, tokens e custo total. O destino pode retornar uso na resposta, oferecer consulta separada ou exigir preços no cliente. Normalize no ledger: ```json { "request_id": "internal_123", "provider_request_id": "external_456", "gateway": "target", "model": "resolved-model-id", "input_tokens": 1200, "output_tokens": 340, "cost_usd": 0.0123 } ``` Separe estimativas e cobranças conciliadas. Reavalie limites antes de migrar agentes de produção. ## Verifique solicitações multimodais Imagem, áudio e vídeo dependem de modelo e endpoint. Dois gateways podem diferir em partes de conteúdo, upload, URL, jobs assíncronos e resultados. Crie fixtures por modalidade. Sucesso em texto não comprova compatibilidade de mídia. ## Teste o comportamento operacional Meça headers de limite, códigos repetíveis, timeouts, fila, região, idempotência, logs e suporte. Use a documentação atual do destino. Uma implantação prática tem quatro portas: 1. Repetir um conjunto de referência offline. 2. Rodar tráfego seguro em sombra. 3. Fazer canary com pouco tráfego de baixo risco. 4. Expandir apenas se erros, latência, custo e asserções cumprirem os limites. Mantenha rollback simples até testar carga representativa. ## Decida se consolidar compensa OpenRouter continua adequado quando seu catálogo de LLMs e roteamento atendem ao produto. Atlas Cloud pode ser atraente quando uma relação compatível com OpenAI para texto, imagem e vídeo simplifica a pilha. Nenhuma vantagem substitui testes. Decida por requisitos medidos, não pelo menor diff. ## Em resumo Mude a configuração e audite cada suposição não padrão de modelos, rotas, ferramentas, streaming, uso e operação. Um adaptador com testes de referência mantém a migração reversível e evita que uma solicitação válida esconda regressão semântica. ## FAQ ### Posso migrar do OpenRouter mudando apenas base_url e api_key? Às vezes para chat simples, mas integrações de produção costumam depender de slugs, opções de rota, headers, streaming, campos de uso ou semântica de fallback que também precisam mudar. ### Quais campos do OpenRouter têm menor portabilidade? Preferências de provedor, arrays de fallback, headers de atribuição, transforms, plugins e metadados específicos são pontos comuns. Mantenha-os fora do modelo central da solicitação. ### APIs compatíveis com OpenAI usam os mesmos nomes de modelo? Não. A compatibilidade normalmente cobre o formato da solicitação, não a identidade do catálogo. Mapeie explicitamente aliases do aplicativo para os IDs atuais de cada gateway. ### Como testar streaming depois da migração? Registre sequências de eventos para deltas de texto, argumentos de ferramenta, motivo de término, uso, cancelamento e erros. Compare eventos analisados, não blocos brutos. ### Qual é a implantação de migração mais segura? Use um adaptador, reproduza um conjunto de referência, rode uma pequena amostra em sombra e faça canary de baixo risco com limites de rollback para erros, latência, custo e asserções. ### Quando uma equipe deve permanecer no OpenRouter? Quando seu catálogo de LLMs, controles de roteamento e ferramentas operacionais valem mais que a consolidação em outro lugar. A migração deve responder a requisitos medidos, não só a alegações de compatibilidade.