L'API di NotHoly entra nel tuo codice OpenAI o Anthropic

Passare da un provider di modelli a un altro quasi sempre vuol dire riscrivere: un altro client, altri campi di richiesta, un altro streaming. È questo costo che tiene un team su un provider molto dopo che ha un motivo per andarsene. NotHoly toglie il costo parlando le due forme di API che il tuo codice già usa.

L'API è compatibile con i formati di OpenAI e di Anthropic. Cambi la base URL, la chiave e l'ID del modello, e la libreria client, i corpi di richiesta, le definizioni degli strumenti e lo streaming che hai già scritto continuano a funzionare. Lo stesso account e la stessa chiave raggiungono entrambe le forme.

#La forma OpenAI

Punta l'SDK di OpenAI a NotHoly e scegli un ID di modello dal catalogo. Nient'altro nella chiamata cambia, comprese le funzioni-strumento che passi e il modo di leggere una risposta in stream.

from openai import OpenAI

client = OpenAI(base_url="https://api.notholy.com/v1", api_key="nh_live_...")

r = client.chat.completions.create(
    model="MODEL_ID",
    messages=[{"role": "user", "content": "List the auth checks this endpoint is missing."}],
    max_tokens=800,
)
print(r.choices[0].message.content)

GET /v1/chat/completions, /v1/completions e /v1/responses rispondono in questa forma, con server-sent events quando attivi stream, ogni evento una riga data: che finisce con data: [DONE]. Sono accettati sia Authorization: Bearer sia x-api-key, quindi un client che manda uno dei due header funziona senza modifiche.

#La forma Anthropic

Gli SDK di Anthropic prendono https://api.notholy.com come base URL, senza /v1, e chiamano POST /v1/messages. Tieni max_tokens e tieni il reasoning: thinking con un budget di token, o output_config.effort per un livello con nome che si mappa al più vicino che il modello ha. I turni user e assistant portano blocchi text, tool_use e tool_result allo stesso modo.

curl https://api.notholy.com/v1/messages \
  -H "x-api-key: $NOTHOLY_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 800, "thinking": {"type": "enabled", "budget_tokens": 2000}, "messages": [{"role": "user", "content": "Explain this stack trace and name the likely bug class."}]}'

La risposta è la forma di messaggio di Anthropic, gli errori usano i tipi di errore di Anthropic, e uno stream restituisce eventi di Anthropic. POST /v1/messages/count_tokens stima la dimensione dell'input prima di inviare, senza chiamare il modello.

#Gli strumenti che già usi

Visto che le forme coincidono, coincidono anche le librerie sopra di esse. Gli SDK di OpenAI e di Anthropic in qualsiasi linguaggio puntano a NotHoly con la sola configurazione, e lo stesso vale per gli agenti di codice che parlano quei protocolli. La CLI scrive quella configurazione per agenti come Claude Code, Codex e OpenCode, così non modifichi ognuno a mano. La guida alla migrazione è la versione breve: base URL, chiave, modello. L'uso è misurato a token alla tariffa pubblicata di ogni modello su tutti questi endpoint, quindi il passaggio non cambia come ragioni sul costo.

#Dove non si adatta

Alcune cose non passano con il resto. L'API Responses è senza stato, quindi previous_response_id restituisce 400. cache_control è accettato e ignorato, perché il caching gira da solo. Sugli endpoint grezzi il server non esegue nessuno strumento proprio; esegue solo le funzioni-strumento che mandi, e il tuo codice le esegue. n deve essere 1. Non c'è ancora un modello di embedding, e non c'è endpoint per batch, fine-tuning, assistants, audio o generazione di immagini. Una fonte document in PDF nella forma Messages restituisce 400, quindi manda i file dalla chat o dall'endpoint dei file.

Se l'unica cosa che ti lega a un provider è il lavoro di integrazione, qui ce n'è poco. Metti un saldo piccolo su prezzi, cambia tre valori ed esegui il codice che hai già.