Spreadsheet work is where many local-model questions actually start, because the data is real and the stakes are personal. This page is not a guide to prompting a model into writing your formulas. It is a task-by-task map of when a local model is the right tool and when a cloud API is, based on two factors that matter more than the model’s score: whether the data can leave the machine, and whether the work repeats enough to justify running hardware.
The two factors that decide, not the benchmark
For office work the usual “which model is best” framing misses the point. A local model either can run or cannot, and that is set by VRAM. But whether it should run is set by two other things.
Data residency. A spreadsheet often holds salaries, customer lists, or unreleased numbers. If that data cannot leave the building, a cloud API is off the table regardless of quality, and a local model on owned hardware becomes the only option that keeps the file in place.
Task volume. A single formula is a few cents on an API and free on local hardware you already own, but the local hardware still has to exist. When the same class of task runs thousands of times a month, the API bill scales linearly while the local cost flattens to electricity. Volume is what turns “local is possible” into “local is cheaper.”
VRAM sits underneath both as a gate, not a tie-breaker. It answers “can it run,” never “should it run.”
Task-by-task map
Each row names a spreadsheet task, why it is easy or hard for a model, the usual call between local and cloud, and the basis for that call. The basis, not the column, is the content.
| Task | Why it is easy or hard | Usual call | Basis for the call |
|---|---|---|---|
| Formula generation | Short input, short output, well-specified | Cloud API for one-offs | Trivial data leaves only the question, not the sheet; API round-trip is cheaper than owning hardware for rare use |
| Whole-table data cleaning | Bulk edits over many rows of real values | Local model | The sheet itself is the input and often cannot leave; running locally keeps it on owned hardware |
| Cross-sheet join and explanation | Needs long context to read several sheets | Local if memory allows, else cloud | Long context grows KV cache and VRAM; feasible locally only at the tier the hardware supports |
| Batch repetitive tasks | Same transform applied many times | Local model | Per-call API cost compounds with volume while local cost flattens; steady volume favors local |
| Error audit and trace | Needs the model to read logic, not just cells | Either, by residency | Difficulty is moderate; the deciding factor is whether the workbook may be uploaded |
| Data classification or extraction | Many small decisions over a column | Local for volume, cloud for rare | High call count pushes cost toward local; a single pass favors the API |
| Narrative from a table | Open-ended summary of findings | Cloud API | Quality gap on open explanation is wider; input can often be anonymized first |
| Live in-sheet assistant | Interactive, low latency, private data | Local model | Residency plus interactivity; latency and privacy both point away from a round-trip |
The pattern: tasks that touch the raw sheet and repeat point local; tasks that are short, rare, or need the strongest open-ended reasoning point cloud. Residency can override the volume argument in either direction.
Why volume flips the cost
Cost is the place where local and cloud trade places. A cloud API charges per token, so a task done once a day stays cheap and a task done ten thousand times a month gets expensive. A local model charges once, in hardware, and then runs the same task for the price of electricity. The cross-over point depends on call volume, model size, and electricity, not on model quality.
The token cost calculator turns a monthly token estimate into a local-versus-API comparison, and the LLM API cost comparison page lists current API prices with the update date they were pulled. The ChatGPT cost per month page breaks subscription pricing by region for the cloud side of the same decision. None of these decide residency; they only size the volume argument.
Why context length changes the local math
Several rows above depend on context, and context is where a local model’s memory budget bites. Reading three sheets to explain a join means feeding a long prompt, and the KV cache grows with that length. A model that fits comfortably for a single cell may not fit the same way when it has to hold a whole workbook in context. The context length cost page shows how the cache scales, and the KV cache size explained page covers the mechanism.
This is why “can a local model do cross-sheet work” is really two questions: can it run the model, and can it hold the context. Both are memory questions, and both are decided before quality enters the room.
Where a local model clearly wins
A local model wins on its own terms when both conditions hold: the workbook cannot be uploaded, and the task recurs. Cleaning a confidential ledger every week, classifying internal tickets by the thousand, or running a private assistant inside a sensitive workbook are cases where residency and volume line up. The model does not have to beat the frontier API; it only has to be good enough and stay on the machine.
Where a cloud API clearly wins
A cloud API wins when the data can travel and the task is occasional or open-ended. A one-time formula, a one-off explanation of a chart, or a brainstorm over anonymized summaries are cases where the API’s quality lead and zero hardware cost beat a local install. Sending a stripped, anonymized copy of the data to the API is often the practical middle path, and it is a policy question as much as a technical one.
What this page does not tell you
- It does not give step-by-step instructions for any spreadsheet software. The task is to map the decision, not to operate a specific app.
- It does not compare specific products by name or rank them. The call is made per task on residency and volume; naming winners would date faster than the reasoning.
- It does not give legal, compliance, or regulatory judgment. “Data cannot leave the building” is a statement the reader must confirm against their own policy; this page only flags it as the deciding factor.
- It does not quote token-per-second speeds. Those depend on the engine build, driver, and offload ratio, and are out of scope here.
- It does not size the hardware. Whether a given local model fits is the VRAM calculator job; this page assumes the fit question is already answered.
For the run itself, the run locally hub links the full set of pages, and the local LLM hardware guide covers memory budgets without purchase advice. The privacy page states how this site treats data, and the about page explains the editorial stance behind these comparisons.