What is a tool call for an AI worker?
A tool call is one action an AI worker takes in a connected app, such as reading a thread or adding a calendar event, and it is the unit plans meter.
Tokens measure how much an agent thought. Tool calls measure how much it did. They are different costs, metered differently, and confusing them is the most common surprise on a first invoice.
Tokens vs tool calls
| Model tokens | Tool calls | |
|---|---|---|
| Measures | Reading and writing text | Actions in connected apps |
| Billed by | Your model provider, at list price | Included in your plan |
| Runs out how | A balance empties, the run is skipped | A daily cap is hit, the worker pauses |
| Controlled by | The wallet or your key | Your plan tier |
| Grows with | How much context a run reads | How many actions a run takes |
Running out of one does not affect the other. A worker can have plenty of wallet balance and still pause at its daily cap, and vice versa.
What counts as one
One thing done in one connected app:
- reading an email thread
- sending a reply
- adding a calendar event
- looking up a CRM record
- creating a task
Each is one invocation of a tool the app exposes, which is also the unit MCP speaks in.
A single run makes several. Meeting Prep Assistant reaches calendar, email, meeting notes and CRM to build a prep sheet: it might list the day's meetings, read two threads per meeting, pull a CRM record and write one document. That is easily a dozen calls for one meeting-heavy morning.
The daily caps
| Plan | Tool calls a day | Rate shaping |
|---|---|---|
| Free | 500 | 60 an hour |
| Pro | 5,000 | Daily cap |
| Team | 50,000, pooled | Daily cap, burst headroom |
| Enterprise | Custom | Priority lanes |
Two details worth pulling out. Free carries an hourly shape of 60 as well as the daily 500, so a burst is smoothed rather than spending the day's allowance before lunch. Team's allowance is pooled across the account rather than divided per user, so one heavy worker does not starve the rest by design.
Estimating a worker before you deploy it
Multiply calls per run by runs per day. That is the whole model, and it is worth doing before adding a schedule rather than after.
| Pattern | Runs a day | At 8 calls a run | Fits |
|---|---|---|---|
| Once each morning | 1 | 8 | Free |
| Hourly, 10 hour day | 10 | 80 | Free |
| Every 15 minutes, all day | 96 | 768 | Pro |
| Every minute | 1,440 | 11,520 | Over Pro's cap |
Frequency is the multiplier on everything. This is the concrete reason to pick a schedule that matches the job rather than the fastest one available: the last row is not merely expensive, it is impossible on Pro.
And a minute-by-minute schedule is usually a webhook trigger nobody has wired yet. A trigger runs only when something actually happened, so it typically costs less than an hourly schedule while reacting in seconds.
Hard caps are the right failure
At the cap a worker **stops until the counter resets, then picks its schedule back up.** Nothing is deleted. No setting changes. No overage appears on a bill you did not agree to.
For unattended work a hard cap is a better failure mode than a soft one. A runaway loop on a soft cap is an invoice you discover later; on a hard cap it is a paused worker and a receipt explaining why. You lose some work and learn immediately, instead of losing money and learning at the end of the month.
The reasonable objection is that a hard cap can stop real work at a bad moment. True, and the mitigations are in your hands: the receipt names the cause, caps reset daily, and Team pools its allowance so a spike in one worker draws on the whole account rather than one seat's share.
When the cap is the wrong thing to optimise
Not every high-call worker is a problem to solve.
- A once-daily sweep that reads a lot is fine. It is one run; the calls are the job.
- A worker close to its cap on Free may simply belong on Pro. $29 a month against the time spent re-tuning a schedule is usually not a close call.
- A worker that is genuinely event-shaped should move to a trigger rather than have its polling interval tuned.
The thing actually worth optimising is a worker that makes many calls to discover that nothing happened.
FAQ
What counts as a tool call on WorkerKit?
One action a worker takes in a connected app: reading an email thread, sending a reply, adding a calendar event, looking up a CRM record, creating a task. A single run usually makes several.
How many tool calls do I get?
500 a day on Free with 60 an hour of rate shaping, 5,000 a day on Pro, and 50,000 a day on Team pooled across the whole account. Enterprise is custom with priority lanes.
What happens when a worker hits the daily limit?
It stops until the counter resets, then resumes its schedule. Nothing is deleted and no configuration changes. The caps are hard by design so an unattended fleet cannot run up an overage.
Are tool calls the same as model tokens?
No. Tool calls are actions in your apps, included in your plan and capped daily. Model tokens are what the model reads and writes, billed separately at provider list price with no markup from the wallet or your own key. See /pricing.
How do I reduce a worker's tool calls?
Lower the frequency first, since runs per day multiplies everything else. If the job is really a reaction to an event, move it to a webhook trigger, which does not run at all on a quiet day.