1. Space Bunny 到底是谁：匿名模型为什么能接近 Opus 5
先说结论：Space Bunny 大概率不是一个官方正式发布的产品名，而是一个「匿名模型」的马甲。它最近在一批第三方 API 聚合平台的调用量统计里冲到第一，社区口碑又总拿它跟 Opus 5 那一档的闭源旗舰比，所以很多人才会一边用一边猜：这到底是哪家的模型？
我在自己常用的网关后台第一次看到space-bunny/alpha这个模型 ID 时，第一反应也是去官网搜一圈，结果当然搜不到。后来才反应过来，这事儿根本不该按“官网下载、官方文档接入”的思路去理解。匿名模型走的是另一条路径：它被部署在某个模型网关后面，对外只暴露一个 OpenAI 兼容接口和一个代号。你不需要知道它背后是哪个实验室、哪套权重、哪个版本，只要拿到 API Key，填上 Base URL，就能像调普通模型一样把它接进自己的工具链。
1.1 匿名模型到底是什么
所谓匿名模型，不是“没有名字”的模型，而是“不公开官方身份”的模型。常见的有三类：
| 类型 | 特征 | 典型场景 |
|---|---|---|
| 官方内测马甲 | 大模型团队自己挂的测试代号，防止评测污染 | 灰度上线前的线上验证、小范围真实流量压测 |
| 派生/蒸馏模型 | 基于某个开源基座做微调或蒸馏，换个名字上线 | 用更低的成本冲调用量、避开原厂商的舆论压力 |
| 网关私有别名 | 第三方网关把同一个模型重命名成自己的渠道名 | 渠道隔离、分账结算、客户定制 |
Space Bunny 比较像第一类或第三类。它不是传统意义上的“开源模型”，也没有公开权重下载；它的价值全部通过 API 体现。所以在讨论它时，不要问“这个模型在哪可以下载”，而要问“这个模型在哪个网关里能用”。这也解释了为什么它“调用量第一”而不是“下载量第一”：匿名模型本来就不靠下载冲量，靠的是真实请求数。
1.2 “接近 Opus 5”这句话要怎么听
很多人在讨论 Space Bunny 的时候，都会说它“接近 Opus 5”。这里的“接近”不是官方认证，更多是第三方跑分和主观评测里的一种共识描述。意思是：它的代码能力、指令跟随、长上下文处理这些硬指标，已经摸到了第一梯队闭源模型的门槛。
但要注意，匿名模型的评测结果天然要打折。因为你无法确认同一个代号背后是不是同一个权重，平台方也随时可能把流量切到不同版本上。我自己的习惯是：把这类评价当成方向参考，别当成采购依据。真正要不要用，拿自己的任务集跑一轮对比，比看十条排行榜都管用。
1.3 天价调用量是怎么来的
Space Bunny 能登顶调用量第一，我理解是几个因素叠出来的：
- 接入门槛极低。它走 OpenAI 兼容协议，现有的 SDK、客户端、Agent 工具基本不用改代码，只改 Base URL 和模型名就能用。
- 价格或免费额度有优势。很多网关给它挂了
:free后缀，虽然限流，但足够个人开发者跑脚本、做验证，这类请求量非常巨大。 - Agent 生态把它带起来了。Codex CLI、Claude Code、Dify 这类工具都在支持自定义模型供应商，用户在同一个工具里切到 Space Bunny 只是改一行配置的事。
- 社区有“解密心态”。大家越好奇它是谁，就越想亲自试，越试调用量越高。匿名反而成了传播杠杆。
2. 接入前必须搞清楚的三个底层概念
在动手改配置之前，我建议先把三个概念理清楚。否则你会看到一堆教程叫你在某个客户端里填 URL、填 Key、填模型名，但你不知道每个字段到底发生了什么，出了问题会无从下手。
2.1 OpenAI 兼容协议就是“通用插座”
现在的模型网关普遍提供 OpenAI 兼容接口，也就是/v1/chat/completions这一类 REST 端点。它约定了三件事：认证方式、请求格式、响应格式。
- 认证方式：HTTP Header 里带
Authorization: Bearer <你的Key> - 请求格式：JSON Body，包含
model、messages、max_tokens、temperature等字段 - 响应格式：统一返回
choices、usage这类结构
你可以把 OpenAI 兼容协议理解成电器里的通用插座。网关背后接的是 Space Bunny、DeepSeek，还是某个本地模型，都不重要；只要它给你一个插座，你的插头就能插进去。这也是为什么匿名模型能快速铺开——它不需要为每个客户端单独做适配。
2.2 接入一个模型到底需要哪几个参数
无论你用 curl、Python、Codex 还是 Dify，最终都在传递同样几个参数：
| 参数 | 作用 | 示例 |
|---|---|---|
| Base URL | API 网关的根地址 | https://api.gateway.example/v1 |
| API Key | 身份凭证 | sk-xxxxx |
| Model ID | 指明你要调用哪个模型 | space-bunny/alpha |
| Request Body | 你的对话内容与生成参数 | messages、max_tokens等 |
很多人接不上模型，不是因为不会填，而是因为不知道“模型 ID”到底写什么。匿名模型的 ID 不固定，不同网关可能给完全不同的别名。所以接入第一步不是改代码，而是去网关的控制台或模型列表页确认真实的 Model ID。
2.3 怎么确认 Model ID，而不是靠猜
最稳妥的办法是直接问网关的模型列表接口。以 OpenAI 兼容网关为例，用 curl 拉一份当前账号可见的模型清单：
curl https://api.gateway.example/v1/models \ -H "Authorization: Bearer $SPACE_BUNNY_API_KEY"返回的 JSON 里一般会有data数组，每个元素带id字段。看到space-bunny/alpha、space-bunny:free、space-bunny-latest之类的 ID，才是你真正要填进客户端的内容。不要在社区里看到别人写一个就抄一个，网关之间差异很大。
3. 三条接入路径：curl、ccswitch、Codex 与 Dify 的实操
我实际接入 Space Bunny 时，主要走三条路线。第一条是直连 API，适合验证模型手感和写自动化脚本；第二条是用 ccswitch 这类切换工具做多模型管理，适合日常办公和应急切换；第三条是把它塞进 Codex 或 Dify，直接变成 Agent 的底层模型。下面每一条都给出我实测下来能跑的配置。
3.1 路径一：直连 API，最快验证模型手感
先别急着上复杂工具，直接用 curl 发一条消息，确认 Key、Base URL、Model ID 三个要素都没错。
curl https://api.gateway.example/v1/chat/completions \ -H "Authorization: Bearer $SPACE_BUNNY_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "space-bunny/alpha", "messages": [ {"role": "system", "content": "你是一名严谨的编程助手。"}, {"role": "user", "content": "用 Python 写一个函数，判断一个字符串是否是回文。"} ], "max_tokens": 1024, "stream": false }'如果返回正常，你会看到choices[0].message.content里有模型生成的代码。这里有个小细节：stream字段先设成false，等验证通了再改成true。否则排查问题时，你还要同时处理 SSE 流式格式，干扰太多。
curl 通了之后，再用 Python 封装成脚本，方便批量测试。安装好openaiSDK 后：
import os from openai import OpenAI client = OpenAI( base_url="https://api.gateway.example/v1", api_key=os.getenv("SPACE_BUNNY_API_KEY"), ) resp = client.chat.completions.create( model="space-bunny/alpha", messages=[ {"role": "system", "content": "你是一个擅长代码 Review 的助手。"}, {"role": "user", "content": "帮我看看这段 Python 代码有没有内存泄漏风险。"}, ], temperature=0.2, ) print(resp.choices[0].message.content)注意，base_url里的 path 一定要精确。有的网关要求写https://api.gateway.example/v1，有的要求写到https://api.gateway.example不带/v1。SDK 通常会自动拼接/chat/completions，你如果多写一层或者少写一层，就会得到 404。
3.2 路径二：用 ccswitch 管理多 Provider，秒切 Space Bunny 和本地模型
ccswitch 这类工具解决的痛点是：你不可能只用一个模型。Space Bunny 高峰期限流了，你要切到本地模型继续干活；Codex 要接一家，Claude Code 又要接另一家。手动改环境变量容易改错，ccswitch 把这些配置固化成配置档，一键切换。
我的做法是在 ccswitch 里建两个 Profile：
- Profile A：Space Bunny 远程 API
- Base URL：
https://api.gateway.example/v1 - API Key：
sk-你的Key - Model：
space-bunny/alpha
- Base URL：
- Profile B：本地 LLM Studio 服务
- Base URL：
http://localhost:1234/v1 - API Key：
lm-studio（本地服务一般不校验） - Model：
local-model-name
- Base URL：
然后通过 ccswitch 的界面或 CLI 切换 Profile。切完之后，同一个终端里启动 Codex 或 Claude Code，它会自动读到新的配置。
这个方案最大的好处是“故障切换”极快。Space Bunny 某次凌晨宕机，我切到本地模型，前后不超过十秒。不要等到线上任务跑挂了才想起来去改配置文件，提前把两套 Profile 都配好，出问题直接切。
3.3 路径三：把 Space Bunny 接进 Codex CLI
OpenAI 的 Codex CLI 默认绑定它自己的模型，但它是支持自定义模型供应商的。Space Bunny 在编码场景口碑不错，接进 Codex 是很多人的第一诉求。
编辑 Codex 的配置文件，通常在~/.codex/config.toml：
model = "space-bunny/alpha" model_provider = "spacebunny" [model_providers.spacebunny] name = "Space Bunny Gateway" base_url = "https://api.gateway.example/v1" env_key = "SPACE_BUNNY_API_KEY" wire_api = "chat"这里wire_api有两个可选值：chat和responses。大部分第三方网关只实现了 OpenAI 的/v1/chat/completions，所以填chat最稳。如果你的网关明确支持 Responses API，再改成responses。我从踩坑经验出发，建议默认先填chat，报 400 再换。
配好后，在终端里启动：
export SPACE_BUNNY_API_KEY="sk-你的Key" codexCodex 就会用 Space Bunny 执行编码任务。注意它和 Anthropic 协议的 Claude Code 不一样，Codex 有自己的工具调用格式，所以如果你把 Space Bunny 接到 Codex 里发现功能调用不稳定，问题往往出在网关对 Responses 协议或工具调用格式的支持层，而不一定是模型本身。
如果你用的是 Claude Code，原理类似，只是环境变量名不同：
export ANTHROPIC_BASE_URL="https://api.gateway.example/anthropic" export ANTHROPIC_AUTH_TOKEN="sk-你的Key" export ANTHROPIC_MODEL="space-bunny/alpha" export ANTHROPIC_SMALL_FAST_MODEL="space-bunny/alpha-mini" claude但这要求网关把 Anthropic 的 Messages 协议翻译成下游模型可理解的格式。不是所有网关都支持，所以 Claude Code 这条路要先确认网关文档，不要盲目照抄。
3.4 路径四：Dify 低代码平台接入
如果你不想写代码，Dify 这类低代码平台接入 Space Bunny 也很快。在 Dify 里找到“模型供应商”设置，选择“OpenAI-API-compatible”或“自定义模型供应商”，然后填入：
- API Base URL：
https://api.gateway.example/v1 - API Key：
sk-你的Key - Model ID：
space-bunny/alpha
保存后，回到应用编排界面，把默认模型改成 Space Bunny，就能在聊天助手、Agent 工作流里直接用了。这里我提醒一句：Dify 里如果遇到“模型不支持工具调用”的提示，别慌张，去模型设置里检查是否手动开启了 Function Calling。匿名模型的工具调用能力差异很大，有些模型确实不支持，这时候你应该把需要调用工具的子任务拆给另一个模型，而不是硬塞给 Space Bunny。
4. 接入后最容易踩的坑：常见报错与排查实录
不管你是手工配还是用工具配，接入匿名模型总有几个高频问题。我把实际遇到的、以及在社区里看到最多的现象整理成一张速查表。
4.1 高频报错速查表
| 现象 | 大概率原因 | 处理方式 |
|---|---|---|
| 401 Unauthorized | API Key 填错、环境变量没加载、Key 前面多了空格 | 检查 shell 里echo $SPACE_BUNNY_API_KEY，确认没有换行或空格 |
| 404 Not Found | Base URL 路径拼错，或 Model ID 不存在 | 拉一次/v1/models列表，对照真实 ID |
| 400 Invalid Parameter | 把responses协议的参数发给chat/completions，或传了不支持的tools格式 | 检查客户端wire_api，改为chat；去掉不支持的参数 |
| 429 Rate Limit | 免费档限流，或单账号并发太高 | 退避重试、换付费档、或分流到本地模型 |
| 502/504 Gateway Error | 上游模型服务过载 | 稍等重试；长时间不稳就切换 Profile |
| 返回的内容文风突变 | 网关把模型别名指到了另一个后端 | 记录请求 ID，找网关方确认路由 |
这里最容易被忽略的是 400。很多第三方网关只实现了 Chat Completions API 的子集，你按 OpenAI 官方文档传了stream_options或response_format，它就报错。遇到 400 时，先用 curl 发一个最精简的请求，确认能通，再把参数一项项加回来，很容易定位。
4.2 为什么接入的是 Space Bunny，却感觉像另一个模型
匿名模型最让人挠头的问题就是“货不对板”。你感觉这次回答像 DeepSeek，下次又像某个本地微调模型，甚至同一个 Model ID 不同时段表现不一致。
我的排查思路是这样的：
- 先确认请求确实打到了预期的网关。登录网关控制台，看最近请求日志里的 Model 字段和 Tokens 消耗。
- 确认你用的是固定版本 ID，而不是
latest或free这类浮动标签。浮动标签在网关侧可能被重新映射。 - 如果同一 ID 在早晚高峰表现差异明显，大概率是上游在做负载均衡，不同后端能力不完全一致。
- 把带 Request ID 的对话记录保存下来。任何一个负责任的网关都能根据 Request ID 追踪到具体路由，这是扯皮时最有力的证据。
4.3 长上下文和工具调用的隐性门槛
Space Bunny 在短任务上又快又稳，但一拉长上下文或者开启工具调用，就容易露馅。我碰到过三种典型症状：
- 携带 50 万字代码库后，模型开始答非所问，明显超出它的最佳上下文区间。
- Agent 让它调用某个工具，它却返回一段“解释”而不是结构化工具调用参数。
- 多轮工具调用后，它突然开始重复之前的动作，陷入循环。
这不是说模型差，而是说你把它放错了位置。匿名模型适合当“单轮、短上下文、强指令”任务的执行者；真正需要复杂规划、多工具协作的长链路任务，我还是更信任经过完整工具调用训练的旗舰模型。接入时不要只看排行榜成绩，先跑一条接近你真实业务的路径。
5. 我的几点避坑心得和后续玩法
最后分享几个我自己总结的经验，不一定写在哪篇文档里，但实战很管用。
第一，API Key 永远别写进代码仓库。很多人为了方便，直接把 Key 写到 Codex 的config.toml里，甚至还提交到 Git。建议改成环境变量引用，并把配置文件权限收紧：chmod 600 ~/.codex/config.toml。匿名模型的热度越高，盯上这类 Key 的人就越多。
第二，生产环境不要用浮动标签。space-bunny/latest用着用着可能就被网关悄悄换了版本，等到行为异常才发现，已经浪费了一周排查时间。尽量锁到具体版本 ID，比如space-bunny/alpha-20250110（以网关实际提供为准）。
第三，把 ccswitch 这类工具当成“保险丝”用。Key 的价值不只是省事，而是出事时能一秒钟换路。Space Bunny 再强也是别人的模型，提供商改定价、临时下架、被官方追认或否认，都是无常的。你手里最好有第二个模型做兜底，哪怕是个本地模型。
我个人现在的用法是：Space Bunny 放在 Codex 里当主力编码模型，本地 LLM Studio 模型做离线兜底，再用 ccswitch 一键切换。这样不管是网关限流、模型下架，还是单纯想省点钱，我都有路可退。匿名模型的世界里，灵活配置比盲目相信一个代号更靠谱。
