goaldrift
Back

What we send to the model, and what we don't

23 May 2026 By goaldrift 5 min read

A sealed envelope on a plain table, addressed side down.

Any app with an AI feature is sending something somewhere. Most are vague about what, and the vagueness is doing work.

Here's the specific version for this one.

What gets sent

Only when you press unstick, and only for the goal you pressed it on.

What goes: the goal's title, its description, its steps, its blocker if it has one, and its recent notes. Plus the days-since number, because that's what the request is about.

What doesn't: your other goals. Notes from goals you didn't ask about. Anything from your timer sessions on other work. Your email address, if you have one. Any identifier that says which user this is.

The request is one goal's worth of text and nothing else. It's assembled in your browser, sent from your browser, and it isn't retained anywhere afterwards.

The scoping is deliberate rather than incidental. A feature that read your whole list would give slightly better answers — it could notice that everything stopped at once, or that two goals are competing for the same evenings. It would also mean pressing one button sent everything you've written about your life to a third party, and the marginal improvement isn't worth that.

Where it goes

To the model provider you have an account with, using your key, from your machine.

That's the part that matters most and it's a structural difference rather than a promise. In the usual arrangement, your text goes to the app company's servers, which forward it to a model provider. Two parties see it, and one of them is asking you to trust a policy.

Here there's no middle step. The path is your browser to the provider. Whatever their retention policy is applies, and it's between you and them — the same relationship you'd have if you used their product directly.

Which means the honest answer to how much of my data do you hold is none. Not encrypted, not anonymised, not retained for a period. Absent, because it never arrived.

This part isn't ours to promise, and it's worth being straight about that.

Model providers have their own policies on retention and on whether API inputs are used for training. Those policies differ, they change, and they're often different for API access than for the consumer chat product. Anyone who cares should read the current terms for the provider they're using rather than take an app's word for it.

What can be said from this side: you chose the provider, you hold the account, and you can change either. If a provider's terms become unacceptable to you, you swap the key. That's a meaningfully different position from having your text routed through a company whose provider relationship you have no say in.

What comes back

Three moves of thirty minutes or less, and a line quoted from your own notes.

The quote isn't decorative. It's a verification mechanism — if the model can't produce a line from what you actually wrote, the advice is generic, and generic advice about stalled goals is worth nothing. It lets you check in about two seconds whether the response is about your situation.

The response isn't stored anywhere except your browser. There's no conversation history, no memory between requests, nothing accumulating. Press it again next month and it starts from nothing, which is deliberate — a feature that remembered you would be a relationship, and this is a tool.

The limits of all this

The honest section, because there are things this arrangement doesn't protect you from.

Your key sits in your browser. That's better than several alternatives and it isn't a vault. Clearing site data removes it. Anyone with access to your machine and browser profile has access to it. Setting a spending cap at the provider, which most allow, removes most of the practical risk.

The text still leaves your machine. Local-first applies to your goals, not to this. If you press unstick on a goal whose notes contain something genuinely sensitive, that text goes to a third party, and no arrangement here changes that. The only complete protection is not pressing the button on that goal.

And a browser is not a secure enclave. Extensions can read what's on a page. A compromised machine is a compromised machine. Nothing about this design fixes that, and claiming otherwise would be the sort of thing this post exists to avoid.

Why be this specific

Because a log is only worth keeping if it's honest, and it'll only be honest if you know who can see it.

The most valuable entries anyone writes are the uncomfortable ones — avoided this again, three weeks now, told them it was nearly done, it isn't. Those are the notes that change something, and they're the first casualty of uncertainty about where the text goes. Given any doubt, people write blander entries, and the blander entries are useless.

So the specific version matters more than a reassuring one. You should know exactly what leaves, exactly when, and exactly to whom, so you can decide what to write and which goals to press the button on.

What's on the page and what isn't

To be exhaustive about the whole system, not just the AI part.

Your goals, notes, steps and blockers live in your browser. Nothing is sent anywhere for the app to work, and there's no account to send it to — the only way anything leaves is the export file you save yourself.

You can export everything to a file and load it elsewhere. That file never contains your API key.

And the AI does one thing on request, on one goal, with one goal's text, using your key, and then it's finished.

If any of that changes, this page changes with it. A specific claim about data is only useful if it's kept current, and a vague one was never useful at all.


Related: AI can't want it for you · Bring your own key · Local-first software, explained

Share: