The text never leaves the phone

deAIfy does one thing: it takes a piece of text and removes the marks that machine writing leaves behind, the long dashes, the curly quotes, the invisible characters, the filler words. Most of that is deterministic, and it runs entirely on the phone. The optional part, asking a language model to rewrite the text to sound more human, runs only when the user pastes in their own API key, and then it runs against that user's account, not mine. Choosing on-device as the default and the model as the exception, rather than the other way round, was the most consequential product decision in the tool, and it changed three things that I did not fully anticipate.

Three things that disappear

The first thing that disappears is the leak. Text that never leaves the device cannot be intercepted, logged, retained, subpoenaed or used for training, because there is no server to do any of those things. A privacy policy for the on-device path is one sentence, and it is true.

The second is the bill. A deterministic pipeline costs nothing per use, so the tool has no marginal cost, which means it has no reason to meter, no reason to throttle, and no reason to gate features behind a subscription. The model path, when the user chooses it, is billed by their provider to their key, at whatever rate they have agreed. The tool itself never touches money.

The third is the account. There is nothing to sign up for, because there is nothing to bill and nothing to store. A tool with no account has no password database, no session tokens, no reset emails and no way to lose any of them.

What the deterministic pass actually does

It helps to be concrete about what runs on the device, because the word deterministic hides how much of the job it covers. The pass is a table of rules applied in order. The dash rules take the four Unicode dash characters that keyboards never produce and word processors and models do, and replace each according to where it sits: between two words with spaces around it, a comma or a colon depending on what follows; between digits, a plain hyphen; at the end of a clause, a full stop. The quote rules turn curly quotation marks and apostrophes into their straight forms. The invisible rules strip zero-width spaces and joiners, soft hyphens, byte-order marks and non-breaking spaces, which are the characters that survive copy and paste and mark a passage as generated more reliably than any word does. The ellipsis character becomes three full stops. The filler rules remove or rewrite a list of phrases that appear in machine prose at many times their natural rate, and the list is the part of the table that gets edited most.

Every rule is a lookup, which is why the whole pass runs in a few milliseconds on a phone and why it can be shipped inside the app. A model cannot be shipped that way at useful quality on most phones yet, and it also cannot be read. The rule table can: the entire list of what the tool changes is short enough to print, and a user who wants to know exactly what will happen to their text can read it before pressing the button. That auditability is a property of the on-device path that the model path can never have, whichever key it runs under.

What zero marginal cost is worth

It is easy to underrate the second point because the numbers per use are small. They are not small in aggregate, and a chart makes the shape clear. Take a rewrite of a five-hundred-token passage, which returns roughly the same length, and price it at three providers' small models as published in September 2026: Anthropic's Claude Haiku 4.5 at one dollar per million input tokens and five per million output; OpenAI's current small model at 75 cents and 4.50; Google's Gemini Flash tier at an introductory 75 cents and 3.75. A thousand rewrites cost between about two and three dollars, and a tool with a hundred thousand daily rewrites would carry a bill of several hundred dollars a day that it would have to recover from someone.

The chart also says why the model path is a bring-your-own-key feature rather than a built-in one. A built-in key means the tool pays those bars, which means the tool needs revenue, which means accounts, metering and a subscription, which means the three things that disappeared come back. Routing the model call through the user's own key keeps the tool at zero and keeps the model's cost with the person who chose to use it.

The egress ledger

The design decision generalises into a document I now ship with anything that handles a person's text, and I call it the egress ledger. It lists every byte that can leave the device: what is sent, to whom, under what condition, and which setting stops it. For deAIfy the ledger has one row. The text is sent to the model provider the user configured, only when the user has entered a key and pressed the rewrite action, and removing the key removes the row. There is no telemetry row, no crash-report row with text in it, no analytics row, because there is no server to receive any of them.

The ledger is useful in proportion to how honest it forces the author to be. Writing the telemetry row for a product that has telemetry means writing down that a crash report contains the text the user was editing, which is a thing many products do and few say. Writing the condition column means discovering the code path that sends analytics on launch before the user has agreed to anything. A ledger that a user can read, in the settings screen or the repository, is a promise with a checklist attached, and a ledger that exists only as a paragraph in a privacy policy is not the same document.

Where the on-device line sits

The honest limit of the design is that the on-device path can only do what a deterministic pipeline can do. Dashes, quotes, hidden characters and a list of filler phrases are rules, and rules run anywhere. Making a paragraph read as if a particular person wrote it is not a rule, and the tool does not pretend it is; that is what the model path is for, and it is why the path exists at all rather than being left out for purity. The line between the two is the line between what can be specified and what can only be judged, and the tool puts the deterministic side on the device and the judgement side behind the user's own key.

There is a middle ground opening up, which is small language models that run on the phone itself, and the day one of them can do the rewrite acceptably on the hardware most people carry, the egress ledger loses its only row. That is the direction the design points, and it is the reason the model path was built as a pluggable provider rather than a fixed one. The default is already on the device. The exception is waiting to join it.