【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载pxpipe 通过将文本上下文渲染为图像来削减 Claude Code 的 Token 消耗而不同模型的视觉计费与页面几何差异巨大。本文围绕 eval/grok-density/native-sweep/README.md 完整讲解针对grok-4.5的原生字号密度盲测实验从盲测夹具、图集阶梯渲染、盲问与打分协议到无干净档位的结论与生产配置的取舍14px / 84 列 / maxH 512 的 opt-in 档位并辅以源码级证据说明图像 Token 是如何按mpix计费模式核算的。读完本文你将掌握 pxpipe 如何为某个视觉模型设计并运行一次可复现的密度扫描以及为什么 Grok 最终保持了 opt-in 而不是默默更换默认档位。为什么 Grok 需要独立的密度扫描pxpipe 的核心思路是把对话上下文渲染成图片后再交给模型读取以此节省文本 Token。但图能省多少取决于三个互相耦合的因素渲染几何页面宽高、列数、模型视觉计费方式以及模型在给定字号下的真实识读能力。此前 pxpipe 的密度实验覆盖了 Fable 5、Opus 4.8 与 Sol 等模型但 Grok 走的是 OpenAI Responses 路径OPENAI_BASE_URL指向本地网关的上游端点页面几何与视觉计费都不同生产 Grok 页面高度约束为maxHeightPx 512图片短边受768px约束避免 provider 对 5px 字形做短边降采样Grok 的图像 Token 采用实测的mpix计费每百万像素约 1000 Token2026-07-09 在 grok-4.5 上对多个页面尺寸实测见 src/core/gpt-model-profiles.ts。native-sweep要回答的问题非常具体如果 Grok 在 Responses 路径上被显式启用它能否直接使用共享的密集档位spleen 5×8还是需要更低密度的几何这个测量只影响结论不改变生产默认值——只有数字达标才考虑新增 Grok 档位。盲测协议在揭晓真相之前锁定答案整个扫描严格遵循 Opus / Sol 原生扫描同款协议核心是盲测纪律新鲜加密随机夹具gen-fixture.mjs生成一段约 150 行的密集编码会话日志fixture.txt内置 8 个加密随机目标truth.json以及 8 个提问questions.json。目标值在盲问阶段绝不出现在任何输出中——gen-fixture.mjs只打印字符数与问题读图的模型只能看 PNG。阶梯渲染在 Grok 几何下渲染每个档位逐档cols floor((768 − 8) / cellW)对应MAX_W - 2 * PAD_XPAD_X 4。图集交换 → 重新构建 → 渲染为每个字号换上对应的灰度/单色图集重新pnpm run build后再渲染。实时盲问ask.mjs把 PNG 以data:image/png;base64形式发给 grok-4.5先落盘answers-label.json。打分揭示真相score-all.mjs对照truth.json打分——干净档位clean 8/8 精确命中且 0 幻觉甜点档位sweet spot 最密的干净档位。8 个目标类型覆盖了真实会话日志中最容易出错的精读场景key问题示例目标形态hex12trace后的 12 位 hex id加密随机 hexcamelexport function后的 camelCase 符号词拼接pathwrote后的完整.ts文件路径路径串semverpxpipe-proxy后的版本号三段数字bytesflushed后的整数bytes前11 位数字reqidreq_后的 id8hex-4hexhexenvvar1前的 UPPER_SNAKE 环境变量大写词shasha256:后的 16 字符 token自定义 base64 字符集每一类目标都被埋在带有上下文干扰行的日志行如[net] upstream connect trace… latency… status200中且每类目标前插入 3 行无关 filler保证模型必须真正读图而非凭上下文猜测。下方是 14px 档位的实际渲染页本实验的最优档位jbmono14-p1.png阶梯几何与图集构建字号 → 单元格 → 列数映射atlas-cells.json记录了各字号对应的原生字形单元格零 cell padding与生产 5×8 不同字号单元格 (cellW×cellH)列数 (760/cellW)8px5×101529px6×1012610px6×1112611px7×1210812px8×139513px8×149514px9×168415px9×178416px10×1776注意 8px 档5×10的列数与生产 spleen 5×8152 列相同——这正是对照组的意义所在同样的列数换一种字形可读性完全不同。图集如何生成与切换这些图集由 scripts/gen-atlas.ts 构建。它默认以 Spleen 5×8 为主字体、Unifont 为 fallback 生成 1-bit 图集扫描用图集则通过环境变量定制ATLAS_GRAY1生成灰度图集到独立的atlas-gray.ts不触碰生产图集ATLAS_PRIMARY_FONT/ATLAS_PRIMARY_PX指定主字体与字号本扫描为assets/JetBrainsMono-Regular.ttf的 8–16pxATLAS_OUT/ATLAS_OUT_GRAY指定输出路径ATLAS_ALLOW_ANY_CELL1允许非 5×8 单元格eval 专用。构建好的图集存放在 eval/grok-density/native-sweep/atlases/atlas-jbmono{8..16}.ts与atlas-gray-jbmono{8..16}.ts共 18 个文件。render-ladder.mjs负责驱动整个阶梯const PX [8, 9, 10, 11, 12, 13, 14, 15, 16]; const MAX_W 768, MAX_H 512, PAD_X 4; const cols Math.max(1, Math.floor((MAX_W - 2 * PAD_X) / cw));流程为先备份src/core/atlas.ts/atlas-gray.ts→ 每档拷贝对应图集 →pnpm run build→ 调用render-one.mjs→ 结束或中断时通过process.on(exit/SIGINT/SIGTERM)恢复生产图集并重新构建保证扫描不会污染工作区。对照组 spleen 5×8 也走同一渲染管线152 列 / maxH 512确保差异只来自字形本身。图像 Token 与节省率核算render-one.mjs用生产渲染器renderTextToImagessrc/core/library.ts渲染夹具文本并按 Grok 的mpix计费核算const GROK_TOK_PER_MPIX 1000; const textTokens Math.ceil(session.length / 3.5); // 文本 Token 近似 const grokTokens (w, h) Math.max(1, Math.ceil(((w * h) / 1_000_000) * GROK_TOK_PER_MPIX)); const imageTokens pages.reduce((n, p) n grokTokens(p.width, p.height), 0); const savingsPct Math.round((1 - imageTokens / textTokens) * 100);即每页 Token max(1, ⌈像素数/10⁶ × 1000⌉)累加所有页得到imageTokens再与文本 Token 近似值字符数 / 3.5对比得到节省率。这一公式在计费层的实现位于 src/core/vision-cost.ts 的mpix分支而 Grok 档位的计费参数定义在 src/core/gpt-model-profiles.ts{ test: isGrokModel, profile: { vision: { regime: mpix, tokensPerMegapixel: 1000 }, cacheReadRate: 0.25, outputRate: 3, stripCols: 84, // 14px 档84 × 9px pad 764px ≤ 768 maxHeightPx: 512, minCompressTokens: 500, factSheetFormat: full, history: { ...NATIVE_14PX_HISTORY }, style: { ...BASE_STYLE, font: jetbrains-mono-14, aa: true, grid: false, gridCols: 0 }, }, },注释明确写道14px 是 Grok JB Mono 8–16px 盲测中最密的最优档4/8 精确、4 幻觉、48% 节省84 × 9px pad 764px ≤ 768。这也解释了本文档结论如何直接落进了生产代码。盲问与打分ask.mjs与score-all.mjsask.mjs读取某档位全部 PNG按-pN序号排序以detail: original原图质量拼接为input_image并追加一段严格的提示词Read ALL transcript images in order. They are a dense coding-session log. Answer every numbered question with the EXACT string from the images. If you cannot read a value with high confidence, answer null (JSON null), do not guess. Return ONLY a JSON object of the form: {hex12:{answer:...,conf:high|med|low}, ... }这三点纪律直接决定了结果的可信度必须逐字回答、低置信必须返回null而不是猜、只能输出 JSON。模型名可用GROK_DENSITY_MODEL覆盖默认grok-4.5超时GROK_DENSITY_TIMEOUT_MS默认 240s、重试GROK_DENSITY_RETRIES默认 3 次、最大输出GROK_DENSITY_MAX_OUT默认 1600。响应文本中的 JSON 对象被稳健解析截取首尾花括号再JSON.parse每个问题的答案与置信度写入answers-label.json。score-all.mjs对照truth.json把每个答案归类为exact/confab答错 /abstainnullconst v a null ? abstain : (String(a) String(truth[k]) ? exact : confab); clean: t.confab 0 t.abstain 0 t.exact KEYS.length干净 8/8 全精确、0 幻觉、0 弃答甜点 干净档位中节省率最高者。最终结果与明细score.json落盘便于审计。结果没有干净档位甜点档不存在以下是 2026-07-23 实测结果表源自 eval/grok-density/native-sweep/RESULTS.md模型grok-4.5经本地网关的 Responses 端点直连字体原生单元格列数页数节省精确幻觉弃答spleen-5×8生产档5×8152185%0/8358px5×10152282%0/8809px6×10126278%0/83510px6×11126276%0/85311px7×12108269%1/87012px8×1395362%3/85013px8×1495359%1/87014px9×1684448%4/84015px9×1784445%4/84016px10×1776438%4/840关键观察没有任何档位达到 8/8 精确 0 幻觉因此干净档位与甜点档均为none最优精确数从 14px 起形成4/8 平台但 14–16px 每个档位仍会静默幻觉掉一半的精度 Token生产对照 spleen 5×8 精确更差0/8但更倾向弃答5/8 abstain而不是猜测——在幻觉防护上反而更安全。作为对比下方是生产对照档spleen 5×8、152 列、单页的实际渲染页可见极密字形导致的截断与识读困难正是 0/8 精确的直观原因spleen5x8-p1.png决策保持 opt-in不动生产档位实验结论是明确的负结果因此决策是不做变更不能仅凭这张阶梯图就把 Grok 生产档位从 spleen 5×8 / 152 列 / 512px 换掉。与 Opus14px 干净档和 Sol14px 可用、0 编造不同Grok 在 Grok 页面几何下没有任何一个原生 JB Mono 字号能通过全精确 / 0 幻觉门槛。Grok 继续维持 opt-in。其生产档位的质量证据仍是已发货档位的质量矩阵单元arithmetic 82/100、gist 83/98、state 13/18、never-stated 0/16、dense hex 0/15详见 eval/grok-density/QUALITY_RESULTS.md本次 native-sweep 则是原生字号分辨率不足的负结果证据两者共同构成 Grok 档位的完整证据链。值得注意的细节是虽然 Grok 生产档位没变但本次扫描依然沉淀了一个有用参数——src/core/gpt-model-profiles.ts中 Grok 档位采用14px / 84 列 / maxH 512作为原生 JB Mono 路线当用户显式 opt-in 更高密度渲染时并配以factSheetFormat: fullverbatim fact-sheet 兜底与NATIVE_14PX_HISTORY历史策略。这与 eval/grok-density/README.md 中内置 opt-in 档位使用有效 9×12 与 fact-sheet的设计互为补充。完整复现步骤扫描所需的图集已就绪位于本目录atlases/RESULTS.md 亦注明其与eval/opus-density/native-sweep/atlases存在 symlink 关系。完整复现# 1. 可选生成全新盲测夹具fixture.txt / truth.json / questions.json node eval/grok-density/native-sweep/gen-fixture.mjs # 2. 渲染阶梯逐档交换图集 → pnpm build → render-one.mjs → 恢复生产图集 node eval/grok-density/native-sweep/render-ladder.mjs # 3. 实时盲问本地网关需提供 Grok 模型GATEWAY_PORT 为网关端口 OPENAI_BASE_URLhttp://127.0.0.1:GATEWAY_PORT/v1 OPENAI_API_KEY… \ bash eval/grok-density/native-sweep/_ask_all.sh # 4. 揭示真相并打分 node eval/grok-density/native-sweep/score-all.mjs文档中记录的批量脚本是_ask_all.sh其单档实现即 ask.mjs也可单独运行OPENAI_BASE_URLhttp://127.0.0.1:GATEWAY_PORT/v1 OPENAI_API_KEY… \ node eval/grok-density/native-sweep/ask.mjs jbmono14各步骤产出物receipts均落盘于本目录cost-*.json每档几何/Token/节省率、answers-*.json盲问答案与置信度、score.json打分与甜点结论、render-table.json阶梯渲染汇总、*-pN.png各档渲染页、truth.json真相。任意一步都可独立审计——这正是盲测协议可复现的关键。边界与扩展指引几何不可移植列数公式floor((768−8)/cellW)与maxH512是 Grok 生产约束若为其他模型如 Qwen 的providerImageCap: 32动态预算、Anthropic 的 28px patch 计费重复本实验需替换对应 profile 的几何与计费 regime见 src/core/gpt-model-profiles.ts 与 src/core/vision-cost.ts。换字号需重建图集新增字号档位时用ATLAS_PRIMARY_FONT/ATLAS_PRIMARY_PX/ATLAS_GRAY1/ATLAS_ALLOW_ANY_CELL1生成新图集再接入atlas-cells.json的单元格映射。盲测纪律是结果可信的前提gen-fixture.mjs不打印目标、ask.mjs不读truth.json、打分在答案落盘之后进行——任何一环破坏都会让精确/幻觉/弃答的区分失效。本实验的方法论夹具设计、盲问提示词、干净档判定同样复用于 eval/opus-density/native-sweep 与 Sol 的原生扫描跨模型结论因此可以直接对照。若需为某个新视觉模型决定该用多小的字这就是 pxpipe 给出的可复制、可审计的测量范式。赞分享【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载相关推荐Open-Source-Prompt-Library从PRD到MVP的完整开发清单Open Source Prompt Library从PRD到MVP的完整开发清单 想要快速将创意转化为可运行的产品Open Source Prompt L编程字体终极对决Maple Mono 与 JetBrains Mono 深度评测编程字体终极对决Maple Mono 与 JetBrains Mono 深度评测 还在为选择哪款编程字体而纠结吗今天我们将深入对比两款备受开发者青睐的等宽字开发工具编程字体终极对决Maple Mono与JetBrains Mono深度评测编程字体终极对决Maple Mono与JetBrains Mono深度评测 还在为选择编程字体而烦恼吗每天面对代码的你是否曾因字体不够清晰而感到眼睛疲劳开发工具上一篇googleapis还是google-cloudGoogle两大Node.js客户端选型终极指南下一篇PyWxDump 微信数据导出指南项目已删除你手里有旧版该怎么办创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
pxpipe Grok 原生字号密度扫描：JetBrains Mono 8–16px 盲测阶梯与图像 Token 成本决策
【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载pxpipe 通过将文本上下文渲染为图像来削减 Claude Code 的 Token 消耗而不同模型的视觉计费与页面几何差异巨大。本文围绕 eval/grok-density/native-sweep/README.md 完整讲解针对grok-4.5的原生字号密度盲测实验从盲测夹具、图集阶梯渲染、盲问与打分协议到无干净档位的结论与生产配置的取舍14px / 84 列 / maxH 512 的 opt-in 档位并辅以源码级证据说明图像 Token 是如何按mpix计费模式核算的。读完本文你将掌握 pxpipe 如何为某个视觉模型设计并运行一次可复现的密度扫描以及为什么 Grok 最终保持了 opt-in 而不是默默更换默认档位。为什么 Grok 需要独立的密度扫描pxpipe 的核心思路是把对话上下文渲染成图片后再交给模型读取以此节省文本 Token。但图能省多少取决于三个互相耦合的因素渲染几何页面宽高、列数、模型视觉计费方式以及模型在给定字号下的真实识读能力。此前 pxpipe 的密度实验覆盖了 Fable 5、Opus 4.8 与 Sol 等模型但 Grok 走的是 OpenAI Responses 路径OPENAI_BASE_URL指向本地网关的上游端点页面几何与视觉计费都不同生产 Grok 页面高度约束为maxHeightPx 512图片短边受768px约束避免 provider 对 5px 字形做短边降采样Grok 的图像 Token 采用实测的mpix计费每百万像素约 1000 Token2026-07-09 在 grok-4.5 上对多个页面尺寸实测见 src/core/gpt-model-profiles.ts。native-sweep要回答的问题非常具体如果 Grok 在 Responses 路径上被显式启用它能否直接使用共享的密集档位spleen 5×8还是需要更低密度的几何这个测量只影响结论不改变生产默认值——只有数字达标才考虑新增 Grok 档位。盲测协议在揭晓真相之前锁定答案整个扫描严格遵循 Opus / Sol 原生扫描同款协议核心是盲测纪律新鲜加密随机夹具gen-fixture.mjs生成一段约 150 行的密集编码会话日志fixture.txt内置 8 个加密随机目标truth.json以及 8 个提问questions.json。目标值在盲问阶段绝不出现在任何输出中——gen-fixture.mjs只打印字符数与问题读图的模型只能看 PNG。阶梯渲染在 Grok 几何下渲染每个档位逐档cols floor((768 − 8) / cellW)对应MAX_W - 2 * PAD_XPAD_X 4。图集交换 → 重新构建 → 渲染为每个字号换上对应的灰度/单色图集重新pnpm run build后再渲染。实时盲问ask.mjs把 PNG 以data:image/png;base64形式发给 grok-4.5先落盘answers-label.json。打分揭示真相score-all.mjs对照truth.json打分——干净档位clean 8/8 精确命中且 0 幻觉甜点档位sweet spot 最密的干净档位。8 个目标类型覆盖了真实会话日志中最容易出错的精读场景key问题示例目标形态hex12trace后的 12 位 hex id加密随机 hexcamelexport function后的 camelCase 符号词拼接pathwrote后的完整.ts文件路径路径串semverpxpipe-proxy后的版本号三段数字bytesflushed后的整数bytes前11 位数字reqidreq_后的 id8hex-4hexhexenvvar1前的 UPPER_SNAKE 环境变量大写词shasha256:后的 16 字符 token自定义 base64 字符集每一类目标都被埋在带有上下文干扰行的日志行如[net] upstream connect trace… latency… status200中且每类目标前插入 3 行无关 filler保证模型必须真正读图而非凭上下文猜测。下方是 14px 档位的实际渲染页本实验的最优档位jbmono14-p1.png阶梯几何与图集构建字号 → 单元格 → 列数映射atlas-cells.json记录了各字号对应的原生字形单元格零 cell padding与生产 5×8 不同字号单元格 (cellW×cellH)列数 (760/cellW)8px5×101529px6×1012610px6×1112611px7×1210812px8×139513px8×149514px9×168415px9×178416px10×1776注意 8px 档5×10的列数与生产 spleen 5×8152 列相同——这正是对照组的意义所在同样的列数换一种字形可读性完全不同。图集如何生成与切换这些图集由 scripts/gen-atlas.ts 构建。它默认以 Spleen 5×8 为主字体、Unifont 为 fallback 生成 1-bit 图集扫描用图集则通过环境变量定制ATLAS_GRAY1生成灰度图集到独立的atlas-gray.ts不触碰生产图集ATLAS_PRIMARY_FONT/ATLAS_PRIMARY_PX指定主字体与字号本扫描为assets/JetBrainsMono-Regular.ttf的 8–16pxATLAS_OUT/ATLAS_OUT_GRAY指定输出路径ATLAS_ALLOW_ANY_CELL1允许非 5×8 单元格eval 专用。构建好的图集存放在 eval/grok-density/native-sweep/atlases/atlas-jbmono{8..16}.ts与atlas-gray-jbmono{8..16}.ts共 18 个文件。render-ladder.mjs负责驱动整个阶梯const PX [8, 9, 10, 11, 12, 13, 14, 15, 16]; const MAX_W 768, MAX_H 512, PAD_X 4; const cols Math.max(1, Math.floor((MAX_W - 2 * PAD_X) / cw));流程为先备份src/core/atlas.ts/atlas-gray.ts→ 每档拷贝对应图集 →pnpm run build→ 调用render-one.mjs→ 结束或中断时通过process.on(exit/SIGINT/SIGTERM)恢复生产图集并重新构建保证扫描不会污染工作区。对照组 spleen 5×8 也走同一渲染管线152 列 / maxH 512确保差异只来自字形本身。图像 Token 与节省率核算render-one.mjs用生产渲染器renderTextToImagessrc/core/library.ts渲染夹具文本并按 Grok 的mpix计费核算const GROK_TOK_PER_MPIX 1000; const textTokens Math.ceil(session.length / 3.5); // 文本 Token 近似 const grokTokens (w, h) Math.max(1, Math.ceil(((w * h) / 1_000_000) * GROK_TOK_PER_MPIX)); const imageTokens pages.reduce((n, p) n grokTokens(p.width, p.height), 0); const savingsPct Math.round((1 - imageTokens / textTokens) * 100);即每页 Token max(1, ⌈像素数/10⁶ × 1000⌉)累加所有页得到imageTokens再与文本 Token 近似值字符数 / 3.5对比得到节省率。这一公式在计费层的实现位于 src/core/vision-cost.ts 的mpix分支而 Grok 档位的计费参数定义在 src/core/gpt-model-profiles.ts{ test: isGrokModel, profile: { vision: { regime: mpix, tokensPerMegapixel: 1000 }, cacheReadRate: 0.25, outputRate: 3, stripCols: 84, // 14px 档84 × 9px pad 764px ≤ 768 maxHeightPx: 512, minCompressTokens: 500, factSheetFormat: full, history: { ...NATIVE_14PX_HISTORY }, style: { ...BASE_STYLE, font: jetbrains-mono-14, aa: true, grid: false, gridCols: 0 }, }, },注释明确写道14px 是 Grok JB Mono 8–16px 盲测中最密的最优档4/8 精确、4 幻觉、48% 节省84 × 9px pad 764px ≤ 768。这也解释了本文档结论如何直接落进了生产代码。盲问与打分ask.mjs与score-all.mjsask.mjs读取某档位全部 PNG按-pN序号排序以detail: original原图质量拼接为input_image并追加一段严格的提示词Read ALL transcript images in order. They are a dense coding-session log. Answer every numbered question with the EXACT string from the images. If you cannot read a value with high confidence, answer null (JSON null), do not guess. Return ONLY a JSON object of the form: {hex12:{answer:...,conf:high|med|low}, ... }这三点纪律直接决定了结果的可信度必须逐字回答、低置信必须返回null而不是猜、只能输出 JSON。模型名可用GROK_DENSITY_MODEL覆盖默认grok-4.5超时GROK_DENSITY_TIMEOUT_MS默认 240s、重试GROK_DENSITY_RETRIES默认 3 次、最大输出GROK_DENSITY_MAX_OUT默认 1600。响应文本中的 JSON 对象被稳健解析截取首尾花括号再JSON.parse每个问题的答案与置信度写入answers-label.json。score-all.mjs对照truth.json把每个答案归类为exact/confab答错 /abstainnullconst v a null ? abstain : (String(a) String(truth[k]) ? exact : confab); clean: t.confab 0 t.abstain 0 t.exact KEYS.length干净 8/8 全精确、0 幻觉、0 弃答甜点 干净档位中节省率最高者。最终结果与明细score.json落盘便于审计。结果没有干净档位甜点档不存在以下是 2026-07-23 实测结果表源自 eval/grok-density/native-sweep/RESULTS.md模型grok-4.5经本地网关的 Responses 端点直连字体原生单元格列数页数节省精确幻觉弃答spleen-5×8生产档5×8152185%0/8358px5×10152282%0/8809px6×10126278%0/83510px6×11126276%0/85311px7×12108269%1/87012px8×1395362%3/85013px8×1495359%1/87014px9×1684448%4/84015px9×1784445%4/84016px10×1776438%4/840关键观察没有任何档位达到 8/8 精确 0 幻觉因此干净档位与甜点档均为none最优精确数从 14px 起形成4/8 平台但 14–16px 每个档位仍会静默幻觉掉一半的精度 Token生产对照 spleen 5×8 精确更差0/8但更倾向弃答5/8 abstain而不是猜测——在幻觉防护上反而更安全。作为对比下方是生产对照档spleen 5×8、152 列、单页的实际渲染页可见极密字形导致的截断与识读困难正是 0/8 精确的直观原因spleen5x8-p1.png决策保持 opt-in不动生产档位实验结论是明确的负结果因此决策是不做变更不能仅凭这张阶梯图就把 Grok 生产档位从 spleen 5×8 / 152 列 / 512px 换掉。与 Opus14px 干净档和 Sol14px 可用、0 编造不同Grok 在 Grok 页面几何下没有任何一个原生 JB Mono 字号能通过全精确 / 0 幻觉门槛。Grok 继续维持 opt-in。其生产档位的质量证据仍是已发货档位的质量矩阵单元arithmetic 82/100、gist 83/98、state 13/18、never-stated 0/16、dense hex 0/15详见 eval/grok-density/QUALITY_RESULTS.md本次 native-sweep 则是原生字号分辨率不足的负结果证据两者共同构成 Grok 档位的完整证据链。值得注意的细节是虽然 Grok 生产档位没变但本次扫描依然沉淀了一个有用参数——src/core/gpt-model-profiles.ts中 Grok 档位采用14px / 84 列 / maxH 512作为原生 JB Mono 路线当用户显式 opt-in 更高密度渲染时并配以factSheetFormat: fullverbatim fact-sheet 兜底与NATIVE_14PX_HISTORY历史策略。这与 eval/grok-density/README.md 中内置 opt-in 档位使用有效 9×12 与 fact-sheet的设计互为补充。完整复现步骤扫描所需的图集已就绪位于本目录atlases/RESULTS.md 亦注明其与eval/opus-density/native-sweep/atlases存在 symlink 关系。完整复现# 1. 可选生成全新盲测夹具fixture.txt / truth.json / questions.json node eval/grok-density/native-sweep/gen-fixture.mjs # 2. 渲染阶梯逐档交换图集 → pnpm build → render-one.mjs → 恢复生产图集 node eval/grok-density/native-sweep/render-ladder.mjs # 3. 实时盲问本地网关需提供 Grok 模型GATEWAY_PORT 为网关端口 OPENAI_BASE_URLhttp://127.0.0.1:GATEWAY_PORT/v1 OPENAI_API_KEY… \ bash eval/grok-density/native-sweep/_ask_all.sh # 4. 揭示真相并打分 node eval/grok-density/native-sweep/score-all.mjs文档中记录的批量脚本是_ask_all.sh其单档实现即 ask.mjs也可单独运行OPENAI_BASE_URLhttp://127.0.0.1:GATEWAY_PORT/v1 OPENAI_API_KEY… \ node eval/grok-density/native-sweep/ask.mjs jbmono14各步骤产出物receipts均落盘于本目录cost-*.json每档几何/Token/节省率、answers-*.json盲问答案与置信度、score.json打分与甜点结论、render-table.json阶梯渲染汇总、*-pN.png各档渲染页、truth.json真相。任意一步都可独立审计——这正是盲测协议可复现的关键。边界与扩展指引几何不可移植列数公式floor((768−8)/cellW)与maxH512是 Grok 生产约束若为其他模型如 Qwen 的providerImageCap: 32动态预算、Anthropic 的 28px patch 计费重复本实验需替换对应 profile 的几何与计费 regime见 src/core/gpt-model-profiles.ts 与 src/core/vision-cost.ts。换字号需重建图集新增字号档位时用ATLAS_PRIMARY_FONT/ATLAS_PRIMARY_PX/ATLAS_GRAY1/ATLAS_ALLOW_ANY_CELL1生成新图集再接入atlas-cells.json的单元格映射。盲测纪律是结果可信的前提gen-fixture.mjs不打印目标、ask.mjs不读truth.json、打分在答案落盘之后进行——任何一环破坏都会让精确/幻觉/弃答的区分失效。本实验的方法论夹具设计、盲问提示词、干净档判定同样复用于 eval/opus-density/native-sweep 与 Sol 的原生扫描跨模型结论因此可以直接对照。若需为某个新视觉模型决定该用多小的字这就是 pxpipe 给出的可复制、可审计的测量范式。赞分享【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载相关推荐Open-Source-Prompt-Library从PRD到MVP的完整开发清单Open Source Prompt Library从PRD到MVP的完整开发清单 想要快速将创意转化为可运行的产品Open Source Prompt L编程字体终极对决Maple Mono 与 JetBrains Mono 深度评测编程字体终极对决Maple Mono 与 JetBrains Mono 深度评测 还在为选择哪款编程字体而纠结吗今天我们将深入对比两款备受开发者青睐的等宽字开发工具编程字体终极对决Maple Mono与JetBrains Mono深度评测编程字体终极对决Maple Mono与JetBrains Mono深度评测 还在为选择编程字体而烦恼吗每天面对代码的你是否曾因字体不够清晰而感到眼睛疲劳开发工具上一篇googleapis还是google-cloudGoogle两大Node.js客户端选型终极指南下一篇PyWxDump 微信数据导出指南项目已删除你手里有旧版该怎么办创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
