Threads is the Meta platform that gives a proxied client the most for the least, and the number is in the head. On 28 September 2026 we fetched one public profile thirteen times through residential exits in the United States, Germany and Brazil. A plain HTTP client with no login and no JavaScript received 1,034,341 bytes with the follower count and post count in the meta description, the h1, the canonical and the recent posts in the HTML. Rendering the same page cost 2,028,277 bytes for a word count that changed with every exit. What the exit country changed was the number itself: 12.7M, 12,7 Mio., 12,7 mi.
Search for Threads proxies and Google thinks you mean concurrency
This is the only keyword in the series where the SERP is about a different noun. "Threads" is the word proxy vendors use for concurrent connections, and the first page is a forum post asking what threads mean in a residential plan, two vendor help pages on thread limits, a forum answer recommending no more than ten threads per proxy, and a plan page priced by thread count. Two results are about the Meta app, both selling proxies for running many accounts, and two are posts on threads.com written by proxy sellers. Autocomplete for the head term returns nothing; "proxies for threads" suggests "proxy threads", the concurrency meaning, and "threads scraper" is where the data intent lives: github, api, apify, post, profile, comment, search.
If you are here for connection limits: our residential and rotating endpoints have no per-account thread cap, and the number that matters on Threads is bytes per profile, below. If you are here for the Meta app, read on, and note that Meta's terms apply to Threads exactly as they apply to Instagram and Facebook, because Threads accounts are Instagram accounts.
The profile is server-rendered, and the counts are in the meta description
We audited threads.com/@nasa with and without JavaScript from each of the three exits, weighed it over plain HTTP from all three, and rendered it from one.
| Fetch | Exit | Bytes | Words, strict count | Description opens with | Title ends with |
|---|---|---|---|---|---|
| Profile, no JavaScript | US | 1,034,341 | 177 | 12.7M Followers • 137 Threads | Threads, Say more |
| Profile, no JavaScript | DE | 1,033,248 | 162 | 12,7 Mio. Follower • 137 Threads | Threads – sag mehr |
| Profile, no JavaScript | BR | 1,059,354 | 189 | 12,7 mi seguidores • 137 threads | Threads, diga mais |
| Profile, rendered | US | 2,028,277 | 198 | 12.7M Followers • 137 Threads | Threads, Say more |
| Profile, rendered | DE | 383 | 12,7 Mio. Follower • 137 Threads | Threads – sag mehr | |
| Profile, rendered | BR | 232 | 12,7 mi seguidores • 137 threads | Threads, diga mais |
Read the description column first. Every plain fetch carried the follower count and the post count in the head, server-rendered, with no script involved. On Facebook the same trick gives you the follower count of a Page for 923,794 bytes; on Threads it gives you followers and posts for about one megabyte, and the canonical, the h1 and an Open Graph block come with it. There is no JSON-LD of any kind on the profile, so the description is the structured surface.
The strict word count in the table is the audit's conservative measure of main content, and it undersells the page. A full Markdown extraction of the same plain HTML returned 2,132 words and 17 images from the US exit, 2,110 from Germany and 2,235 from Brazil: the recent posts, with their text, are in the HTML that a client without JavaScript receives. That is the whole difference from Instagram and Facebook, where the posts arrive only after hydration. On Threads the first page of a public profile is a plain HTTP read.
The rendered rows are the ones that ruin a benchmark. The browser downloaded twice the bytes, ran for 7.8 seconds, and produced 198 words from the United States, 383 from Germany and 232 from Brazil for the same profile. The feed hydrates progressively and the capture window catches a different amount of it every time, so a rendered word count on Threads is not a measurement, it is a timing. Assert on the plain HTML, where the counts are stable within a few words across exits, and where the description carries the numbers you actually want.
The exit country rewrites the number, not just the label
We sent no Accept-Language header and changed nothing between exits. Threads localised the whole head from the IP: the title suffix, the description, and, the part that matters, the format of the counter.
| Exit | Counter as served | What a naive parser reads |
|---|---|---|
| United States | 12.7M Followers | 12.7 million |
| Germany | 12,7 Mio. Follower | 127, or 12 with a comma split, and no match on "Followers" |
| Brazil | 12,7 mi seguidores | 12,7 mi is not a suffix any English regex knows |
The German exit writes the decimal as a comma and the magnitude as "Mio."; the Brazilian exit writes "mi". A parser built on the US page, matching ([\d.]+)M, matches nothing from Germany and Brazil, and one that strips non-digits first turns 12,7 Mio. into 127. Both failures are silent. Either pin the exit country per job and parse for that locale, or parse the counter with a locale table: decimal separator, magnitude suffix, and the label word, which is "Followers", "Follower" and "seguidores" respectively. On Threads geo targeting is a parsing dependency before it is anything else, exactly as we found on Facebook, and the safest storage is the string as served plus the exit country, so the parse can be redone.
The canonical did not move: https://www.threads.com/@nasa from all three countries, and the bytes stayed within 2.5 percent of each other. Threads does not shard by region or redirect to country domains the way Pinterest does. It rewrites the strings and nothing else.
The Threads API wants a token, and its limits are about posting
Threads has an official API at graph.threads.com (and graph.threads.net), and every call carries an access token obtained through Meta's app review and a user's authorisation. It is a publishing and insights API for accounts that granted your app access. The documented limits make its purpose clear: an app's call count is 4,800 multiplied by the number of impressions the app's users generated, per rolling 24 hours; a profile may publish 250 posts, 1,000 replies and 100 deletions per 24-hour window, and run 500 location searches. None of those numbers describes reading strangers' public profiles, because the API does not do that at scale. The keyword-search endpoint it offers also requires a token.
So the map is the same as on the other Meta platforms. The public web profile is the surface a proxied client can read without an identity, and on Threads it is a good one: counters in the head, posts in the HTML, no browser needed. The API is for accounts you are authorised to act for. Neither is a licence to build a dataset, and robots.txt says so in its first four lines.
What robots.txt says, and who is on the list
threads.com/robots.txt is 8,149 bytes and opens with a notice rather than a rule: collection of data on Threads through automated means is prohibited unless you have express written permission from Threads, and every authorised user agent listed must comply with Meta's Automated Data Collection Terms, whose URL is in the comment. Then fourteen named agents get a flat Disallow: /: Amazonbot, Applebot-Extended, Brightbot, ClaudeBot, Google-Extended, GPTBot, PerplexityBot, PetalBot, Scrapy, uptimerobot, viberbot, YaK, Yandex and Yeti. Then Googlebot, Bingbot, Applebot, DuckDuckBot, the link unfurlers of Discord, Telegram, Twitter, LinkedIn and Pinterest, and a few SEO crawlers get a shared block that disallows accounts, settings, the ajax and query endpoints and the /publicapi/ path, with Googlebot and Bingbot additionally kept out of individual posts and comment pages. Then the last block:
User-agent: *
Disallow: /Followed by fifteen Sitemap: lines: profile sitemaps in five tiers, US top creators, emerging creators, active producers, micro producers, high-potential posts, hashtags and typeahead tags. As on Facebook, the platform publishes a map of its public accounts and tells any client it has not named to stay out of all of it. The Automated Data Collection Terms, 2,765 words, are the document behind the notice, and their first requirement is written permission.
So be accurate about what you are standing on. A Threads profile is readable over plain HTTP, and it publishes the counts and the recent posts to every client. Meta's position is that automated collection needs written permission, and the notice is the first line of robots.txt. Reading a few public profiles to verify a creator, or checking how your own account and posts render in another market, sits inside ordinary use; crawling the profile sitemap is what the notice is about. Under United States case law the two questions are separate, and we cover that ground in is web scraping legal in the US; Meta's terms do not depend on it, and a residential IP settles none of it.
What a Threads profile costs to read
Every number here came through residential proxies on the Basic line at $0.80/GB, counting a gigabyte as 10^9 bytes.
| Job | Bytes per request | Requests per GB | Cost per request |
|---|---|---|---|
| Profile with counts and recent posts, no JavaScript, US exit | 1,034,341 | 967 | $0.00083 |
| Profile, no JavaScript, BR exit | 1,059,354 | 944 | $0.00085 |
| Profile, rendered | 2,028,277 | 493 | $0.0016 plus 7.8 s of browser |
A gigabyte holds 967 profile pages over plain HTTP, each with the follower count, the post count and the first page of posts. Ten thousand creators is 10.3 GB and about $8.30; rendered, 20.3 GB, $16.20, and 22 hours of browser time for a word count you cannot compare between exits. The same 10,000 pages on mobile at $2.30/GB would be $24 for a surface that never asked what network we came from: thirteen fetches, thirteen complete pages, no address-level obstacle from any exit. On Threads the cost is the megabyte of application every profile ships, and the only lever is to never render it.
The setting that works on Threads
- Network: residential proxies, Basic line, $0.80/GB. Thirteen fetches from three countries returned complete plain-HTTP pages; the Premium ($2.20/GB) and Mobile ($2.30/GB) lines returned nothing extra on logged-out reads.
- Fetch mode:
engine: tls, plain HTTP, never rendered. The profile returns the follower and post counts in the meta description and the recent posts in the HTML, 2,132 words in a full extraction, for 1,034,341 bytes; rendered it costs 2,028,277 bytes and 7.8 seconds for a word count that varied from 198 to 383 by exit. - Country: pin the exit per job and parse for that locale. The counter is served as 12.7M from the United States, 12,7 Mio. from Germany and 12,7 mi from Brazil; store the string as served with the exit country, and never match on the English label. The canonical stays on www.threads.com from every exit.
- When the proxy is not enough: there is no Threads collector in our catalogue. The web scraping API without rendering returns the profile as clean Markdown from $0.0002 per page, with a CSS extraction schema for the description counters and the post list; failed requests are never billed. To run the same no-JS versus rendered comparison on your own list of profiles, the SEO Audit API does both fetches in one call at $0.0012 per URL. For the same counters on the sibling platform, the Instagram profile collector returns them as rows.
- Free tier: every account gets $2 of free API usage per month, which is 10,000 profile pages through the scraping API before you pay anything.
Read the profile over plain HTTP, take the counts from the description, parse them for the exit's locale, and read Meta's notice before you read the sitemap. For the platform in this series where the counts are also in the head but the posts are not, compare Instagram; for the one that puts the whole feed in the HTML with no terms notice at all, Telegram.
What we will not help you do
The two results on this keyword that are about the Meta app sell running many Threads accounts through proxies. We will not write that. Threads accounts are Instagram accounts, Meta's terms forbid bulk registration, account farming, engagement automation and evading enforcement, the enforcement runs on device and behavioural signals a proxy never touches, and no proxy restores a disabled account. What proxies legitimately serve on Threads is creator research and sponsorship due diligence on public profiles, brand and impersonation monitoring, checking that your own account, posts and any promoted content render correctly in each market, which the localised head makes a real per-country question, and social listening on public conversations within the limits Meta's terms set. Public does not mean unlicensed: posts and profiles are their authors' content and, where they name people, personal data, so purpose, retention and deletion still apply.