What the X API actually costs an LLM agent, per tool call

A developer building an MCP server that exposes the X API to an LLM agent found that cost control, not API design, dominated the work, because a search returning 100 posts is billed as 100 post reads at $0.005 each ($0.50) versus $0.025 for the same query with max_results set to 5. The developer recommends embedding per-resource pricing in tool descriptions, using X's free counts endpoint to size a query before paying for posts, batching lookups up to 100 ids, making pagination manual, and enforcing hard ceilings in environment variables, noting that duplicate fetches within a 24-hour UTC window are billed only once.

There is no free tier on the X API any more. For new developers the subscription tiers are gone and it is pay per use: you load credits in the developer console and every request eats them in real time. Legacy Basic and Pro survive for accounts that already had them, Enterprise starts around $42,000 a month, and everyone else gets credits. That is fine for a script you wrote and can read. It is a different problem when the thing making the calls is a language model that decides for itself how many results to ask for. I found this out building an MCP server that hands the X API to an agent. Most of the design ended up being about money rather than about the API. Here is what I would want to know before pointing a model at it. This is the whole thing. It is the one sentence that changes how you write the tools. A search that returns 100 posts is not one request. It is 100 billable post reads. At $0.005 per post that is $0.50. The same search with max results: 5 answers the same question for $0.025. Twenty times cheaper, same query, same code path. Prices at the time of writing, and re-check them because they have moved several times this year: | Operation | Price | |---|---| | Post read | $0.005 per post returned | | User read | $0.010 per user returned | | Followers / following read | $0.010 per resource | | Owned reads your own posts, bookmarks, likes, lists | $0.001 per resource | | Publishing a post | $0.015 | | Publishing a post containing a URL | $0.200 | | Like, repost, other interactions | $0.015 | Now put that in front of a model. Models are agreeable. Ask one to research a topic and it will happily call search three times with the default page size, then paginate because pagination was available, then look up every author it found. None of those are wrong moves. They are just expensive moves, and nothing in the API response tells the model it just spent four dollars. Four things fell out of this, and they generalize to any paid API behind an agent. Put the price in the tool description. The model reads those descriptions before every call. Mine say, in plain words, that reads are billed per resource returned and that it should ask for the smallest count that answers the question. This works better than it has any right to. It is not a guarantee, but the default behaviour shifts a lot. Give it a cheap way to size the problem first. X has a counts endpoint that returns match counts bucketed by minute, hour or day for the same query syntax as search, and it does not touch the post-read budget. So the pattern is: count first, look at the number, then decide whether to pay for the posts. A tool that answers "how much would this cost" for free is worth more than a tool that is 10% cheaper. Batch instead of loop. Lookups take up to 100 ids in one call. If the model can loop it will loop, so the batching tools say so explicitly, and the per-call ids limit is high enough that looping is never the easier path. Do not paginate on the model's behalf. This one is a judgment call and I went the other way from most wrappers. It is tempting to write a tool that walks pages until it has everything, because that is convenient. But every page is billed, and a convenience that quietly multiplies the bill is not a convenience. Pagination is manual: the tool returns a token, and going further is a decision someone makes on purpose. And then the part that does not depend on the model at all: the hard ceilings belong in env vars . Maximum results, maximum queries per call, maximum days back. The model can ask for whatever it likes and the process refuses above the ceiling. Prompt-level guidance shapes the common case; the ceiling is what stops the bad case. You need both, and only one of them is enforceable. Deduplication is on your side, if you know about it. The same resource fetched twice inside a 24-hour UTC window is billed once. That makes caching less urgent than you would think, and it makes a retry after a timeout much less scary than it looks. A link costs thirteen times more than a plain post. Publishing is $0.015. Publishing something containing a URL is $0.20. That is not a rounding difference, and it changes how you would write an agent that posts. Worth knowing before you build a workflow around it rather than after. Not a billing thing, but it is the single most common way an X integration ends up broken, so it belongs here. An access token permanently keeps whatever permissions the app had at the moment the token was generated. If you created the token while the app was Read-only and later flipped the app to Read and Write, the token is still read-only. Every write fails, forever. Nothing on the app settings page hints at it, and regenerating the API key and secret does not fix it. You have to regenerate the access token and secret. Because this is so easy to hit, my server calls GET /2/users/me once at startup, before registering a single tool, and refuses to boot if the token is read-only, saying exactly that. Failing at startup is unpleasant. A server that starts and then fails every write is worse. If you are wrapping a metered API for an agent, the useful mental model is that you are not designing an API client. You are designing a spending policy that happens to be written as tool descriptions and env vars. The model is a coworker who is fast, willing, and completely unaware of your credit balance. The server I pulled these examples from is mcp-x https://github.com/Role1776/mcp-x : Go, MIT, 42 tools over the official X API v2. Fair warning, and it is the direct cost of doing this against the paid API instead of scraping a browser session: you cannot run it at all without a funded X developer account. Good luck