
一句话说
任意 SDK + 任意模型 = 都能跑。
把 base_url 指向 api.picklyone.com,接下来:
- 用 OpenAI SDK 调
gpt-5.5、claude-opus-4-7、deepseek-v4-pro、gemini-2.5-pro—— 一行model=字段切换 - 用 Anthropic SDK 调
claude-opus-4-7、gpt-5.5、deepseek-v4-pro—— 同样一行字段切换 - 用 curl 直接打两个端点都行 ——
/v1/chat/completions或/v1/messages
存量代码不用改,新模型随时接入。
为什么这件事值得说
不同公司的官方 SDK 对应不同的协议:OpenAI SDK 只发 /v1/chat/completions,Anthropic SDK 只发 /v1/messages。如果你的项目历史上用了 OpenAI SDK,想用 Claude 通常就得:
- 装一个 anthropic-sdk
- 重写一套调用代码
- 维护两套日志、两套异常处理
Picklyone 的协议层把这件事吃掉了。一个网关同时讲两种话,你保留任何一边的代码习惯都行。
协议 × 模型 = 矩阵全通
OpenAI SDK / /v1/chat/completions | Anthropic SDK / /v1/messages | |
|---|---|---|
| GPT-5.5 / GPT-5 | ✓ 原生 | ✓ 协议转换 |
| Claude Opus / Sonnet 4.x | ✓ 协议转换 | ✓ 原生 |
| DeepSeek V4 / V3 | ✓ 原生 | ✓ 协议转换 |
| Gemini 2.5 Pro / Flash | ✓ 兼容 | ✓ 协议转换 |
| Qwen / Kimi / GLM | ✓ 原生 | ✓ 协议转换 |
无论你用哪边的 SDK,都能调到任何一边的模型。
代码示例:同一个模型,两种 SDK
用 OpenAI SDK 调 Claude
from openai import OpenAI
client = OpenAI(
api_key="pk_live_...",
base_url="https://api.picklyone.com/v1",
)
resp = client.chat.completions.create(
model="claude-opus-4-7", # ← Claude 模型,但用 OpenAI SDK
messages=[{"role": "user", "content": "解释一下分布式事务"}],
)
print(resp.choices[0].message.content)
用 Anthropic SDK 调 GPT
import anthropic
client = anthropic.Anthropic(
api_key="pk_live_...",
base_url="https://api.picklyone.com",
)
msg = client.messages.create(
model="gpt-5.5", # ← GPT 模型,但用 Anthropic SDK
max_tokens=2048,
messages=[{"role": "user", "content": "Explain distributed transactions"}],
)
print(msg.content[0].text)
两边都跑得通。你最熟的那套 SDK,就是最适合你的 SDK。
定价页同步升级:每个模型支持哪个协议,一目了然
打开 定价页,除了价格,你现在还能看到每行模型的兼容协议标签:
- 标 OpenAI 的 →
/v1/chat/completions接得通 - 标 Claude 的 →
/v1/messages接得通 - 两个都标 → 任选 SDK 都能用(绝大多数模型都是这种)
而且这次定价页还做了三件 UX 优化:
- 顶部工具栏滚动时固定 —— 搜索 / 厂商筛选 / 格式筛选 / 排序始终触手可及,不用反复回到顶部
- 三种排序方式 —— 按厂商分组、按输入价升序、按输出价升序,横向比价更方便
- 格式筛选器 —— 可以只看支持 Claude 协议的模型、或只看 OpenAI 协议的模型
我应该用哪个协议?
简单决策树:
- 现有代码已经在用 OpenAI SDK → 不动,直接
base_url切到 picklyone,模型字段随便换 - 现有代码已经在用 Anthropic SDK → 不动,直接
base_url切到 picklyone,模型字段随便换 - 新项目从零开始 → 推荐 OpenAI SDK(生态更成熟、社区资料更多),但选哪边都行
- 想用流式 + 工具调用 + 缓存 → 两边都全程支持,体验一致
路线图
下一阶段我们会做的:
- 响应级别的协议转换准确性提升 —— 个别 edge case(超长 tool_use 嵌套、特殊 stop_reason)的转换精度还在打磨
- Responses API 全面支持 —— 已对 sub2api 系列上游开通,正在扩展到更多上游
- 更多模型接入 —— 国产新版本(GLM-5、Kimi K2)、视频生成(可行性评估中)
有具体场景或想优先支持的厂商,欢迎在企业微信群或 support@picklyone.com 告诉我们 🙌