Key takeaways
- Idle connectors cost little per turn. In a measured test, six claude.ai connectors (Gmail, Google Drive, Google Docs, Google Calendar, BigQuery and Claude Docs) added 3,139 tokens to every request in Claude Code, about 17% on top of an 18,947-token base prompt. The increase was identical on Claude Haiku 5.5 and Opus 5.5.
- Server instructions are the hidden part. One connector that ships a long instruction block added 1,693 tokens by itself, more than half of the total. Those instructions also steer the model's behaviour, not only its bill.
- Loading a connector's tools is the expensive step. When the model loaded Gmail's 30 tool definitions, the prompt grew by about 23,400 tokens for the rest of the session. One tool result can add up to 25,000 tokens more before Claude Code moves it to a file.
- Anthropic reports the same pattern at scale. Five typical servers loaded up front cost about 55,000 tokens. Tool search cut a 72,000-token load by 85% and raised tool-selection accuracy on Anthropic's evaluations.
- Switch connectors on per task. In a simulated developer day, switching connectors on only for the tasks that need them cut tokens processed by about two thirds (4.38 million to 1.50 million) and list-price cost by 63%. Keep connectors off by default and enable only the one a task needs. The main gain is not tokens but fewer send-capable tools and fewer stray instructions in sessions that do not need them.
How to read the numbers
All facts are stated as of 13 October 2026. Measured marks figures from a test run on Claude Code 2.1.296 on 13 October 2026 (method below). Vendor marks figures read on Anthropic's pages, and Vendor claim marks Anthropic's statements about its own evaluations. Arithmetic marks my calculation from stated figures, and Estimate marks a figure derived indirectly. Prices are Anthropic list prices per million tokens, from Claude orchestration and cost and Costs and economics. How connectors work is covered in Agent frameworks and protocols, and their security in Regulation and security.
How a connector reaches the model
A connector is an MCP server that Claude can call. In Claude Code, connectors added on a claude.ai account load automatically when the user signs in with a subscription (Vendor; Claude Code MCP documentation). What reaches the model depends on the stage:
- At session start, only names and server instructions. Claude Code defers MCP tool definitions by default. Each tool description and each server's instructions are cut at 2,048 characters (Vendor; Claude Code MCP documentation).
- When a tool is needed, its full definition. The model searches for the tool and loads its schema, which then stays in context for the rest of the session.
- After a call, the result. Claude Code warns when a tool's output exceeds 10,000 tokens and limits it to 25,000 tokens by default (
MAX_MCP_OUTPUT_TOKENS). Larger results are saved to a file (Vendor; Claude Code MCP documentation).
Clients that do not defer tool definitions, or Claude Code with ENABLE_TOOL_SEARCH=false, load every definition at the start of the session.
What a test measured
Method. One headless request (claude -p, asking for a one-word reply) was sent per configuration from an empty folder, with connectors switched through Claude Code's settings file. The prompt size is the sum of the input, cache-write and cache-read tokens in the run's usage report. The all-off baseline was repeated and matched to the token. Microsoft 365 and Atlassian connectors were not connected, so they were not measured (Measured).
| Configuration | Model | Prompt tokens | Change |
|---|---|---|---|
| All connectors off (baseline, run twice) | Haiku 5.5 | 18,947 | baseline |
| Six connectors on, idle | Haiku 5.5 | 22,086 | +3,139 |
| All connectors off | Opus 5.5 | 17,969 | baseline |
| Six connectors on, idle | Opus 5.5 | 21,108 | +3,139 |
| Six on, Google Drive's 11 tool definitions loaded | Haiku 5.5 | about 27,900 | about +5,800 for Drive's tools (Estimate) |
| Six on, Gmail's 30 tool definitions loaded | Haiku 5.5 | about 45,500 | about +23,400 for Gmail's tools (Estimate) |
The six single-connector results add up to 3,175 tokens, close to the 3,139 measured with all six on together. The "loaded" rows come from asking the model to load the definitions without calling any tool. The second-turn prompt was estimated as the two-turn total minus the first turn, less about 200 tokens for the search itself (Estimate). On this basis Gmail's tools average about 780 tokens each and Drive's about 530 (Arithmetic).
Switching on the skills synced from a claude.ai account made no difference in these headless runs. An interactive session may list them differently, and that was not measured.
What that costs
At Opus 5.5 list prices, writing to the 1-hour cache costs $8 per million tokens and reading it $0.20 (Vendor; Anthropic pricing). In a 50-turn session, the extra context is written once and read on every turn (Arithmetic):
| Extra context in a 50-turn Opus 5.5 session | Tokens | One cache write | 50 cache reads | Total |
|---|---|---|---|---|
| Six idle connectors | 3,139 | $0.025 | $0.031 | about $0.06 |
| Gmail's tool definitions, loaded once | about 23,400 | $0.19 | $0.23 | about $0.42 |
| One tool result at the 25,000-token cap, kept in context | 25,000 | $0.20 | $0.25 | about $0.45 |
Idle connectors cost cents per session. Loaded definitions and large results cost roughly ten times as much, and they also use up context the model needs for the task. On subscription plans these amounts are a proxy for how fast a session uses its usage window.
Always on or switched on per task: a simulated day
A simulated developer day shows what switching connectors on per task changes. The inputs are the measured sizes above plus stated assumptions (Assumption): 20 Claude Code sessions a day of 40 turns each; two sessions need Gmail and load its tools at turn 10. With connectors always on, every session carries the six idle connectors, and two other sessions also load Google Drive's tools without needing them. With per-task switching, only the two Gmail sessions enable Gmail, on its own. Each session writes the 1-hour cache once and reads it every turn, at Opus 5.5 list prices (Arithmetic).
Each row in the figure is one session, and bar length is the extra tokens it processes, on one scale for both panels.
| Per developer | Always on | Switched on per task | Change |
|---|---|---|---|
| Tokens processed per day (cache writes and reads) | 4.38 million | 1.50 million | −66% |
| Cost per day at list price | $1.82 | $0.68 | −63% |
| Cost per month (22 working days) | $40.1 | $14.9 | −$25 |
| Team of 20, tokens and cost per month | 1.93 billion, $802 | 0.66 billion, $298 | −$504 |
| Connector tools named in every session | 66 | none (30 in 2 sessions) | |
| Sessions with send-capable tools (send mail, share files, create events) | 20 of 20 | 2 of 20 |
The Gmail work costs the same $0.65 either way. The saving comes from removing idle connectors from the 18 sessions that never used one, and from avoiding unneeded tool loads. Per developer that is about $25 a month at list price, or usage-window headroom on a subscription; for a team of 20 it is about 1.27 billion tokens, or about $504 at list price, a month (Arithmetic). The larger difference is in the last two rows: what the model can see and do in sessions that never needed a connector.
What Anthropic has published
- Tool search: 85% fewer tokens. Fifty-plus MCP tools loaded up front took about 72,000 tokens; with tool search it was about 500 up front plus about 3,000 for the tools used. Accuracy on Anthropic's MCP evaluations rose from 49% to 74% for Opus 4 (Vendor claim; Anthropic, Advanced tool use).
- Typical servers: about 55,000 tokens. A setup with GitHub, Slack, Sentry, Grafana and Splunk "can consume ~55k tokens in definitions" before any work, and tool choice degrades once 30 to 50 tools are available (Vendor; Anthropic, Tool search tool).
- Code execution: 98.7% fewer tokens. Exposing tools as code that the model reads on demand cut one workflow from 150,000 tokens to 2,000 (Vendor claim; Anthropic, Code execution with MCP).
- Fewer, consolidated tools. "More tools don't always lead to better outcomes"; overlapping tools distract agents, and responses should be paginated or truncated (Vendor; Anthropic, Writing tools for agents).
Switching connectors on per task
Claude Code can stop loading claude.ai connectors with the disableClaudeAiConnectors setting, and deniedMcpServers blocks single servers by name. The connection itself stays on the claude.ai account (Vendor; Claude Code MCP documentation). In the same test, three behaviours mattered for a per-task routine (Measured):
- Settings changes reached running sessions within seconds.
- Once the user setting disabled connectors, a per-session override (
--settingsor an environment variable) did not switch them back on, so a small script that edits the user setting is the practical switch. - Enabling one connector while denying the rest by name worked: only the chosen connector loaded.
Administrators can enforce the same choices for everyone with managed settings, which users cannot override (Vendor; Claude Code managed MCP).
What this means for your business
These points are inferences from the evidence above, not sourced forecasts.
- Keep connectors off by default. Enable a connector for the task that needs it, and switch it off afterwards. The token saving is modest; the bigger gain is that send-capable tools and stray instructions are absent from sessions that do not need them.
- Watch instructions and results, not just tool counts. A long server instruction costs more than several idle connectors, and one large result costs more than all of them. Prefer servers with short instructions and paginated results.
- Keep tool search on. Loading every definition up front multiplies the cost and lowers tool-choice accuracy.
- Measure your own setup. One one-word request per configuration is enough to see what each connector adds. Repeat after client or server updates.
- Use managed settings in teams. Set which servers are allowed centrally rather than relying on each user's choices.
Open questions and unverified items
- The loaded-definition sizes are estimates from two-turn totals, not direct measurements (estimate).
- The test used single runs per configuration on one Claude Code version; behaviour may change between versions (unverified).
- Synced claude.ai skills were measured only in headless runs (open-question).
- The always-on versus per-task comparison is a simulation with stated assumptions, not a measured working day (estimate).