When does a wider workspace use more tokens?

A folder can contain a thousand files and contribute zero file contents to a request. Usage changes when a search returns matches, a read brings an SVG into context, or Claude makes another model call to decide which asset to use. A search that returns three filenames can be cheaper than reading one large SVG.

Consider an illustrative case. A tool returns 2,000 tokens of irrelevant SVG markup. If the next request writes those tokens to the prompt cache and three later requests each read them from cache, that one result accounts for 2,000 cache-write tokens and 6,000 cache-read tokens. The two categories carry different prices. A tighter workspace could avoid those reads, but a blocked lookup could also trigger extra searches.

Can Claude Code read outside your project?

In the local CLI, the answer depends on which tool Claude uses. Sandboxed Bash commands can ordinarily read much more of the filesystem than they can write. The built-in Read and Write tools follow Claude Code permission rules. A successful or blocked shell command tells you about that command path alone. Anthropic’s sandbox reference.

  1. In a disposable workspace, create sibling folders named project and neighbor. Put a file named marker.txt in each with a different invented phrase. Keep the phrases out of your prompt. Start Claude Code in project and record the CLI version, OS, permission mode, and sandbox settings.
  2. Ask Claude to read each marker using the Read tool, then repeat with sandboxed Bash. For writes, ask each tool path to create a fresh, uniquely named empty file in each folder. Check the returned phrases and files yourself. Record success, denial, or an approval prompt for each attempt. Decline escalation so the result reflects the original boundary.
  3. Restrict Bash reads of the sibling folder with sandbox.filesystem.denyRead and configure a matching Read deny rule for the built-in tool. Repeat the checks in a fresh session with new markers. The two settings use different absolute-path syntax. Claude Code permission rules.

Measure tokens per completed fix

Run the cost comparison in separate sessions from the permission checks. Put the correct icon in the project and a similarly named decoy in the sibling folder. Give both runs the same task: “Fix the broken toolbar icon using the project’s existing asset.” Use the same starting files, model, and prompt. Reset the fixture between runs and change only the access policy.

For each session, verify the patch points to the intended project asset and the icon renders. In the request logs, group by session and count each request ID once. Sum fresh input, cache writes, cache reads, output, and estimated API cost separately. Include calls after a denial. Record how many fixes passed alongside the totals. Anthropic’s request event fields.

If the narrower run costs more, inspect the first denial and the next tool call. Did Claude try three more paths before it found the icon? Repeat with the asset path in the task description to test whether better instructions remove those retries. Across repeated runs, divide total estimated cost, including failed attempts, by the number of passing fixes. For subscription users, that figure expresses API-equivalent cost.

For a worked example of converting the four token counters into dollars, see why Claude Code uses so many tokens.