服务条款
你与我们之间关于 akrouter 的主协议。买方与卖方共同适用，商户另需接受商户协议。
- 生效日期
- 2026-07-22
- 最近更新
- 2026-07-22
- 文本修订
- 1.0
1.合同双方与文本效力
1.1
本服务条款（下称「本条款」）是你与 AK Router（下称「我们」）之间就 akrouter 服务达成的协议。
1.2
本条款自页面顶部标注的生效日期起适用，版本号见同一处的「文本修订」。 我们保留历史版本；你可以就任一具体版本向 [email protected] 索取存档。 条款如何变更、变更前我们怎么通知你，见第 15 章。
1.4
本文本以中文为准。若我们提供英文或其它语言译本，仅供参考； 译本与中文本不一致时以中文本为准。
2.服务说明
这一章界定我们到底提供什么。它同时也是后面责任限制（第 13 章）的事实基础。
2.1
akrouter 是 LLM API 聚合网关与双边商户市场。 我们在
https://api.akrouter.com 上暴露三套原生协议入口：POST /v1/messages（Anthropic）、POST /v1/responses（OpenAI Responses）、POST /v1/chat/completions（OpenAI Chat）； 控制台与市场页在 https://akrouter.com。 收到请求后我们按路由策略选择一条上游渠道，把请求转发过去，并把响应回传给你。2.2
模型推理由上游完成，不由我们完成。上游渠道可能来自模型厂商的官方 API、转售商，或第三方商户在我们市场上架的渠道。 我们不训练、不托管、不微调模型。
2.3
我们在同协议下原样转发请求，尽量不改写你的报文。 当没有同协议渠道可用时，我们可能走跨协议翻译的降级路径 ——翻译是有损的（扩展思考内容、缓存断点、工具调用 id 对齐、beta 特性开关都可能受影响）， 我们会在请求日志中标记该次请求已翻译。你可以在路由策略中禁止翻译路径。
2.4
我们会在多条渠道之间做容灾与并发调度：一条渠道失败时自动改换其它渠道重试。客户端错误（400/413/422 一类）绝不跨渠道重试，会直接回传给你 —— 重试一个你自己发错的请求，只会让你多付钱。
2.5
对外模型名、价格、可用渠道、市场展示的成功率与延迟均可能随时变化。 模型列表与价格以站内当时展示的为准。
3.我们的角色：平台与服务提供方的分界
双边市场里最容易含糊、也最容易在出事后引发争议的一条： 出了问题该找谁。这一章给出答案。
3.1
对你（买方）而言，我们是服务提供方。你与我们之间存在直接的合同关系：我们向你收费、向你出具用量与账单、 对计费准确性负责、按隐私政策所述的措施保护你的账户与数据， 并对路由是否按本条款与你设定的策略执行负责 （不是对被选中的那条上游的响应质量负责，见第 3.2 条）。你不需要与任何商户建立合同关系，也不需要向商户付款。
3.2
对上游供给而言，我们是聚合与路由平台。商户是独立经营者，其渠道的模型真实性、稳定性、以及其自身获取上游能力的 合法性由商户负责。我们对商户执行入驻审核、自动探测与持续监测 （见 商户协议），但这是尽力而为的风控， 不是对每一次上游响应质量的担保。
3.3
结算与合规的对接窗口在我们这里。具体包括：向你收取的费用由我们计算并对账、 商户的分成由我们结算、滥用举报由我们受理并按可接受使用政策处置、 执法请求由我们接收并按法律处理。你不需要为这些事去找商户；至于我们与商户之间如何分担由此产生的责任， 属于我们与商户之间的内部约定，不影响你向我们主张权利。
4.账户
4.1
注册需要一个可用邮箱。你应保证注册信息真实，并及时更新。 我们通过该邮箱发送密码重置、邮箱验证与必要的服务通知。
4.2
年龄要求：你须年满 18 周岁且具备完全民事行为能力。本服务面向开发者，采用预付费并涉及付款义务，我们不接受未成年人开立账户。 若适用法律就订立此类合同规定了更高的年龄门槛，以该规定为准。 若你代表机构使用本服务，你应保证已获得该机构的授权。
4.3
账户下发生的一切行为由你负责，包括你的雇员、承包方或任何持有你 API Key 的人发起的调用。你应妥善保管口令与 Key，发现泄漏后应立即在控制台吊销相应 Key。
4.4
我们不禁止你在团队内共享账户，但账户不可转让或出售。 以规避封禁、规避额度或规避风控为目的注册多个账户属于违规，见可接受使用政策。
5.API Key
5.1
API Key 的明文只在创建时显示一次。我们服务端只保存它的 SHA-256 摘要与 用于识别的前缀（形如
ak-live-…），页面上只显示前缀。我们无法找回你的 Key，丢失只能吊销后重建 —— 这是刻意的设计，不是缺陷。5.2
你的 Key 不会被转发给任何上游或商户。我们在转发请求前会剥离下游认证头（
authorization、x-api-key 等），换成该渠道自己的凭据。 这是系统强制执行的行为，不是可以关闭的选项。5.3
每个 Key 可以单独设置允许调用的模型、速率与并发上限、价格上限、路由策略， 以及调用来源 IP 白名单（设了之后来自其它 IP 的调用一律拒绝， 这是把 Key 泄漏的后果限制在你自己的出口 IP 之内最有效的一招）。Key 级设置与账户级设置合并时，收紧型限制取更严的一方 —— 你不可能通过 Key 级设置放宽账户级的硬性限制。
5.4
我们可在你的 Key 出现异常调用特征（凭据疑似泄漏、异常速率、命中滥用规则）时 限流或吊销该 Key，并尽可能通知你。
6.计费与余额
完整的计费口径见计费文档，本章只写具有约束力的部分。
6.1
预付费，不赊账。你先充值获得额度，调用按 token 从余额中扣减。 余额不足时新请求被直接拒绝（HTTP 402），我们不提供透支或事后结算。
6.2
请求执行期间会有一笔在途预扣。请求开始时我们按本次可能的最高花费预扣一笔额度（按你的策略允许的最贵渠道、 按输出拉满估算），请求结束后按实际用量结算，未用完的部分立即释放。预扣的目的是让并发请求不能把余额花成负数。
所以余额看起来够，仍可能被拒
控制台显示的余额不扣除在途预扣（否则它会在请求期间上下跳动，无法解释）。 余额不足的错误信息里会同时给出在途占用的金额，两者相加等于控制台上的数字。 并发越高、单次请求的上界越大，被在途预扣占住的部分越多。
6.3
充值到账与网关生效之间有短暂滞后。鉴权层的密钥与余额缓存有数十秒量级的有效期， 因此刚充值完的极短时间内仍可能收到余额不足的错误，稍后重试即可。 同理，吊销一把 Key 也可能延迟数十秒才在网关侧完全生效。 这是如实告知的工程事实，不是缺陷 —— 但它不会造成反向后果： 权威的扣费闸门直接读实时余额，不存在"余额不足却放行"。
6.4
计费口径：被选中渠道的报价 + 平台费。一次请求的费用等于路由实际选中的那条渠道的报价乘以本次用量， 再加上一笔按比例计算的平台费。两部分在你的账单与请求日志里分开记录， 你可以看到一次请求里有多少是平台收的。
因此同一模型的单价不是固定的
不同渠道的报价不同，路由选到哪条，你就按哪条计费。 价格页展示的是起价—— 在架渠道的最低报价加平台费， 它按构造等于你走到最便宜那条渠道时的实收价，不是所有请求的统一价。
要给费用设上界，靠的不是价目表而是成本护栏（第 7 章）： 单次请求花费上限、绝对单价上限、相对最低价的倍数上限。 超出上限时我们让请求失败，而不是替你花钱。
6.5
当前的平台费率是 10%，按被选中渠道的报价计算后加收。 本页展示的是此刻实际生效的值，与控制台、价格页读的是同一个配置项。
费率调整不设提前通知期，与条款变更不是一回事
平台费率的调整在生效时即时适用，我们不承诺提前通知。第 15 章的 10 天提前期约束的是本条款文本本身的实质性不利变更， 不覆盖费率调整 —— 别把两者混在一起读。
对你的实际保护是另外两条，它们是硬的：费率调整对已经发生的请求没有溯及力（一次请求按它发生时生效的费率计费）； 以及你的成本护栏在费率变化后照常生效 —— 单次请求花费上限按含平台费的金额判定，费率涨了只会让更多请求被护栏挡下， 不会让你在无感知的情况下多花钱。
另外，费率读取失败时结算按 0 计算 —— 这是刻意的方向：宁可少收，不可多收。
6.6
市场页展示的倍率是相对第三方公开基准价换算出的参考数字，不参与任何计费或结算，仅用于横向比较。
6.7
我们在系统内部始终分别记录两笔金额，二者不会被合并：
| 金额 | 含义 | 与你的关系 |
|---|---|---|
| 上游成本 | 我们实际付给上游服务商的钱，含全部失败尝试与中断续写的重复部分 | 不进你的账单 |
| 向你收取的金额 | 逻辑上的一次请求应向你收取的金额 = 选中渠道的报价对应部分 + 平台费 | 这就是你的账单金额 |
结论：容灾多花的钱由我们承担，不转嫁给你。一次请求哪怕在内部换了五条渠道，也只按一次向你计费。
6.8
没有产生输出的失败请求不计费。连接失败、首字节前超时、上游 5xx、 被成本护栏拒绝的请求都不向你收费。已经产生输出后中断的请求按已产生的 token 计费 —— 那部分算力我们已经付过钱了。你主动断开连接（
client_aborted）同理。6.9
token 计量优先采用上游返回的 usage 并做交叉校验； 对 usage 缺失或不可信的上游类型，以我们本地计量为准。本地计量存在正常范围内的误差， 我们按同一套口径对所有用户执行。
6.10
金额在系统内以定点整数存储，精确到小数点后 6 位美元，全程不使用浮点数。 展示时的四舍五入不改变实际扣费。
6.11
账本仅追加。你的余额是账本流水的求和，任何一次充值、消费、退款、 人工调整都是一条不可修改、不可删除的流水，且带幂等键 —— 同一次请求或同一笔支付无论重放多少次都只会记一条。 我们运行定期对账任务校验缓存余额与账本的一致性。
为什么把这个写进条款
它是你能核对账单的前提：出现分歧时我们双方看的是同一份不可篡改的流水， 而不是某个可以被就地修改的余额数字。计费争议的处理流程见退款政策。
6.12
渠道报价由商户自行调整，平台费率由我们调整，两者都可能随时变化，都不设提前通知期。你能依赖的是另一件事：价格变动对已经发生的用量没有溯及力 —— 一次请求按它发生时生效的价格与费率计费。 要在价格变动时保护自己的成本，用的是第 7 章的成本护栏，而不是等我们的通知。
6.13
支付由第三方支付服务商处理，我们不接触你的完整卡号。各支付通道的销售主体（Merchant of Record）如下：
| 支付通道 | 法律意义上的卖方 | 税务与拒付由谁承担 |
|---|---|---|
| 易支付（支付宝 / 微信） | AK Router | 我们 |
| Stripe（银行卡） | AK Router | 我们 |
| creem.io（银行卡） | creem.io | creem.io |
银行卡通道由我们在后台切换，因此以你在结账页面上看到的收款方名称为准 —— 那一方就是该次交易法律意义上的卖方。 走 creem.io 的交易由它开具票据、代缴销售税并处理拒付； 退款仍可向我们提出，由我们发起并协助对接（见 退款政策）。无论走哪条通道，你的账户额度与本条款项下的其它权利义务都不受影响。
7.成本护栏与路由策略
这一章写的是一个反直觉但刻意的取舍，必须让你在事前知道，而不是在账单上发现。
7.1
你可以在账户级与 Key 级设置成本护栏，包括单次请求花费上限、 绝对单价上限、相对最便宜渠道的倍数上限，以及可用渠道的范围。
7.2
单次请求花费上限按"最坏情况的上界"判定，不是按事后的实际花费判定。我们在请求发出前无法知道模型会输出多少 token，因此按你的策略允许的最贵渠道、 按输出拉满来估算，估算值超过上限就拒绝。 后果是有些实际花费不会超限的请求也会被拒 —— 这是刻意的： 一个"事后才发现超了"的上限不是上限。
7.3
成本护栏优先于可用性。当所有满足你护栏的渠道都不可用时， 我们拒绝这次请求并返回错误，而不是替你落到更贵的渠道上。 这会提高失败率，是设计意图 —— 在聚合市场里， 便宜渠道集体故障后静默落到贵几十倍的渠道，是比请求失败严重得多的后果。
7.4
因此：由你自己的护栏或渠道范围设置导致的请求失败，不属于服务故障， 不构成退款或补偿事由。我们会在错误响应与请求日志中说明被过滤的原因。
7.5
你可以在请求中带
X-Akrouter-Metadata: enabled获取本次请求的路由元数据（候选池大小、被硬过滤与被降权的渠道数、 每次尝试的渠道与错误分类）。这是排查"为什么这次失败/为什么选了这家"的依据。8.服务可用性
8.1
我们目前不提供服务等级协议（SLA），也不对任何可用率数字作出承诺。我们没有足够长的运行历史来支撑这样的承诺，因此不做。 详细说明见 可用性声明。
8.2
状态页与市场页展示的成功率、延迟、正常运行时间是已发生的被动统计结果， 口径公开，但它们是历史数据，不是对未来表现的承诺，也不构成条款的一部分。
8.3
我们会进行计划内维护与紧急维护。部署时我们会等待进行中的流式请求结束再停机， 但这不排除意外中断的可能。维护通知方式见第 15 章。
8.4
服务按「现状」与「现有可用」提供。在适用法律允许的范围内， 我们不对适销性、特定用途适用性或不侵权作出默示保证。
9.你的内容
9.1
你发送的请求内容与收到的响应内容，归属关系不因经过我们而改变。我们不主张对它们的所有权。你授予我们的，仅限于为提供服务所必需的处理与转发权利。
9.2
你的请求内容会被转发给被路由选中的上游 —— 包括第三方商户。这是聚合网关的工作方式，无法回避。转发范围、我们是否留存、 上游可能如何留存，全部写在 隐私政策 第 3 章。请在发送前阅读那一章。
9.3
我们不存储请求正文与响应正文。我们记录的是结构化元数据 （时间、模型、token 数、金额、选中渠道、错误分类等），不含你的 prompt 与模型输出。 具体字段清单见隐私政策。
9.4
我们不使用你的请求内容训练模型 —— 我们不训练模型。 但上游各自的政策独立适用，我们无法代它们作出承诺。
9.5
你保证你提交的内容不违反法律、不侵犯第三方权利，且你有权将其提交给我们与上游处理。 模型输出可能不准确、不完整或具有冒犯性；你对如何使用输出负责，尤其是在医疗、法律、金融等高风险场景中。
10.上游、商户与第三方服务
10.1
上游服务商（含商户）各自的使用政策与你同时适用。 当两者的限制不一致时，以更严格的一方为准。 典型例子：某上游禁止的用途，即使我们的政策没有明确禁止，你也不得通过我们去做。
10.2
我们对商户执行审核、自动探测与持续监测，并在检出问题时降权或下架。 但我们不对商户所提供内容的准确性、模型的真实性或其上游合规性作出担保。 如果你对某条渠道有疑虑，可以在路由策略中排除它或只使用已认证商户。
10.3
我们使用第三方服务来运行本平台（支付、错误监控、指标采集、邮件等）。 清单与各自接触到的数据见 子处理方清单。
11.知识产权
11.1
本平台的软件、界面、文档与商标归我们或相应权利人所有。 本条款不向你转让任何这些权利。
11.2
你不得对本服务进行反向工程、抓取、批量导出市场数据用于构建竞品， 或以自动化手段规避速率限制。
11.3
你可以在推广材料中说明你使用了 akrouter，但不得暗示我们对你的产品背书。
12.限流、暂停与终止
12.1
我们可以在以下情形限制、暂停或终止你的账户或某个 Key：
- 违反本条款或可接受使用政策
- 调用行为危及平台或上游的稳定性
- 支付争议、拒付或疑似欺诈
- 法律或上游服务商的要求
12.2
处置应当与情节相称。除非情况紧急或涉及明显违法， 我们会优先采用限流或暂停单个 Key 等较轻的手段，并说明原因。 紧急处置后我们会尽快补充说明。
12.3
你可以通过 [email protected] 对处置提出申诉。 我们会在合理时间内复核，并把结论告诉你。
12.4
终止后：你的 API Key 立即失效；账本与用量记录按隐私政策的保留期限保留； 未消费余额的处理见 退款政策。因违规被终止时，未消费余额默认仍可退，只有退款政策第 4.6 条穷尽列举的严重违规与违法情形才不予退还，且该认定由人做出并可申诉。
13.免责与责任限制
13.1
在适用法律允许的最大范围内，我们不对间接损失、附带损失、后果性损失（包括利润损失、数据损失、业务中断、商誉损失）承担责任， 无论我们是否被告知过此类损失的可能性。
13.2
我们在本条款项下的累计责任上限为 索赔发生前 12 个月内你实际向我们支付的费用总额。 我们是预付费的低客单价服务，这个上限与你实际承担的对价相称； 它不适用于第 13.4 条列举的依法不可排除的责任。
13.3
以下情形我们不承担责任：上游服务商的故障、变更或政策调整； 由你自己的成本护栏或渠道范围设置导致的请求失败； 你未妥善保管凭据导致的损失；模型输出的内容本身。
13.4
本章不排除依法不可排除的责任，包括故意或重大过失导致的损害、 人身伤害，以及适用消费者保护法下不可排除的权利。
13.5
不可抗力（自然灾害、战争、罢工、政府行为、大规模网络或云服务中断等） 导致的不能履行，双方互不承担违约责任，但受影响方应及时通知对方。
14.赔偿
14.1
因你违反本条款、违反可接受使用政策，或因你提交的内容侵犯第三方权利而引起的第三方索赔，你应赔偿我们由此产生的合理损失与费用。
这一条针对的是什么
典型情形：你用本服务生成针对特定真人的诽谤内容而被对方连带起诉； 你在请求中提交了他人享有著作权的作品而权利人向我们主张侵权； 你把本服务集成进自己的产品转售，而你的最终用户因你的承诺起诉我们。 这些情形的共同点是损失由你的行为造成，账单却先寄到我们这里。
它不是一张空白支票。触发它需要三件事同时成立：存在第三方的实际索赔、 该索赔源于上述违规行为、且违规与损失之间有因果关系。 你正常使用本服务而引发的任何主张，不在本章范围内。
14.2
我们收到此类索赔后会及时通知你，并给予你参与抗辩的机会； 未经你同意，我们不会就该索赔达成使你承担付款义务的和解。我们未及时通知你、以致你丧失抗辩机会的，你不承担因此扩大的部分。
14.3
以下情形你不承担本章义务：
- 索赔源于我们自身的过错、我们的路由或计费行为，或我们与商户之间的关系
- 索赔源于我们未按本条款履行义务
- 索赔与你的违规行为之间不存在因果关系的部分
14.4
你是个人用户而非商业主体时，本章的赔偿责任以你在索赔发生前 12 个月内实际向我们支付的费用总额为限，与我们在第 13.2 条项下的责任上限对称。 我们把这个对称写进条款，是因为一份只有一方封顶的赔偿条款， 在多数辖区面对个人用户时本来就难以执行 —— 与其写一个可能被整条判无效的版本， 不如写一个真能用的。
15.条款变更与通知
15.1
我们可以修改本条款。实质性不利变更（缩减服务范围、增加你的义务、 限制你的救济途径、改变余额或退款规则）我们会提前至少 10 天通过邮件或控制台内通知。 非实质性变更（错别字、措辞澄清、新增说明性内容、对你更有利的调整）自发布时生效。
15.2
★ 本章管的是条款文本，不管价格。平台费率与渠道报价的调整不适用上述 10 天提前期，它们即时生效（见第 6.5 条）， 当前费率始终以控制台与价格页实时展示的为准。 把两者写在一起会让人以为涨价也要等 10 天，那是我们兑现不了的承诺。
15.3
你不接受变更时的退出方式：在变更生效前停止使用并申请注销账户。 变更生效后继续使用，视为接受。
15.4
我们发出的通知以你在账户中登记的邮箱为准， 或以控制台内的显著提示为准。你应保证邮箱可用。
15.5
每一版文本都会更新页面顶部的修订号与更新日期。 我们保留历史版本以便你比对。
16.适用法律与争议解决
16.1
适用法律：本条款适用我们运营主体注册地的法律，不适用其冲突法规则。 我们的注册地与注册信息可通过 [email protected] 索取。
16.2
先协商。发生争议时，双方应先通过 [email protected] 友好协商， 期限为一方书面提出之日起 30 天。 绝大多数争议是计费分歧，而计费分歧我们有账本、请求记录与幂等键可以直接核对 （见 退款政策 第 5 章）—— 走完这一步通常就不需要下一步。
16.3
协商不成的，提交我们运营主体注册地有管辖权的法院诉讼解决。
16.4
我们不主张这一条在所有情形下都拦得住。如果你是受你所在地消费者保护法保护的个人用户， 该法律通常规定你有权在自己所在地起诉，且这项权利不能被合同排除 ——本章不减损任何此类不可放弃的法定权利。 我们如实写出这一点， 而不是印一句看起来很强、真到用时却无效的管辖条款。
16.5
不接受集体诉讼与代表人诉讼的合并：在适用法律允许的范围内， 双方仅以各自的名义就自身的争议提出主张，不将争议与他人的争议合并审理。
17.其它
17.1
可分割性：本条款某一条被认定无效或不可执行的，不影响其余条款的效力， 该条应在最接近原意的范围内作最小限度的调整。
17.2
不弃权：我们未行使或延迟行使某项权利，不构成对该权利的放弃。
17.3
转让：未经我们书面同意，你不得转让本条款项下的权利义务。 我们可以在业务合并、收购或资产转让时转让本条款，并会提前通知你。
17.4
完整协议：本条款连同第 1.3 条所列附属文本构成双方就本服务的完整约定， 取代此前的口头或书面沟通。
17.5
联系方式：[email protected]。 一般事务、隐私事务、滥用举报与执法请求目前都收到这一个地址 —— 我们没有分设收件人的规模，写四个邮箱只会让其中三个没人看。 请在主题里写明事由（如「执法请求」「滥用举报」），我们据此分流。