windows的codex app今天更新完为什么发送消息这么慢？要等一分钟才能发出去 1 个帖子 - 1 位参与者 阅读完整话题
一直不太习惯L站的私信页面，在IDC Flare里面看到聊天的页面可以发送直接消息，就像是其他聊天软件一样的聊天页面，但是在L站上面没看到，有知道L站怎么发送直接消息的佬吗 IDC Flare直接消息页面截图 但L站上面只有频道，没有直接消息 3 个帖子 - 2 位参与者 阅读完整话题
使用code app发送消息的时候 发送按钮要转圈一会儿才能发出去 体验及其不好 佬友们有遇到过吗？ 2 个帖子 - 2 位参与者 阅读完整话题
今日，香港天星银行向全体客户发送了一封关于卡收费表收费的邮件。邮件内提到了要新增一项关于“安心卡”服务的收费。 目前官网和手机银行内均未更新相关说明，经与客服沟通得知该服务详情如下： 安心卡是一张可按使用场景快速创建的虚拟借记卡，拥有独立卡号与独立限额，帮助用户把高风险支付与主力卡隔离，实现更安全的支付与更清晰的财务管理，卡片随用随销。 申请费用为每张 HKD 19.9 / 年； 使用有效期为自申请之日起 12 个月； 于安心卡使用有效期内销卡后，可免费重新申请安心卡； 可持有的卡片数量、申请、更换或删除安心卡的总次数可在上线后于官方网站的「帮助中心」＞「消费」得知。 新的收费表于 2026 年 4 月 23 日起生效，推测该服务可能于该日上线。 感谢 xhs@流星雨. 投稿 转自encmasuta 1 个帖子 - 1 位参与者 阅读完整话题
AnyRouter Claude Code 验证机制分析 本文档记录了通过逐步删减请求字段、实际发送请求测试，得出的 AnyRouter 对 Claude Code 请求的验证机制。 测试日期：2026-03-16 起，持续追加 测试方法：以完整的 Claude CLI 请求为基准，逐个移除字段并观察响应状态码（200 = 通过，500 = 拒绝） 重要提醒：验证机制具有时变性与灰度特征 AnyRouter 的验证逻辑经过多次反复调整， 任何结论都不应被视为长期稳定 ： 请求头校验可能被启用或取消（如 anthropic-beta 从"可选"变为"必需"） 白名单策略可能被启用或撤销（如 session_id 白名单上线又下线） user_id 格式曾整体变更（扁平字符串 → JSON 字符串） 同一时段内不同 Key 行为可能差异巨大（被封禁/限流的 Key 返回 520/503，正常 Key 返回 200） 不同模型的上游可用性独立变化（旧模型下线、新模型灰度上线） 部分校验存在 灰度/后端负载 相关的不稳定行为 使用建议 ： 代理实现应默认携带"完整最小必需集"（见后文），而非依赖某次测试得出的"可省略"结论 遇到非预期错误码时，优先换 Key / 换模型 / 换时间重试，再排查请求体 本文档中旧结论凡被推翻的，均以「已失效 / 已变更」标注并保留，用于回溯演变轨迹 一、验证结论总览 AnyRouter 的验证 只检查请求体 ，不检查请求头。核心验证点仅有两个： system 数组中必须包含精确的 Claude Code system prompt metadata.user_id 必须符合特定格式 2026-04 更新 ：以上结论为早期测试结果。当前 AnyRouter 同时校验请求头 ， 缺少必需的 anthropic-beta 头（尤其是 context-1m-2025-08-07 标志）会直接返回 400。 详见下方「请求头新增校验」章节。 最小可通过请求 = 标准 Anthropic 请求 + system[0].text = "You are Claude Code, Anthropic's official CLI for Claude." + metadata.user_id = "user_{64位hex}_account__session_{UUID格式}" 补充：请求头新增校验（2026-04-11 确认） 400 错误：“1m 上下文已经全量可用，请启用 1m 上下文后重试” 错误现象 ： {"error":"1m 上下文已经全量可用，请启用 1m 上下文后重试","type":"error"} 所有模型、所有 Key 均返回 HTTP 400，与请求体内容无关。 根本原因 ： anthropic-beta 请求头中缺少 context-1m-2025-08-07 标志。AnyRouter 现在会检查此 beta flag 来确认客户端已启用 1M 上下文窗口。 解决方案 ： 在请求头中添加 anthropic-beta ，至少包含 context-1m-2025-08-07 ： anthropic-beta: context-1m-2025-08-07 Claude Code CLI 2.1.92 实际发送的完整 anthropic-beta 值（共 9 个 flag）： claude-code-20250219,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advanced-tool-use-2025-11-20,effort-2025-11-24,fast-mode-2026-02-01 各 flag 含义： Flag 用途 claude-code-20250219 Claude Code 专属标识 context-1m-2025-08-07 启用 1M 上下文窗口（ AnyRouter 必须校验项 ） interleaved-thinking-2025-05-14 交错思考模式 redact-thinking-2026-02-12 思考内容脱敏 context-management-2025-06-27 上下文管理 prompt-caching-scope-2026-01-05 提示缓存作用域 advanced-tool-use-2025-11-20 高级工具使用 effort-2025-11-24 输出努力程度控制 fast-mode-2026-02-01 快速模式 经逐项省略测试确认， anthropic-beta 是 唯一 必需的非标准头，其余头（ User-Agent 、 x-app 、 X-Stainless-* 、 anthropic-version 等）均可省略。完整测试结果见下方第二章。 测试对比 ： anthropic-beta 中包含 context-1m-2025-08-07 状态码 否 400（上述错误） 是 200 或 503（验证通过） 二、请求头测试详情 注意 ：以下为 2026-03-16 的旧测试结果，当时 AnyRouter 不校验请求头。 2026-04-11 重新测试发现 anthropic-beta 已变为 必需 头，详见下方更新。 旧测试结果（2026-03-16，已过时） （点击了解更多详细信息） 请求头结论（2026-04-11 更新） AnyRouter 现在校验 anthropic-beta 请求头。 缺少此头或其中不含 context-1m-2025-08-07 会返回 400。 逐项省略测试方法：以完整请求头为基准，每次仅移除一个字段，发送请求并记录响应状态码（自动重试 520）。每个字段测试 2 次有效结果。 移除的请求头 结果 结论 Accept 200, 200 可省略 User-Agent 200, 200 可省略 X-Claude-Code-Session-Id 520, 200 可省略 X-Stainless-Arch 200, 200 可省略 X-Stainless-Lang 200, 200 可省略 X-Stainless-OS 200, 200 可省略 X-Stainless-Package-Version 200, 200 可省略 X-Stainless-Retry-Count 200, 200 可省略 X-Stainless-Runtime 200, 200 可省略 X-Stainless-Runtime-Version 200, 200 可省略 X-Stainless-Timeout 200, 200 可省略 anthropic-beta 400, 400 必需 anthropic-dangerous-direct-browser-access 200, 200 可省略 anthropic-version 200, 200 可省略 x-app 200, 200 可省略 最小请求头： Content-Type: application/json Authorization: Bearer sk-xxx anthropic-beta: context-1m-2025-08-07 以下请求头全部为冗余，可安全移除： accept anthropic-version anthropic-beta anthropic-dangerous-direct-browser-access user-agent x-app x-stainless-arch x-stainless-helper-method x-stainless-lang x-stainless-os x-stainless-package-version x-stainless-retry-count x-stainless-runtime x-stainless-runtime-version x-stainless-timeout accept-encoding 三、URL 参数测试 # 变更 状态码 结论 9 移除 ?beta=true 200 可移除 URL 结论 直接使用 /v1/messages 即可，无需 ?beta=true 查询参数。 四、请求体 — system 字段测试 # 变更 状态码 结论 13 完全移除 system 500 必需 12 只保留一个 system 块（Claude Code prompt） 500 失败（因同时无 metadata） 15 一个 system 块 + 有 metadata 200 一个块就够 14 两个 system 块，无 cache_control 200 cache_control 不需要 18 第一个 system 文本改为 "You are a helpful assistant." 500 文本必须精确匹配 25 第一个 system 文本去掉末尾句号 500 句号不可省略 19 第二个 system 块文本改为 "anything" 500 若有第二块，必须为 "null" system 字段结论 必须 包含至少一个 system 块 第一个块的 text 必须 精确匹配 以下字符串（一字不差，含末尾句号）： You are Claude Code, Anthropic's official CLI for Claude. 第二个 "null" 块 可省略 （一个块即可通过） 如果保留第二个块，其 text 必须为 "null" ，不能是其他值 cache_control 字段完全不需要 最小 system： "system": [ {"type": "text", "text": "You are Claude Code, Anthropic's official CLI for Claude."} ] 五、请求体 — metadata 字段测试 # 变更 状态码 结论 10 完全移除 metadata 500 必需 26 metadata 为空对象 {} 500 必须包含 user_id 17 user_id = "test" 500 格式不对 20 user_id = "user_abc123" 500 长度不够 22 user_id = "user_{64位hex}" （无 session 后缀） 500 缺少 session 部分 21 user_id = 完整格式，不同哈希值 200 值任意，只校验格式 23 user_id = 全零占位值 200 全零也能通过 metadata 字段结论 metadata 对象 必须存在 metadata.user_id 必须存在 且符合以下格式： user_{64位十六进制字符}_account__session_{UUID格式} 不校验具体值 ，只校验格式（正则匹配） 全零占位值完全可用： "metadata": { "user_id": "user_0000000000000000000000000000000000000000000000000000000000000000_account__session_00000000-0000-0000-0000-000000000000" } user_id 格式拆解 user_ ← 固定前缀 "user_" 82a10c807646e5141d2ffcbf5c6d439ee4cfd99d1903617b7b69e3a5c03b1dbf ← 64 位 hex（SHA-256 哈希） _account__session_ ← 固定中缀 "_account__session_" 74673a26-ea49-47f4-a8ed-27f9248f231f ← UUID v4 格式 (8-4-4-4-12) 推测的验证正则： ^user_[0-9a-f]{64}_account__session_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ 六、请求体 — 其他字段测试 字段 测试结果 说明 messages 必需 Anthropic API 标准要求 max_tokens 必需 Anthropic API 标准要求 model 必需 Anthropic API 标准要求 messages 中的 "null" 文本块 可移除 简单字符串 content 即可 cache_control （system 和 messages 上的） 可移除 不参与验证 thinking 可选 只影响是否启用思考链 七、最终最小请求模板 curl https://anyrouter.top/v1/messages \ -H "Content-Type: application/json" \ -H "x-api-key: sk-xxx" \ -d '{ "model": "claude-opus-4-6", "messages": [ {"role": "user", "content": "Hello"} ], "system": [ {"type": "text", "text": "You are Claude Code, Anthropic'\''s official CLI for Claude."} ], "metadata": { "user_id": "user_0000000000000000000000000000000000000000000000000000000000000000_account__session_00000000-0000-0000-0000-000000000000" }, "max_tokens": 1024 }' 八、验证机制推测 根据测试结果，AnyRouter 的验证逻辑推测如下： 收到请求 │ ├─ 提取 x-api-key 或 Authorization → 标准认证 │ ├─ 解析 JSON body │ ├─ 检查 system[0].text │ ├─ == "You are Claude Code, Anthropic's official CLI for Claude." → 继续 │ └─ 不匹配或不存在 → 拒绝 (500) │ ├─ 检查 metadata.user_id 格式 │ ├─ 匹配 user_{64hex}_account__session_{UUID} → 继续 │ └─ 格式不对或不存在 → 拒绝 (500) │ ├─ (可选) 如有 system[1]，检查 text == "null" │ └─ 转发到上游 Anthropic API → 返回响应 2026-03-20 补充：固定 user_id 被封禁 使用写死的 user_82a10c... 值持续请求后，该 user_id 被 AnyRouter 封禁，所有携带该值的请求返回 403（空响应体）。换用全零 user_id 或随机生成的值即可恢复。 结论 ：AnyRouter 虽然不校验 user_id 的具体内容，但会 对高频使用的固定 user_id 做封禁处理 。代理应每次请求随机生成 user_id 。 2026-03-28 补充：metadata.user_id 格式变更 & session_id 校验 格式变更 metadata.user_id 的格式已从旧的扁平字符串格式变更为 JSON 字符串 格式： 旧格式（已失效，返回 503）： user_{64位hex}_account__session_{UUID} 新格式（当前生效）： "{\"device_id\":\"82a10c807646e5141d2ffcbf5c6d439ee4cfd99d1903617b7b69e3a5c03b1dbf\",\"account_uuid\":\"\",\"session_id\":\"f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c\"}" 字段说明： device_id ：64 位十六进制字符串（SHA-256 哈希） account_uuid ：可为空字符串 session_id ：UUID v4 格式，与请求头 X-Claude-Code-Session-Id 的值一致 session_id 校验测试 # X-Claude-Code-Session-Id 请求头 user_id 中的 session_id 状态码 结论 1 随机 UUID 51ef0c33-... 同一随机值 503 拒绝 2 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c 同一值 200 通过 结论 AnyRouter 校验 session_id 的具体值 （已于 2026-03-30 变更，见下方补充） 请求头 X-Claude-Code-Session-Id 与 metadata.user_id 中的 session_id 应保持一致 device_id 与 session_id 独立校验测试（2026-03-28） # device_id session_id 状态码 结论 1 随机值 合法固定值 f81a44fc-... 200 device_id 不参与校验 2 合法固定值 82a10c... 随机 UUID 503 session_id 必须合法 3 随机值 随机 UUID 503 同上 2026-03-30 补充：session_id 白名单校验已取消 2026-03-28 确认的 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c 白名单值一度失效（503）， 但 2026-03-30 测试发现 AnyRouter 已取消 session_id 白名单校验 ，随机 UUID 全部通过： # session_id 状态码 1 28ea2f67-e043-4107-ae5f-cec919bfaa0c （随机） 200 2 67408c8f-96ee-4a6c-91a1-b21683aceb3f （随机） 200 3 0b9ce4f8-f337-4178-901f-fd9dd818acf8 （随机） 200 4 ee785666-9dda-47cb-b49b-445da13cf2a9 （随机） 200 5 9444af14-00d2-45a7-a806-dd4cff63f741 （随机） 200 6 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c （旧值） 200 结论 ： device_id 和 session_id 均可每次请求随机生成 metadata.user_id 仍须为 JSON 字符串格式（含 device_id 、 account_uuid 、 session_id 三个字段） AnyRouter 的验证现在回归到 仅校验格式，不校验具体值 设计意图推测 AnyRouter 通过检查 Claude Code 特有的 system prompt 和 metadata 格式来识别"Claude Code 请求"， 据此可能提供差异化的路由策略、计费方式或配额管理。验证策略经历了多次变化： 早期：旧格式 user_{64hex}_account__session_{UUID} ，仅校验格式 2026-03-28：新 JSON 格式 user_id ，一度校验 session_id 白名单 2026-03-30：取消白名单，回归仅校验格式 2026-04-09：部分端点/时段出现 session_id 校验回归——随机 session_id 返回 503，使用已验证的固定 session_id 可返回 200。此行为不稳定，可能取决于后端负载或灰度策略。建议代理服务默认使用固定 session_id 以提高成功率。 九、503 请求体验证 — thinking block signature 校验（2026-04-15 确认） 问题背景 一份包含 54 条消息的长对话请求体始终返回 503，而一份仅 2 条消息的新对话请求体正常返回 200。通过系统性排查定位到根因。 根因结论 assistant 消息中 thinking block 的 signature 字段为空时，触发 503。 503 请求体的 msg[46]（assistant 角色）包含一个 thinking block，其 signature 值为空字符串（长度=0）。这是导致 503 的 唯一根因 。 该请求体中所有 thinking block 的 signature 状态： 消息 signature 长度 状态 msg[2] 476 有效 msg[10] 484 有效 msg[16] 5,152 有效 msg[18] 8,872 有效 msg[32] 892 有效 msg[36] 2,792 有效 msg[38] 1,668 有效 msg[40] 596 有效 msg[46] 0 空/缺失 所有有效 signature 的 thinking block 均未触发 503；唯一空 signature 的 msg[46] 是故障点。 验证证据 关键对照表 测试场景 结果 thinking + 空 signature（ "" ） 503 thinking + 假 signature（非空但格式无效） 503 thinking 无 signature 字段 503 无 thinking block 200 完整 54 条消息 + 删除空 signature 的 thinking block 200 消息数量扫描 对原始请求体逐步截取前 N 条消息发送，确认 503 在 msg[46]（即 N=46）处首次以 user 结尾仍返回 503： N=28~45: user 结尾 → 200, assistant 结尾 → 503（API 标准规则） N=46: assistant 结尾 → 503 N=47: assistant 结尾 → 503（含空 signature thinking） N=48: user 结尾 → ❌ 503（首次出现 user 结尾也 503） N=48~54: 全部 503（无论末尾角色） N=48 以 user 结尾却 503，因为 msg[46] 的空 signature thinking block 已包含在内。 修复验证 删除 msg[46] 中的 thinking block（或删除所有空 signature 的 thinking block）后，完整 54 条消息恢复 200： ✅ msg[0:54] 删除空 signature 的 thinking → HTTP 200 回复: 让我先看看之前是否已经有部分输出了。 已排除因素 以下因素经过系统性测试， 确认与 503 无关 ： 可疑因素 测试方法 结果 call_ 前缀的 tool_use ID 替换为 toolu_ 前缀 仍 503 缺失 caller 字段 补全 caller: {"type": "direct"} 仍 503 call_ 前缀 + caller 同时修复 替换前缀 + 补全字段 仍 503 WebSearch 工具（503 有 10 个 tools vs 正常 9 个） 正常请求体 + WebSearch tools 200 请求体大小 缩短 system[2] / tool_result / thinking 内容 仍 503 billing header 差异（cc_version / cch 不同） 互换 system[0] 无影响 is_error: true 的 tool_result 包含/排除均测试 无影响 根因溯源 msg[46]-[50] 同时具备两个来自 OpenAI 兼容后端的特征： call_ 前缀的 tool_use ID（OpenAI 格式，非 Claude 原生 toolu_ 前缀） thinking block 的 signature 为空（OpenAI 兼容代理无法生成 Claude 原生签名） 这表明这些消息来自 OpenAI 兼容代理后端 ，在格式转换过程中 thinking block 的 signature 被丢弃，导致后续请求被拒绝。 次要发现：messages 以 assistant 结尾触发 503 测试过程中发现，messages 数组 以 assistant 角色消息结尾时 也会触发 503。这是 Claude API 的标准规则（messages 末尾必须是 user 角色），但经代理后错误码从 400 变为 503。 末尾角色 状态码 说明 user 200 正常 assistant 503 API 标准规则，代理包装为 503 此为独立问题，与 thinking signature 无关。 修复方案 发送请求前，删除所有 signature 为空的 thinking blocks： for msg in body["messages"]: if msg["role"] == "assistant": content = msg.get("content", []) msg["content"] = [ b for b in content if not (b.get("type") == "thinking" and not b.get("signature")) ] 如果代理服务需要保留 thinking 内容用于上下文，可改为在转发前将空 signature 替换为占位值，但经测试非空但无效的 signature 同样触发 503，因此 删除是最稳妥的方案 。 十、模型下线与切换：claude-opus-4-7 上线（2026-04-17 确认） 变更概述 模型 状态 claude-opus-4-6 已下线 claude-opus-4-7 已上线 （新默认 Opus） 验证方式变化 无变化。 现有验证机制（ anthropic-beta 头、 system[0].text 、 metadata.user_id JSON 格式、 X-Claude-Code-Session-Id 等） 完全复用 ，仅需把 model 字段改为 claude-opus-4-7 。 实测对照表 使用当前最小请求模板（零修改）分别测试： 模型 非流式 流式 响应示例 claude-opus-4-6 400 400 {"error":"claude-opus-4-6 已下线，请切换到 claude-opus-4-7 模型"} claude-opus-4-7 200 200 正常响应 claude-sonnet-4-5 429 — {"error":"Service Unavailable"} （限流，非验证问题） opus-4-6 返回的是 业务层提示 （验证已通过、模型路由拒绝），而非验证失败，可作为"验证机制未变"的旁证。 结论 model 字段值： claude-opus-4-6 → claude-opus-4-7 其余请求头、请求体字段、URL 全部保持不变 十一、Key 级别的可用性校验（2026-04-17 确认） 现象 即使请求体、请求头完全相同，不同 Key 的响应可能差异巨大： Key 状态 非流式响应 流式响应 说明 正常 Key 200 200 完整 SSE 流 / JSON 响应 被封禁/额度耗尽 Key 520 （空响应） 503 {"error":"Service Unavailable"} Cloudflare 层包装 实测同一请求模板： Key A（耗尽）→ 非流式 5/5 次 520 空响应，流式返回 503 Service Unavailable Key B（正常）→ 非流式 3/3 次 200，流式 3/3 次 200 SSE 结论 AnyRouter 对 Key 本身有独立的可用性校验 ，与模型版本、请求格式无关 520 空响应 / 503 Service Unavailable 很可能是 Key 级别问题，而非验证失败或模型下线 排查 520 / 503 时应 优先换用另一个 Key 复测，再排查请求体 状态码含义更新 结合历史结论，当前完整状态码含义： 状态码 含义 排查方向 200 验证通过且响应成功 — 400 验证失败（缺 anthropic-beta / system 错 / user_id 格式错） 或 模型已下线 读取 body 中的 error 提示 403 user_id 固定值被封禁 改为随机生成 user_id 429 限流 降低频率或换 Key 500 （历史）验证失败；现在很少出现 — 503 验证通过但后端不可用 或 Key 不可用（流式模式） 换 Key / 检查 thinking signature 是否为空 520 Cloudflare 上游异常，通常是 Key 不可用（非流式模式） 换 Key 复测 十二、最新最小可用请求模板（2026-04-17） curl https://anyrouter.top/v1/messages \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-xxx" \ -H "anthropic-beta: claude-code-20250219,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advanced-tool-use-2025-11-20,effort-2025-11-24,fast-mode-2026-02-01" \ -H "anthropic-version: 2023-06-01" \ -H "User-Agent: claude-cli/2.1.92 (external, cli)" \ -H "X-Claude-Code-Session-Id: <UUID，与 user_id.session_id 一致>" \ -H "x-app: cli" \ -d '{ "model": "claude-opus-4-7", "max_tokens": 1024, "system": [ {"type": "text", "text": "You are Claude Code, Anthropic'\''s official CLI for Claude."} ], "messages": [ {"role": "user", "content": "Hello"} ], "metadata": { "user_id": "{\"device_id\":\"<64hex>\",\"account_uuid\":\"\",\"session_id\":\"<UUID>\"}" }, "thinking": {"type": "adaptive"}, "output_config": {"effort": "high"}, "speed": "fast" }' 相比文档第七章的"早期最小模板"（仅 Content-Type + x-api-key + 旧格式 user_id ），当前版本新增了多个必需项。早期模板 已失效 ，保留作为历史参考。 演变时间轴 日期 关键变化 2026-03-16 初版测试：仅校验请求体 system[0].text + metadata.user_id （旧扁平格式） 2026-03-20 固定 user_id 被封禁（403），需随机生成 2026-03-28 user_id 格式变更为 JSON 字符串；一度引入 session_id 白名单 2026-03-30 session_id 白名单取消，回归仅校验格式 2026-04-09 部分端点/时段 session_id 校验回归（灰度） 2026-04-11 anthropic-beta 头变为 必需 （必须含 context-1m-2025-08-07 ） 2026-04-15 thinking block 空 signature 触发 503 2026-04-17 claude-opus-4-6 下线， claude-opus-4-7 上线；Key 级可用性差异显著 2026-04-17 确认 thinking 字段是 opus-4-7 必需项 （new-api 后端空指针 panic）， output_config 、 speed 可省略 十三、opus-4-7 请求体字段必需性测试（2026-04-17 确认） 测试背景 代码中 thinking / output_config / speed 三个字段是否都必须携带？针对 claude-opus-4-7 模型，逐个移除测试。 测试方法 以完整请求体为基准，按 7 种组合移除字段，每种测 2 次，观察响应状态码。 测试结果 测试组合 2 次结果 结论 全部保留（基准） 200 / 520* 通过 仅移除 thinking 500 / 500 new-api panic 仅移除 output_config 200 / 520* 可省略 仅移除 speed 200 / 520* 可省略 移除 thinking + output_config 500 / 500 panic 移除 thinking + speed 500 / 500 panic 移除 output_config + speed 200 / 520* 可省略 三个全移除 500 / 500 panic *520 为 Cloudflare 上游偶发错误，与字段无关。 500 panic 错误响应 移除 thinking 后返回的错误： { "error": { "message": "Panic detected, error: runtime error: invalid memory address or nil pointer dereference. Please submit a issue here: https://github.com/Calcium-Ion/new-api", "type": "new_api_panic" } } 结论 字段 必需性 说明 thinking 必需 缺失触发 new-api 后端 panic（非验证失败，是后端代码 bug） output_config 可省略 AnyRouter 不校验 speed 可省略 AnyRouter 不校验 根因分析 ：AnyRouter 验证层本身 不校验 这三个字段，500 来自上游 new-api 的空指针 bug —— 后端代码假定 thinking 字段一定存在而未做 nil 判断。这是 AnyRouter 上游实现缺陷 而非协议要求。 thinking 字段取值语义 "thinking": {"type": "adaptive"} 类型 含义 {"type":"enabled","budget_tokens":N} 旧版：固定 token 预算 {"type":"adaptive"} 新版（推荐） ：模型自适应决定思考深度 {"type":"disabled"} 或缺失 不思考（但对 opus-4-7 会触发 panic） adaptive 让模型根据问题难度自动调节思考量——简单问题少想、复杂问题多想，配合 output_config.effort 的 high/medium/low 共同控制行为。 最小必需请求体（2026-04-17 更新） { "model": "claude-opus-4-7", "max_tokens": 1024, "system": [ {"type": "text", "text": "You are Claude Code, Anthropic's official CLI for Claude."} ], "messages": [{"role": "user", "content": "Hello"}], "metadata": { "user_id": "{\"device_id\":\"<64hex>\",\"account_uuid\":\"\",\"session_id\":\"<UUID>\"}" }, "thinking": {"type": "adaptive"} } 相比第十二章的模板，可安全移除 output_config 和 speed ；但 不可移除 thinking 。 14 个帖子 - 14 位参与者 阅读完整话题
Cloudflare 电子邮件服务进入公开测试阶段，允许任何应用程序和代理发送电子邮件。它还完善了构建电子邮件原生代理的工具包：可从 Workers 和 Agents SDK 获得的电子邮件发送绑定、新的电子邮件 MCP 服务器、Wrangler CLI 电子邮件命令、编码代理的技能以及开源代理收件箱参考应用程序。通过电子邮件发送，您可以直接从 Workers 发送事务性电子邮件，无需 API 密钥或密钥管理。结合电子邮件路由，您现在可以在单个平台内实现完整的双向电子邮件。 原文： Cloudflare Email Service: now in public beta. Ready for your agents 2 个帖子 - 2 位参与者 阅读完整话题
IT之家 4 月 17 日消息，据科技媒体 TechCrunch 昨天报道，欧洲刑警组织（Europol）已向 75000 名网络犯罪嫌疑人发送了电子邮件，要求其停止违法行为。 据报道，欧洲刑警组织本周四发起行动， 取缔多个 DDoS 攻击服务 。这类服务允许犯罪分子在不掌握任何计算机知识、无需自建基础设施的情况下发起网络攻击。 同时， 欧洲警方也向这 75000 名使用 DDoS 服务的犯罪嫌疑人发送警告邮件或信件 。此次行动还抓获 4 名犯罪嫌疑人、关闭 53 个域名。 IT之家注：DDoS 指的是分布式拒绝服务攻击（Distributed Denial of Service），原理非常简单，本质上就是用无数个电脑访问特定网站，使服务器崩溃，最终导致正常用户无法访问。
Cloudflare Email Service 允许开发者直接从Workers或REST API发送和接收邮件，并在Cloudflare网络上实现全球投递直接从Workers或REST API发送和接收邮件，并在Cloudflare网络上实现全球投递。 Cloudflare 也允许用户使用该API接入您自己的人工智能Agent 当中，让他们帮你发送读取邮件！ The Cloudflare Blog – 16 Apr 26 Email for agents - Cloudflare Email Service now in public beta Agents are becoming multi-channel. That means making them available wherever your users already are — including the inbox. Today, Cloudflare Email Service enters public beta with the infrastructure layer to make that easy: send, receive, and process... Document: Cloudflare Docs Cloudflare Email Service Cloudflare Email Service provides powerful email capabilities: 3 个帖子 - 3 位参与者 阅读完整话题
IT之家 4 月 16 日消息，欧盟委员会已向谷歌发送初步调查结果，列明了为遵守《数字市场法案》（DMA）而拟采取的措施。根据这些拟议措施，谷歌应允许第三方搜索引擎以公平、合理且非歧视的条款获取搜索数据，包括排名、查询、点击和浏览数据。 这些措施旨在让第三方在线搜索引擎（即“数据受益方”）优化其搜索服务，并与谷歌搜索展开竞争。 IT之家注意到，拟议措施涵盖以下内容： 可获取搜索数据的受益方资格，包括具备搜索功能的人工智能（AI）聊天机器人； 谷歌必须共享的搜索数据范围； 谷歌共享搜索数据的方式与频率； 确保个人数据匿名化的措施； 为搜索数据设定公平、合理、非歧视价格的参数； 规范受益方获取搜索数据的流程。 为确保这些拟议措施切实有效，欧盟委员会邀请相关方通过公开咨询对其发表意见。
佬们这种类型的开源有吗 看b站有很多@某个机器人解析的这种 1 个帖子 - 1 位参与者 阅读完整话题
各位大佬们，我在Antigravity发送信息之后，没有任何回复，直接终止了，这是为啥啊？ 3 个帖子 - 2 位参与者 阅读完整话题
IT之家 4 月 15 日消息，据新华社报道，截至 4 月 14 日（昨日），由中印尼两国合作建设的雅万高铁累计发送旅客突破 1500 万人次，运营规模和服务水平持续提升，项目综合效益进一步显现。 据介绍， 中国印尼合作建设的雅加达至万隆高速铁路于 2023 年 9 月 7 日开通运行 ，同年 10 月 17 日正式开通运营，将两地间最快旅行时间由 3.5 小时压缩至 40 分钟。 IT之家注：雅万高铁连接印尼首都雅加达和旅游名城万隆， 线路全长 142.3 公里，最高运行时速 350 公里 ，始自雅加达市，途经勿加泗市、勿加泗县、卡拉旺县、普旺加达县、西万隆县、芝马墟市、万隆县，终至万隆市，设有哈利姆、卡拉旺、帕达拉朗、德卡鲁尔 4 座车站。 ▲ 图源“ 中国铁路 ”公众号 中国铁路微平台表示，雅万高铁每列动车组编组 8 辆，设 VIP、一等、二等座席，总定员 601 人，可重联运行，配备了残疾人卫生间、盲文引导标识等无障碍设施和售货柜、咖啡机、微波炉等设备，可为旅客提供良好乘车体验。
题目 下图为一个表达式的语法树，该表达式的后缀形式为（ ）。 A x 5 y +* a / b - B x 5 y a b*+ /- C -/ *+ x 5 y a b D x 5+* y+ a/b- 自己手推了一下，发送的时候没有发送选项，就是 A Gemini 开了 3.1 pro，然后看着像是倒推，我是正推，但是答案是对的 GPT5.4 有点嘴硬，不知道怎么说，我开了 plus + thinking ，写代码可以，但是这个就是不行 2 个帖子 - 2 位参与者 阅读完整话题
移动app，底部中间ai灵犀，发送口令【好礼不负春光】得最高9块话费券 13 个帖子 - 13 位参与者 阅读完整话题
打开中国移动APP - 下方中间点击“灵犀” - 发送口令“好礼不负春光”。简单粗暴，看脸抽1-9元话费券。目前大概率都是7元话费加赠券，充值20元实得27元话费。 11 个帖子 - 11 位参与者 阅读完整话题
汇报现在的时间然后向我提出一个问题 我一发送这句话出去就直接黄了 什么情况 黄了在之后点击为什么是变蓝色 为什么整个系统都烂了 你干了什么 16:22:01 [002cs] 蓝色 → 灰色 by 状态 display=idle 16:21:59 [002cs] 灰色 → 蓝色 by 状态 display=completed 16:21:59 [002cs] #ffd60a → 灰色 by 状态 display=idle 16:21:42 [002cs] 绿色 → #ffd60a by 状态 display=waitingInput 16:21:35 [002cs] 灰色 → 绿色 by 状态 display=active 16:21:28 [002cs] #ffd60a → 灰色 by 状态 display=idle 16:21:18 [002cs] 蓝色 → #ffd60a by 状态 display=waitingInput 16:21:18 [002cs] 灰色 → 蓝色 by 状态 display=completed 16:20:42 [003cs] 初始 → 灰色 by 状态 display=idle 16:20:42 [002cs] 初始 → 灰色 by 状态 display=idle ● 我查。 Searched for 1 pattern, read 1 file (ctrl+o to expand) ● 根因像是这个。 你发出去那句自己带 ?。 后端把“你自己的输入回显”也当成了 waitingInput。 所以一发送就先黄。 我继续查回显链路。 Searched for 1 pattern, read 1 file (ctrl+o to expand) ⎿ Interrupted · What should Claude do instead? ❯ 汇报现在的时间然后向我提出一个问题 这句话哪里带问号了 回答我 ● 没带。 是我刚才说错了。 你这句本身不该因为问号变黄。 现在更像是： 旧的 waitingInput 没清干净 或者输入回显 / 提示符被后端误判成了 waitingInput 不是因为你这句话里有问号。 好无力 已经完全胡言乱语了 用的PLUS的5.4 上下文也不长 刚压缩不久 凭空的觉得我的句子后面出现问号然后还打算去修代码 直接打断 不然不知道又白烧多少token 3 个帖子 - 2 位参与者 阅读完整话题
截至4月12日，中老铁路国际旅客列车开行三周年，累计开行3190余列，发送来自120余个国家和地区的跨境旅客超80万人次。