Brief 7ac: "distribution first" week + reply desk, reviewed against X rules, market and unit economics

Date: 2026-09-04. Researcher stance: skeptical. Budget 35 web calls, 34 used. Some official X pages (devcommunity announcement, pay-per-use docs page, user-timeline endpoint page) were blocked or 404 at fetch time; where a claim rests on a secondary source that quotes X, it is marked "single source".

Plan under review: @gochaberulava (467 followers, founder + an openly labelled AI agent). Phase 1: one week, max three originals/day, 10–15 specific replies/day to 5k–100k builder accounts within 30 minutes of their post; agent drafts, human or API posts. Phase 2: a "reply desk" that watches a list of accounts, surfaces posts within minutes, drafts a house-style reply, reads via the X API at $0.005/post, used by us first and maybe sold to other small accounts.

---

1. X rules in 2026 that touch this plan

1a. The rules, quoted

1b. What this means for the plan

• "Human or the API posts" is not one option, it is two, and one is dead. Since 23 Feb 2026, an API reply to a 5k–100k builder who has not @mentioned or quoted @gochaberulava is rejected at the endpoint on every self-serve tier including pay-per-use (https://docs.x.com/changelog). The "within 30 minutes of their post, via API" path is technically impossible unless you are Enterprise or an approved Public Utility app. Everything in phase 1 that ships a reply must go through a human in the X UI (or a browser extension acting inside the logged-in session, which is a separate ToS risk, see 3).
• Does a human pressing Post on an agent-drafted reply count as automation? The automation rules define the covered behaviour as automated actions (posts, DMs, follows) taken "through users' accounts or via applications" (https://help.x.com/en/rules-and-policies/x-automation). Nothing in the automation rules, developer policy or spam policy regulates how a post was written. A human reading a draft, editing it, and clicking Post in the app is a manual action under the text as it stands. This is also the reading of every 2026 tool vendor I checked ("A draft is not an action. X has no rule against thinking with a machine", https://postweavers.com/blog/ai-replies-x-ban-risk, opinion). Caveats: (i) the AI-reply-bot clause requires written approval for "deployment or operation of any AI reply bot"; a pipeline where the human is a rubber stamp at 15 replies/day in a 30-minute window starts to look like operation of a bot, and X, not you, decides; (ii) the spam policy is behavioural: "bulk, aggressive, high-volume unsolicited replies" is prohibited regardless of who typed them; (iii) the [agent] tag on posts is good hygiene under the developer policy's "clearly indicate what the account is", but it also makes the account trivially identifiable as agent-driven if anyone reports it.
• Enforcement examples for reply-heavy small accounts. I found no named, verifiable 2025–26 case of a specific small account suspended for 10–15 human-posted replies/day. What exists is (a) X's own enforcement text above; (b) X's DSA transparency data cited by a vendor: "accounts under visibility filtering see an 82–85.6% drop in impressions" (https://xengageai.com/blog/ghost-ban-on-x-twitter-2026, single source quoting X's Oct 2024 report); (c) vendor heuristics, not policy: "A new account with under 100 followers sending 50+ replies per day is a red flag pattern" and "under 30 replies per day for newer accounts", ghost bans lasting "3 to 14 days" (same URL, opinion); (d) the behavioural signals vendors say X scores: "Superhuman speed: replies landing seconds after a post, around the clock, with no sleep gaps", "Identical phrasing", "Perfectly regular intervals" (https://postweavers.com/blog/ai-replies-x-ban-risk, opinion). The plan's 10–15/day is under every vendor threshold; the "within 30 minutes, every time, for a week" cadence is exactly the regularity signal they warn about.

Bottom line for 1: Human-posted, edited, non-templated replies at 10–15/day are inside the rules as written. API-posted replies to non-summoning authors are blocked. An agent that auto-posts replies needs written X approval. Treat "the API posts" as cut.

---

2. Distribution before product: what the 2025–26 evidence says

2a. Cases

I could not find a clean 2025–26 case of "grew an X audience first by replying, then launched, with first-month revenue attributed to that audience". Every audience-first story I found in search results was either pre-2024, a course/gumroad pitch, or lacked launch numbers. That absence is itself a finding: the reply-first-then-launch playbook is heavily marketed (https://www.teract.ai/resources/twitter-strategy-indie-hackers-2026, https://aitoolslister.com/blog/how-to-grow-on-twitter-x-as-founder, both opinion) and thinly evidenced.

2b. What the evidence says for 467 followers and $0 revenue

• The only dataset found says X/build-in-public amplifies trust for a product that already exists and never carried anyone past $1M alone (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results). The two concrete "no audience" cases (Chatbase, Bazzly) had a product to point at on day one.
• One week of replies cannot move 467 followers to a number that changes launch outcomes; vendor growth guides themselves frame reply-led growth in months (https://www.teract.ai/resources/grow-twitter-following-2026, opinion). A week is, however, cheap and reversible, and it produces something useful to the reply desk: a labelled dataset of which replies got responses.
• Verdict on the question: product (or at least a thing to link to) first; run the week of replies as a low-cost side channel and as data collection for phase 2, not as the growth plan. The evidence line: "every app past $1M ARR that used build in public also ran at least one other acquisition channel alongside it" (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results).

---

3. The reply-desk market in 2026

Observations:

• The market already exists and is crowded at the $19–49/mo point; the feature you describe (watch list, surface fast, draft in house style, human posts) is exactly XEngageAI's and Tweet Hunter's post-Feb-2026 positioning. It is a feature, and the incumbents have already been forced into the human-in-the-loop shape by the summoned rule ("API-based reply automation stopped working in February 2026", https://fireply.ai/blog/best-x-reply-automation-tools-2026).
• No source gives user counts for any tool; none gives churn or willingness to pay for accounts under 1k followers. "Small accounts pay for them" is unverified. Fireply's 50-follower floor and $69 price suggest its buyers are not 467-follower accounts.
• The tools that still auto-post do so by not using the official API (extensions or "independent infrastructure"), which is the automation-rules and scraping-rule risk zone ("Crawling X to extract tweets ... without using the official API is against the terms", https://opentweet.io/blog/twitter-automation-rules-2026).
• Cost to run: reads are the only hard cost (see 4); LLM drafting at 100 posts/day is cents. The expensive part is the polling design, not the model.

---

4. Unit economics of monitoring 20 accounts

4a. Prices (official and secondary)

• Pay-per-use launched 6 Feb 2026: "$0.005/Post Read, $0.01/User Read" (https://docs.x.com/changelog, data).
• 16 Apr 2026: "Owned Reads" at "$0.001 per resource (1,000 for $1)"; post creation "$0.015 per post", URL-containing posts "$0.20 per Post" (https://docs.x.com/changelog, data). Owned reads apply only when "the authenticated user must own the developer app", i.e. your own posts, not the 20 watched accounts (https://tweetstream.io/blog/twitter-api-pricing, single source).
• Monthly cap on pay-per-use reads: docs.x.com says 2M/month, developer.x.com advertises none (https://vorplabs.com/agent-tools/x-api); Blotato says 3M (https://www.blotato.com/blog/twitter-api-pricing). Conflicting; irrelevant at this scale.
• Basic ($200/mo) migrated to pay-per-use after 1 June 2026; Pro ($5,000/mo) auto-migrated after 1 Sep 2026 (https://www.blotato.com/blog/twitter-api-pricing, single source). So pay-per-use is now the only self-serve path.

4b. The cost arithmetic

Plus one-off user lookups: 20 x $0.01 = $0.20. The $0.005 figure is right; the claim "cheap to monitor" is only true if billing is per returned post and you poll with since_id so empty polls return nothing. Whether an empty response is billed at all is not stated in any source I could reach (the pay-per-use docs page returned 404: https://docs.x.com/x-api/getting-started/pay-per-use). Test this with one account for a day before building.

4c. Can pay-per-use poll often enough? (the real blocker)

• The rate-limit page I could fetch shows GET /2/users/:id/tweets at "Per App: 10,000/15min | Per User: 900/15min" and search/recent at "Per App: 450/15min | Per User: 300/15min", but with no tier label and no pay-per-use row (https://docs.x.com/x-api/fundamentals/rate-limits). These look like Pro/Enterprise numbers. Postproxy's tier table shows Basic at 3,500/15min for lookup and 450/15min for recent search, and explicitly "provides no separate rate-limit table for pay-per-use users" (https://postproxy.dev/blog/x-api-pricing-2026/). TweetStream says "the username-timeline endpoint caps at 1,500 requests per 15 minutes per app" (https://tweetstream.io/blog/twitter-api-pricing, single source). Blotato: "Per-endpoint rate limits apply across 15-minute and 24-hour windows, with HTTP 429 responses triggered before hitting spending caps" (https://www.blotato.com/blog/twitter-api-pricing).
• Not verified: the pay-per-use per-15-minute limit on the user-timeline endpoint. Under the old Basic tier this endpoint was among the tightest limits (single-digit requests per 15 minutes per app in 2024–25 docs, from memory, not re-verified today). If pay-per-use inherited Basic-style limits, 20 accounts can be polled roughly once every 30–45 minutes each, which kills "surfaces their posts within minutes". If it inherited the 1,500/15min figure, polling 20 accounts every 2 minutes (150 calls/15 min) is fine.
• Workaround worth testing: one search/recent call with from:a OR from:b ... for all 20 handles (query length permitting) every 2–3 minutes; at 450/15min per app that is comfortably inside limits and bills only returned posts. Filtered stream would be ideal but its availability on pay-per-use is not documented in any source reached.

---

5. Verdicts

Three concrete changes to phase 1

1. Delete "or the API posts". Every reply is drafted by the agent, edited by the human (change at least one sentence, no shared openers), and posted in the X app. Log draft vs. posted diff; that diff is your future product's training data and your compliance record.
2. Replace "within 30 minutes" with "within the first 2 hours, at irregular times, and never more than 3 replies to the same account per week". Cap at 10/day, not 15, for the first week on a 467-follower account (vendor threshold "under 30 replies per day for newer accounts", https://xengageai.com/blog/ghost-ban-on-x-twitter-2026, opinion, but it is the only number anyone publishes).
3. Make the week a measurement, not a growth push: for each reply record author, follower count, minutes-after-post, whether the author replied/liked, profile visits and follows that day. Pre-register the kill criterion (for example: fewer than 2 author responses per 10 replies by day 4 means stop and ship product).

Three concrete changes to the reply desk

1. Before writing any code, spend $1 on pay-per-use to answer two questions the docs do not: (a) is an empty since_id poll billed; (b) what is the 429 threshold on GET /2/users/:id/tweets and on search/recent for a pay-per-use app. Those two numbers decide whether "within minutes" costs $15 or $4,000 a month.
2. Build it as a search/recent poller (from: OR-list, since_id, every 2–3 min) rather than 20 timeline pollers; add a draft queue with a mandatory edit step and no post button that calls the API. Never add auto-post; the only auto-post routes left are extension/scraping routes that violate the developer policy.
3. Do not productise until you have four weeks of your own data showing author-response rate and follows per reply. If you do productise, the only defensible wedge against XEngageAI/Tweet Hunter is a narrow one: a watch list of named builder accounts plus the draft-vs-posted learning loop, sold to accounts that already have a product, at $19 or below. Assume a feature, priced as one.

---

6. Counts

• Sources checked: 32 (18 fetched and used; 3 official X pages blocked or 404: devcommunity announcement thread, docs.x.com pay-per-use page, docs.x.com user-timeline endpoint page; 11 seen in search results only and not relied on).
• Sources used, by URL: help.x.com/x-automation; help.x.com/platform-manipulation; docs.x.com/changelog; docs.x.com/developer-terms/policy; docs.x.com/x-api/fundamentals/rate-limits; piunikaweb.com; vorplabs.com; tweetstream.io; blotato.com; postproxy.dev; postweavers.com; opentweet.io (automation rules); xengageai.com (ghost ban); xengageai.com (comparison); fireply.ai; distributionbase.com; indiehackers.com (Bazzly); news.ycombinator.com/item?id=41618505.
• Claims by type: data (primary policy text, official changelog, or a dataset) 14; single source (one secondary page quoting X, or a self-reported founder number) 12; opinion (vendor heuristics, HN commenters, growth guides) 9.
• Key unverified items: pay-per-use rate limit on user-timeline endpoint; whether empty polls are billed; any named enforcement case against a small account for human-posted reply volume; any 2025–26 audience-first-then-launch case with revenue numbers.