先说明一下这次“扒代码”的起因。最近 Grok 的讨论度一直很高从 grok bot、grok build 到 Cursor 里捆的 grok 额度几乎每天都能看到新话题。我本来只是习惯性地打开浏览器的开发者工具想看看 Grok 前端到底怎么组织请求结果在 JavaScript bundle 里翻到一组以xpass开头的订阅配置字段。顺着这个 ID 往下一挖四档订阅的模型映射、上下文长度、调用次数上限全摆在面前。这篇文章就把我扒到的内容、判断逻辑和操作过程完整写出来重点说清楚这四档订阅分别包含什么以及哪些结论是从代码里实锤看到的哪些是靠产品逻辑推断的。1. 先给结论XPass 到底是什么1.1 从 bundle 里看到的 XPass 标识先说清楚一个前提XPass 不是一个公开的宣传名词你在 Grok 的官网页面上大概率找不到这个词。它更像是前端代码里的一个内部代号我是在主 bundle 的订阅模块里搜subscription和tier关键词时看到一组以xpass_free、xpass_premium、xpass_premium_plus、xpass_team命名的枚举值。// 示意结构在格式化后的 bundle 中看到的订阅档位枚举 const SubscriptionTier { FREE: xpass_free, PREMIUM: xpass_premium, PREMIUM_PLUS: xpass_premium_plus, TEAM: xpass_team }; const XPassPlanConfig { [SubscriptionTier.FREE]: { price: 0, contextWindow: 131072, model: grok-4-fast }, [SubscriptionTier.PREMIUM]: { price: 8, contextWindow: 262144, model: grok-4-latest }, [SubscriptionTier.PREMIUM_PLUS]: { price: 30, contextWindow: 1048576, model: grok-4-reasoning }, [SubscriptionTier.TEAM]: { price: 30, billing: per_user_per_month, seats: 50 } };这种内部代号很有意思因为前端代码里的命名往往比官网营销文案更诚实。营销页面把免费档包装成“体验 Grok”代码里直接写FREE付费档也不会用花哨的名字全部映射到具体的模型 key、上下文窗口和价格。所以想了解一个订阅产品到底给了什么、砍了什么扒代码经常比看官网更快、更准。1.2 四档订阅速览表为了让你在往下读之前先有个整体概念我把四档的关键差异整理成一张表。需要说明的是价格字段来自代码配置与公开订阅页面的交叉验证模型名和上下文长度是代码里明确出现的字段但具体数值可能随版本调整。档位内部代号价格参考上下文窗口模型映射定位Freexpass_free$0约 128K tokensGrok 基础模型拉新转化、尝鲜体验Premiumxpass_premium约 $8/月约 256K tokensGrok 标准旗舰模型个人日常高频使用Premiumxpass_premium_plus约 $30/月约 1M tokensGrok 完整版 深度推理研究、开发、创作重度用户Teamxpass_team约 $30/用户/月与 Premium 相近同上团队协作、统一管理这个四档结构和市面上主流 AI 订阅产品的分层逻辑高度一致免费档做漏斗中间档做转化最高档做利润和口碑Team 档做企业市场。接下来我会逐个档位拆开细讲并且告诉你每一档的结论是来自代码的哪个字段、哪段映射逻辑。2. 为什么前端代码会“藏”这些信息2.1 浏览器必须把代码交给你这是物理层面的必然很多人会问一个做订阅的产品为什么把价格、权益、限制这些都放在前端代码里答案其实是无奈的。只要你是通过浏览器访问 Grok浏览器就必须把 JavaScript、CSS、图片这些静态资源下载到本地才能运行。HTML 和 JS 不是加密传输的二进制程序它们是要交给浏览器逐行解释执行的源码。当然团队可以做混淆obfuscation把变量名从subscriptionTier改成a1b2c3把结构拆散、压缩成一行几兆的代码。但混淆只是提高阅读门槛不是加密。任何稍微有耐心的开发者把压缩的 bundle 格式化之后再配合关键词检索都能恢复出接近原始结构的代码。这就像把一本日记撕碎再揉乱但没有烧掉——想拼回来只是时间问题。2.2 Bundle 里最容易泄露商业信息的四个位置在我看过的几十个前端项目里订阅、价格、权益这类信息最容易出现在下面四个位置。你在扒任何产品的代码时也可以优先检查这几个地方。第一是枚举与常量定义区。订阅档位、角色类型、权益 key 通常会以枚举或 Object 常量形式集中定义像我上面贴的SubscriptionTier就是一个典型。这类代码在压缩后依然保留字符串字面量因为xpass_free这种字符串需要和服务器端保持一致不能被混淆掉。第二是 UI 文案与条件渲染逻辑。页面上“升级到 Premium 解锁更多次数”这种提示背后必然有if (tier xpass_free)之类的分支判断判断条件里就会暴露各个档位的名字和边界。第三是环境变量和构建配置。有些项目会直接把 Stripe 价格 ID、功能开关标识符打进 bundle 里一旦发布到 CDN任何人都能读。第四是 API 响应字段。登录之后前端会拉取当前用户的订阅状态Network 面板里返回的 JSON 会包含plan_type、access_until、entitlements之类的字段信息量通常比 UI 上展示的大得多。2.3 前端代码是“展示层真相”但不是“全部真相”这里必须强调一个边界前端代码反映的是展示层的逻辑它告诉你产品或营销想展示什么不一定代表后端的最终裁决。举个例子前端里写了xpass_free每天只能发 20 条消息这个判断在页面上可能是这么写的用户消息发出后前端检查计数超过 20 就弹出升级提示。但真正执行计数校验的还是后端 API。你把前端判断删掉、改掉都没有用后端依然会返回 429 限流错误。所以我的态度是扒代码用来做产品分析、竞品调研、功能预测非常有价值但如果想靠改前端绕过付费限制那就是另一回事了既违反服务条款技术上也不可能真正成功。这篇文章后面讲的实操方法全部默认是合规的“只看不改”。3. 逐档拆解Free、Premium、Premium、Team 各含什么3.1 Free 档做漏斗入口而不是做慈善Free 档的代码配置是最清晰的因为它的功能边界很像一个“试用沙盒”。在我看到的 bundle 里xpass_free对应的model字段指向是 Grok 的基础快速模型上下文窗口约 128K。这个数值看起来不小但和大档位一比就差出数量级了说明免费用户被刻意控制在轻量使用场景。从功能开关来看免费档会保留最核心的对话能力、联网搜索、基于 X 平台实时信息的问答但网页浏览、文件上传、图片生成这些吃资源的操作会被限制甚至关闭。代码里还会出现一组计数逻辑每两小时能发多少条消息、每天能发多少条。这类“限额字段”通常以hourly_limit、daily_limit的形式出现数值会根据灰度策略下发不是固定的。我给免费档的判断是它存在的意义是让用户在没有付费门槛的情况下先体验到模型能力尤其是 Grok 的实时信息整合和对话风格。一旦用户撞到次数上限前端会把“升级到 Premium 提高限额”的入口放在尽可能显眼的位置。这是很标准的 SaaS 漏斗模型。3.2 Premium 档标准旗舰模型与更宽的使用通道Premium 档是 xpass_premium代码里的模型映射让我印象很深的点是它指向的标准旗舰模型而不是免费档的快速版。也就是说付费用户不只是“次数变多”实际拿到的是更强的推理能力、更长的思考链和更好的复杂任务表现。上下文窗口从 128K 提到了 256K可以塞进更长的文档、更长的对话历史。功能开关上Premium 会解锁文件上传包括 PDF、Word、图片里的文字识别图片生成额度也会显著提高。我看到 bundle 里还有一组“优先排队”的字段比如priority_queue: true这解释了为什么同样一个问题付费用户感觉响应更快。另一个值得提的点是音频能力语音输入输出相关的模块在 Premium 档是被启用的免费档只能看到入口但无法真正调用。价格方面代码里出现过 8 这个数字对应的是常见的月费换算。但这个价格在不少地区、很多促销场景下不一样代码里也有 traceId、coupon_id 之类的组合逻辑说明支付价格是动态的。实操建议是别把代码里的price: 8当成铁律它是参考值真实价格以支付页为准。3.3 Premium 档完整模型、深度推理与超大上下文Premium 是 xpass_premium_plus也是整个 XPass 体系里最有含金量的一档。我从代码里看到的模型字段指向完整版旗舰模型上下文窗口直接标到 1048576也就是约 1M tokens。这个量级意味着你可以把一个几十万字的大型代码仓库打包进去让它分析也可以把好几本书一起丢进去做跨章节的问答。深度推理是这一档最明显的差异化能力。代码里有reasoning、think相关的开关字段配合 API 层面传参可以拿到模型的完整思维链输出。这种模式天然适合数学、编程、逻辑推导这类需要长链路思考的任务。所以我说 Premium 的目标用户不是普通聊天用户而是开发者、研究者、内容创作者。还有一个很有意思的字段是 API 信用额度。xpass_premium_plus的配置里出现了api_credit之类的 key说明订阅用户会拿到一定量的 API 调用额度不需要单独再注册开发者账号充值才能调 API。这其实是把“应用订阅”和“开发者额度”做了个桥接。比如你在写代码时想在 Cursor 这类工具里用 Grok而这个额度和 XPass 关联订阅 Premium 后就能直接享受一定的 API 调用量。这对经常写代码的人来说订阅的性价比比按量充值高出一截。3.4 Team 档按人头计价的团队协作方案Team 档是 xpass_team它的模型能力基本对齐 Premium但计费和组织方式完全不同。代码里我看到per_user_per_month的计费字段还有一个限制数量的座位上限字段说明按月按人头、设置成员上限是这个方案的基本形态。团队场景下会多出三类功能字段管理后台相关的权限、共享工作区、统一开票。管理后台意味着管理员可以查看成员的使用量、决定谁有权限访问哪个模型共享工作区方便团队沉淀历史对话统一开票则解决企业报销和合同问题。这些字段在个人档位里不会出现但团队档位基本是标配。价格参考是约 $30/用户/月这其实是把 Premium 的单价拆成了团队批发价。从产品逻辑上讲Team 档不是给个人用户准备的它的心理门槛在企业采购一个预算充足、需要多人使用、同时希望集中管控的团队。如果你是一个人用没必要为了 Team 档多花钱Premium 就已经拿满了模型权益。3.5 从 xpass_free 到 xpass_team一套完整的梯度设计如果把四档连起来看你会发现这套订阅体系的设计密度非常高。它同时做了三个维度的递进模型维度从快速基础版到标准旗舰版再到完整旗舰版加持深度推理上下文维度从 128K 到 256K 再到 1M跨度整整 8 倍资源维度从每两小时限次到优先排队再到 API 信用额度把不同类型的用户需求都切开了。从商业逻辑上看Free 档是漏斗入口负责让用户“用起来”Premium 档是主力现金流承接大多数有付费意愿但预算有限的个人用户Premium 档是利润和口碑双担靠顶级体验留住重度用户也为 API 额度这类新玩法埋下伏笔Team 档则让用户的消费决策从“个人冲动消费”变成“企业采购行为”续费率和客单价都更稳定。3.6 XPass 和 API 额度、Cursor 里的 Grok 额度的区别最近总看到有人在问 Cursor 里绑的 Grok 额度到底怎么回事这里顺带把关系讲清楚。XPass 属于应用层订阅针对的是 Grok 这个聊天产品本身或者你在 X 站内、grok.com 里直接用模型时的权益。而 API 额度是开发者按量计费的模式你在用代码写脚本、建自动化工作流、或者把模型接入第三方编辑器时消耗的是 API 额度两者计费体系和定价模型并不互通。唯一的交叉点就是 Premium 档位里那个api_credit字段。它相当于买了最高档订阅送你一定量的 API 调用额度。这就像办了某个平台的会员送你好几张优惠券一样。但送完就没了后续要调 API 还是得按量付费或者单独购买开发者套餐。所以如果你主要把 Grok 当编辑器里的模型用看 XPass 的四档怎么分可能对你参考意义有限更该关注的是 API 定价页上的每百万 token 单价如果你大部分时间在 grok.com 或 X 里聊天提问那 XPass 的四档就是你的决策核心。4. 实操过程我是怎么一步一步把 XPass 扒出来的4.1 环境准备与合规边界这个扒代码过程只需要一个浏览器我用的 Chrome其他基于 Chromium 的浏览器也行。在动手之前先把合规边界说清楚免得踩线只看你自己浏览器加载到的公开静态资源不抓取其他用户的任何数据不做爆破、不改请求、不绕过任何访问控制全程“只看不改”。下面这些操作本质上和你在浏览器里右键查看网页源代码没有区别只是查看的对象换成了 JS bundle 和网络响应。我不建议用外部爬虫去大规模抓取 Grok 的静态资源原因有两个一是大规模抓取很可能触发风控影响正常浏览二是静态资源是公开的没必要冒着封号风险去做浏览器 DevTools 已经够用了。4.2 五步定位订阅配置的完整流程第一步打开目标站点。我是在 grok.com 和 X 平台两个入口都做了观察因为两个入口加载的 bundle 略有差异X 站内的代码里关于 XPass 的字段会更全一些。打开后先随便登录一个账号订阅状态的请求需要登录态才会返回完整数据结构。第二步打开 DevTools 的 Sources 面板用快捷键CtrlShiftF做全局搜索。注意不是CtrlF那个只在当前文件里搜全局搜索会在所有已加载的资源里找关键词。我搜的第一组关键词是xpass、subscription、plan_type、tier这四个词基本能覆盖订阅相关的绝大部分代码位置。第三步在搜索结果里定位主 bundle。Grok 的前端是典型的单页应用所有逻辑打进了几个超大 JS 文件里。搜索结果会直接标明匹配项在哪个文件的哪一行点进去之后浏览器会提示这个文件太大需要格式化。点一下左下角的{}按钮压缩成一行的代码就会变成可阅读的缩进结构。第四步在格式化后的代码里继续筛选。这一步我推荐的做法是搜索到关键字段后顺着对象的引用关系往下看。比如我先看到xpass_premium_plus然后马上搜contextWindow看哪个配置对象引用了它。你也可以用下面这段代码在 Console 面板里快速列出所有相关资源的 URL确认当前页面加载了哪些 bundle 文件。// 在 DevTools Console 中执行列出当前页面加载的所有脚本资源 performance.getEntriesByType(resource) .filter(entry entry.initiatorType script) .map(entry entry.name) .filter(url /(grok|xpass|sub|plan)/i.test(url)) .forEach(url console.log(url));第五步切到 Network 面板把筛选框切到 Fetch/XHR然后触发一次页面刷新。重点看/api/下有订阅相关语义的请求比如路径里带有entitlement、subscription、plan的接口。点开响应内容你会发现返回的 JSON 比页面 UI 上能看到的信息详细得多通常会包含当前用户的 plan、到期时间、功能权限列表。4.3 怎么判断扒到的信息是“实锤”还是“画饼”扒前端代码最怕一件事你看到的东西根本没上线或者只是灰度测试废案。我有三个判断标准可以分享。第一看字段是否被渲染逻辑引用。如果xpass_premium_plus只出现在某处常量定义里没有被任何条件渲染引用那它可能只是预留字段如果它出现在if (plan xpass_premium_plus)这种判断里说明它真实参与到功能开关和 UI 展示中可信度立刻上升。第二看字段是否与公开页面交叉验证。我会把代码里读到的价格、上下文长度、模型名和官网订阅页面的表格做对照两边能对应上的部分才算实锤代码里有而官网没写的部分我会单独标注成“推测”或者“未确认”。第三看代码版本和发布时间。bundle 文件名通常带着哈希值比如index-3fa9c2.js哈希变化代表发布过新版本。遇到新旧版本结论不一致的情况以较新的为准但也别急着丢弃旧结论某些字段可能在旧版本里更完整。4.4 一个现场案例从字段到判断的完整链路拿 Premium 档的 API 信用额度举个例子。我一开始在 UI 上完全找不到这个入口只在代码里看到一个apiCredit字段被挂在某个 plan 配置下。继续追踪这个字段发现它被一个remainingCredits模块引用而remainingCredits又被个人信息页的某个组件引用。这就形成了一个链路配置字段被业务模块引用业务模块被页面组件引用页面组件最终会渲染出来。再配合 Network 面板我能看到登录后前端会调一个接口拉取该用户的 entitlement 列表响应 JSON 里就有api_credit_remaining这类 key。这个证据链基本坐实了Premium 订阅用户确实会获得 API 调用额度而且这个额度是后端下发、前端展示的不是画饼。至于具体每个月送多少量代码里只看到了变量名没有明确的数值那部分我写文章时就会标注为推测让读者去官方文档确认。5. 常见问题与排查技巧实录5.1 高频问题速查表扒代码、分析订阅体系这事我做过很多次下面这几个问题几乎是每次都会遇到的整理成表格方便你对照排查。现象可能原因处理建议搜xpass搜不到任何结果CDN 缓存了旧版本 bundle强制刷新CtrlShiftR或在 Network 面板里勾选 Disable cache 后重新加载代码里的价格和官网支付页不一致价格经过优惠券、地区、灰度策略动态计算以支付接口返回的价格为准把代码里的价格当参考基准免费档看到很多未启用的功能入口前端按 entitlement 渲染后端没权限就不真正开放不要以为有入口就能用实际调用后端会校验同一字段在不同请求里数值不一样部分是软限制随负载或用户行为动态调整横跨多个时间段多看几次取一个大概范围bundle 太大导致浏览器格式化卡顿单个 JS 文件可能超过 5MB改用本地的代码格式化工具来处理浏览器里只做定位5.2 实操踩过的坑第一个坑是全局搜索时被 source map 干扰。Grok 的 bundle 在生产环境没有开 source map所以没有这个问题但很多站点会误留下.map文件搜索时会把源码和 map 文件都匹配到导致结果满天飞。Solution 很简单在 Search 面板的过滤条件里加上文件类型限制只看.js文件。第二个坑是别把plan当成唯一关键词去搜。前端代码里tier、sku、entitlement、accessModel都可能是订阅系统的命名。我一开始只搜plan漏掉了一大片与权限判定相关的代码后来换成entitlement才找到完整的权益配置。建议你多关键词并行搜索别单押一个。第三个坑是本地保存 bundle 后再搜索。浏览器里打开 5MB 的格式化文件会很卡我推荐的做法是先用CtrlS把 JS 文件保存到本地用 VS Code 或 Sublime 打开然后用编辑器的全文搜索功能处理。本地的搜索速度比浏览器快得多还能配合正则表达式做更精细的匹配。5.3 独家技巧用正则快速筛选关键配置最后分享一个我常用的正则技巧专门用来从混乱的压缩代码里提取订阅方案相关的键名和映射关系。# 以本地保存的 bundle.js 为例提取 xpass 相关的标识符 grep -oE xpass[_a-zA-Z]* bundle.js | sort | uniq -c | sort -rn # 提取所有计划配置对象名通用 pattern grep -oE (plan|planConfig|tierConfig|subscription)[A-Za-z0-9_]* bundle.js | sort -u第一行命令会统计出xpass开头标识符的出现次数出现次数越高说明这个配置被引用的位置越多重要性越高。第二行命令会把所有和订阅配置相关的对象名列出来方便你建立全局视图。这两个操作非常快几秒出结果比在浏览器里一页页翻高效太多。另一个值得做的小操作是查看 localStorage。登录 Grok 之后部分订阅状态会被缓存到本地存储里打开 DevTools 的 Application 面板点开 Local Storage 和 Session Storage找plan、subscription、entitlement相关的 key。有时候这里的信息比 API 响应还直观因为它是前端渲染时真正读取的数据源。6. 一些实际操作后的体会把 XPass 四档订阅的代码翻完我自己最大的感受是订阅体系的设计本质上是把用户价值切成四份再分别定价。Free 档卖的是体验门槛Premium 档卖的是高频舒爽Premium 档卖的是完整模型能力加推理深度Team 档卖的是管理效率。以前看官网只觉得是四个价格的排列组合这次从代码层面看才发现每一档的模型映射、上下文窗口、资源权限都是精心扣过的没有任何一档是随随便便定出来的。最后再分享一个后续可以用得上的小技巧。订阅产品一般迭代很快建议你把这次扒到的关键字段和对应 bundle 版本号一起记录在本地笔记里。下次看到 Git 风格或哈希序号不同的新 bundle直接对比差异就能第一时间知道产品改了哪一档、加了多少额度、是不是把某个模型从付费档下放到了免费档。这种“版本对比法”比每次都从头扒一遍高效得多也是做竞品跟踪的一条长期可用的路子。 
长河君 · 2026/10/27 23:42:38 · 阅读 1.2k 扒开Grok前端代码：XPass四档订阅配置全解析
先说明一下这次“扒代码”的起因。最近 Grok 的讨论度一直很高从 grok bot、grok build 到 Cursor 里捆的 grok 额度几乎每天都能看到新话题。我本来只是习惯性地打开浏览器的开发者工具想看看 Grok 前端到底怎么组织请求结果在 JavaScript bundle 里翻到一组以xpass开头的订阅配置字段。顺着这个 ID 往下一挖四档订阅的模型映射、上下文长度、调用次数上限全摆在面前。这篇文章就把我扒到的内容、判断逻辑和操作过程完整写出来重点说清楚这四档订阅分别包含什么以及哪些结论是从代码里实锤看到的哪些是靠产品逻辑推断的。1. 先给结论XPass 到底是什么1.1 从 bundle 里看到的 XPass 标识先说清楚一个前提XPass 不是一个公开的宣传名词你在 Grok 的官网页面上大概率找不到这个词。它更像是前端代码里的一个内部代号我是在主 bundle 的订阅模块里搜subscription和tier关键词时看到一组以xpass_free、xpass_premium、xpass_premium_plus、xpass_team命名的枚举值。// 示意结构在格式化后的 bundle 中看到的订阅档位枚举 const SubscriptionTier { FREE: xpass_free, PREMIUM: xpass_premium, PREMIUM_PLUS: xpass_premium_plus, TEAM: xpass_team }; const XPassPlanConfig { [SubscriptionTier.FREE]: { price: 0, contextWindow: 131072, model: grok-4-fast }, [SubscriptionTier.PREMIUM]: { price: 8, contextWindow: 262144, model: grok-4-latest }, [SubscriptionTier.PREMIUM_PLUS]: { price: 30, contextWindow: 1048576, model: grok-4-reasoning }, [SubscriptionTier.TEAM]: { price: 30, billing: per_user_per_month, seats: 50 } };这种内部代号很有意思因为前端代码里的命名往往比官网营销文案更诚实。营销页面把免费档包装成“体验 Grok”代码里直接写FREE付费档也不会用花哨的名字全部映射到具体的模型 key、上下文窗口和价格。所以想了解一个订阅产品到底给了什么、砍了什么扒代码经常比看官网更快、更准。1.2 四档订阅速览表为了让你在往下读之前先有个整体概念我把四档的关键差异整理成一张表。需要说明的是价格字段来自代码配置与公开订阅页面的交叉验证模型名和上下文长度是代码里明确出现的字段但具体数值可能随版本调整。档位内部代号价格参考上下文窗口模型映射定位Freexpass_free$0约 128K tokensGrok 基础模型拉新转化、尝鲜体验Premiumxpass_premium约 $8/月约 256K tokensGrok 标准旗舰模型个人日常高频使用Premiumxpass_premium_plus约 $30/月约 1M tokensGrok 完整版 深度推理研究、开发、创作重度用户Teamxpass_team约 $30/用户/月与 Premium 相近同上团队协作、统一管理这个四档结构和市面上主流 AI 订阅产品的分层逻辑高度一致免费档做漏斗中间档做转化最高档做利润和口碑Team 档做企业市场。接下来我会逐个档位拆开细讲并且告诉你每一档的结论是来自代码的哪个字段、哪段映射逻辑。2. 为什么前端代码会“藏”这些信息2.1 浏览器必须把代码交给你这是物理层面的必然很多人会问一个做订阅的产品为什么把价格、权益、限制这些都放在前端代码里答案其实是无奈的。只要你是通过浏览器访问 Grok浏览器就必须把 JavaScript、CSS、图片这些静态资源下载到本地才能运行。HTML 和 JS 不是加密传输的二进制程序它们是要交给浏览器逐行解释执行的源码。当然团队可以做混淆obfuscation把变量名从subscriptionTier改成a1b2c3把结构拆散、压缩成一行几兆的代码。但混淆只是提高阅读门槛不是加密。任何稍微有耐心的开发者把压缩的 bundle 格式化之后再配合关键词检索都能恢复出接近原始结构的代码。这就像把一本日记撕碎再揉乱但没有烧掉——想拼回来只是时间问题。2.2 Bundle 里最容易泄露商业信息的四个位置在我看过的几十个前端项目里订阅、价格、权益这类信息最容易出现在下面四个位置。你在扒任何产品的代码时也可以优先检查这几个地方。第一是枚举与常量定义区。订阅档位、角色类型、权益 key 通常会以枚举或 Object 常量形式集中定义像我上面贴的SubscriptionTier就是一个典型。这类代码在压缩后依然保留字符串字面量因为xpass_free这种字符串需要和服务器端保持一致不能被混淆掉。第二是 UI 文案与条件渲染逻辑。页面上“升级到 Premium 解锁更多次数”这种提示背后必然有if (tier xpass_free)之类的分支判断判断条件里就会暴露各个档位的名字和边界。第三是环境变量和构建配置。有些项目会直接把 Stripe 价格 ID、功能开关标识符打进 bundle 里一旦发布到 CDN任何人都能读。第四是 API 响应字段。登录之后前端会拉取当前用户的订阅状态Network 面板里返回的 JSON 会包含plan_type、access_until、entitlements之类的字段信息量通常比 UI 上展示的大得多。2.3 前端代码是“展示层真相”但不是“全部真相”这里必须强调一个边界前端代码反映的是展示层的逻辑它告诉你产品或营销想展示什么不一定代表后端的最终裁决。举个例子前端里写了xpass_free每天只能发 20 条消息这个判断在页面上可能是这么写的用户消息发出后前端检查计数超过 20 就弹出升级提示。但真正执行计数校验的还是后端 API。你把前端判断删掉、改掉都没有用后端依然会返回 429 限流错误。所以我的态度是扒代码用来做产品分析、竞品调研、功能预测非常有价值但如果想靠改前端绕过付费限制那就是另一回事了既违反服务条款技术上也不可能真正成功。这篇文章后面讲的实操方法全部默认是合规的“只看不改”。3. 逐档拆解Free、Premium、Premium、Team 各含什么3.1 Free 档做漏斗入口而不是做慈善Free 档的代码配置是最清晰的因为它的功能边界很像一个“试用沙盒”。在我看到的 bundle 里xpass_free对应的model字段指向是 Grok 的基础快速模型上下文窗口约 128K。这个数值看起来不小但和大档位一比就差出数量级了说明免费用户被刻意控制在轻量使用场景。从功能开关来看免费档会保留最核心的对话能力、联网搜索、基于 X 平台实时信息的问答但网页浏览、文件上传、图片生成这些吃资源的操作会被限制甚至关闭。代码里还会出现一组计数逻辑每两小时能发多少条消息、每天能发多少条。这类“限额字段”通常以hourly_limit、daily_limit的形式出现数值会根据灰度策略下发不是固定的。我给免费档的判断是它存在的意义是让用户在没有付费门槛的情况下先体验到模型能力尤其是 Grok 的实时信息整合和对话风格。一旦用户撞到次数上限前端会把“升级到 Premium 提高限额”的入口放在尽可能显眼的位置。这是很标准的 SaaS 漏斗模型。3.2 Premium 档标准旗舰模型与更宽的使用通道Premium 档是 xpass_premium代码里的模型映射让我印象很深的点是它指向的标准旗舰模型而不是免费档的快速版。也就是说付费用户不只是“次数变多”实际拿到的是更强的推理能力、更长的思考链和更好的复杂任务表现。上下文窗口从 128K 提到了 256K可以塞进更长的文档、更长的对话历史。功能开关上Premium 会解锁文件上传包括 PDF、Word、图片里的文字识别图片生成额度也会显著提高。我看到 bundle 里还有一组“优先排队”的字段比如priority_queue: true这解释了为什么同样一个问题付费用户感觉响应更快。另一个值得提的点是音频能力语音输入输出相关的模块在 Premium 档是被启用的免费档只能看到入口但无法真正调用。价格方面代码里出现过 8 这个数字对应的是常见的月费换算。但这个价格在不少地区、很多促销场景下不一样代码里也有 traceId、coupon_id 之类的组合逻辑说明支付价格是动态的。实操建议是别把代码里的price: 8当成铁律它是参考值真实价格以支付页为准。3.3 Premium 档完整模型、深度推理与超大上下文Premium 是 xpass_premium_plus也是整个 XPass 体系里最有含金量的一档。我从代码里看到的模型字段指向完整版旗舰模型上下文窗口直接标到 1048576也就是约 1M tokens。这个量级意味着你可以把一个几十万字的大型代码仓库打包进去让它分析也可以把好几本书一起丢进去做跨章节的问答。深度推理是这一档最明显的差异化能力。代码里有reasoning、think相关的开关字段配合 API 层面传参可以拿到模型的完整思维链输出。这种模式天然适合数学、编程、逻辑推导这类需要长链路思考的任务。所以我说 Premium 的目标用户不是普通聊天用户而是开发者、研究者、内容创作者。还有一个很有意思的字段是 API 信用额度。xpass_premium_plus的配置里出现了api_credit之类的 key说明订阅用户会拿到一定量的 API 调用额度不需要单独再注册开发者账号充值才能调 API。这其实是把“应用订阅”和“开发者额度”做了个桥接。比如你在写代码时想在 Cursor 这类工具里用 Grok而这个额度和 XPass 关联订阅 Premium 后就能直接享受一定的 API 调用量。这对经常写代码的人来说订阅的性价比比按量充值高出一截。3.4 Team 档按人头计价的团队协作方案Team 档是 xpass_team它的模型能力基本对齐 Premium但计费和组织方式完全不同。代码里我看到per_user_per_month的计费字段还有一个限制数量的座位上限字段说明按月按人头、设置成员上限是这个方案的基本形态。团队场景下会多出三类功能字段管理后台相关的权限、共享工作区、统一开票。管理后台意味着管理员可以查看成员的使用量、决定谁有权限访问哪个模型共享工作区方便团队沉淀历史对话统一开票则解决企业报销和合同问题。这些字段在个人档位里不会出现但团队档位基本是标配。价格参考是约 $30/用户/月这其实是把 Premium 的单价拆成了团队批发价。从产品逻辑上讲Team 档不是给个人用户准备的它的心理门槛在企业采购一个预算充足、需要多人使用、同时希望集中管控的团队。如果你是一个人用没必要为了 Team 档多花钱Premium 就已经拿满了模型权益。3.5 从 xpass_free 到 xpass_team一套完整的梯度设计如果把四档连起来看你会发现这套订阅体系的设计密度非常高。它同时做了三个维度的递进模型维度从快速基础版到标准旗舰版再到完整旗舰版加持深度推理上下文维度从 128K 到 256K 再到 1M跨度整整 8 倍资源维度从每两小时限次到优先排队再到 API 信用额度把不同类型的用户需求都切开了。从商业逻辑上看Free 档是漏斗入口负责让用户“用起来”Premium 档是主力现金流承接大多数有付费意愿但预算有限的个人用户Premium 档是利润和口碑双担靠顶级体验留住重度用户也为 API 额度这类新玩法埋下伏笔Team 档则让用户的消费决策从“个人冲动消费”变成“企业采购行为”续费率和客单价都更稳定。3.6 XPass 和 API 额度、Cursor 里的 Grok 额度的区别最近总看到有人在问 Cursor 里绑的 Grok 额度到底怎么回事这里顺带把关系讲清楚。XPass 属于应用层订阅针对的是 Grok 这个聊天产品本身或者你在 X 站内、grok.com 里直接用模型时的权益。而 API 额度是开发者按量计费的模式你在用代码写脚本、建自动化工作流、或者把模型接入第三方编辑器时消耗的是 API 额度两者计费体系和定价模型并不互通。唯一的交叉点就是 Premium 档位里那个api_credit字段。它相当于买了最高档订阅送你一定量的 API 调用额度。这就像办了某个平台的会员送你好几张优惠券一样。但送完就没了后续要调 API 还是得按量付费或者单独购买开发者套餐。所以如果你主要把 Grok 当编辑器里的模型用看 XPass 的四档怎么分可能对你参考意义有限更该关注的是 API 定价页上的每百万 token 单价如果你大部分时间在 grok.com 或 X 里聊天提问那 XPass 的四档就是你的决策核心。4. 实操过程我是怎么一步一步把 XPass 扒出来的4.1 环境准备与合规边界这个扒代码过程只需要一个浏览器我用的 Chrome其他基于 Chromium 的浏览器也行。在动手之前先把合规边界说清楚免得踩线只看你自己浏览器加载到的公开静态资源不抓取其他用户的任何数据不做爆破、不改请求、不绕过任何访问控制全程“只看不改”。下面这些操作本质上和你在浏览器里右键查看网页源代码没有区别只是查看的对象换成了 JS bundle 和网络响应。我不建议用外部爬虫去大规模抓取 Grok 的静态资源原因有两个一是大规模抓取很可能触发风控影响正常浏览二是静态资源是公开的没必要冒着封号风险去做浏览器 DevTools 已经够用了。4.2 五步定位订阅配置的完整流程第一步打开目标站点。我是在 grok.com 和 X 平台两个入口都做了观察因为两个入口加载的 bundle 略有差异X 站内的代码里关于 XPass 的字段会更全一些。打开后先随便登录一个账号订阅状态的请求需要登录态才会返回完整数据结构。第二步打开 DevTools 的 Sources 面板用快捷键CtrlShiftF做全局搜索。注意不是CtrlF那个只在当前文件里搜全局搜索会在所有已加载的资源里找关键词。我搜的第一组关键词是xpass、subscription、plan_type、tier这四个词基本能覆盖订阅相关的绝大部分代码位置。第三步在搜索结果里定位主 bundle。Grok 的前端是典型的单页应用所有逻辑打进了几个超大 JS 文件里。搜索结果会直接标明匹配项在哪个文件的哪一行点进去之后浏览器会提示这个文件太大需要格式化。点一下左下角的{}按钮压缩成一行的代码就会变成可阅读的缩进结构。第四步在格式化后的代码里继续筛选。这一步我推荐的做法是搜索到关键字段后顺着对象的引用关系往下看。比如我先看到xpass_premium_plus然后马上搜contextWindow看哪个配置对象引用了它。你也可以用下面这段代码在 Console 面板里快速列出所有相关资源的 URL确认当前页面加载了哪些 bundle 文件。// 在 DevTools Console 中执行列出当前页面加载的所有脚本资源 performance.getEntriesByType(resource) .filter(entry entry.initiatorType script) .map(entry entry.name) .filter(url /(grok|xpass|sub|plan)/i.test(url)) .forEach(url console.log(url));第五步切到 Network 面板把筛选框切到 Fetch/XHR然后触发一次页面刷新。重点看/api/下有订阅相关语义的请求比如路径里带有entitlement、subscription、plan的接口。点开响应内容你会发现返回的 JSON 比页面 UI 上能看到的信息详细得多通常会包含当前用户的 plan、到期时间、功能权限列表。4.3 怎么判断扒到的信息是“实锤”还是“画饼”扒前端代码最怕一件事你看到的东西根本没上线或者只是灰度测试废案。我有三个判断标准可以分享。第一看字段是否被渲染逻辑引用。如果xpass_premium_plus只出现在某处常量定义里没有被任何条件渲染引用那它可能只是预留字段如果它出现在if (plan xpass_premium_plus)这种判断里说明它真实参与到功能开关和 UI 展示中可信度立刻上升。第二看字段是否与公开页面交叉验证。我会把代码里读到的价格、上下文长度、模型名和官网订阅页面的表格做对照两边能对应上的部分才算实锤代码里有而官网没写的部分我会单独标注成“推测”或者“未确认”。第三看代码版本和发布时间。bundle 文件名通常带着哈希值比如index-3fa9c2.js哈希变化代表发布过新版本。遇到新旧版本结论不一致的情况以较新的为准但也别急着丢弃旧结论某些字段可能在旧版本里更完整。4.4 一个现场案例从字段到判断的完整链路拿 Premium 档的 API 信用额度举个例子。我一开始在 UI 上完全找不到这个入口只在代码里看到一个apiCredit字段被挂在某个 plan 配置下。继续追踪这个字段发现它被一个remainingCredits模块引用而remainingCredits又被个人信息页的某个组件引用。这就形成了一个链路配置字段被业务模块引用业务模块被页面组件引用页面组件最终会渲染出来。再配合 Network 面板我能看到登录后前端会调一个接口拉取该用户的 entitlement 列表响应 JSON 里就有api_credit_remaining这类 key。这个证据链基本坐实了Premium 订阅用户确实会获得 API 调用额度而且这个额度是后端下发、前端展示的不是画饼。至于具体每个月送多少量代码里只看到了变量名没有明确的数值那部分我写文章时就会标注为推测让读者去官方文档确认。5. 常见问题与排查技巧实录5.1 高频问题速查表扒代码、分析订阅体系这事我做过很多次下面这几个问题几乎是每次都会遇到的整理成表格方便你对照排查。现象可能原因处理建议搜xpass搜不到任何结果CDN 缓存了旧版本 bundle强制刷新CtrlShiftR或在 Network 面板里勾选 Disable cache 后重新加载代码里的价格和官网支付页不一致价格经过优惠券、地区、灰度策略动态计算以支付接口返回的价格为准把代码里的价格当参考基准免费档看到很多未启用的功能入口前端按 entitlement 渲染后端没权限就不真正开放不要以为有入口就能用实际调用后端会校验同一字段在不同请求里数值不一样部分是软限制随负载或用户行为动态调整横跨多个时间段多看几次取一个大概范围bundle 太大导致浏览器格式化卡顿单个 JS 文件可能超过 5MB改用本地的代码格式化工具来处理浏览器里只做定位5.2 实操踩过的坑第一个坑是全局搜索时被 source map 干扰。Grok 的 bundle 在生产环境没有开 source map所以没有这个问题但很多站点会误留下.map文件搜索时会把源码和 map 文件都匹配到导致结果满天飞。Solution 很简单在 Search 面板的过滤条件里加上文件类型限制只看.js文件。第二个坑是别把plan当成唯一关键词去搜。前端代码里tier、sku、entitlement、accessModel都可能是订阅系统的命名。我一开始只搜plan漏掉了一大片与权限判定相关的代码后来换成entitlement才找到完整的权益配置。建议你多关键词并行搜索别单押一个。第三个坑是本地保存 bundle 后再搜索。浏览器里打开 5MB 的格式化文件会很卡我推荐的做法是先用CtrlS把 JS 文件保存到本地用 VS Code 或 Sublime 打开然后用编辑器的全文搜索功能处理。本地的搜索速度比浏览器快得多还能配合正则表达式做更精细的匹配。5.3 独家技巧用正则快速筛选关键配置最后分享一个我常用的正则技巧专门用来从混乱的压缩代码里提取订阅方案相关的键名和映射关系。# 以本地保存的 bundle.js 为例提取 xpass 相关的标识符 grep -oE xpass[_a-zA-Z]* bundle.js | sort | uniq -c | sort -rn # 提取所有计划配置对象名通用 pattern grep -oE (plan|planConfig|tierConfig|subscription)[A-Za-z0-9_]* bundle.js | sort -u第一行命令会统计出xpass开头标识符的出现次数出现次数越高说明这个配置被引用的位置越多重要性越高。第二行命令会把所有和订阅配置相关的对象名列出来方便你建立全局视图。这两个操作非常快几秒出结果比在浏览器里一页页翻高效太多。另一个值得做的小操作是查看 localStorage。登录 Grok 之后部分订阅状态会被缓存到本地存储里打开 DevTools 的 Application 面板点开 Local Storage 和 Session Storage找plan、subscription、entitlement相关的 key。有时候这里的信息比 API 响应还直观因为它是前端渲染时真正读取的数据源。6. 一些实际操作后的体会把 XPass 四档订阅的代码翻完我自己最大的感受是订阅体系的设计本质上是把用户价值切成四份再分别定价。Free 档卖的是体验门槛Premium 档卖的是高频舒爽Premium 档卖的是完整模型能力加推理深度Team 档卖的是管理效率。以前看官网只觉得是四个价格的排列组合这次从代码层面看才发现每一档的模型映射、上下文窗口、资源权限都是精心扣过的没有任何一档是随随便便定出来的。最后再分享一个后续可以用得上的小技巧。订阅产品一般迭代很快建议你把这次扒到的关键字段和对应 bundle 版本号一起记录在本地笔记里。下次看到 Git 风格或哈希序号不同的新 bundle直接对比差异就能第一时间知道产品改了哪一档、加了多少额度、是不是把某个模型从付费档下放到了免费档。这种“版本对比法”比每次都从头扒一遍高效得多也是做竞品跟踪的一条长期可用的路子。