3 步验证 API 中轉：Token Cafe 零对话留存
你改好 base_url，贴上 sk-cafe- 金钥，Cursor 或自架 App 就能呼叫 GPT、Claude、智谱——但心裡那两个问题还在：模型是不是正版？对话会不会被中轉商拿去存？
Token Cafe 的设计很直接：走各厂授权的正式 API 端点，中轉层只写计费 metadata，不写 messages 内容——而且你可以自己验证。
为什么中轉平台需要「可验证的信任」
中轉平台常被误解成「灰色介面」或「网页版逆向」。对开发者来说，真正的风险是两件事：
- 品质与来源：呼叫的到底是不是该厂正式 API？
- 隐私边界：prompt 与 AI 回覆会不会被中轉层持久化？
Token Cafe 把这两件事变成可观测、可对帐的设计，而不是一句「请相信我们」。
模型保障：正式 API，不是灰色介面
每个公开模型在后台绑定一条或多条 Channel（上游通道）。闸道对上游使用 OpenAI 相容格式：
POST {channel.base_url}/chat/completions
Authorization: Bearer {channel.api_key}
常见配置：
| 模型家族 | 上游范例 | 通道类型 |
|---|---|---|
| GPT | api.openai.com |
官方 API |
| Claude | api.anthropic.com |
官方 API |
| MiniMax / 智谱 / 通义 | 各厂官方网域 | 官方 API |
| 部分扩充模型 | OpenRouter、BazaarLink 等 | 授权聚合 |
定价页与 模型目錄 会标示通道名称与通道类型。多通道 fallback 仅在上游故障时切换至同一模型的备援路由，不会悄悄换成不同品质的替代品。
资料隐私：中轉层零对话留存
为了计费与对帐，Token Cafe 的 token_usage 只记錄：
- 模型名称、上游通道
- prompt / completion / total tokens
- HTTP 状态、延迟、错误片段（除错用，最多约 200 字元）
不记錄 messages 内容。请求处理完毕即释放；为产生回覆，内容必须即时送达上游——这与直接呼叫 OpenAI 相同，上游资料政策依各厂为准。
| 项目 | Token Cafe | 上游 AI 供应商 |
|---|---|---|
| 对话内容 | 不储存 | 为推理必须处理 |
| Token 用量、通道、延迟 | 储存（计费） | 各家不同 |
| 帐号、交易纪錄 | 储存 | — |
完整说明见 安全与保障页。
自己动手验证（30 秒）
1. 看 API 回应 header
curl -i https://api.aciemind.com/v1/chat/completions \
-H "Authorization: Bearer sk-cafe-你的金钥" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"ping"}]}'
在回应 header 找 x-cafe-channel，即本次实际使用的上游通道。
2. 帐号中心用量页
登入 account.aciemind.com →「用量」→「上游通道」栏应与 header 一致。
3. Probe 双模式
Dashboard「计费验证 Probe」提供历史比对（零成本）与即时探测（扣少量 credits），两者都显示 token 用量与通道。
服务状态与持续监控
服务状态页 每 5 分鐘探测各上游连通性，并分层显示官方直连与聚合 fallback，不公开任何 API Key。
快速开始
Base URL: https://api.aciemind.com/v1
API Key: sk-cafe-...（帐号中心建立）
串接文件：token.aciemind.com/docs.html
Aciemind · Token Cafe — 台湾开发者的 AI API 中轉，正式端点、零对话留存、可验证。
留言