Freebuff2API 控制台

1. 浏览器登录 freebuff.com
2. 按 F12 打开开发者工具 → Network 标签
3. 刷新页面，点任意请求 → Headers → 找到 Cookie: 开头那一整行
4. 整行复制，粘贴到上面的框里，点「导入」
5. 也可以在 Application → Cookies → https://freebuff.com 里逐项复制（需要包含 __Secure-next-auth.session-token）

客户端（Claude Code / Cursor）把 OpenAI 或 Claude 格式的请求发到本地 47821 端口。 网关先解析模型名 → 从账号池挑健康账号（评分 + 熔断状态）→ 确保该账号在上游有活跃会话 → 把请求改写为上游格式（注入 run 元数据、按模型校正思考档位、拼上提示词/技能/记忆） → 转发上游，再把响应（流式）实时转回客户端格式。

每个账号有独立的健康分与熔断器（Closed / Open / HalfOpen 三态）：连续失败 4 次自动断开， 冷却随断开次数指数增长（封顶 10 分钟）；冷却结束进入半开状态放行探测，连续成功 2 次恢复。 请求失败会自动换号重试（最多 3 次）——但只在"尚未向客户端写出任何字节"之前重试， 绝不会把半截响应写给你。

注入顺序：基础提示词 → 启用的提示词 → 技能 roster（名称+描述）→ 记忆块（低权威）， 拼成一条 system 消息放最前面。技能与记忆有严格预算（默认 2000 / 512 token），超出整条丢弃， 避免"越装越贵"。记忆按你当前的问题检索（本地 trigram 全文索引，支持中文）。

每次请求都记录：路由决策（请求模型→实际模型→账号）、上游状态码、首字节时间、总耗时、token 用量、 错误类型与片段。在「总览 → 最近请求」点任意一行看细节与人话解释；「实时日志」页实时推送 正在发生的事（断线自动补发）。

上游免费层通过"会话 + 广告刷新"维持额度：网关每 45 秒心跳，会话剩余不足时触发广告刷新延长。 出现 waiting_room_queued 表示上游在排队——不是网关故障，稍等重试或多加账号提升并发。

每次对话在上游都会生成一个 thread。网关记录自己创建的 thread，并每小时清理超过 24 小时的旧会话（thread_cleanup_interval_sec / thread_max_age_hours 可调，间隔设 0 关闭）——避免反代长期堆积给上游制造压力。 也可在「原理」页对应的 API 手动预演：POST /api/threads/cleanup {"dry_run":true}。

全部本地：data/freebuff2api.sqlite（用量）、data/telemetry.sqlite（请求详情）、 data/memory.sqlite（记忆）、data/skills/（技能 Markdown，真相源）、 data/tokens.json（凭证）。备份或整体删除即可重置。