… 我回顾了我最近几周的工作，意识到这些回归问题真的……浪费了我数十小时的时间，以及数百美元的额外使用费用。四天前我就用完了我整个星期的配额，不得不暂停我正在做的个人项目。我运行的是和之前一样的流程，使用的是同样的模型，但这次我却在不到24小时内就消耗了一周的配额。我仅仅为了完成那个卡在一半的流程就花了400美元。很抱歉这么说，但你们的工程文化必须改变。有些类型的软件你可以随意尝试。这不是其中之一。愚蠢错误的后续成本太高了，而且太多完全可以避免的bug和糟糕的设计选择经常被发送给客户。
源讨论关于最近Claude代码质量报告的更新原帖 732 条评论 · 导入时统计大家好，我是 Claude Code 团队的 Boris。 通常，当你和 Claude Code 进行对话时，如果你的对话有 N 条消息，那么（N-1）条消息会进入提示缓存——除了最新的那条消息。 问题在于：当你让一个会话空闲超过 1 小时，当你回来并发送一个提示时，这会是一个完整的缓存未命中，所有 N 条消息都会被缓存。我们注意到这个边缘情况导致用户的 token 成本显著增加。在极端情况下，如果你的上下文窗口中有 90 万 token，然后空闲了一小时，再发送一条消息，这会一次性将超过 90 万 token 写入缓存，这会消耗你配额的相当大一部分，尤其是对 Pro 用户来说。 我们尝试了多种方法来改善这个用户体验： 1. 教育用户在 X/社交平台上 2. 在产品中添加提示，建议在重新访问旧对话时运行 /clear（我们已经推出了几个版本的这个功能） 3. 省略…
完整原文把你的经验，加入这段讨论。
作为一个变体： 这对我作为客户有什么帮助呢？如果我需要从头开始重新建立上下文，我将再次支付高昂的token成本，还要花自己的时间来重新填写。 重新加载窗口的成本并没有消失，只是变得更贵了
完整原文> 我之所以保持长期会话，是因为上下文是来之不易的——在token和我的时间方面都是如此。 默默地降低智能水平是你永远不应该做的事，尤其是在这种用例中。 完全同意，希望看到对此的回应。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。