Integrations

Most tools that talk to a language model already speak one of two wire formats. Grafilab serves both from one host, so pointing an editor, a chat UI, or an SDK at Grafilab is usually two settings: a base URL and an API key.

https://llm.grafilab.ai exposes two request formats over the same catalog, the same key, and the same wallet:

• OpenAI chat completions — POST /v1/chat/completions, plus embeddings, images, videos, and model listing. This is what most tools mean by “OpenAI-compatible” or “custom OpenAI endpoint”.
• Anthropic messages — POST /v1/messages, used by Claude Code and the Anthropic SDKs.

Either way you call the same model ids, spend from the same credit balance, and see the usage attributed to the key that authenticated the request. Pick whichever format your tool already supports; there is no benefit to preferring one over the other unless a tool insists.

The single most common mistake is adding or omitting /v1. The rule is simple: OpenAI-style clients append paths to a base that already ends in /v1, while Anthropic-style clients append /v1/messages themselves.

For the tools on this site:

• A Grafilab API key. In the console open API (https://app.grafilab.ai/api) and click Generate New Key — see API Keys.

Create a separate key per tool and name it after the tool. Usage is recorded against the key that authenticated each request, so one key per tool turns per-key usage into a per-tool cost breakdown, and revoking one tool’s access never disturbs the others.

The OpenAI surface reads the key from Authorization: Bearer. The Anthropic surface accepts either x-api-key or Authorization: Bearer, so a tool that only offers one of them still works.

The model catalog is live, so list it rather than copying ids from a page. Every entry’s id is the exact string to use in any tool or SDK.

curl https://llm.grafilab.ai/v1/models \
  -H "Authorization: Bearer $GRAFILAB_API_KEY" | jq -r '.data[].id'

from openai import OpenAI

client = OpenAI(api_key="sk-grafilab-...", base_url="https://llm.grafilab.ai/v1")
for model in client.models.list():
    print(model.id)

import OpenAI from "openai";

const client = new OpenAI({ apiKey: "sk-grafilab-...", baseURL: "https://llm.grafilab.ai/v1" });
for await (const model of client.models.list()) {
  console.log(model.id);
}

The same ids appear as cards in the Playground, with context size and prices.

Model listing lives on the OpenAI surface only. Even when your tool talks to Grafilab in Anthropic format, list the catalog with GET /v1/models and a Bearer token, then paste the id you want into the tool.

Before you touch a tool’s settings, confirm the key and the URL from a terminal. A working curl means any later failure is the tool’s configuration, not your account.

curl https://llm.grafilab.ai/v1/chat/completions \
  -H "Authorization: Bearer $GRAFILAB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grafilab/qwen3.6-flash",
    "messages": [{"role": "user", "content": "Say hi in five words."}]
  }'

curl https://llm.grafilab.ai/v1/messages \
  -H "x-api-key: $GRAFILAB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grafilab/qwen3.6-flash",
    "max_tokens": 64,
    "messages": [{"role": "user", "content": "Say hi in five words."}]
  }'

max_tokens is required on /v1/messages and optional on /v1/chat/completions. Both calls should return a JSON body with a content or choices field. A 401 means the key string is wrong or carries stray whitespace; a 404 means the model id does not match a catalog id; a 429 means your credit balance is empty, not that you are sending too fast.

/v1/messages implements a subset of the Messages protocol. It is enough for coding agents and chat clients, but a few things behave differently from Anthropic’s own endpoint:

• Server-side tools are rejected. web_search_*, bash_*, and any tool whose type is not custom come back as 400 rather than being silently dropped. So do unknown content-block types and unknown message roles.
• Five fields are accepted and ignored: top_k, thinking, output_config, context_management, and cache_control wherever it appears. Requests carrying them succeed; the fields simply have no effect.
• Cache writes are never reported. Prompt caching still happens where the model supports it and cached input shows up in usage.cache_read_input_tokens, but usage.cache_creation_input_tokens is always 0.
• usage.input_tokens excludes cached tokens, following the Anthropic convention.
• There is no model listing. Use GET /v1/models on the OpenAI surface.
• anthropic-version is not read. Sending it is harmless; omitting it is fine.
• Streaming has no terminator frame. The sequence ends at message_stop, and a failure after the first frame arrives in-band as event: error on an HTTP 200.

Supported content blocks are text, image, and tool_result on user turns, and text, tool_use, thinking, and redacted_thinking on assistant turns. Anything else returns 400. The Claude Code page maps each of these to a symptom you might actually notice.