我用 AI 编程工具之后，最先遇到的并不是模型不够用，而是订阅越来越碎。
想用 GLM，要开一份套餐；项目做到一半觉得 Kimi 更适合长上下文，又要去另一家订阅；换成 DeepSeek 或 MiniMax，额度、有效期和 API Key 还得重新管理。更让我不舒服的是短周期额度窗口：明明月费已经付了，连续写一阵代码，却要停下来等 5 小时窗口恢复，之后还要继续留意周额度。以 Kimi 当前官方规则为例，Kimi Code 除了共享月度额度池，还单独设有 5 小时和周使用限额。
我最近使用的 AiiOnly Token Plan 换了一种思路：不再按某一个模型订阅，而是把 11 个国产主流模型放进同一个月度 Credits 池。Standard 国内版首发价是 79 元/月，包含 6,320,000 Credits，是 Lite 套餐用量的 2.9 倍。
11 个模型放在同一个月度池里
Standard 当前包含 DeepSeek、GLM、Kimi 和 MiniMax 四个系列，共 11 个模型。这里最吸引我的地方不是数量本身，而是不用再提前押注“这个月只能用哪一家”。复杂后端可以交给偏推理和工程能力的模型，前端页面换一个更擅长长上下文或视觉理解的模型，测试、文档和小修改再用响应更快的版本。
套餐使用一把 API Key 和统一的 Credits 池。控制台同时给出了 OpenAI 兼容接口和 Anthropic 兼容接口：
OpenAI：https://llm.aiionly.com/v1/chat/completions
Anthropic：https://llm.aiionly.com/v1/messages
“同时提供两类接口”不等于每一个模型都能不加区分地走两种协议。Anthropic /v1/messages 只适用于平台已经适配 Messages 格式的部分模型，实际接入时仍要按照模型明细和工具教程选择协议。OpenAI 兼容工具通常走 /v1/chat/completions，Claude Code 这类工具则更适合走已适配的 /v1/messages。
控制台的模型明细给出了准确的 API 模型 ID，Standard 的 QPS 是 2。复制模型 ID 时最好从这里直接取值，避免把页面展示名称当成请求参数。
我第一次查看控制台时，里面还是上面的 10 个模型。最近再打开模型明细，列表中已经多了 GLM-5.3，API 模型 ID 是 glm-5.3，所以 Standard 目前是 11 个模型。它不是替换 GLM-5.2，两个版本都还保留在套餐里。
GLM-5.3 延续了 GLM-5.2 的基座，主要加强复杂 Coding 和长程任务。智谱在发布说明中称，其内部 Code Bench 相比 GLM-5.2 提升 50%；这是厂商自测结果，我还没有单独跑同一项目做对比。现阶段我会把它放在大型项目、复杂调试和需要 Agent 连续执行的任务里尝试，稳定工作流仍可以继续使用 GLM-5.2。
这 11 个模型并不是简单的同类替换。我根据各家官方定位，把它们放进实际开发流程后，大致会这样选：
| 模型 | 更适合的任务 | 我会怎么用 |
|---|---|---|
| GLM-5.3 | 在 GLM-5.2 基础上加强复杂 Coding 和长程 Agent 任务 | 大型项目、复杂调试和需要持续规划执行的工程任务 |
| DeepSeek-V4-Pro | 1M 上下文、复杂推理、Coding 和 Agent 长任务 | 后端架构、核心业务、疑难 Bug 和跨模块修改 |
| DeepSeek-V4-Flash | 同样支持 1M 上下文，模型更轻，日常任务响应更灵活 | 快速改代码、代码审查、补测试和中等复杂度任务 |
| GLM-5.2 | 1M 上下文，面向项目级工程和长程 Coding Agent | 大仓库理解、跨文件重构、从需求到部署的完整交付 |
| GLM-5.1 | 200K 上下文，强调长程执行、工具调用和工程优化 | 多阶段开发、性能优化、需要持续迭代的 Agent 任务 |
| Kimi-K3 | 1M 上下文、原生多模态、长程 Coding 和知识工作 | 大型项目、全栈任务、前端实现和长文档处理 |
| Kimi-K2.7-Code | 专用编程模型，长上下文指令遵循和代码任务成功率更强 | 日常编码、多文件修改、终端工具协作 |
| Kimi-K2.6 | 通用能力均衡，覆盖代码、Agent、文本和视觉输入 | 通用开发、代码问答、Agent 与视觉理解混合任务 |
| Kimi-K2.5 | 原生多模态，支持思考与非思考模式 | 看图理解页面、设计稿转代码、视觉 Agent |
| MiniMax-M3 | 1M 上下文、原生多模态、Coding 与复杂 Agent | 长周期工程任务、大代码库、需要多步工具调用的工作 |
| MiniMax-M2.5 | 编码、搜索、工具调用和办公任务，执行效率较高 | 高频编码、搜索整理、测试、文档和常规自动化辅助 |
上表描述的是模型本身的官方能力。原始模型支持图片或视频，不代表 AiiOnly 当前每一条 Token Plan 接口都开放了对应输入格式，多模态任务仍要以平台接口说明和实测为准。
额度按月看，不再被短窗口打断
Token Plan 控制台展示的是整个月的 Credits 总量和套餐有效期，没有再拆成 5 小时滚动窗口或周额度。对我来说，这比“每隔几小时恢复一部分”的方式直观得多：这个月还有多少额度、哪个模型消耗得快，都能在一个页面里看清楚。
Credits 不是 Token 的另一种写法，而是平台统一的额度单位。一次请求完成后，系统会根据具体模型实际消耗的输入、输出和缓存 Token 换算扣减，因此不同模型、不同长度的任务不能只按“请求次数”比较成本。
这也是我不建议把它写成“无限调用”的原因。Standard 有 632 万 Credits 和 QPS 2，模型倍率也不同。它解决的是短周期窗口带来的频繁中断，并不是取消所有额度和并发限制。对于一个人在 Claude Code、Codex、OpenCode 等交互式编程工具里开发，月度总池更容易安排；高并发批量任务则不是这个套餐的使用场景。
VeryClaw 把模型接入和 Chat 放到了一起
除了把 Token Plan 接进现有编程工具，AiiOnly 也在做自己的桌面客户端 VeryClaw。它给我的第一感觉有点像 WorkBuddy，不过入口更集中：左侧除了新对话，还有模型、Agents、频道、技能、定时任务和智能助手。
模型接入就在客户端内完成。添加 AI 提供商时选择 AiiOnly，填入套餐 API Key 和模型 ID，就能把 Token Plan 里的模型加入 VeryClaw。页面也注明 API 密钥保存在本机，不需要为了开始对话再单独配置一套中转工具。
接好模型后，可以直接回到 Chat 对话，在输入框下方选择刚才添加的模型。我用 GLM-5.2 提了一个简单的 Python 编程任务，让它写滑块算法；对话里不仅返回了实现思路和运行方式，还能看到工具调用以及新增的 slider_solver.py 文件。模型额度、对话、工具执行和文件结果都留在同一个客户端里，这比只提供一个聊天框更接近实际工作流程。
VeryClaw 也把技能放进了 Chat 输入区，目前能看到 Word、PDF、PPT、技能查找和自我改进等入口。再加上 Agents、频道、定时任务和智能助手，它想做的一站式路径已经很清楚：先接入 Token Plan 的模型，再在 Chat 中交代任务，需要时调用技能或 Agent，最后把结果落到文档和代码文件里。底部的本地 gateway 状态则用来确认执行环境是否连接。
从添加模型、开始对话，到调用工具、生成文件，VeryClaw 已经把几个原本分散的步骤放进了同一个工作台。Token Plan 提供统一的模型额度，VeryClaw 负责对话、Agent、技能和任务执行，整个使用过程不需要在多个客户端之间来回切换。
先接入 Claude Code，四个角色分配不同模型
AiiOnly 的文档中心已经按工具拆好了教程，除了 Claude Code，还能看到 CC Switch、Cherry Studio、OpenCode、OpenClaw、Trae、Chatbox、WorkBuddy 等入口。第一次接入不需要自己猜环境变量和接口路径，先按对应工具的页面操作即可。
我先在 CC Switch 里添加 AiiOnly。Claude Code 的请求地址填写服务端点 https://llm.aiionly.com，不要把完整的 /v1/messages 再拼进去；API 格式选择 Anthropic Messages，认证字段使用 ANTHROPIC_AUTH_TOKEN。
Claude Code 的模型菜单有 Sonnet、Opus、Fable、Haiku 等角色槽位，我把它们分别映射到 DeepSeek-V4-Pro、DeepSeek-V4-Flash、GLM-5.2 和 Kimi-K3。这样切换的是 Claude Code 里的角色，真正发给平台的则是右侧配置的实际模型 ID。
这里有两个配置细节容易混淆。CC Switch 的“请求地址”需要的是服务端点，所以填写 https://llm.aiionly.com；平台控制台提供的 https://llm.aiionly.com/v1/messages 则是实际请求使用的完整接口。如果工具会自动拼接路径，再手动填入 /v1/messages 就可能造成地址重复。模型映射右侧也要使用控制台给出的真实 ID，例如 deepseek-v4-pro，不能只照着套餐页面上的中文或大写展示名称输入。
保存前我先做了连通测试，CC Switch 返回 aiionly 连通正常（29ms）。这个数字反映的是当时接口连通延迟，不是模型生成完整答案只用了 29ms，但至少能快速排除地址无法访问、网络中断和认证信息完全无效等基础问题。
连通正常之后仍然要跑一次真实对话，因为测速并不会验证每个模型都支持当前协议。地址能访问，但模型没有适配 Anthropic Messages、模型 ID 写错或工具附带的请求字段不兼容，仍可能在生成阶段报错。我的检查顺序是先确认服务端点，再核对 API 格式和模型 ID，最后用一句最简单的问候测试返回内容。这样遇到问题时能判断是连接层、协议层还是模型层，不用反复更换 Key 碰运气。
重新进入 Claude Code 后，模型菜单已经出现刚才配置的四个实际名称。这里的好处很直接：同一个项目不需要退出工具或更换账号，/model 里就能在 DeepSeek、GLM、Kimi 之间切换。四个槽位只是当前 Claude Code 菜单里的映射，并不代表套餐只能用四个模型；其余模型可以按任务需要重新配置到对应角色。
菜单里的 [1m] 是 CC Switch 向 Claude Code 声明的上下文能力标记，是否真的适合把超长项目一次全部放进去，还要结合模型本身的上下文规格、平台限制和 Credits 消耗判断。第一次验证没有必要直接塞入整个仓库，我选择 DeepSeek-V4-Flash 做了一个最小对话测试，先确认请求能从 Claude Code 到达正确模型并返回可解析内容。
模型正常回复后，Claude Code 顶部也能看到当前使用的是 deepseek-v4-flash[1m]。一句“你好”当然不能证明它能完成复杂工程，但可以确认 Anthropic Messages 接口、CC Switch 映射和套餐 Key 已经连通。等这条基础路径稳定，再让模型读取项目和执行工具，排查成本会低很多。
后端开发时，我会优先把核心架构和复杂逻辑交给 DeepSeek-V4-Pro，日常修改则切到 Flash；需要一次读入更多项目文件时，再换 GLM-5.2 或 Kimi-K3。它不要求每个项目绑定唯一模型，分工可以跟着任务变化。
再接入 Codex，让 Kimi-K3 完成前端任务
接着我把同一份套餐接到 Codex。这里走的是 OpenAI Chat Completions 协议，而不是 Responses API。Codex 菜单仍显示它熟悉的模型槽位，我在配置中把这些槽位映射到 AiiOnly 的实际模型：DeepSeek-V4-Pro、Kimi-K3 和 GLM-5.2。
这次选择的是 gpt-5.4 槽位，它实际对应 Kimi-K3。我让它在空目录创建一个原生 HTML、CSS、JavaScript 的“AI 编程任务看板”，包含三个任务、状态筛选、进度切换和响应式布局，不使用构建工具和前端框架。
Codex 接到任务后直接创建 index.html、style.css 和 script.js。从任务要求到开始写文件都保留在同一个会话里，当前模型槽位也显示在任务上方。
生成的页面可以直接在浏览器打开，筛选按钮、任务状态和总进度都能交互。页面卡片里的 GPT-5、Claude Sonnet 4 和 Gemini 2.5 Pro 是这个演示看板的静态任务数据，不是本次请求实际调用的模型；真正完成页面生成的是前面映射的 Kimi-K3。
回到 Token Plan 的模型明细，Kimi-K3 的请求次数是 1，文本输入约 0.013921M Token，文本输出约 0.01322M Token，消耗 25,884.02 Credits。这组数据把工具端和平台端对应起来了：Codex 里完成的一次前端任务，确实进入了同一个 Standard 月度池。
到这里，两套工具就都跑通了。Claude Code 用 DeepSeek，Codex 用 Kimi-K3，消耗都从同一个套餐里扣。以后想换成新加入的 GLM-5.3，也只需要改一下模型映射。
最后提醒
Standard 每月有 6,320,000 Credits，QPS 为 2，不同模型的扣减倍率也不一样，并不是无限用。套餐购买后不支持退款和降配。Token Plan 只限 OpenClaw、Claude Code 这类交互式智能体和编程工具使用，不能拿套餐 Key 跑自定义应用后端、自动化脚本或批量调用。
对我来说，一个月只管这一份额度，比同时盯着几家会员舒服多了。
