I built this to programmatically interact with Grok directly through the X.com web UI.
The motivation is simple: I’m already paying for an X Premium subscription. I have enough API keys scattered around, and I didn't want to open yet another billing account just to use an AI I already have access to.
*The core idea:* Persist an X browser session, navigate to `x.com/i/grok`, type the prompt, wait for the streaming response to stabilize, then extract the reply DOM and convert it back to Markdown via Turndown with custom rules (Grok renders headings as `display:block` spans and bold as hashed utility classes, not semantic HTML).
The fragile part is those hashed CSS class names — X's CSS-in-JS pipeline regenerates them on every front-end deploy. We centralize them in a `SELECTORS` constant and ship an `npm run inspect` script that re-discovers the new classes when things break.
*Limitations (honest):*
* Requires X Premium.
* Needs a GUI for the initial login (no headless CI support for the very first run).
* Sessions expire; re-login is manual due to CAPTCHA/2FA.
* DOM selectors break on X front-end deploys — recoverable via the inspect script, but not zero-maintenance.
* Technically violates X ToS — low risk for personal/low-frequency use, but a real consideration.
Hi HN,
I built this to programmatically interact with Grok directly through the X.com web UI.
The motivation is simple: I’m already paying for an X Premium subscription. I have enough API keys scattered around, and I didn't want to open yet another billing account just to use an AI I already have access to.
*Tech stack:* Node.js + Playwright (Chromium) + Turndown.
*The core idea:* Persist an X browser session, navigate to `x.com/i/grok`, type the prompt, wait for the streaming response to stabilize, then extract the reply DOM and convert it back to Markdown via Turndown with custom rules (Grok renders headings as `display:block` spans and bold as hashed utility classes, not semantic HTML).
The fragile part is those hashed CSS class names — X's CSS-in-JS pipeline regenerates them on every front-end deploy. We centralize them in a `SELECTORS` constant and ship an `npm run inspect` script that re-discovers the new classes when things break.
*Limitations (honest):*
* Requires X Premium.
* Needs a GUI for the initial login (no headless CI support for the very first run).
* Sessions expire; re-login is manual due to CAPTCHA/2FA.
* DOM selectors break on X front-end deploys — recoverable via the inspect script, but not zero-maintenance.
* Technically violates X ToS — low risk for personal/low-frequency use, but a real consideration.
Would love to hear your thoughts!