DEV Community: alice kelly

OpenAI API Relay Setup: Environment Variables That Keep Your Project Clean

alice kelly — Sun, 14 Jun 2026 06:24:00 +0000

An OpenAI API relay is easiest to manage when your project treats it as configuration, not hardcoded code. The clean pattern is simple: keep the base URL, key, and model name in environment variables, then read them from your app.

This makes it easier to switch between direct API access, relay testing, and different models without touching source files.

The three variables I usually keep

AI_API_BASE_URL=https://api.wappkit.com/v1
AI_API_KEY=your_relay_key
AI_MODEL=gpt-5.5

AI_API_BASE_URL points your SDK to the OpenAI-compatible endpoint.

AI_API_KEY is the key issued by the relay service.

AI_MODEL lets you switch models without editing your app code.

Before choosing a model, check the live model list. Do not rely on old examples copied from another project.

Python example

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AI_API_KEY"],
    base_url=os.environ.get("AI_API_BASE_URL", "https://api.openai.com/v1"),
)

response = client.chat.completions.create(
    model=os.environ.get("AI_MODEL", "gpt-5.5"),
    messages=[{"role": "user", "content": "Write one sentence about API relays."}],
    max_tokens=80,
)

print(response.choices[0].message.content)

This keeps the code portable. Your local machine can use the relay. Production can use a different endpoint if needed.

Node.js example

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.AI_API_KEY,
  baseURL: process.env.AI_API_BASE_URL || "https://api.openai.com/v1",
});

const response = await client.chat.completions.create({
  model: process.env.AI_MODEL || "gpt-5.5",
  messages: [{ role: "user", content: "Write one sentence about API relays." }],
  max_tokens: 80,
});

console.log(response.choices[0].message.content);

Same idea: the app reads configuration, the environment decides the provider.

Why this helps

First, you avoid leaking keys into source control.

Second, you can test different models like gpt-5.5 or gpt-5.4 by changing one variable.

Third, teammates can use their own keys without editing shared files.

Fourth, rollback is easy. If the relay endpoint has an issue, you can change the base URL and restart.

Add a startup check

Before your app handles real work, validate the required variables:

required = ["AI_API_KEY", "AI_API_BASE_URL", "AI_MODEL"]
missing = [name for name in required if not os.environ.get(name)]

if missing:
    raise RuntimeError(f"Missing environment variables: {', '.join(missing)}")

This catches configuration mistakes early.

Keep a tiny smoke test

Create a separate smoke test that sends one short request:

python smoke_test_ai.py

Run it after changing the key, model, or base URL. If it fails, check the docs, billing page, and status page before rewriting application code.

Practical boundary

An OpenAI API relay is useful for development, prototypes, multi-model testing, and payment friction. It is not a reason to ignore security, cost controls, or production review.

Use environment variables, keep keys out of git, verify model names from the live list, and run a smoke test whenever configuration changes. That small bit of discipline prevents most relay setup bugs.

OpenAI-Compatible Base URL Troubleshooting: 7 Checks Before You Blame the SDK

alice kelly — Sun, 14 Jun 2026 06:23:26 +0000

An OpenAI-compatible base URL is supposed to make model switching boring: change the endpoint, keep the SDK, and move on. In real projects, the first run often fails with a 401, 404, 429, or a model-not-found error.

Here is the checklist I use before blaming the SDK.

1. Confirm the base URL includes the right API prefix

Most OpenAI-compatible gateways expect a /v1 prefix:

from openai import OpenAI

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

If you use only the domain, some SDK calls may resolve to the wrong path. Check the provider's docs and copy the exact base URL format.

2. Make sure the key belongs to that gateway

A common mistake is mixing keys:

OpenAI key with relay base URL
Relay key with OpenAI base URL
Old test key from a disabled project
Key copied with a leading or trailing space

When you see 401 Unauthorized, print the first and last few characters of the key locally and compare it with the dashboard. Do not log the full key.

3. Check the model name from the live list

Do not guess model names from memory. Gateway model names can change as upstream availability changes.

Before using gpt-5.5, gpt-5.4, or a Claude Code model, check the current model list. Copy the model id exactly.

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "Say hello in one sentence."}],
)

If the model name is wrong, you usually get 404, model_not_found, or a gateway-specific validation error.

4. Test with the smallest possible request

Before debugging your whole app, run one tiny request:

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "ping"}],
    max_tokens=20,
)
print(resp.choices[0].message.content)

If this works, the base URL, key, and model are probably fine. Your bug is likely in the app layer: streaming, tool calling, message format, proxy settings, or retry logic.

5. Separate rate limits from auth errors

401 usually means key or account state.

429 usually means rate limit, balance, or temporary traffic control.

If you get 429, check the billing page and wait before retrying. A tight retry loop can make the problem worse.

6. Check the status page before changing code

When the same request worked yesterday and fails today, do not rewrite the integration first. Check the status page. If there is an upstream incident, your code may be fine.

This is especially useful with relay services because there is one more layer between your app and the model provider.

7. Keep one known-good curl command

Save a minimal curl command in your project docs:

curl https://api.wappkit.com/v1/chat/completions \
  -H "Authorization: Bearer YOUR_RELAY_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "ping"}],
    "max_tokens": 20
  }'

When the app breaks, run the curl command first. If curl fails, debug account, gateway, model, or network. If curl works, debug your app.

OpenAI-compatible base URLs are simple once the basics are clean: exact /v1 endpoint, matching API key, live model name, small test request, billing check, status check, and one known-good curl command.

OpenAI-Compatible Base URL Troubleshooting: 7 Checks Before You Blame the SDK

alice kelly — Sun, 14 Jun 2026 05:31:41 +0000

Here is the checklist I use before blaming the SDK.

1. Confirm the base URL includes the right API prefix

Most OpenAI-compatible gateways expect a /v1 prefix:

from openai import OpenAI

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

If you use only the domain, some SDK calls may resolve to the wrong path. Check the provider's docs and copy the exact base URL format.

2. Make sure the key belongs to that gateway

A common mistake is mixing keys:

OpenAI key with relay base URL
Relay key with OpenAI base URL
Old test key from a disabled project
Key copied with a leading or trailing space

When you see 401 Unauthorized, print the first and last few characters of the key locally and compare it with the dashboard. Do not log the full key.

3. Check the model name from the live list

Do not guess model names from memory. Gateway model names can change as upstream availability changes.

Before using gpt-5.5, gpt-5.4, or a Claude Code model, check the current model list. Copy the model id exactly.

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "Say hello in one sentence."}],
)

If the model name is wrong, you usually get 404, model_not_found, or a gateway-specific validation error.

4. Test with the smallest possible request

Before debugging your whole app, run one tiny request:

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "ping"}],
    max_tokens=20,
)
print(resp.choices[0].message.content)

If this works, the base URL, key, and model are probably fine. Your bug is likely in the app layer: streaming, tool calling, message format, proxy settings, or retry logic.

5. Separate rate limits from auth errors

401 usually means key or account state.

429 usually means rate limit, balance, or temporary traffic control.

If you get 429, check the billing page and wait before retrying. A tight retry loop can make the problem worse.

6. Check the status page before changing code

When the same request worked yesterday and fails today, do not rewrite the integration first. Check the status page. If there is an upstream incident, your code may be fine.

This is especially useful with relay services because there is one more layer between your app and the model provider.

7. Keep one known-good curl command

Save a minimal curl command in your project docs:

curl https://api.wappkit.com/v1/chat/completions \
  -H "Authorization: Bearer YOUR_RELAY_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "ping"}],
    "max_tokens": 20
  }'

When the app breaks, run the curl command first. If curl fails, debug account, gateway, model, or network. If curl works, debug your app.

API中转站测评: 模型完整度、延迟、价格和真伪,5 个维度怎么看

alice kelly — Fri, 12 Jun 2026 00:45:16 +0000

中转站测评 不该是看谁家首页吹得响。一个 API 中转站到底能不能用,落到实处就几件事: 模型全不全、快不快、稳不稳、贵不贵、是不是真的。这篇给一套你自己就能跑的测评维度,不替任何一家站背书,只讲怎么判断。

下面的示例模型用 gpt-5.5、claude code opus 4.8,实际以你要测的站的模型列表为准。

维度一: 模型完整度

先看模型列表,不要看宣传图。要确认的是:

你要用的模型在不在,比如 gpt-5.5、gpt-5.4、claude-code-opus-4.8、claude-code-opus-4.7。
模型名是机器可读的、能直接复制进代码的,而不是只在海报上写个 "支持最新模型"。
同一个模型有没有清楚的版本号,避免你以为在用 4.8、其实路由到老版本。

判断方法很简单: 打开模型列表,复制一个模型名,留着下一步用 curl 实测。列表里没有、或者名字对不上的,这一项就不算过。

维度二: 延迟和稳定性

延迟分两块: 首字延迟(TTFB)和整体完成时间。最直接的测法是用 curl 计时:

curl -o /dev/null -s -w "连接 %{time_connect}s / 首字 %{time_starttransfer}s / 总计 %{time_total}s\n" \
  https://api.wappkit.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-your-token" \
  -d '{"model":"gpt-5.5","messages":[{"role":"user","content":"ping"}]}'

同一条命令跑 5~10 次,看 time_starttransfer 稳不稳。偶尔抖动正常,每次都几秒起步就要留意。稳定性还要看不同时段: 高峰期和凌晨各测一轮,差距太大说明上游容量紧张。

维度三: 价格和计费透明度

价格不只是单价,更重要的是计费是否透明:

按什么计费(token / 请求 / 套餐),余额怎么扣。
失败的请求扣不扣费 —— 这一条最容易被忽略,也最容易踩坑。
有没有免费测试额度让你先跑通再付费。
充值方式是否覆盖你能用的(支付宝、微信、PayPal、国际卡)。

便宜但计费含糊,最后未必省钱。把计费规则问清楚,比盯着单价更实际。

维度四: 真伪检测

中转站最受质疑的就是 "模型是不是真的"。你想接 gpt-5.5,结果路由到一个便宜的小模型,这种情况确实存在。粗略的判断方法:

用同一个有标准答案的复杂提示词,分别问官方文档示例和这个中转端点,比较回答深度。
问模型一些只有新版本才答得好的问题,看水平是否匹配它声称的版本。
看返回里的 model 字段是否和你请求的一致。

这只能粗判,不能完全证真。但如果回答质量明显配不上声称的模型,基本可以排除。更系统的做法见下一篇 中转站检测。

维度五: 错误信息和状态页

出问题不可怕,可怕的是出了问题你看不见。我会看这几项:

401(token 错)、404(路径/模型错)、429(限流)、余额不足这些错误能不能区分清楚。
有没有状态页说明上游异常。
一个含糊的 request failed,你根本不知道是 token 错、模型没了还是上游挂了 —— 这种站调试成本很高。

一个能跑的最小测评流程

把上面几条串起来,15 分钟就能给一个站打分:

打开模型列表,确认目标模型在 → 复制模型名。
用免费额度拿一个 token。
curl 跑通一次,确认返回有 choices。
同一命令跑 10 次,记录首字延迟波动。
故意写错 token、写错模型名,看错误信息清不清楚。
翻一遍计费规则和状态页。

六步都过,再考虑长期用;卡在前三步的,直接换下一家。

小结

api中转站测评 说到底是一张检查清单: 模型完整度、延迟稳定性、价格透明度、真伪、错误可读性。五项里模型和计费是硬指标,延迟和错误信息决定你日常用着舒不舒服。

想自己跑一遍这套流程,可以先用免费测试额度测 gpt-5.5 或 claude code opus 4.8,再对照模型列表打分。

AI API 中转站: 没有美国信用卡,怎么用 OpenAI 和 Claude API

alice kelly — Fri, 12 Jun 2026 00:45:00 +0000

如果你要做 AI API 中转站 相关搜索词,真正能打的点不是旧模型,而是当前模型和支付便利:比如 gpt-5.5、gpt-5.4、claude code opus 4.8、claude code opus 4.7。如果你想在没有美国信用卡的情况下用 OpenAI API,或者从官方计费没覆盖的国家访问 Anthropic/Claude API,你大概撞上过和很多留学生、海外开发者一样的墙:代码写好了、文档也看懂了,偏偏卡在付款这一步过不去。

为什么官方计费会卡住你

OpenAI 和 Anthropic 走的支付处理商会校验信用卡的发卡国和账单地址(AVS)。常见的几种翻车:

你的卡发卡国还不在它们支持的范围内。
账单地址跟处理商预期的对不上。
预付卡或某些虚拟卡被风控拒掉。

这些都不是 bug —— 就是区域计费而已。所以解法不是"骗过表单",而是"换一条真正被接受的付款路径"。

老实盘点你的几个选项

选项	怎么运作	代价
搞一张被接受的卡	虚拟美元卡,或支持国家的亲友的卡	虚拟卡常被风控拒;借别人的卡没法长久
区域计费方案	通过支持国家的账单资料走	脆弱 —— 验证一收紧就断
OpenAI 兼容网关	一个第三方端点,暴露 OpenAI/Anthropic API,并接受其他付款方式(支付宝、微信、PayPal)	是个便利层,不是官方 API;模型从它的列表里选

前两个,偶尔用用还行。如果你在做东西、又想用支付宝或微信付款,OpenAI 兼容网关通常是最省事的一条路。

OpenAI 兼容网关到底是什么

它是一个端点,讲的是跟 OpenAI(/v1/chat/completions)和 Anthropic 一样的 API,所以你现有的 SDK 和工具不用改 —— 只换 base_url 和 key。一个账号、一个 key,通常就能调到站内模型列表暴露的多个模型系列,具体以模型列表为准。

像凡人 AI(基于开源 new-api 搭建)这类服务,允许你用非美国的付款方式充值,并给你一个 base_url + token。当前支持的付款方式见配置文档。

快速上手

把任意 OpenAI SDK 指向网关的 base URL:

curl https://api.wappkit.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-your-token" \
  -d '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

返回的 JSON 带 choices 数组,就说明通了。完整的 SDK 配置(Python、Node.js)见把 OpenAI SDK 指向一个 OpenAI 兼容端点。

实用提示

模型名从端点的模型列表里选,比如站内暴露的 gpt-5.5、gpt-5.4、claude code opus 4.8、claude code opus 4.7。
大多数网关都给免费测试额度,充值前可以先确认路由通不通。
token 别提交到 Git、别截图泄露。

小结

没有美国信用卡,并不等于用不了 OpenAI 或 Claude API。偶尔用,一张被接受的虚拟卡可能就够了;如果你在做项目、想用支付宝或微信付款,一个 OpenAI 兼容网关几分钟就能给你 base_url + token,一个账号调多个模型。

AI API Relay for Beginners: What It Is and Why You Might Need One

alice kelly — Thu, 11 Jun 2026 12:12:57 +0000

If you're trying to use OpenAI or Claude API but keep hitting walls with payment or switching between models, you've probably heard about "AI API relay stations" (also called gateways or proxies). Here's what they actually do and when they're useful.

The Problem They Solve

OpenAI requires a US credit card. Claude supports more regions but still needs international payment. Want gpt-5.5? Go to OpenAI. Want claude-code-opus-4.8? Go to Anthropic. Each platform needs separate keys and config. Token-based billing means you don't know the cost until after the request. Easy to overspend during testing.

What AI API Relays Do

An ai api 中转站 (relay station) sits between your code and the official APIs:

Your Code → Relay Station → OpenAI / Anthropic / Others

It handles payment localization (pay via Alipay/WeChat instead of international cards), unified interface (one base URL, switch models by changing the model parameter), and pre-paid balance (top up a fixed amount, requests stop when balance runs out).

When to Use a Relay

Scenario	Use Relay	Use Official
No US credit card	✅	❌
Need to switch between models often	✅	🤔
Limited budget, afraid of overspending	✅	❌
Production with SLA requirements	❌	✅
Need custom fine-tuning	❌	✅

Simple rule: testing, development, personal projects use relay. Production, enterprise, custom needs use official.

How to Pick One

I've tried 5-6 and got burned twice (one shut down after I paid, another leaked my key). Here's what to check:

Does it offer free credits for testing? Check the model list for gpt-5.5, claude-code-opus-4.8, etc. Can you see real-time uptime at status page? Does the billing page mention refunds for unused balance?

If it fails any of these, move on.

Common Misconceptions

Relays are not just cheaper. Pricing is often close to official rates. The real value is removing payment friction.

Relays cannot replace official APIs entirely. If you need SLA, custom models, or high-volume stability, you'll eventually need to go official.

Not all relays are scams. Some are, but legitimate ones exist. The trick is knowing what to check before paying.

My Setup

I use a relay for development. Test new models without juggling multiple API keys, top up small amounts ($10-20) to avoid overspending, switch to official API when moving to production.

This way I get the convenience during dev and the reliability in prod.

AI API relays solve payment and multi-model friction for developers. Use them for testing and small projects, not as a long-term replacement for official APIs. Before picking one, check for free tier, recent models, status page, and refund policy.