Why the NotHoly API fits your OpenAI or Anthropic code

Moving between model providers usually means a rewrite: a different client, different request fields, different streaming. That cost is what keeps a team on a provider long after it has a reason to leave. NotHoly removes the cost by speaking the two API shapes your code already uses.

The API is compatible with both the OpenAI and the Anthropic formats. You change the base URL, the key and the model ID, and the client library, the request bodies, the tool definitions and the streaming you already wrote keep working. The same account and the same key reach both shapes. Keys, budgets and the model list sit on one account, so a team can move one service at a time.

#The OpenAI shape

Point the OpenAI SDK at NotHoly and set a model ID from the catalog. Nothing else in the call changes, including the function tools you pass and the way you read a streamed response.

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 and /v1/responses all answer in this shape, with server-sent events when you set stream, each event a data: line that ends with data: [DONE]. Both Authorization: Bearer and x-api-key are accepted, so a client that sends either header works unchanged.

#The Anthropic shape

The Anthropic SDKs take https://api.notholy.com as the base URL, without /v1, and call POST /v1/messages. You keep max_tokens, and you keep reasoning: thinking with a token budget, or output_config.effort for a named level that maps to the nearest the model has. user and assistant turns carry text, tool_use and tool_result blocks the same way.

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."}]}'

The reply is the Anthropic message shape, errors use the Anthropic error types, and a stream returns Anthropic events. POST /v1/messages/count_tokens estimates the input size before you send, without calling the model.

#The tools you already run

Because the shapes match, the libraries built on them match too. The OpenAI and Anthropic SDKs in every language point at NotHoly by configuration alone, and so do the coding agents that speak those protocols. The CLI writes that configuration for agents like Claude Code, Codex and OpenCode, so you do not hand-edit each one. The migration guide is the short version: base URL, key, model. Usage is metered per token at each model's published rate on every one of these endpoints, so the switch does not change how you reason about cost. Your evaluation harness, your logging wrapper and your retry logic keep their meaning, because the request and the response they wrap did not change.

#Where it does not fit

Some things do not carry across. The Responses API is stateless, so previous_response_id returns 400. cache_control is accepted and ignored, because caching runs on its own. On the raw endpoints the server runs none of its own tools; it runs only the function tools you send, and your code executes them. n must be 1. There is no embedding model yet, and there is no batch, fine-tuning, assistants, audio or image generation endpoint. A PDF document source in the Messages format returns 400, so send files through the chat or the files endpoint instead.

If the only thing holding you to a provider is the integration work, there is little of it here. Add a small balance on pricing, change three values, and run the code you already have.