Ask "how much data does an AI agent use?" and every search result talks about tokens — the unit your LLM provider bills for context and generation. But an autonomous agent that browses the web, calls tools, and runs on a device also moves real bytes over a mobile network. Those are two completely different meters, and confusing them is the single most expensive mistake when you put an agent on a cellular connection. This guide separates them and gives you order-of-magnitude numbers for the network side — the one nobody answers.
Tokens are not megabytes
A token is a chunk of text (roughly 4 characters, or about 0.75 of an English word) that your language-model provider counts to price a request. A megabyte is a measure of the raw bytes that cross the network. They correlate loosely but they are not the same thing, and the network number is almost always far smaller than people expect.
Here is the arithmetic. English text encodes at roughly 4 bytes per token in UTF-8. So a 200,000-token context window — a very large prompt — is about 800 KB of text on the wire. A typical 1,000-token prompt with a 500-token answer is a couple of kilobytes each way. The bottleneck for LLM apps is the token meter (cost) and the GPU (latency), not bandwidth. Even a fairly large LLM application usually runs well under 100 Mbps total, and a modest multi-user chat app needs a fraction of that on download.
The tokens you send cost money and add latency. The bytes they turn into on the network are almost an afterthought — which is exactly why a per-GB data plan is the wrong shape for a text agent.
A per-task bandwidth table
These are order-of-magnitude estimates, not measured benchmarks. Real numbers depend heavily on your agent's task mix, whether responses stream, how much of a page you actually download, and whether you fetch images. Treat them as a planning envelope, not a spec sheet.
| Agent task | Approx. network data | Why |
|---|---|---|
| One text LLM API call (request + response) | ~2–50 KB | A few thousand tokens each way at ~4 bytes/token, plus JSON and streaming overhead |
| Fetch one web page's HTML (text only) | ~0.1–0.5 MB | Just the markup; Google itself only crawls the first ~15 MB of HTML |
| Full page render / scrape (HTML + CSS + JS + images) | ~2–3 MB | The median web page is ~2.2 MB desktop; images alone median ~1 MB |
| Image-generation or multimodal task (up/download an image) | ~1–10 MB | Depends on resolution and format; a single hi-res image is several MB |
| Long autonomous run: dozens of text-only fetches + API calls | ~5–30 MB | Scales with how many pages it opens and whether it downloads assets |
Worked example: a research agent's day
Say you run an autonomous research agent that, over a day, makes 200 LLM API calls and fetches 100 web pages text-only. Rough math:
- 200 API calls × ~20 KB average = ~4 MB
- 100 text-only page fetches × ~0.3 MB = ~30 MB
- Total: roughly 34 MB for a busy day of autonomous work
What does that cost? A 34 MB day on Roamzy comes to about $0.03 at the France rate, or $0.11 at the United States rate — the meter bills only the megabytes that actually moved, at each country's local rate.
If that same agent renders every page with images and scripts instead of pulling text, the 100 fetches balloon toward ~250 MB. So the biggest lever on an agent's data bill is not the LLM at all — it is whether it downloads page assets or just the text it needs to reason over.
Why a 1GB package wastes ~99% for a text agent
Now put that 34 MB/day agent on a conventional travel eSIM: a 1GB / 7-day package. Over the week it might move ~34 MB × 7 = ~240 MB — if it runs hard every day. More realistically a lighter agent uses a few MB per day. Either way you paid for 1,024 MB and used a fraction of it. The package also expires in 7 days, so whatever you didn't burn is gone. That is the structural mismatch: fixed bundles are sized and timed for a human streaming video on holiday, not a text agent nibbling kilobytes.
| 1GB / 7-day package | Per-MB billing (Roamzy) | |
|---|---|---|
| What a light text agent uses | Maybe 20–50 MB | Maybe 20–50 MB |
| What you pay for | 1,024 MB, fixed | Exactly what moved |
| Waste | ~95–99% | ~0% |
| Unused balance | Expires in 7 days | Never expires |
| Agent can meter/cap spend | No — opaque bundle | Yes, programmatically via MCP |
Per-megabyte billing flips this. The agent pays cents for exactly the bytes it moves, the leftover balance never dies, and — the part that matters for autonomy — the agent can read its own usage and cap its own spend. Full mechanics in pay-per-megabyte eSIM, explained.
Metering and capping spend programmatically
A human notices a data plan running out. An agent needs an interface. Roamzy exposes an MCP server (12 tools) plus a REST API so the agent can check its own balance, estimate a cost before it acts, and stop when it hits a cap — no dashboard, no human in the loop. Because billing is per megabyte settled in USDT/USDC stablecoins with no account and no KYC, an agent can provision connectivity end-to-end on its own — no card that can get declined at checkout — it pays for connectivity in stablecoins instead. It can even earn a 20% referral on downstream usage it drives. Background on why this shape suits machine buyers: which eSIM can an AI actually buy and agentic commerce and connectivity.
One eSIM, wherever the agent runs
Autonomous agents don't stay in one country. An agent running a task in Japan, a fleet of scrapers hosted near Germany, a monitoring bot in Singapore, or a field device in the United States all want the same thing: one connection that works everywhere and bills identically. Roamzy is a single global eSIM across 193 countries — the same per-MB meter in Brazil, India, or the UAE — so you don't juggle a package per region. Get it running with the give your AI agent a global eSIM walkthrough, or compare shortlist options in the best eSIM for AI agents.
Practical takeaways
- Measure bytes, not tokens, when you budget a cellular connection — they are different meters.
- Text agents are cheap on bandwidth — single-digit to low-tens of MB per day is a realistic envelope.
- Rendering full pages is the real cost driver. Fetch text, not assets, unless you truly need them.
- Fixed GB packages waste ~99% for a text agent and then expire; per-MB billing matches spend to usage and never expires.
- Give the agent an interface to its own spend so it can cap itself — that is what MCP and per-MB pricing unlock.
FAQ
Is an AI agent's data usage measured in tokens or megabytes?
Both, but they measure different things. Tokens are how your LLM provider bills for the text a model reads and writes. Megabytes are the raw bytes that cross the network. For budgeting a mobile or cellular connection you care about megabytes, and for a text agent that number is usually far smaller than the token count would suggest — roughly 4 bytes per token on the wire.
How much mobile data does a text-only agent actually use per day?
As an order-of-magnitude estimate, a busy text-only agent making a few hundred API calls and fetching pages as text might move on the order of tens of megabytes per day; a lighter one, just a few. These are planning estimates, not benchmarks — your real usage depends entirely on how many pages it opens and whether it downloads images and scripts.
Why does a 1GB eSIM package waste money for an AI agent?
Because a text agent may use only 20–50 MB where the package sells you 1,024 MB, so you pay for data you never move — and the unused balance expires when the package's validity window (often 7 days) ends. Per-megabyte billing charges only for the bytes that actually flowed, and with Roamzy the balance never expires.
Can an AI agent control its own connectivity spending?
Yes, if the provider exposes a machine interface. Roamzy offers an MCP server and REST API so the agent can check its balance, estimate a cost before acting, and stop at a cap — all programmatically, with no human dashboard. Billing in USDT/USDC stablecoins with no account or KYC lets the agent provision connectivity end to end on its own.
What makes an agent's data bill spike?
Rendering full web pages with all their assets. The median web page is around 2.2 MB, with images alone near 1 MB, so downloading complete pages instead of just their text can multiply an agent's bandwidth by 10× or more. If your agent only needs to reason over text, fetch the HTML and skip the assets.