Since approximately 2026-05-09 02:00 UTC, requests using TX-IDs generated by this library produce a 200 OK from x.com/i/api/graphql/.../SearchTimeline but return cached/stale tweets only (the entire result set is frozen at Apr 15 23:58-23:59 UTC regardless of since/until window). Other endpoints like UserTweets continue to return fresh data, so this is specifically affecting search.
Diff vs browser:
Library output (v1.0.2): 94 chars
Browser output (Chrome 148, captured from DevTools on a live x.com search): 96 chars
Same method (GET), same path. The 2-char (≈12-bit) difference suggests Twitter added an input/step/length in the algorithm that this library hasn't picked up.
Verified ruled out:
queryId (latest pulled from current main.js)
variables / features arrays (matched browser exactly)
cookies (full browser cookie jar including kdt, twid, auth_multi, personalization_id, __cf_bm)
Authorization bearer (identical)
TLS impersonation (tested chrome120 through chrome146 via curl_cffi)
Source IP (tested via IPRoyal residential pool and direct IP — identical 4 different exit IPs all return the same Apr 15 23:59:47 first tweet, confirming server-side cache)
User-Agent (matched browser's Chrome 148 string)
The only remaining differentiator is the x-client-transaction-id header value itself. Suggests Twitter rolled an algorithm change between 2026-03-18 (last release) and 2026-05-09 that adds ~2 bytes of output and is now validated server-side.
Happy to help validate any candidate fix.
Since approximately 2026-05-09 02:00 UTC, requests using TX-IDs generated by this library produce a 200 OK from x.com/i/api/graphql/.../SearchTimeline but return cached/stale tweets only (the entire result set is frozen at Apr 15 23:58-23:59 UTC regardless of since/until window). Other endpoints like UserTweets continue to return fresh data, so this is specifically affecting search.
Diff vs browser:
Library output (v1.0.2): 94 chars
Browser output (Chrome 148, captured from DevTools on a live x.com search): 96 chars
Same method (GET), same path. The 2-char (≈12-bit) difference suggests Twitter added an input/step/length in the algorithm that this library hasn't picked up.
Verified ruled out:
queryId (latest pulled from current main.js)
variables / features arrays (matched browser exactly)
cookies (full browser cookie jar including kdt, twid, auth_multi, personalization_id, __cf_bm)
Authorization bearer (identical)
TLS impersonation (tested chrome120 through chrome146 via curl_cffi)
Source IP (tested via IPRoyal residential pool and direct IP — identical 4 different exit IPs all return the same Apr 15 23:59:47 first tweet, confirming server-side cache)
User-Agent (matched browser's Chrome 148 string)
The only remaining differentiator is the x-client-transaction-id header value itself. Suggests Twitter rolled an algorithm change between 2026-03-18 (last release) and 2026-05-09 that adds ~2 bytes of output and is now validated server-side.
Happy to help validate any candidate fix.