## Claude Pro Max 5x 配额耗尽 - 摘要 一位Pro Max 5x (Opus) 计划的用户在使用过程中,配额意外迅速耗尽——在适度使用1.5小时内,尽管预计可运行数小时。初步调查显示,核心问题可能在于`cache_read` tokens 以*完整速率*计入配额,从而抵消了提示缓存的成本效益。 之前的配额在大量开发(5小时)中按预期消耗完毕,但重置后,即使是轻量级的问答和开发也迅速耗尽了配额。数据显示,来自后台Claude Code会话的大量token消耗,以及自动压缩事件期间的昂贵峰值(发送约960k tokens)。1M上下文窗口加剧了这个问题,因为每次API调用都会传输大量token。 预期行为是`cache_read` tokens 仅贡献1/10的token到配额。目前的情况使得提示缓存对于速率限制无效,并显著减少了可用配额时间。建议的改进包括澄清缓存计算、按有效token进行速率限制、管理空闲会话消耗,以及在Claude Code中提供详细的配额可见性。这似乎是较早版本的回归。
## 终端中的DOOM:一个基于cURL的移植
这个项目使用cURL和bash将DOOM游戏流式传输到终端,无需其他依赖。它通过将DOOM帧渲染为ANSI半块字符并通过HTTP传输来运行。
有两种玩法:一种是通过`curl | bash`下载的简单脚本,另一种是“自虐式”的纯cURL方法,需要手动配置终端(`stty`)以获取原始输入。后者在请求体中发送按键,并在响应中接收ANSI帧,利用单个TCP连接。
服务器使用Node.js构建,管理DOOM会话,将640x400的帧缓冲缩小到终端尺寸。它通过仅发送颜色变化来优化带宽。会话在不活动后超时。
主要功能包括可配置的终端大小、帧速率(默认15fps)和WAD文件选择。该项目利用`doomgeneric`作为自定义渲染后端,并依赖`doom1.wad`(共享软件剧集)进行游戏。它被设计用于*托管*游戏,而不是在服务器上直接运行。