Where this started
I run a handful of science accounts, and Matharium is the one that grew the fastest. It started around June this year as a maths-history account on X, and it now lives on Instagram, Facebook, Threads, YouTube, TikTok and Pinterest as well. Every post I write is meant to go to all of them.
Doing that by hand sounds like a ten-minute job. It is a ten-minute job, seven times over, every single day. On days with a lab session or a class it simply did not happen, so the X account would be current and the other six would sit a week behind. After a few months of that I did what I always do when something annoys me enough: I started writing code to make it go away.
The plan on paper was simple. X is where I write first, so X becomes the source of truth. A bot watches the account, picks up anything new, and pushes it to every other platform with the right formatting for each one. Writing to Threads, Bluesky, Facebook and Pinterest turned out to be the easy half. Reading my own posts back out of X turned out to be the whole problem, and it is the part this post is really about.
The wall: X does not give you your own posts for free
Every other platform I post to hands out an API token and lets you read your own account with it. X does not. The free developer tier has been write-only for years: you can publish a post through it, but you cannot read one back, not even your own. Reading sits behind the paid plans, and for a long time that meant Basic at around $200 a month for roughly 10,000 reads, or Pro at $5,000 a month. In 2026 X has been moving everyone onto pay-per-use credits instead, at about half a cent per post returned, and the legacy tiers are being closed to new developers (opentweet pricing summary, checked against docs.x.com in October 2026).
On paper half a cent sounds like nothing. The catch is that a sync bot does not read once. It polls. If it checks each account every few hours and the endpoint returns the last twenty or so posts each time, the reads pile up fast, and you pay for the same posts over and over. Multiply that by six or seven accounts and it stops being a hobby expense. The cheaper owned-reads rate needs each account to be authenticated against its own developer app, which is its own pile of setup and verification per account.
What I actually needed was tiny: the text, the image or video, and the timestamp of my own last few posts. Paying a monthly plan for that felt wrong, so I went looking for ways around it.
First attempt: twscrape and a jar of cookies
The first thing that worked was twscrape, an open-source Python library that talks to the same internal endpoints the X web app uses. You log in to x.com in your browser like a normal person, export the session cookies, hand them to twscrape, and it fetches timelines as if it were your browser tab. No developer account, no plan, no credits.
For a couple of weeks it felt like I had beaten the system. Then the cracks showed. The internal endpoints are rate limited per account, so a bot polling several profiles from one session would hit the limit and go quiet for a while. The session cookies expire, sometimes after a few days and sometimes after a random logout, and the bot would silently fetch nothing until I noticed the other platforms had gone stale and logged in again by hand. The part that bothered me most was the risk. X does not want you doing this, and an account that behaves like a script can get rate limited harder, locked, or banned. Matharium is a monetised account. I was not willing to lose it to save a few dollars.
So twscrape stayed in the toolbox as a fallback, and I kept looking for something I would not have to babysit.
Second attempt: borrowing someone else's API
The next door I found was the third-party X APIs. There is a whole cottage industry of services that scrape X at scale and resell the data through a clean REST endpoint, usually with a free tier generous enough for a small bot. You send a username, you get the latest posts back as JSON with media URLs attached, and you never touch X directly.
This was the first version of the sync that ran for real. A small server bot would call the third-party API, compare the result with the last post it had already handled, and push anything new to Facebook, Threads and Bluesky through their official APIs. Two of my accounts ran on this for months, and for the first time the platforms stayed in step without me doing anything.
I never believed it was the long-term answer, though. Those services only exist because X has not shut them down yet, and their free tiers shrink the moment they get popular. One of them could close tomorrow, or put the endpoint I depend on behind a paywall, and my sync would be dead again. It bought me time. It did not solve the problem.
Then Grok Bot started reading X for me
The thing that finally changed the picture came from X itself. Grok Bot, xAI's agent product, can now fetch X content on its own. It runs inside its own cloud computer with a browser, a file system and a scheduler, and because it belongs to the same company that owns X, its access to posts does not depend on a cookie I exported or a scraper that might get blocked next week. The session is official and it refreshes itself.
I had already been using Grok Bot as a kind of intern for Matharium, so this was not a big leap. The job I gave it first was Pinterest. Matharium posts infographic cards on X several times a day, and Pinterest turns out to be a very good home for exactly that kind of image. The bot runs a routine every three hours: fetch whatever Matharium has posted since the last run, pull out the cards, and pin each one to the Matharium board with a fitted description and a link back to the X post. For now it does this through Pinterest's own website, logged in to the official account inside the bot's VM. Moving that step over to the Pinterest API is on my list.
That one routine is the reason the Pinterest account exists at all. It has picked up 150+ followers and sits at about 1.5 million monthly views, and I have not pinned a single card by hand.
Once I saw it fetch X reliably for Pinterest, the obvious next thought was: why is this not the fetcher for everything? It fixed exactly the problem the previous two attempts could not. No paid X plan, no cookie jar to refill, no third-party service that might vanish. Grok Bot reads X, and the rest of the pipeline stays the same.
The setup that works
The shape of it today is simple. Grok Bot is the only thing that reads from X. Everything downstream talks to official APIs. Pinterest, Threads and Bluesky all hand out tokens without much fuss, and those tokens live inside the bot's VM, not in my repo and not on my laptop. The bot fetches, decides what is new, and posts through the API for each platform. Only where an API is missing or not yet wired up does it fall back to driving the website in its browser, and I try to keep that to a minimum. An API call costs a fraction of the credits a browser session does, and it does not break when a platform redesigns a button.
The second half of the setup is teaching. A fetcher that copies a tweet word for word onto Bluesky is not much better than doing it by hand, because every platform wants the text shaped a little differently. So each agent gets a short brief on how Matharium writes: the three-paragraph caption structure, no emoji, no hashtags on X but four on Instagram, what a Pinterest description should look like, how to handle a thread. Once the style is in the brief, the agent does not need me in the loop for the writing.
The routine is where the credits get saved. Instead of letting the agent poll constantly, it runs on a fixed schedule, and in each run it handles everything that arrived since the last one. That one gap matters more than it sounds. If three posts went out on X in a three-hour window, a naive bot would dump all three onto Threads within a minute of each other, which looks like spam and performs like spam. The brief tells the agent to space them out across the window and to respect the posting hours that work for each platform.
Adding a new account is now the easiest part. I point the new agent at the previous one and tell it to work the same way, with the account's own tokens and its own style brief. The do's and don'ts carry over: the posting windows, the spacing rule, what to skip, what to never touch. I am on the Premium tier of Grok Bot, having started on SuperGrok, and with the agents set up this way it comfortably covers six or seven accounts. The trick is to spend the bot's credits on judgement, not on clicking around a browser.
Where it stands
I am not going to pretend this is finished. The Pinterest leg still runs through a logged-in browser rather than the API, and until that is moved over it is the most fragile piece. Grok Bot is a young product, and its pricing and limits will change the way every other tool in this story changed. If xAI decides tomorrow that fetching X posts is a paid feature, I will be writing another one of these posts.
What has changed is the kind of problem I have. A few months ago the question was how to get my own posts out of X without paying for a plan I could not justify. Today the question is how to teach an agent to post well, and that is a much nicer problem to have. The scraper taught me what the data looked like, the third-party APIs kept the accounts in sync while I figured out the rest, and the bot turned the whole thing into something I do not think about.
If you are starting the same thing, the short version is this. Do not pay X to read your own posts, and do not build on cookies you have to refresh by hand either. Let Grok Bot be the thing that reads X. For every other platform, get the official token: Threads through a Meta app, Bluesky through an app password, Pinterest through its developer API. Keep those tokens somewhere the bot can use them without you, and spend your effort on the brief that tells the bot how you write and when to post. The fetching is the smallest part of the system, once you stop fighting it.
