做了个按任务分组的模型 API，让 Agent 小活别再吃掉大预算

爱意满满的作品展示区。

大家好，分享一下最近做的 XCoffee： https://api.xcoff.ee

起因：我用 Agent 写代码，发现账单里大部分是重复小活。规划用好模型值得，但让同一个模型去做格式化和字段提取，太浪费。

所以做了三个任务组：快速（ 0.5×）、编码（ 1.3×）、默认（ 1×）。换个 Base URL 和模型名就能接，支持 OpenAI Chat Completions / Responses 、Anthropic Messages 、Gemini 原生接口。

¥50 / 30 天，支付宝；海外可用 PayPal $8
每天 300 积分，每小时上限 100 ，北京时间 8 点重置
不足：

组内模型自动路由，不能指定
并发 4 、每分钟 120 次，不适合大批量生产流量
不含文件上传、存储会话等

欢迎拍砖。

模型

任务

Agent

1 replies

awendujitang

2 days ago

补一条数据（楼主更新）

价格更正：帖里 ¥50/30 天是旧价，现在 ¥30/30 天（支付宝，海外 PayPal ）。额度没变：每天 300 积分、滚动 1 小时上限 100 、北京时间 8 点重置。三组倍率也没变：快速 0.5× / 编码 1.3× / 默认 1×。

今天跑的一轮实测（ Standard key ，70 次请求）：
· 快速组 30/30 成功，p50 2.7s ，p95 20.9s
· 编码组 20/20 成功，p50 2.0s ，p95 4.2s
· 默认组 19/20 成功（ 1 次 Cloudflare 502 ），p50 4.0s ，p95 5.9s
四种协议实测全部 200：OpenAI Chat Completions / Responses 、Anthropic Messages 、Gemini 原生。

顺带一个自测 failover 的方法（对任何中转站都适用，不只我这家）：
1. 让其中一个上游故障（把它的 key 换成必 429 的）
2. 发一个正常请求
3. 看返回：错误体里出现 provider 名 / rate limit / idle timeout → 说明 failover 没生效，错误原样甩给你；正常返回且请求落在组内其他上游 → 生效
多数中转站宣称的 failover 卡在第 3 步。这条比价格和倍率更值得较真。

限制不变：组内模型自动路由、不能指定；并发 4 、每分钟 120 次；不含文件上传和会话存储。