How your file gets read is your choice, and it says where the data goes
Reading a spreadsheet and reading a contract are not the same job. One is a parser, the other needs a model. Most tools decide that for you, quietly, and you find out where your data went afterwards. SnoutData asks you, and each option says where the data goes before you pick it.
Four options, in escalation order
The parsers, on this computer. The default. Structured files are read locally by code. The data stays on your machine and no model is involved at any point. Fastest, free, and the right answer for most files.
A model on this computer. For documents the parsers refuse, a PDF of prose, say. A local model reads them on your own hardware, so the data still does not leave the machine. It downloads on demand the first time you choose it.
Our AI. The managed gateway, metered against your plan, for when the local model is not good enough and you would rather not run one yourself. Your content reaches a model through our gateway in order to be read.
A model of your own. Your key, your provider. Requests go straight from your machine to them, so nothing passes through our servers and the billing relationship is yours.
Where the data goes is computed, not written on a screen
That line under each option is not marketing copy someone typed once and forgot to update. It is derived from the route the data will actually take. Which means it cannot drift away from the truth the way a hand-written reassurance does the first time somebody changes the plumbing.
A file is never handed over whole
When a model does read something, it does not get the file. This is the part that surprised us most when we built it.
A table has a regular shape, so we sample it: the header, the first twenty rows, the last twenty. The model is not asked to read the data. It is asked how to read this table. Then the parser reads every row that way. A one gigabyte export costs one call and forty rows of exposure, and it is faster by an order of magnitude: a 120 row table read live in one call took 7.5 seconds where windowing the whole thing took a minute and a half.
A document has no such regularity, so there is nothing to generalise from. It is streamed in windows, in as many passes as it takes. There is no length at which we refuse a file.
Failing is not the same as falling back
If the reader you chose cannot do the job, we do not quietly try a different one. You picked an option partly because of where the data goes, and silently escalating to the next rung would make that choice meaningless.
So a failure is reported, and two situations are kept apart. The reader could not run at all, in which case the run stops. Or the reader could not read this particular file, in which case that file is named and skipped and the run continues.