Hacker News 中文摘要

RSS订阅

Pro Max 5x配额1.5小时耗尽,使用量适中 -- Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage

文章摘要

用户报告Pro Max 5x配额在1.5小时内耗尽,尽管使用量适中。该问题已提交至GitHub的claude-code项目问题追踪系统,编号#45756,属于技术故障类问题。

文章总结

[BUG] Pro Max 5x配额在1.5小时内耗尽,尽管使用量适中

主要内容:
用户报告在使用Pro Max 5x(Opus)计划时,配额重置后仅1.5小时即耗尽,尽管使用量仅为中等(主要是问答和轻度开发)。相比之下,重置前的5小时高强度开发(多文件实现、多代理任务)消耗完配额是预期内的。

关键问题:
1. 缓存读取令牌可能按全额计算:怀疑cache_read令牌在速率限制中按全额计算,抵消了提示缓存的成本优势。
- 若按1/10比率计算,1.5小时应消耗13.1M有效令牌(8.7M/小时),不会耗尽配额。
- 若按全额计算,则消耗105.7M令牌(70.5M/小时),导致配额快速耗尽。

  1. 背景会话消耗配额:未主动使用的会话(如token-analysiscareer-ops)仍在后台调用API,占用了78%的配额。

  2. 自动压缩导致高消耗:每次自动压缩会发送完整上下文(约966k令牌)作为cache_creation,产生高额单次调用成本。

  3. 大上下文窗口加剧问题:1M的上下文窗口导致每次调用携带更多令牌,加速配额消耗。

环境信息:
- 计划:Pro Max 5x
- 模型:claude-opus-4-6(1M上下文)
- 平台:WSL2上的Claude Code CLI

建议改进:
- 明确cache_read的配额计算规则。
- 按有效令牌(1/10比率)计算速率限制。
- 检测闲置会话并减少其配额消耗。
- 提供实时配额消耗明细。

后续讨论:
其他用户通过工具分析发现,cache_read可能实际未计入配额(与假设相反),但需更多数据验证。工具已开源供社区测试。

关联问题:
- 缓存TTL从1小时降为5分钟导致配额和成本增加 #46829

(注:删减了导航菜单、重复标签和部分评论细节,保留核心问题和分析。)

评论总结

以下是评论内容的总结:

主要观点和论据

  1. 订阅服务缺乏透明度

    • 用户抱怨无法清楚了解订阅服务的具体计费方式和请求定义(评论6、11)。
    • "It's basically impossible for people to tell what they're actually buying"(评论11)。
    • "Fair transactions involve fair and transparent measurements of goods exchanged"(评论2)。
  2. 配额和限制问题

    • 许多用户表示配额消耗速度显著增加,相同任务下使用量上升(评论7、20)。
    • "Now a single question consistently uses around 15% of my quota"(评论7)。
    • "This week, I've used up half the limit in a day"(评论20)。
  3. 转向其他服务或本地模型

    • 部分用户转向Codex、开源模型或本地LLM(评论4、5、25)。
    • "I’ve moved away from Claude and toward open-source models"(评论5)。
    • "You know you can actually....use local LLMs?"(评论25)。
  4. 对Anthropic的失望

    • 用户批评Anthropic处理问题的态度和模型质量下降(评论9、22)。
    • "There's this honeymoon period with Claude... followed by a trough of disillusionment"(评论9)。
    • "At this point, I cannot recommend it in good conscience"(评论22)。
  5. 价格和性价比争议

    • 部分用户认为高价订阅不值得,尤其是对个人用户(评论18、23)。
    • "It's more than my monthly energy bill"(评论18)。
    • "I exhausted my quota after just 30 images"(评论23)。

不同观点的平衡性

  • 支持其他服务:Codex和开源模型被多次提及为更优选择(评论4、5、22)。
  • 对Anthropic的辩护:少数用户认为问题可能被夸大(评论27、29)。
  • 本地模型的建议:部分用户建议使用本地LLM以避免依赖订阅服务(评论25)。

关键引用

  • 透明度问题
    "How is this normal?"(评论11)。
  • 配额问题
    "I’ve used up half the limit in a day"(评论20)。
  • 转向其他服务
    "I ended up buying the $100 Codex plan"(评论22)。

总结:用户主要批评订阅服务的透明度和配额问题,部分转向其他服务或本地模型,同时对Anthropic的处理方式表示失望。