同一份请求,3 个 API key 排队 400 失败 3 次才告诉你请求体有问题,白白消耗 3 份 token。429 限流时又密集轮询 3 个 key 把上游打爆。扒 model-router.service.ts:classifyError 把上游错误分成 9 类,bad_request 硬拦截不重试、rate_limit 走 1/2/4s 阶梯 + provider 停用 60s 起指数封顶 5 分钟,以及为什么 billing_error 要整组停用而不是只换一个 key。
提交返回的 task_id 拿不到图/视频，是 wuyin 没跑完还是代理提前放弃？源码逐行：同步轮询（图片）vs 异步分步（视频）的两套 client 模型、GET→POST 405 兜底、status 枚举没有常量、submit 阶段双鉴权。
为什么 agent 跑长任务会被 idle timeout 误杀？为什么日志里 'LLM idle timeout (120s): no response from model' 出现时上游其实没事？源码逐行：管道心跳、上下文自动截断、4xx 错误透传上游 body。
把同一个请求在 3 个 key 之间轮询、遇到特定错误跳过熔断、整组限流就停 30s——这套机制是 LLM 代理的「心脏」。源码解读 + 你自己的代理可以怎么照搬。
怡途Claw APP 端课程三接口（/api/app/courses、/{slug}、/categories）的难点不在调用而在过滤参数：难度有两套词表、分类比较连一个空格都容不下、分页其实是内存里 slice。这篇逐条对照 docs/app-api.md 和 src/lib/blog-service.ts，讲清每处差额的来龙去脉和客户端的最稳传参姿势。
怡途Claw APP 端的学习进度同步看着只有 GET / POST 两个接口，但全量替换语义 + device_id 标识 + 缺事务这三个决定一起决定了"为什么换台手机进度会丢、为什么网络抖一下历史就清空"。这一篇把 docs/app-api.md 第三章的承诺和 `src/app/api/app/progress/route.ts` 的实现之间那点没说清的差额，一次讲完。
怡途Claw APP 端的博客四个接口（list/detail/categories/tags）看着只是 GET 包装，但 blog-service.ts 在分页、分类过滤、标签聚合、质量过滤上各埋了一处和文档承诺不一致的差额。客户端上线前最好把这些差额捋一遍，否则列表里看到的文章和详情接口拿到的可能是两份数据。