Big files and data analysis

Two ways Claude works with a file

When you attach a document, Claude works with it in one of two ways, and knowing which matters.

For a normal-sized file, Claude holds the whole thing in view (inside its context window, the amount of text it can consider at once) and reads it directly. Ask about a ten-page policy and it has every line available.

For a very large file, or a Project stuffed with reference documents, holding all of it at once isn't possible, so Claude retrieves the relevant parts on demand, a technique called retrieval-augmented generation, or RAG. It's clever and it scales, but it has a consequence worth remembering: Claude may be answering from the passages it pulled, not from a cover-to-cover read. So for a big file, a question like "does this document anywhere say X?" is less reliable than a pointed question about a specific section, and asking Claude to quote the lines it used lets you confirm it actually found the right part.

Either way, one habit carries over from Phase 0: separate your instruction from the material. Label the document, state the job, name the output format. With a big file the instruction can otherwise get lost in the noise.

The problem with numbers

Here's the trap that catches people. A model like Claude predicts text. Left to "read" a column of numbers and add them up in its head, it can produce a total that looks right and isn't, the same way a person skimming a spreadsheet might. For anything where the arithmetic matters, you don't want Claude to estimate the answer; you want it to calculate it.

That's what the data-analysis tool is for. Instead of eyeballing the figures, Claude writes a little code, runs it on the actual data, and reports what the code returned. The numbers come from real computation, not a confident guess. It's enabled by the same capability setting as artifacts (Settings → Capabilities, the code-execution toggle) and Anthropic introduced it precisely so Claude could do "mathematically accurate" work on spreadsheets. See the analysis-tool announcement. When a question involves sums, averages, counts or trends, this is the difference between a usable answer and a plausible-sounding wrong one.

Worked example: the messy Fernway sales CSV

The Fernway sales export is deliberately, realistically messy, the kind of file you actually get handed. It has inconsistent date formats (some 04/04/2026, one 2026-04-03, one 17/4/2026), region names misspelled (Sotuh, Midlnads), blank cells where a rep or a unit count is missing, at least one empty Total, and a couple of totals that don't match units times price. Start by asking Claude to audit it rather than analyse it: find the problems before trusting any sum.

I've attached our April to May sales export. Before any analysis, use the analysis tool to audit it. List every data-quality problem you find: inconsistent date formats, misspelled region names, blank cells, and any row where Units × Unit Price doesn't equal Total. For each problem, give the row and exactly what's wrong. Don't fix anything yet.

Claude runs code over the file and returns a specific list: the region typos Sotuh and Midlnads, the rows with a missing rep or missing units, the blank totals, and the rows where the maths doesn't add up (a Pro Plan row totalled at 650 when 5 × 120 is 600, and a Starter row showing a total of 49.00 when 10 × 49 is 490). Because it computed those checks rather than eyeballing them, the arithmetic mismatches are caught reliably. Now you can analyse with your eyes open.

Now analyse it with the analysis tool. First standardise the region names (Sotuh → South, Midlnads → Midlands) and recalculate Total as Units × Unit Price wherever they disagree, using the recalculated figure. Then give me: total revenue by region, total revenue by product, and the single biggest month-on-month change. Note how many rows you had to drop or flag for missing data, and show your cleaned totals in a table.

The reply now rests on computed figures and explicit cleaning rules you set. Iterate as needed ("add a per-rep breakdown", "show which region the missing-rep rows fell in") and each answer stays grounded in the actual numbers. If the result is something you'll reuse, ask for it as an artifact or a downloadable file so you're not copying figures by hand.

Before I use these figures, list the assumptions your analysis made: which rows you dropped, how you handled blanks, and anything in the data that looks suspicious or could change the totals if I decided differently. What would you double-check by hand?

Try it now

Common mistakes

• Letting Claude eyeball the maths. For anything involving sums, counts or averages, ask it to use the analysis tool. A confidently stated total that was estimated rather than computed is the classic way to end up quoting a wrong number.
• Not stating how to handle the mess. Blank cells, typos and duplicate-looking rows force a decision. If you don't set the rule, Claude sets it silently, and you won't know a chunk of rows was dropped. Say what to do with the dirty data.
• Trusting a big-file answer as if it read every line. With a very large file, Claude may be answering from retrieved passages, not the whole thing. Ask it to quote the lines it used, and prefer pointed questions over "does it anywhere mention…".
• Over-trusting computed figures because code ran. The analysis tool computes accurately, but it computes what it was told to, on data it may have cleaned in ways you didn't check. A correct calculation on wrongly-cleaned data is still a wrong answer. Read the assumptions, verify a couple of the figures against the source rows, and only then put them in front of anyone.

Keeping current

The way Claude handles files and data is evolving quickly: bigger files, richer code execution, downloadable outputs. The durable habits (audit before you analyse, make it calculate, state your cleaning rules, verify a sample) will outlast any specific button. Check the analysis-tool announcement and the Claude release notes for what's changed. Accurate as of 13 July 2026.