Qwen, DeepSeek, Kimi, GLM and MiniMax behind one OpenAI-compatible key. Point your client at us; everything else keeps working.
The relay
deeprelay sits between your client and the open-model frontier. Requests stream in on one OpenAI-compatible key, the relay routes each one to the model you named, and tokens stream back. The stream above is the product drawn literally.
your app ──▶ api.deeprelay.ai ──▶ deepseek-v4
├──▶ glm-5.3
├──▶ kimi-k3
├──▶ qwen-image
├──▶ wan-2.2
└──▶ …38 models, one keyChat
Streaming, tool calls, JSON mode and the usage block behave the way your client already expects, including reasoning tokens, surfaced in usage instead of silently swallowed.
stream = client.chat.completions.create(
model="deepseek-v4",
messages=[{"role": "user", "content": q}],
tools=tools,
stream=True,
)
for chunk in stream:
delta = chunk.choices[0].deltaImage
The OpenAI images shape, pointed at the open image models: one request, a finished image, accounted inside the plan like everything else.
curl https://api.deeprelay.ai/v1/images/generations \
-H "Authorization: Bearer $DEEPRELAY_API_KEY" \
-d '{
"model": "qwen-image",
"prompt": "a watercolor fox",
"size": "1024x1024"
}'Video
Generation runs as an async job: submit, poll, download. Long renders never hold a connection open, and seconds of video are accounted the same way as tokens, inside the plan.
curl https://api.deeprelay.ai/v1/videos \
-d '{"model": "wan-2.2", "prompt": "..."}'
# → {"id": "vid_…", "status": "queued"}
curl https://api.deeprelay.ai/v1/videos/vid_…/content
# → the finished renderThe catalog
Featured chat
Featured image
Featured video
Every open model → one endpoint → one key ›
Every model · one key
The whole catalog under one key, on a flat monthly plan. The same OpenAI-compatible calls you already write.