I Batch-Scanned 95 Twitter Accounts with Actionbook and Hit a Wall at #60

You can’t really judge a tool with 5 accounts. It takes 95 to see the truth.

Why I Need a “Twitter Scanning System”

As a content creator and entrepreneur, I need a constant flow of fresh industry news. The AI space moves so fast that today’s news is tomorrow’s old news.

The obvious approach is to scroll Twitter every morning. I tried that for a while and ran into two problems:

First, it’s a massive time sink. Going through 95 accounts manually? Easily an hour gone.

Second, you get pulled into junk. Twitter’s recommendation algorithm keeps pushing marketing content at you. Morning Twitter scrolling is basically the same as doom-scrolling TikTok — you came for information, but you end up burning attention.

So my approach: let an AI Agent do the scanning, pull back tweets from the past 24 hours across all 95 accounts, and I’ll cherry-pick what’s worth reading. Humans decide what matters; machines do the legwork.

The Tool Selection Journey

Direction was clear. Finding the right tool took a few rounds.

Round 1: API services. Tried third-party services like Xpoz — they work, but they cost money. I also have multiple Twitter accounts for different purposes, and multi-account support gets messy. For a personal once-a-day need, a monthly subscription felt like overkill.

Round 2: Playwright automation. Built my own script using Playwright to control a browser, visiting each account’s page one by one, grabbing tweets from the past 24 hours. Upside: free, controllable, stable. Downside: painfully slow — about 28 minutes for a full run. Had to add a 3-second safety delay between accounts to avoid triggering Twitter’s anti-automation detection.

28 minutes. Every day. Honestly, it worked, but it wasn’t good enough.

Round 3: Actionbook. Recently came across Actionbook — a Rust-based browser automation CLI designed specifically for AI Agent workflows. Installed it immediately, tested 5 accounts: 2.1 seconds per account on average. At that speed, 95 accounts would take just 3.5 minutes.

28 minutes down to 3.5. An 8x speedup. This was exactly what I was looking for.

Security First

No matter how fast a tool is, safety comes first.

Before letting any new tool touch my Twitter session, I always check the code. Not paranoia — after seeing enough npm supply chain attack stories, spending 10 minutes reviewing install scripts and entry files is a lot cheaper than dealing with the aftermath.

Quick audit: the install script just sets executable permissions on the Rust binary. The entry file is a thin wrapper that forwards CLI arguments to the binary. No data uploads, no telemetry. Small project (about 300 stars, 3 maintainers), so I pinned the version and moved on.

All clear. Moving on.

The “Perfect” 5-Account Test

Small-scale results looked great — all 5 accounts scanned successfully, averaging just over 2 seconds each. Complete data, and a nice bonus: no need for Actionbook’s built-in “action manuals”; the browser’s native selectors could grab all the tweet data directly.

My reaction: this thing is amazing, let’s replace Playwright entirely.

Looking back, this was the classic small sample trap.

Reality at 95 Accounts

I wrote a Python script to have Actionbook scan all 95 accounts sequentially, with 1.5-second intervals.

The first 60: smooth sailing. Fast, complete data, not a hint of anti-scraping measures.

Then the page went blank.

The entire x.com showed nothing but an X logo sitting in the center of the screen. No error, no popup — just nothing loading.

Worse — I switched to my regular browsing account and couldn’t get in either. Twitter was completely dead in that browser.

From “8x speedup” to “locked out of Twitter” in a matter of seconds.

Figuring Out What Happened

After a brief moment of panic, I started investigating.

Clue #1: Pulled out my phone on the same WiFi — Twitter app worked perfectly fine. Scrolling, reading, commenting, no issues.

That ruled out IP blocking. If Twitter had blocked my IP, the phone wouldn’t work either.

Clue #2: Switched VPN nodes on my laptop — Chrome still showed a blank page.

Ruled out exit IP issues.

Clue #3: About five or six minutes later, I refreshed out of stubbornness — and it suddenly worked again.

Conclusion: Twitter uses session-level rate limiting.

It doesn’t block your IP or your account. Instead, it flags your browser session as “suspicious.” Once flagged, every request to x.com from that browser returns a blank page. The phone app has its own independent session, so it’s completely unaffected.

This also explained something I’d always wondered about: that 3-second delay between accounts in the Playwright setup wasn’t conservative — it was necessary.

That said, the rate limiting is actually pretty mild — no account bans, no IP bans, just wait a few minutes and you’re back. Compared to platforms that hand out permanent bans at the drop of a hat, Twitter’s approach here is fairly restrained.

The Final Solution: Let Each Tool Do Its Thing

Stepping back, I actually had all the data I needed:

• Actionbook is genuinely faster per account — 2 seconds vs Playwright’s 8 seconds
• But after ~60 consecutive accounts, Twitter steps in
• The rate limit only affects the current browser session, auto-recovers in 5-10 minutes
• Phone, other browsers — completely unaffected

So the answer wasn’t “Actionbook is better” or “Playwright is better” — it was to let each do its own job.

Key insight: Actionbook and Playwright use completely separate browser instances. Actionbook has its own Chrome profile directory; Playwright manages its own browser process. They don’t interfere with each other — they can run simultaneously.

Actionbook (first 45 accounts)  ████████ ~3 min ──┐
                                                    ├── Merge
Playwright (remaining 48 accounts) ████████████████████████ ~12 min ──┘

Total time dropped from 28 minutes to about 12 — nearly 60% faster.

Quick scan mode (just the top 30 priority accounts) is even simpler — hand it all to Actionbook, done in 1 minute. Used to take 10. This is where Actionbook truly shines: fast scans on smaller batches, both quick and reliable.

Reflections

Actionbook is a great tool. Built in Rust, fast to start, fast to execute, with built-in stealth features, and clean code — no telemetry, no data uploads. For AI Agent scenarios that need browser automation, it’s one of the smoothest solutions I’ve used. The only thing to watch is pacing during batch operations — don’t run too many accounts in one go and trigger platform rate limits.

Small-scale tests can be deceiving. The “2 seconds per account, 100% success” from 5 accounts gave me false confidence. The real bottleneck wasn’t per-request speed — it was the platform’s tolerance for sustained high-frequency requests. Tool evaluation needs to happen under realistic load.

Rate limiting doesn’t mean getting banned. Seeing Twitter go completely blank was honestly scary. But once I understood the mechanism, it wasn’t so bad — a temporary session-level flag that doesn’t affect the account, doesn’t affect the IP, and clears itself in a few minutes.

The best solution is often not either/or. Tool selection easily falls into “A or B” thinking. But letting A do what it’s good at (fast scanning of small batches) and B do what it’s good at (stable processing of large volumes) beats going all-in on one side.

If a tool touches your login session, check the code first. Ten minutes reviewing install scripts to make sure nothing shady is going on. This habit will save you from a bad day sooner or later.

Long-running scripts need to save progress as they go. The first version of my scan script only wrote the file at the very end. When it crashed, 60 successful results vanished. Now it saves after every single account. This lesson applies far beyond web scraping.

Appendix: Final Parameters for X (Twitter) Scanning

These are the parameters I dialed in for scanning X (Twitter) accounts, for reference:

For tool evaluation, reading the README and running a demo isn’t enough. Install it, inspect it, test it small, then push it to real-world scale.

Crashing isn’t scary. What’s scary is crashing and not writing it down.