What surprised me here is how unromantic the economics are. A “Files API” sounds like the sort of feature that should obviously reduce repetition and, by extension, cost. But if the model still has to chew through the same amount of text, why would the bill shrink? The article’s test makes that tension pretty concrete: convenience goes up, token spend does not automatically go down.
That’s the part I’d keep in mind if I were building with Claude. Developers often treat “attach the file” as if it were closer to storing state than to sending text. It isn’t. At least not in the way people hope. If the document is still being re-embedded into the request path, then the API is mostly saving you from copy-paste pain, not from paying for context.
The more interesting wrinkle is prompt caching. That last-minute addition is where the piece seems to find actual savings, which feels exactly right. Caching is the sort of mechanism that changes the unit economics because it changes what gets recomputed, not just how you package the same input. That distinction matters a lot, and I think a lot of people miss it when they first look at vendor features like this.
I also think there’s a quiet lesson here about product naming. “Files API” invites a storage mindset, but the underlying pricing behavior is still model-inference math. If you expect a file upload to act like a cheap pointer, you’ll probably be disappointed. If you expect it to make app code cleaner and maybe more maintainable, that sounds more plausible.
So yes, I’d try the Files API. I just wouldn’t sell it to myself as a cost optimization until I’d tested it with caching, repeated prompts, and the actual shape of my workload. That’s the boring answer, but it’s usually the real one.
Reference: Anthropic's new Files API vs. pasting: It will save you time, but it won’t save you money.
