X API alternative：每千条帖子 $5 对 $0.0033

X 官方 API 现在只卖按量付费：每读一条帖子 $0.005，每读一个用户资料 $0.010，1,000 条帖子就是 $5（X 定价页，2026 年 11 月 9 日 00:15 新加坡时间读取）。我们在同一天用 EveryInfra 的 twitter/search 等 9 项能力真调 27 次，一次请求一个价、最多回 200 条，关键词搜索折合每 1,000 条 $0.0033，约为官方的 1,530 分之一；粉丝列表一次回了 2,000 个可见粉丝（是样本，不保证完整），官方按完整列表算 2,000 个要 $20。更要紧的是一条刚公布的变化：X 在 2026 年 10 月 23 日通知，11 月 22 日起随帖子一起带回的作者资料也按 $0.010 一个收费；按我们样本里 200 条帖子有 186 个不同作者算，带作者信息的 1,000 条帖子在官方会从 $5 涨到约 $14.30。

这篇写给正在找 X API 替代方案的开发者：手里有一个只读公开数据的项目，例如品牌监测、舆情周报、研究抽样、给 AI agent 当信息来源，算了一下 X 官方的账单觉得太贵。我们这一侧全部是 2026 年 11 月 9 日的真调，每个数都能回到原始返回；X 那一侧只用它自己公开的文档、开发者论坛公告和更新日志，没有注册 X 开发者账号，也没有调用 X 的接口，所以表里 X 的数字都是公开单价乘出来的，不是实测账单。站内已经有一篇比较各类推文抓取工具按条价的对比文，那篇里 X 官方只占一节；本篇反过来，主角是 X 官方的计费规则本身：逐个端点的单价、24 小时去重、11 月 22 日的扩展字段计费、每月上限、额度、上手步骤和 MCP 接入，以及什么时候应该留在官方。

先看结论：x api alternative 总对比表

下表把一个只读项目最常用的七种数据放在同一个单位上：每拿到 1,000 条（帖子、账号或回复），或者每 1,000 次请求（热榜、单条帖子查询）。X 一列是 docs.x.com 定价页的公开单价直接乘 1,000；EveryInfra 一列是本文真调的实扣金额（响应里的 billing.charged_usd）除以去重后的条数再乘 1,000，不是目录上的理论值。

读这张表要注意三件事。第一，差距最大的几行都来自「一次请求回一整页」：搜索和账号帖子一次最多 200 条，粉丝列表一次最多 2,000 个，一页越满，每条摊到的钱越少；只要单个账号资料、单条帖子这类一次只能回一个对象的请求，差距就缩到 9 到 18 倍。第二，X 的「帖子 + 作者」一行是按 11 月 22 日之后的规则算的，作者数取我们第一次搜索的实测比例（200 条帖子 186 个不同作者），你的查询里同一个作者发得越多，这一行越接近 $5。第三，X 有一条我们没有的规则：同一个对象在同一个 UTC 日里重复读到只收一次钱。所以对「同一个查询反复查、每次大部分是旧帖子」的用法，表里的倍数会被高估，后面「24 小时去重」一节专门算了这种情况，在新帖很少的时候 X 反而更便宜。

X API 现在怎么收费：按量付费单价表

X 的开发者 API 在 2026 年 2 月 6 日正式上线按量付费（Pay-Per-Use），先买额度，调用时按端点扣；旧的 Basic 套餐在 5 月 21 日宣布 6 月 1 日后按各自的账单日迁到按量付费，月付用户迁移时先扣 $200 初始额度，默认每个账单周期花费上限 $400；Pro 套餐在 8 月 14 日宣布 9 月 1 日后迁走，月付用户先扣 $5,000 初始额度，默认花费上限 $10,000。到写稿这天，新开发者能自助开通的只剩按量付费一种，更大的用量要填企业版意向表，价格不公开。

下面是定价页「读取」部分的原文截图。我们在 2026 年 11 月 9 日 00:20（新加坡时间）用无头浏览器打开，青绿框里是读取类资源的单价，以及每月 300 万条帖子读取的上限。这一段是本文所有 X 侧算术的起点。

这张表有两个容易漏看的地方。第一，读取类是「按返回的对象」计费，所以 X 的成本和你要的条数严格成正比，不存在一次请求拿满一页就便宜的说法；它的搜索接口一页最多 100 条（最近 7 天）或 500 条（全量归档），一页满不满都按条收。第二，定价页写明「价格可能变化」，以开发者控制台为准；4 月 20 日那次调整就把普通发帖从 $0.01 涨到 $0.015，带链接的帖子定成 $0.20（4 月 16 日公告）。如果你的项目对价格敏感，最好每个月重读一次定价页。

11 月 22 日起，扩展字段也要收钱

X API v2 有一个叫「扩展」（expansions）的机制：查帖子时加上 expansions=author_id，响应的 includes 里会附带作者的完整资料，不用再单独查一次用户（扩展文档）。到 11 月 21 日为止，这些附带对象不计入用量；X 开发者平台团队在 10 月 23 日的公告里写明，从 11 月 22 日起，通过扩展带回的帖子、用户、媒体、投票和地点都按各自的标准单价收费：帖子 $0.005、用户 $0.010、媒体 $0.005、投票 $0.005、地点 $0.005。公告里的原话是这不是新的定价模式，但取决于你用扩展有多多，账单可能会变。

这条变化对监测类项目影响很大，因为几乎没有人只要帖子正文不要作者。我们用自己的第一次搜索做了一个估算：twitter/search 搜「x api pricing」回了 200 条帖子，按 author_id 去重后是 186 个不同作者。如果同样这 200 条从 X 的搜索接口拿，并且带上 author_id 扩展，11 月 22 日之后的账单是 200 × $0.005 + 186 × $0.010 = $2.86，折合每 1,000 条约 $14.30，是之前 $5 的 2.86 倍。再带上 attachments.media_keys，这 200 条里有 78 条带图片或视频，每个媒体对象再加 $0.005。X 的 24 小时去重同样适用于用户对象，所以同一个作者一天里出现多次只收一次，作者重复度高的查询（例如只搜几个固定账号）不会涨这么多。

我们这一侧的返回本来就把作者的粉丝数、认证状态、简介、注册时间等放在每条帖子里，目录里 twitter/search 的 response_fields 列了 38 个字段（目录）。这不等于两边字段一样：X 的帖子对象有编辑历史、上下文注释、社区笔记等我们没有的字段，我们也有 X 帖子对象里没有直接给的东西，后面「字段」一节逐项写。

我们怎么测，以及怎么判断对错

动笔之前，我们先写下判据：至少 4 种数据各真调一次以上、分布在 3 个以上不同时刻；每 1,000 条的价格一律用「实扣金额 ÷ 去重后的条数 × 1,000」，不用请求里写的 limit；至少 2 次「没拿到数据」的请求要记下扣费；只要某种情况 X 更便宜或更合适，正文和总表都照写。所有请求都发到 POST https://api.everyinfra.com/api/v1/social，Key 只经环境变量注入；每次记下发出时刻、HTTP 状态、客户端总耗时、条数和 charged_usd，之后用脚本从原始返回重新算一遍，正文、表和图里的数都取自脚本输出。

全部真调集中在 2026 年 11 月 9 日 00:17–01:48（新加坡时间）这一段，合计 27 次，其中 18 次扣费，实扣合计 $0.010008。这把测试 Key 被几篇稿子共用，每分钟只给 10 次，所以中间有几次被限速，下文照实记。

实测一：关键词搜索，同样 1,000 条帖子

搜帖子是只读项目里最常见的用法。X 官方有两个搜索端点：最近 7 天的 /2/tweets/search/recent，所有开发者可用，每次最多 100 条；全量归档的 /2/tweets/search/all，按量付费和企业客户可用，可以搜到 2006 年，每次最多 500 条，每秒 1 次（搜索文档、限速表）。两个端点都按返回的帖子数收 $0.005 一条。我们这一侧对应 twitter/search，必填 keyword，可选 limit（默认 25，最多 200）和 sort；X 的搜索语法（from:、since:、lang: 等）直接写进 keyword。

# 2026-11-09 00:17:15 新加坡时间：HTTP 200，用时 52.7 秒，count 200，billing.charged_usd 0.000556
curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"x api pricing","limit":200}}'

9 次成功的搜索一共回了 1,531 条帖子，每次内部没有重复；7 次拿满 200 条，s05 回 131 条是因为 from:XDevelopers since:2026-01-01 这个范围里只给了这么多，去重条数的中位数是 200。两次例外要照实说：00:24 的 s02 和 00:25 的 s03，limit 写的是 200，只回了 100 条，而且每条只有 15 个字段，没有作者 ID、作者粉丝数和图片视频，其余 7 次每条有 26 到 32 个字段。钱照样是 $0.000556 一次，所以这两次折合每 1,000 条是 $0.00556，比满页贵一倍，但仍然是 X 的九百分之一。用时方面，9 次搜索中位 54.1 秒，最慢 69.5 秒，没有达到我们动笔前定的 30 秒目标；拿满 200 条的请求基本在 48 到 59 秒之间。等不了这么久的程序，可以在请求体里加 "mode":"async"，先拿到 job_id 再轮询，响应里的 async_hint 写着这个用法。

这组数里有一个值得单独说的现象：默认排序是「热门」，第一次搜「x api pricing」的 200 条里只有 80 条发在最近 7 天，87 条在最近 30 天，最早一条是 2023 年 8 月。X 的最近 7 天搜索拿不到另外那 120 条，要用全量归档端点；价格不变，但限速从每 15 分钟 450 次降到每秒 1 次。反过来，如果你只要最近 7 天，在我们这边要在 keyword 里加 since: 日期，否则会混进老帖子，这一点和 X 的最近搜索端点默认行为不同，迁移时要改。

实测二：某个账号的帖子，以及 3,200 条上限

拿某个账号的帖子，X 用用户时间线端点 /2/users/:id/tweets：最多拿到最近 3,200 条，可以排除回复和转发，按条收 $0.005（时间线文档）；它的应用级限速很宽，每 15 分钟 10,000 次。要注意的是，如果你读的是自己 App 所有者账号的时间线，4 月 20 日起按 Owned Reads 计费，每条只要 $0.001，这是 X 有而我们没有的便宜通道。

我们这一侧是 twitter/user_posts，必填 username，limit 最多 200。00:18 拿 @XDevelopers 回了 200 条、200 条不重复，时间从 2025 年 11 月 19 日到 2026 年 11 月 6 日，跨了将近一年，其中 120 条是转发、55 条是回复；00:24 拿 @NASA 回了 200 条，从 2026 年 9 月 23 日到 11 月 8 日，62 条是转发。两次各扣 $0.000556，折合每 1,000 条 $0.00278；同样 400 条在 X 是 $2.00。如果你只要原创帖子，X 可以在请求里用 exclude=retweets,replies 少拿也少付钱，我们这边是拿回来再按 is_repost、is_reply 过滤，钱不变但能用的条数会少。@XDevelopers 这 200 条里转发 120、回复 55，原创只有 25 条，只要原创时实际单价要乘 8；只排除转发、保留回复时乘 2.5。@NASA 的 200 条里原创 83 条，乘 2.4 左右。所以按原创帖子算每千条价，要先看目标账号的发帖习惯，再决定用 user_posts 一次拿满，还是用搜索加 from: 和时间段去拿。

要比 200 条更早的帖子，我们这边可以用搜索加 from: 和 until: 按时间往前切片，我们试了一次：00:33 搜 from:XDevelopers since:2026-01-01，一次回了 131 条，从 2026 年 1 月 6 日到 11 月 6 日，其中 105 条是转发、6 条是回复，扣 $0.000556。拿它和 00:18 的 twitter/user_posts 对照，这 131 条全部在那 200 条里，但那 200 条里 2026 年发的有 180 条，搜索切片漏了 49 条。所以按时间切片往前翻是可行的，价格也一样低，但不保证一条不漏；X 的时间线端点在 3,200 条以内是按时间倒序完整给的，要求完整时这是它的优势。00:39 我们又拿了一次 @XDevelopers 的 200 条（u01b），和 00:18 那次完全一样，说明同一时段内的结果是稳定的。

实测三：用户资料和粉丝列表

X 对用户对象收得比帖子贵一倍：User: Read 和 Following/Followers: Read 都是每个 $0.010（定价页）。按用户名查资料的 /2/users/by 一次最多 100 个，粉丝列表 /2/users/:id/followers 一页最多 1,000 个（用户查询文档、关注关系文档）；不管一页多少个，每个都按 $0.010 算，所以 1,000 个账号的资料或 1,000 个粉丝就是 $10。

我们这一侧有三条路，价格差得很远。twitter/profile 一次查一个账号，带粉丝数、关注数、发帖数，每次 $0.000556，1,000 个账号 $0.556，是 X 的 18 分之一，这是本文差距最小的一行。twitter/profiles_by_ids 一次最多查 20 个数字 ID，目录价 $0.000806 一次，按次计费、不按个数；目录写明它不回简介和粉丝数。我们在 00:31、00:39 和 01:48 三个时刻各试了一次，三次都回 503 unavailable，响应写着「Not charged」，所以本文没有它的实测每千条价，表里只写目录推算的 $0.0403（每次 20 个），不算进实测结论。twitter/search_users（按关键词找账号）00:31 和 01:48 两次也是 503、不扣费。

粉丝列表要先说清两边卖的不是同一样东西。X 的 /2/users/:id/followers 可以一页一页翻完一个账号的全部粉丝；我们的 twitter/followers_list 在目录里写明「读取可见粉丝和关注账号，不保证完整关系网」，回的是一份样本。所以要抽样看粉丝构成，我们一次 2,000 个 $0.000556；要一个不漏的完整列表，只能用 X，2,000 个 $20。00:23 我们查 @XDevelopers 的粉丝，limit 2,000，一次回了 2,000 个不重复的账号，每个都带粉丝数、关注数、发帖数、认证状态和注册时间。它适合回答「这个账号的粉丝里有多少是今年新注册、零粉丝的号」这类问题，不适合做完整的关系网分析，也不适合要逐个通知粉丝的场景。

这张小表也说明了为什么粉丝数据值得便宜地拿：一个账号的粉丝里有多大比例是零粉丝、零发帖的新号，是判断它粉丝质量的常用指标之一，但在 X 官方按每个 $0.010 收费时，看 2,000 个粉丝就要 $20，很少有人会为一个竞品账号花这个钱。

实测四：回复和单条帖子

X 没有单独的「回复」端点：要拿某个帖子下的回复，通常是用搜索加 conversation_id: 运算符，返回的每条回复按帖子收 $0.005（查询运算符）。我们这一侧是 twitter/comments，必填帖子 id，limit 最多 50。00:30 我们拿 @XDevelopers 2024 年 10 月 30 日那条调价公告（帖子本身显示 1,332 条回复）的回复，limit 50，回了 47 条、47 条不重复、42 个不同作者，最早一条和原帖同一天，最晚一条是 2025 年 5 月；00:31 拿一条 2026 年 10 月的热门帖（显示 605 条回复），回了 50 条、49 个作者。两次各扣 $0.000556，97 条回复折合每 1,000 条 $0.0115；同样 97 条在 X 按帖子算是 $0.485。要看清楚的是上限：twitter/comments 一次最多 50 条，没有翻页参数，所以对一个有 1,332 条回复的帖子，我们只能拿到前 50 条左右；要完整的回复树，用 X 的 conversation_id: 搜索一页一页翻更合适，钱按条算，1,332 条约 $6.66。

按 ID 查帖子是另一种情况。X 的 /2/tweets 一次可以查 100 个 ID，按返回的帖子收 $0.005 一条（帖子查询文档）；我们的 twitter/post 一次只查一个 ID，00:31 我们查了上面那条 2024 年 10 月的公告，用时 10.8 秒，回了点赞 3,996、回复 1,332、浏览 2,252,652 等字段，扣 $0.000556；所以按 1,000 条算是 X $5、我们 $0.556，只差 9 倍。如果你手里是一份很长的帖子 ID 清单（比如别人论文里公开的数据集），每次 100 个的 X 批量查询在速度上更省事，钱上我们仍然便宜，但要多发 100 倍的请求。

热榜：按次计费的两边对比

热榜两边都按次收钱，是最干净的一组对照。X 的 Trends 是每次请求 $0.010（定价页），按地区的 WOEID 查；我们的 twitter/trending 每次 $0.000556，用两位国家代码（目录列了 us、uk、jp、sg、br 等 35 个地区），00:25 查美国回了 51 条，带名次和统计时段（period 都是 Live；volume 讨论量字段这一次 51 条全为空）。每 1,000 次请求是 $10 对 $0.556，18 倍。热榜的特点是变化快，监测类项目通常每小时查一次、每天 24 次，一年下来 X 是 $87.60，我们是 $4.87。

失败、空结果和限速扣不扣钱

这一节是选接口时最容易被忽略、账单上最容易出意外的地方。我们这边的规则写在价格页：失败或空结果不计费。本文专门做了 4 次「拿不到数据」的请求，另外有 5 次碰上能力暂不可用（503），加起来 9 次，结果都是 $0：

这几次返回值得细看。查一个不存在的账号时，我们回的是 200 和空结果，响应里 billing.reason 写着 empty_result_refunded，refund.status 是 succeeded：先预扣、拿不到就当场退回。把 X 的参数名 query 照搬过来时，返回 422 missing_param，next_steps 里直接写「Add the required keyword (query is not a parameter here)」并给了一个能用的示例请求；这对让 AI agent 自己改参数很有用。被限速时返回 429，写明「Nothing was charged」和 retry_after 秒数。

X 一侧没有「失败退款」这种说法，但它的计费单位决定了大部分失败不花钱：读取按「响应里返回的对象」收费，一个 404 或空结果没有返回对象，也就没有费用（定价页）。真正要小心的是另外三件事。第一，余额可能被扣成略低于零，这时所有请求都会被拦下，直到你补足欠款（同一页「Credit balance」一节原文）。第二，自动充值每 5 分钟最多触发一次，用量突发时即使开了自动充值也可能看到额度用完的错误。第三，超过每月 300 万条帖子的上限、或者超过你在控制台设的花费上限时，返回的也是 429，标题是「Usage Capped」；开发者论坛 7 月 1 日的一个帖子里，一位付费客户贴出的响应头显示每 15 分钟还剩 1,499 次额度，却收到了 usage-capped 的 429。写重试逻辑时，要把「限速 429」和「用量封顶 429」分开处理，后者重试没有用。

24 小时去重：X 有、我们没有的一条规则

X 定价页的「Deduplication」一节写着：所有资源在一个 UTC 自然日内去重，同一条帖子当天被多次请求只收一次钱，UTC 零点重置；同时注明这是「软保证」，服务中断等极端情况下可能没去重（定价页、用量与计费）。我们这边没有这条规则：每次调用都按次收费，不管里面有多少条是你上一次已经拿过的。

这条规则让一种用法在 X 上更省钱：同一个查询高频轮询，而这个话题每天的新帖不多。我们用 00:17 和 00:29 两次搜「x api pricing」做了验证：00:29 那次（隔了 12 分钟）回的 200 条里，171 条第一次已经拿过，29 条是新出现的；而这 29 条里真正发在两次之间的只有 3 条，其余 26 条是排序变动后挤进前 200 的老帖子。00:38 第三次和第一次比，174 条重复、26 条新，同样只有 3 条是这期间新发的。在 X 上，同一个 UTC 日里第二次读到的 171 条不再收钱，第二次只为 29 条付 $0.145；如果你的程序只要上次之后的新帖，第二次只会回 3 条，$0.015。我们这边第二次照样是 $0.000556。也就是说，只要每次请求里平均有 0.11 条以上（$0.000556 ÷ $0.005）是当天没读过的，我们这边仍然更便宜；低于这个数，X 更便宜。换成一般的算术：如果每 15 分钟查一次（每天 96 次），我们每天的花费固定是 96 × $0.000556 = $0.0534；X 的花费是当天不重复的新帖数 × $0.005。两者相等的点是每天约 10.7 条新帖；每小时查一次时，持平点降到每天约 2.7 条。

所以结论要分两种情况说。冷门关键词、小账号、一天只有几条新帖的监测，用 X 官方按量付费反而更便宜，而且没有轮询带来的重复；热门话题就是另一回事，但要先说清我们这边能不能接得住。00:24 我们用 sort: latest 搜「openai」，一次回的 100 条全部发在 14 分 22 秒之内（16:09:54 到 16:24:16 UTC）。按这一个 14 分钟窗口粗估，这个词每天的新帖在一万条量级；在 X 上把这些帖子拿全，约 $50 一天，11 月 22 日之后还要加作者费用。

我们这边每 14 分钟查一次约 $0.056 一天，但能不能接住全部新帖，要实测才算数。红队审稿后，我们在 02:45、02:59、03:13（新加坡时间）用完全相同的参数（keyword openai、sort: latest、limit 200）连查 3 次，各扣 $0.000556，合计 $0.001668，不计入上面的 27 次。结果和 00:24 那次不一样：3 次各回 200 条，但最早的帖子发在 2023 年，每次只有 25 到 35 条是请求前 24 小时内发的，请求前 15 分钟内发的只有 0、0、1 条；200 条的先后顺序也不是按时间倒序排的，相邻两条里约一半是后一条更新。相邻两次之间有 130 条左右重复。也就是说，这 3 次 sort: latest 实际回的更像热门排序，靠每 14 分钟轮询一次接不住一个热门词的全部新帖。要完整、实时地收一个热门话题，用 X 的过滤流或最近搜索更合适，钱按条算；我们这边适合抽样看讨论的走向，便宜，但不保证覆盖。如果只是盯几个竞品账号的新帖、不要求一条不漏，可以看站内这篇用 Claude Code 盯竞品新帖的做法。

每月账单：从每天 1,000 条到每天 10 万条

把上面的单价放进一个更接近真实项目的场景：每天拿 N 条不重复的帖子，连续 30 天。X 的月账是 N × 30 × $0.005，11 月 22 日之后带作者再乘约 2.86；我们的月账是「每天需要的调用次数 × 30 × $0.000556」，每次调用能拿到的不重复条数取本文搜索实测的中位数 200 条。

最右边一档要特别看：每天 10 万条、每月 300 万条，正好是 X 按量付费的月度上限，再多就要谈企业版。这里还有一处 X 自己的说法不一致：developer.x.com 首页写的是「No fixed monthly costs, no monthly caps」，而文档的定价页和用量与计费页都写着每月 300 万条帖子读取封顶。我们以文档为准；规划用量接近这个数时，最好在控制台确认。我们这一侧没有月度条数上限，限制在每分钟：账户默认每分钟 60 次（同一账户下所有 Key 合计），每次最多 200 条帖子，理论上每分钟可以拿 12,000 条；要更高可以按 30 天买提速包或按累计充值自动升档（价格页）。

额度、最低花费和免费额度

X 的赠送额度规则最近改过一次：10 月 2 日上线时是「首次绑卡就送 $20」，10 月 13 日起改成首次购买额度之后才送；预付卡不算，同一张卡在所有账户里只能领一次。对只想先试一下的人来说，这意味着在 X 上读第一条帖子之前，至少要绑一张信用卡或借记卡并完成一笔购买。xAI 返还的部分只能用在 xAI 的 API 上，要先在控制台把 xAI 团队和 X 开发者账户关联起来。

上手要几步：从注册到读第一条公开帖子

X 的获取访问权限文档把上手写成三步：注册开发者账户、建 App、保存凭证。展开看，每一步里还有小步：用 X 账号登录 console.x.com，接受开发者协议和政策，填写用途；建 App，填名称、描述和用例；生成 API Key、Bearer Token 等凭证，文档提醒这些凭证只显示一次，丢了要重新生成；然后按定价页的要求买额度才能真正调用。如果要以用户身份发帖或读私信，还要配 OAuth 2.0，在 App 设置里把权限改成读写、填回调地址。官方命令行工具 xurl 的说明还提到，如果 OAuth 成功了但读取返回 client-not-enrolled，要在控制台把 App 移到 Pay-per-use 套餐和 Production 环境（xurl 仓库）。

我们这一侧是三步：在快速上手注册拿 Key；领 $1 试用额度或充值；用 curl、SDK 或 MCP 调用。不需要 X 账号，也不需要绑卡就能先试。这不是说 X 的步骤多余：X 要求开发者账户、协议和用途说明，是因为它的 API 能代表用户发帖、读私信，这些权限需要审核和问责；只读公开数据的项目不需要这些能力，才显得步骤多。

接进 AI agent：两边的 MCP 怎么配

X 在 6 月 30 日上线了托管的 X MCP，地址是 https://api.x.com/mcp，协议版本 2025-06-18，可以搜全量归档、查用户、管理书签、读热榜和新闻、起草长文（MCP 文档）。接法有两种：只读的话，把 App 的 Bearer Token 放进 MCP 客户端的请求头；要以你的账号身份操作，用开源的 xurl mcp 做本地桥，第一次运行会打开浏览器走 OAuth 2.0 登录。文档特别说明，X 的 OAuth 必须用你自己的开发者 App，不支持动态客户端注册，所以不能像很多远程 MCP 那样只填一个网址。文档说 X MCP 的工具是在「调用 X API 端点」，没有单列 MCP 的价格，所以我们按同样的端点单价估算，例如经 MCP 读到的每条帖子仍是 $0.005；这一点是推断，以控制台的实际扣费为准。X 另有一个可以自己部署的开源版本 xmcp，把 X API 的 OpenAPI 描述转成工具，不含流式和 webhook 端点。

{
  "mcpServers": {
    "xapi": {
      "url": "https://api.x.com/mcp",
      "headers": { "Authorization": "Bearer $X_BEARER_TOKEN" }
    },
    "everyinfra": {
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}

上面是一个同时挂两边的配置示例，X 一段照抄 X 文档里的 App-only 写法。我们的远程 MCP 地址是 https://api.everyinfra.com/mcp，工具名以 everyinfra_ 开头，模型先查目录再调具体能力，说明在 MCP 接入页。两边都挂上时，一个合理的分工是：要发帖、看自己的书签和私信时让模型走 X 的工具；要大批量读公开帖子、粉丝和热榜时走我们的工具。MCP 协议本身的规范见 modelcontextprotocol.io。

字段：两边拿到的东西不一样

两边返回的字段不是一一对应的，迁移时不要假设能直接替换。X 的帖子对象默认只回 id、text 和 edit_history_tweet_ids，其余字段要用 tweet.fields、user.fields 和扩展逐个点名（数据字典）；我们这边一次返回固定的一组字段，不用点名，也不能挑。下表只列只读项目常用的几项，X 一列按 X 文档，我们一列按目录 response_fields 和本文 9 次搜索的实际返回。

最后几行是 X 有、我们没有的：编辑历史、上下文注释、自己帖子的非公开指标、地点。如果你的分析依赖这些字段，例如按 X 自己的话题分类做统计，那就应该留在官方 API。

从 X API 换过来，代码要改哪几处

如果你已经有一套调 X API v2 的代码，想把其中只读公开数据的部分换到 EveryInfra，改动集中在下面几处。我们按本文真调里实际碰到的情况整理，X 一列按 X 的文档原文。最常见的一个坑我们自己就踩了：把 X 的 query 参数原样带过来，会收到 422 missing_param，好在响应的 next_steps 直接说明要改成 keyword，并给出一个能跑通的示例请求，AI agent 读到这段可以自己改对再调一次，这一次不扣钱。

改完之后建议先用同一个关键词两边各拿一次，对一下条数、时间范围和你真正用到的字段，再切换线上流量。要特别核对两件事：一是排序，我们默认按热门返回，传 sort: latest 也不保证按时间，本文 4 次 sort: latest 里有 3 次回的大部分是老帖子（见「24 小时去重」一节末尾）；二是字段，本文 9 次搜索里有 2 次没有带作者粉丝数，如果下游逻辑依赖这类字段，要在代码里留空值处理。

什么时候 X 官方 API 更合适

这一节照实写，不打折扣。下面这些情况，X 官方 API 是更好的选择，有些是唯一的选择：

第一，任何写操作。发帖、回复、删帖、私信、管理列表和书签，只能走 X 官方 API，价格从每次 $0.005 到 $0.20 不等；我们只读公开数据，不能替你发帖。要注意 X 在 2026 年 2 月 23 日之后限制了程序化回复，只有被原帖作者 @ 到或引用时才能用 API 回复；4 月 20 日起自助套餐也不能再通过 API 关注、点赞和引用转发（更新日志）。

第二，实时过滤流。X 的 Filtered Stream 按规则推送新帖，P99 延迟约 4 到 5 秒，按量付费账户可以设 1,000 条规则、1 个连接（过滤流文档）。我们是请求、返回的模式，最快只能靠轮询，做不到秒级推送。

第三，只要条数不要内容。X 的 Counts 端点按分钟、小时或天返回某个查询的帖子数量，最近 7 天每次 $0.005，全量归档每次 $0.010（计数文档）。想知道一个词过去一年每天被提了多少次，X 用几次请求就能拿到，我们没有对应的能力，只能拿帖子回来自己数，而且拿不全。

第四，读你自己账号的数据。Owned Reads 每个对象只要 $0.001，自己的帖子、提及、书签、粉丝、关注都在内，还能拿到展示次数等非公开指标；做个人或公司账号的数据看板，X 官方既便宜又完整。

第五，低频轮询。前面算过，同一个查询每 15 分钟查一次，当天新帖少于约 10.7 条时，X 的 24 小时去重让它更便宜。

第六，条款和合规。X 的数据通过 X 的 API 拿，使用规则写在开发者协议（2026 年 4 月 27 日最后更新）和开发者政策里，权责最清楚；企业内部的合规审核如果要求数据必须来自平台官方渠道，答案只能是 X 官方 API。协议里还有一些具体限制，例如不能用 X 内容训练或微调基础模型、收到删除请求后 24 小时内要删除对应内容，签之前要逐条读。

X 条款和法律边界

X 的服务条款对使用 X 服务的人有约束，开发者协议对通过 API 拿到的数据另有使用限制；研究人员在欧盟还可以依据《数字服务法》第 40 条申请平台数据访问（法规原文、欧盟委员会关于数据访问的授权法规）。X 的自动化规则对用程序发帖、互动另有要求。这些条款对你的具体项目意味着什么，要问你的律师，本文不提供法律意见；我们能说的是方法上的边界：本文只读公开可见的帖子、账号和列表，不登录、不读私信、不读受保护账号的内容。

最近的变化（2026 年 10 月到 11 月）

再往前，几次大变化分别是：2 月 6 日按量付费上线，旧免费层活跃用户拿到一次性 $10 抵用券；4 月 20 日 Owned Reads 降到 $0.001，带链接的帖子涨到 $0.20；5 月 4 日搜索端点迁到新索引，关键词搜索不再返回转发；5 月 21 日 Basic、8 月 14 日 Pro 先后宣布迁移到按量付费；6 月 30 日上线托管 X MCP。这些都写在 X 的更新日志和开发者论坛的公告区里，变化频率大约一个月一次，规划长期项目时要预留价格变动的余地。按条计价的官方接口频繁调价不只 X 一家，我们在 TikTok API 价格一文里记过 TikTok 官方接口的计费规则，可以对照着看。

上手：先用一次真调看看返回

第一步，在快速上手注册拿 Key；给 everyinfra/everyinfra-agent-plugins 和 everyinfra/seo-skills 两个 GitHub 仓库都点星后，可以在控制台领 $1 试用额度，24 小时内有效。第二步，用上面的 curl 搜一次你最关心的关键词，看 results 的条数和 billing.charged_usd。第三步，在基础设施市场里直接试其他能力，或者在 AI 客户端里挂上 MCP。X 平台的全部能力在 Twitter/X 数据接口页，价格见价格页；要同时监测另一个社区平台的，可以看 Reddit 数据接口。

常见问题

X API 现在还有免费的吗？

没有面向新开发者的免费层。2026 年 2 月 6 日按量付费上线后，只有被 X 认定为公共服务类的应用（Public Utility Apps）继续免费，旧免费层的活跃用户拿到一次性 $10 抵用券（上线公告）；新账户首次购买额度后送 $20，3 个月后过期。r/Twitter 有人在这个帖子里问过同样的问题，想做发帖工具又付不起按条收费。

X API 按量付费多少钱，有没有计算器？

读一条帖子 $0.005，读一个用户 $0.010，发一条帖子 $0.015，带链接的帖子 $0.20，热榜每次 $0.010（定价页）。X 没有公开的计算器，控制台里能看实时花费；你可以用本文的公式自己算：月账 = 每天不重复帖子数 × 30 × $0.005，11 月 22 日之后带作者再加「不重复作者数 × $0.010」。

x api alternative 有哪些，Reddit 上的人怎么选？

Reddit 上常见的说法是三类：继续用官方按量付费、用第三方数据接口、或者自己写抓取程序。r/Web_Development 的一个原帖作者用官方 API 同步书签，算出每 200 条帖子约 $1，觉得长期用不便宜；r/Twitter 那个免费层的帖子下面，有人建议逆向接口加多账号，这样做有封号风险，也违反 X 的条款。要发帖用官方；只读公开数据、量大，可以按本文的总对比表算账，同时看清最后一列：有几项两边买到的不是同一样东西。

X API 每月 300 万条的上限到了怎么办？

按定价页原文，按量付费每个月度账单周期最多读 300 万条帖子，再多要填企业版意向表。到上限时请求会返回 429 「Usage Capped」，等到下一个账单周期才恢复，重试没有用。我们这边没有月度条数上限，每分钟默认 60 次。也有没到上限就收到这个 429 的情况：开发者论坛的这个讨论帖里，6 月 30 日和 7 月 1 日两位付费开发者的额度、花费上限和限速都正常，仍然间歇收到 usage-capped；X 团队 7 月 2 日回复说问题已修复。碰到这种情况，先看控制台，再到论坛搜同类报告。

发带链接的帖子为什么变成 $0.20？

X 在 4 月 16 日的定价公告里宣布，从 4 月 20 日起通过 API 发带网址的帖子每条 $0.20，被 @ 召唤的回复仍是 $0.01，普通发帖从 $0.01 涨到 $0.015。r/technology 的讨论帖标题算的是涨了 1,900%。这一项我们帮不上忙：我们不提供发帖能力。

参考资料

1. X API pay-per-usage pricing and credits，X Developer Platform，2026-11-09 读取，https://docs.x.com/x-api/getting-started/pricing
2. Free credit incentives for X API pay-per-use accounts，X Developer Platform，2026-10-13 更新，https://docs.x.com/x-api/getting-started/free-credits
3. Usage and Billing（月度上限与去重），X Developer Platform，https://docs.x.com/x-api/fundamentals/post-cap
4. Rate limits，X Developer Platform，https://docs.x.com/x-api/fundamentals/rate-limits
5. Getting Access，X Developer Platform，https://docs.x.com/x-api/getting-started/getting-access
6. About the X API，X Developer Platform，https://docs.x.com/x-api/getting-started/about-x-api
7. Search Posts，X Developer Platform，https://docs.x.com/x-api/posts/search/introduction
8. Timelines，X Developer Platform，https://docs.x.com/x-api/posts/timelines/introduction
9. User Lookup，X Developer Platform，https://docs.x.com/x-api/users/lookup/introduction
10. Follows，X Developer Platform，https://docs.x.com/x-api/users/follows/introduction
11. Post Lookup，X Developer Platform，https://docs.x.com/x-api/posts/lookup/introduction
12. Expansions，X Developer Platform，https://docs.x.com/x-api/fundamentals/expansions
13. Post Counts，X Developer Platform，https://docs.x.com/x-api/posts/counts/introduction
14. Filtered Stream，X Developer Platform，https://docs.x.com/x-api/posts/filtered-stream/introduction
15. Response Codes & Errors，X Developer Platform，https://docs.x.com/x-api/fundamentals/response-codes-and-errors
16. MCP servers for the X API and X developer docs，X Developer Platform，https://docs.x.com/tools/mcp
17. X API changelog，X Developer Platform，2026-11-05 条目，https://docs.x.com/changelog
18. Developer Agreement，X，2026-04-27 最后更新，https://docs.x.com/developer-terms/agreement
19. Developer Policy，X，https://docs.x.com/developer-terms/policy
20. Search operators，X Developer Platform，https://docs.x.com/x-api/posts/search/integrate/operators
21. Data dictionary，X Developer Platform，https://docs.x.com/x-api/fundamentals/data-dictionary
22. Usage API，X Developer Platform，https://docs.x.com/x-api/usage/introduction
23. X Activity API，X Developer Platform，https://docs.x.com/x-api/activity/introduction
24. XDK overview，X Developer Platform，https://docs.x.com/xdks/overview
25. Enterprise API interest form，X Developer Platform，https://docs.x.com/forms/enterprise-api-interest
26. X Developer Platform 首页，X，2026-11-09 读取，https://developer.x.com/
27. xurl，xdevplatform（GitHub），https://github.com/xdevplatform/xurl
28. xmcp，xdevplatform（GitHub），https://github.com/xdevplatform/xmcp
29. X API Playground，xdevplatform（GitHub），https://github.com/xdevplatform/playground
30. [Inform] X API PPU - Expansions Update，X Developers 论坛，2026-10-23，https://devcommunity.x.com/t/inform-x-api-ppu-expansions-update/279110
31. Legacy X API Pro Plans Are Moving to Pay-Per-Use，X Developers 论坛，2026-08-14，https://devcommunity.x.com/t/important-update-legacy-x-api-pro-plans-are-moving-to-pay-per-use-ppu/273255
32. Legacy X API Basic Plans Are Moving to Pay-Per-Use，X Developers 论坛，2026-05-21，https://devcommunity.x.com/t/important-update-legacy-x-api-basic-plans-are-moving-to-pay-per-use-ppu/266305
33. Announcing the Launch of X API Pay-Per-Use Pricing，X Developers 论坛，2026-02-06，https://devcommunity.x.com/t/announcing-the-launch-of-x-api-pay-per-use-pricing/256476
34. X API Pricing Update: Owned Reads Now $0.001，X Developers 论坛，2026-04-16，https://devcommunity.x.com/t/x-api-pricing-update-owned-reads-now-0-001-other-changes-effective-april-20-2026/263025
35. Announcing the hosted X MCP，X Developers 论坛，2026-06-30，https://devcommunity.x.com/t/announcing-the-hosted-x-mcp/269558
36. 429 usage-capped on pay-per-use 讨论帖，X Developers 论坛，2026-07-01，https://devcommunity.x.com/t/429-usage-capped-on-pay-per-use-across-multiple-read-endpoints-despite-healthy-rate-limits-and-console-limits/269581
37. I tried the new X API - it's nice, but doesn't look so cheap long term，Reddit r/Web_Development，https://www.reddit.com/r/Web_Development/comments/1qz8ae3/i_tried_the_new_x_api_its_nice_but_doesnt_look_so/
38. X/Twitter api free tier?，Reddit r/Twitter，https://www.reddit.com/r/Twitter/comments/1r2xosn/xtwitter_api_free_tier/
39. X makes it 1900% more expensive to post links，Reddit r/technology，https://www.reddit.com/r/technology/comments/1srwd4i/x_makes_it_1900_more_expensive_to_post_links_it/
40. X Terms of Service，X，https://x.com/en/tos
41. X automation rules，X Help Center，https://help.x.com/en/rules-and-policies/x-automation
42. Model Context Protocol Specification 2025-06-18，modelcontextprotocol.io，https://modelcontextprotocol.io/specification/2025-06-18
43. Regulation (EU) 2022/2065（数字服务法），EUR-Lex，https://eur-lex.europa.eu/eli/reg/2022/2065/oj
44. Delegated act on data access under the DSA，European Commission，https://digital-strategy.ec.europa.eu/en/library/delegated-act-data-access-under-digital-services-act-dsa
45. EveryInfra 数据能力目录，EveryInfra，2026-11-09 00:14 读取，https://api.everyinfra.com/api/v1/social/catalog