Privacy
What we send, and what we keep.
This page was written by reading Fetchi's source code, not by filling in a template. It describes what the software actually does today. Where the honest answer is unflattering, it is written down anyway. How to check Fetchi lists the promises you can test yourself on your own Mac.
The short version
- Fetchi is not an on-device assistant. To answer you, it sends what you said to our server, which passes it to Anthropic's Claude or OpenAI's model. Not yet: moving the rest onto your Mac is what we are building toward. Until it ships, this page says what leaves your Mac today.
- Your wake word and speech-to-text run on your Mac. Realtime conversation, a separate lane that streamed audio to OpenAI, is switched off from 0.2.5 (build 107). On a Mac that can't recognise speech by itself, Apple's speech servers also hear any other turn you speak rather than type.
- Our server is a metering layer, not a memory. It stores no prompt, no transcript, no screenshot. There is no database column anywhere in it that could hold one.
- Things Fetchi remembers about you live on your Mac, in two places you can open: a folder of
plain markdown,
~/Fetchi Brain, and one unencrypted SQLite file for settings, receipts and the memory index. The folder is yours; relevant content from it can accompany a model request, and a short summary of who you are (never an address or a number, never health, money or beliefs) goes with every request to Claude. - By default Fetchi also sends window titles and on-screen text with each request.
Set
BURRI_SEE_SCREEN=0to stop that; there is no Settings control for it yet. Local storage does not mean local processing: relevant saved memories and recent conversation go to the model answering you. - The realtime voice lane is switched off from 0.2.5 (build 107), for every plan: your raw microphone audio no longer streams through our server to OpenAI. In earlier builds that lane is on by default on a paid plan and does stream it. This page said the opposite until 12 August 2026, which was wrong, and until 19 September 2026 it also said that audio skipped our server, which it never did.
What we collect, and what we do not
Plainly, because the rest of this page is detail and this is the part you came for. Fetchi runs in two places — your Mac, and a small server we operate — and they collect very different amounts. The server collects the minimum needed to know who you are, to meter what you spend, and to bill you. It does not collect what you say or what is on your screen.
What our server collects, why, and how long we retain it
| What we collect | Why | Retention |
|---|---|---|
| Your email address, and an account token | To have an account at all, and to reach you about it | Until you ask us to delete the account |
A usage ledger: which model ran, how many tokens moved, what it cost,
when, and which allowance it drew against. One row per request. For work that is
not a model request, that first column names the action instead — a connected-app
action is written as composio: and the action's own name, so a row can read
composio:GMAIL_SEND_EMAIL; a call is twilio-call, verifying your
number is twilio-callerid, a web lookup is web:lookup, and every
text in either direction adds a row. Never the words, the recipient or the result —
the name of the action, and what it cost |
To meter the plan you bought and stop the month at the cap | Until you ask us to delete the account |
| Your plan, your credit balance, your Stripe customer id, and — once your first subscription event arrives — the date your plan next renews | To sell you a plan, to honour credit you bought, and to be able to tell you when you are about to be charged again | Until you ask us to delete the account |
| Push-notification endpoints, if you connect the phone companion | So a notification can reach that phone. Nothing is registered unless you pair one. | Until you unpair, or the push service reports the device gone |
| For each phone you pair: a device key, a label naming the device, and when it was added and last used | So a phone can act for your account without ever holding the account's own token, and so that one phone can be cut off on its own | Until the account is deleted. A phone that is unpaired, revoked, or unused for a month stops working at once. |
| A phone number, only if you give one: the number you verify for calling, kept in full and unhashed; and for Text Fetchi, a keyed hash of your mobile number and its last four digits, not the number | So a call Fetchi places shows your own number, and so an incoming text can be matched to your account | The calling number until you remove it in Settings; the texting hash until you unpair or text STOP. One trace of a texting number outlives both: a number that texted before it was paired, or that texted STOP, leaves its keyed hash on a list we keep for good, so a stranger hears the how-to-pair line once ever and a STOP stays honoured. That list has no account column and deleting your account does not clear it |
| Four product event names with tiny counts — app launched, onboarding step, onboarding complete, active today — only if you opt in | To know whether people come back. The server rejects any event name outside those four. | Until you ask us to delete the account |
| If you invite a friend: a keyed fingerprint of their mailbox, never their address; their address masked to its first letter and its domain (d***@company.com), which only your Home screen shows; which account invited them, when, whether the email went out, and whether they have signed up | So your Home screen can list who you invited and count your invites, and so that nobody is invited twice, by you, by another Fetchi user, or from the waitlist | For good, so nobody is invited twice. If you delete your account, your link to each invite and the masked address go, and only the fingerprint stays. See Inviting a friend |
| Historical website visits: one of three event names, the page path, the referring site's hostname, and a visitor digest — your IP address and browser string hashed under a secret that changes every day | To know whether anyone visited and whether the download worked, and to count one visitor once a day rather than once a page | Kept indefinitely. The digest is the only visitor-shaped thing in them: the date is inside the key, so the same person's rows from two different days cannot be matched to each other, by us or by anyone holding the database, and no row carries an account. That is also why there is nothing in them we could find to delete on request. |
| Standard web-server access logs: IP address, path, status code | Every web server writes these; ours is not special | As long as our host keeps them |
What we do not collect, and structurally cannot. Our server processes your requests without retaining them. There is no prompt, no transcript, no reply, no screenshot, no window title and no memory stored on it — not as a policy we are promising to follow, but because there is no column in the database that could hold one. We also never receive your card number (Stripe collects it, and there is nowhere in Fetchi it could be typed), your passwords for connected services (Composio holds those tokens, and a mail app password stays in your Mac's Keychain), or the contents of your local Fetchi database.
Three claims worth checking rather than trusting
- Your speech is turned into text on your Mac, in the default configuration — by a local Whisper model. From 0.2.5 (build 107) there is one exception: on a Mac that can't recognise speech by itself, Apple's speech servers, which hear any turn you speak rather than type. Builds before it have a second: the realtime voice lane, which is on by default on paid plans there and streams your audio to OpenAI. Both are described in full below, and they are the reason this bullet says "in the default configuration" rather than "always".
- Screenshots are not retained on your Mac or on our server. On your Mac the
capture is written to a temporary file, encoded, and the file is deleted in the same function
that made it. Our server passes it on and has no column that could hold one. It is sent to
Anthropic or OpenAI, depending on the model handling the turn, and their retention governs from
there.
Until 18 September 2026 this bullet said "Screenshots are not retained anywhere." For
one lane that was wrong. When Fetchi drives your screen through OpenAI's model, test
builds of 0.2.2 before build 89 sent each step as a continuation of the one before and never
told OpenAI not to store it. OpenAI therefore kept each step, screenshot included, so that the
next step could refer to it: 30 days by default, under OpenAI's terms rather than ours. None of
those builds was ever public. Every public build with this lane, from 0.2.2 (build 89) on,
carries the task's history itself and marks every step
store: false, which ordinary requests to OpenAI already did. Steps the test builds stored stay with OpenAI until its retention runs out. Nothing in Fetchi deletes them sooner. - Usage telemetry is off unless you turn it on. The onboarding privacy step defaults to Privacy Mode; with no explicit choice the app sends nothing. Opting in is an act, not a default, and the Settings switch overrides whatever you picked at onboarding.
Who we share it with
We do not sell your data and we do not share it for advertising. It reaches the companies listed under the companies that handle your data, each for one job, and the public websites and data services described in the note beneath that list. Until 18 September 2026 this paragraph ended "and nobody else" while that list left several companies out. They are on it now.
What stays on your Mac
The wake word
Fetchi's microphone is open continuously when the wake word is enabled, which it is by default. Every audio frame is scored on your Mac against a local model to decide whether you said the wake phrase. Nothing is transmitted during this. The module that does the listening imports no networking library of any kind — it can score audio and hand it to the rest of the app, and that is the entire set of things it can do. Audio frames that do not trigger the wake word are discarded in memory and never written to disk or sent anywhere.
The one exception is a one-time download: on first run Fetchi fetches the pretrained wake-word model files. That is a download of model weights to your machine, not an upload of anything from it.
If you would rather the microphone not be open at all, turn the wake word off and use push-to-talk
(hold ctrl+option). Fetchi then hears nothing until you hold the key.
Your Mac's own Calendar
Fetchi reads the calendars Calendar.app holds — iCloud, a Google account added to Calendar.app, Exchange, On My Mac — through Apple's EventKit, on the Mac. For the window you asked about it reads each event's title, its start and end, the name of the calendar it is on and which account that calendar belongs to, so the answer can say where it looked. It deliberately does not read the notes field or the attendee list: notes are where people keep door codes and dial-in PINs, and an attendee list is other people's email addresses.
macOS asks for this the first time: System Settings → Privacy & Security → Calendars. Refuse, and Fetchi says it cannot see that calendar rather than saying you are free. Fetchi asks once which calendar you use (or uses the only one it can see) and keeps your answer in fetchi.db on this Mac only; the setting itself is never uploaded or synced, though the calendar's name appears in Fetchi's replies like any other answer. To tell which of your calendars you use, it counts your events on each calendar that takes events over the last and next 30 days, on this Mac: only the counts are kept, for five minutes, and nothing about those events leaves the Mac. Corrected 28 September 2026: this said the answer “is never sent”, and did not name the count.
For a question, Fetchi reads the events inside the stretch of time you asked about; on its own it reads only for the looks named here (the 30-day count that learns which calendar you use, setup's tomorrow, the clash looks and the morning brief).
Setup's tomorrow (app/onboarding_setup.py, added 28 September 2026). On
setup's email and calendar step, once a calendar you picked there is live, Fetchi shows you tomorrow:
up to three of tomorrow's event titles and start times, and which calendars it read. Nobody asks for
this read; it happens because you are on that step. Your Mac's Calendar is read on the Mac, and only if
macOS already allows it. A Google Calendar you connected on that step is read from Google through
Fetchi's server, as one connected-app action: Fetchi's server keeps only the action's name in its usage
ledger, as for every connected-app call, and meters it against your plan like any other. It is read at
most once every ten minutes while the step is open, the answer is kept only in memory for those ten
minutes, and it shows under Connected apps in What left this Mac. A calendar that could not be read is
named as unread, never shown as an empty day.
Adding an event (app/calendar_write.py, app/calendar_choice.py).
Fetchi adds an event only when you ask it to: one event, on the calendar you told Fetchi you use. It
asks you once (or uses the only calendar it can see) and keeps the answer in fetchi.db on this Mac;
change it in Settings → Permissions → Your calendar, or just tell it. On a calendar in your
Mac's Calendar app the write happens on your Mac and is read back before Fetchi says it was added; the
write sends nothing to Fetchi's server. Until you have picked a calendar, an add may first ask Fetchi's
server which apps you have connected, so it can tell whether a Google Calendar is there; that request
carries nothing about the event. On Google Calendar through a connection, the event goes from this Mac
through Fetchi's server to Google, behind the same card — or without it if you turned on Act
without asking → Calendar, or if your own sentence gave the event's title and time with Ask
before acting off (the default). If Fetchi chose the time, it shows you a card first; Act without asking
→ Calendar lets that one go without its card too, on either calendar. If it wrote the event from
something it read this turn (an email, a page, a text), it always shows you a card first.
It never invites anyone from here, and it does not move or cancel an event through EventKit.
Clash warnings and the brief's calendar line (app/watchers.py,
app/brain_triggers.py, app/calendar_choice.py). While Proactive check-ins is
on, Fetchi looks at the next 12 hours of your calendar every 30 minutes during active hours, for events
that clash or are about to start, and the morning brief reads your calendar to say what is on today.
Your Mac's Calendar is read on the Mac. A calendar server set up with your mailbox (CalDAV, in the table
above) is read from this Mac on each of those looks, and shows under Calendar in What left this Mac.
Google Calendar is read too only if you chose it as your calendar: today's and tomorrow's event titles
and times then come from Google through Fetchi's server at most once every three hours, and the looks
in between reuse that read. Each such read is one connected-app action: Fetchi's server keeps only the
action's name in its usage ledger, as for every connected-app call, and meters it against your plan
like any other. These reads show under Connected apps in What left this Mac. The scheduled end-of-day
digest reads the same, except that while you have not chosen a calendar it also reads a connected
Google Calendar, as it always has. A calendar you switched Off in App access is never read. To stop the
looks, say “stop warning me about calendar conflicts”, or turn Proactive check-ins off.
Corrected 28 September 2026: this paragraph did not name the calendar server or the
cost of a Google read, and a Google read happened on every look.
A calendar question Fetchi recognises is answered from these sources with no model call at all. That does not mean the events stay on the Mac: when Fetchi speaks the answer in its own voice, which is the default on an account, the sentence, event titles and times included, goes through our server to the text-to-speech provider (OpenAI, or ElevenLabs), like every spoken reply; choose the Mac's built-in voice in Settings and it is spoken on the Mac. On a live-voice turn, which only builds before 0.2.5 (build 107) have, the events go to OpenAI's realtime model as its answer. Google Calendar is the exception and works as it always has: it is read through Composio, over the network, when you have connected that account — and a calendar question the local reader does not recognise still goes to the model the ordinary way.
Your notes
When you ask about your notes (“what did I write about the lease?”), Fetchi asks the Notes
app on your Mac, read-only (app/notes_read.py): a search returns at most 20
notes, each cut to a short excerpt, and opening one note by name returns at most 4,000 characters of it.
Only that answer goes to the model, and it is marked as other people's words, because a shared note can
hold someone else's writing: a send composed after it waits for your yes on a card. Nothing is written
to Notes by this, and it only runs on a turn you started. Set Notes to Off in Settings →
Connections and it reads nothing.
Your messages
This is off until you turn it on, in Settings → Connections → Read
my Messages. While it is off Fetchi reads nothing from Messages, and will not read it off your
screen either. With it on, when you ask what someone texted you, Fetchi reads Messages' own database on your Mac
(~/Library/Messages/chat.db) read-only: the file is opened so it cannot be
written to, only lookups are run, and it is never copied or uploaded. What goes to the
model is only what answers the question: the messages with the person you named (at most 30), the latest
line of each recent conversation (at most 20), or the messages containing the words you searched for (at
most 20), each cut to 300 characters, with the sender and the time. If you have already allowed
Contacts, a sender's name from Contacts is shown in place of their number: Fetchi looks up only the
numbers and addresses in that answer (at most 25), one by one, on your Mac, and never asks for Contacts
to do it — the same goes for the end-of-day digest's list of who texted and for the members of a
group chat you name. On a live-voice turn, which only builds before 0.2.5 (build 107) have, that model is OpenAI's realtime one. Fetchi treats those lines as someone else's words: sending a reply always waits
for your yes on a card (so does a draft reply, when Fetchi picked who it is for), a file is never opened
on their say-so, and a message written as orders to an assistant puts a warning on the next card.
To send to a group chat you name (“tell the family chat I'm late”), Fetchi looks the group
up in the same database, read-only and only with this switch on — its name, its service and who is
in it, no message text — and the card names the group and every member before anything is sent.
If anyone joins or leaves the group before your yes, nothing is sent (app/messages.py).
Text your Mac
This is off until you turn it on, in Settings → Connections → Text
your Mac, and it needs Read my Messages on and Messages set to Read and act. While it is on,
Fetchi looks at your own thread with yourself in Messages every 2 seconds and answers what you text
yourself from your iPhone, in that same thread (app/imessage_door.py). iMessage carries
those texts between your own devices, end-to-end encrypted by Apple; our server is not
in that path. What it reads: the words of only that thread, only its iMessage rows,
and only rows newer than the moment you turned it on — or last chose which of your addresses it
watches, or turned Read my Messages back on: never another conversation's words, never an SMS (its
sender can be spoofed) and never older history. To find that thread it also reads, every 30 seconds,
Messages' list of chats and addresses, and — when you switch it on, open its Settings pane or
choose an address, and every 30 seconds while none is chosen — the columns Messages keeps for
this Mac's own addresses: metadata, never a message's words. Your thread is the one whose only member
is exactly your own address (country code and all), never one typed in.
Where your texts go: a text that asks for something goes to the model through our proxy exactly like a typed request, and nothing new is stored on our server. A YES or NO to a card is settled on your Mac, with no model. A text held back goes nowhere: past 30 texts in an hour, a text longer than 8,000 characters, or one that reaches your Mac more than 12 hours after you sent it is not acted on, and the thread is told why.
Cards: a card that needs your yes is texted to you in full, the way the Mac's card shows it, with a three-digit code for that one card — except when one request raises two cards at once, when a card is too long for a text (3,000 characters), when it would delete something from Fetchi's memory, and, rarely, when Messages can't be read just then; those wait at your Mac. Only “YES” and that code, sent after the card, approves it; a code is not handed out again within the next 50 cards, the code dies with the card after ten minutes, a new card replaces the old one and says so, and the card can still be answered at the Mac, where whichever answer comes first wins. A card from Fetchi's own forget (a page or a fact in its memory) is never texted, and a forget Fetchi asks you about is answered at the Mac; any other card the thread shows, a screen task included, is approved by its code like the rest.
What it sends: its answers, to your own address, each ending in three invisible
characters that mark it as Fetchi's own; the door ignores a text carrying them, and a text with the
words of one of its answers dated within minutes of it. While it is on, Fetchi's Messages tool refuses
to send a message to that address. That is the whole guarantee: anything else that puts words into
that thread — you, or an action you approve on a card that drives Messages itself — reads
as your request. Turning it on checks with Messages, so macOS asks then, once, for permission to
control Messages if it has not been given; the answers are sent by Messages, not as a request of
Fetchi's own, so they do not appear in What left this Mac. Kept on your Mac only, in
fetchi.db: the switch; your address; where in Messages' database it started, and when;
whether it is paused (Read my Messages off); a fingerprint (a hash, never the words) of each text it
sent you in the last day and of the last 20 it answered, so it never answers itself or one text twice;
the times of the last hour's texts; the codes of the last 50 cards, so none of them is handed out
again; and for the waiting card its row, card id, code, a fingerprint of the stored action, its title
and its verb (once answered, only its code, title and what became of it). The words
themselves are kept in the receipts: each text of yours it takes — answered, or held
back by the hourly limit or its length — and each one it sends you leaves a receipt on your Mac
with its words, in Settings → Activity → What I did. Texts it ignores (its own answers
coming back, a second copy of one text, an SMS in the thread, anyone else's words) leave none.
Drafts you ask for
“Draft a reply to Sam” opens that conversation in Messages and puts the text in its box, on your Mac, then reads it back. Nothing is sent: the text waits in the box until you send it yourself, and a box that already holds words you have not sent is left alone. An email draft, when you have set up your mailbox in Settings → Connections → Mail, is saved by your Mac straight into your own mail server's Drafts folder over IMAP and looked up there once to confirm it arrived; it is never handed over for sending, and nothing of ours is in between. A draft asks first only when Fetchi picked who it is for after reading someone else's words; then one card names them, and its yes writes the draft and nothing more. Sending it afterwards is a separate yes.
Message text is not kept in Fetchi's memory unless you ask for that in your own words. The answer Fetchi gives is kept like every reply, in the day's conversation page on your Mac, in the part deleted after 14 days.
macOS guards that database with Full Disk Access and shows no prompt for it. Turning the switch on, or the first question after it, opens System Settings → Privacy & Security → Full Disk Access for you to switch Fetchi on; a question does not open the page again for ten minutes, and never on a turn you did not start. Turn Read my Messages off, or switch Fetchi off in Full Disk Access, and nothing can be read.
What Fetchi may do in each app
Settings → Connections lists Mail, Messages, Calendar, Notes, Reminders, Files and every connected
app, each set to Off, Read only or Read and act. Every
app starts at Read and act, which is what Fetchi did before these switches existed; Messages starts with
sending on and reading off (Read my Messages, above), and choosing a level for it moves Read my Messages
too. The switch is enforced by Fetchi's own code, not by asking the model: at the one door every tool call
passes, before a screen takeover's card is drawn, at every click and keystroke on the screen, and again
when you approve a card. Read only: Fetchi can still read the app, but it will not send,
change or delete anything in it. Off: Fetchi will not read it or act in it; with Mail off
the inbox watch stops reading mail, and Fetchi does not capture the screen while an app that is off is in
front, nor read that window's text. The background checks obey Off too: with Mail off the bill and
urgent-mail checks read nothing, and with Calendar off the check for clashing events, the morning calendar
line and a phone call's scheduling context read nothing from it. Cards still apply on top of Read and act. The switches are stored on this Mac only, in
fetchi.db, and are never sent to Fetchi's server. The shell and code tools have their own
switches and are not covered by these.
Questions your Mac answers by itself
What time it is in a named city, the offset between two places, how many days until a date, and unit conversions are arithmetic, not judgement. Fetchi works them out on your Mac from a time-zone table and does not call a model, so the question and the answer never leave the machine. It declines rather than guesses: an unknown or ambiguous place gets a question back, and currency is refused outright, because a wrong world fact is not a miss but a false statement. Weather is answered the same way — locally, from the keyless public forecast services named below.
Turning your speech into text
Speech-to-text runs on your Mac using a local Whisper model. In the default configuration, on a Mac that can recognise speech by itself, the audio of your voice never leaves the machine — only the text it becomes does, and only then as part of a request you triggered.
One exception on some Macs, added 25 September 2026. In any turn you speak rather than type — holding the talk key, pressing Talk or its keyboard shortcut, or speaking after the wake word — the Mac app also draws a live caption of what you are saying with Apple's own speech recognizer; every one of those turns opens the same capture. Holding the talk key while a request is still running opens it too (added 26 September 2026): what it hears is used only to decide whether you said “stop”, “cancel” or “never mind” as the whole sentence — if you did, that request stops, and anything else is dropped, never a request of its own. Fetchi asks for it to run on the Mac wherever macOS can do that; on a Mac, or in a language, where it can't, macOS sends that turn's audio to Apple's speech recognition servers, under Apple's terms. The wake word itself never does: it listens on the Mac or not at all, though on such a Mac the sentence you say after it goes to Apple like any other spoken turn. The local Whisper model still transcribes the same audio on your Mac, and its text is used whenever it is ready in time. This request is not in What left this Mac, because macOS makes it, not Fetchi. If you would rather it never happened, type instead of speaking.
Words to expect, added 26 September 2026. So that names come out right, the
recognizers are also given a short list of words to expect (at most 100), built in the background on
your Mac from exactly these: the assistant's name, alone and after "Hey"; your own name (the one you
gave Fetchi, and your Mac account's full name); names of people, projects and places from your Brain
(page titles, aliases and the spellings you corrected, from its 200 most recently changed pages); the
sites you named yourself when you asked Fetchi to open them, and that opened (the browser's front tab
then showed that address): only an address you said or typed in full, such as dripwriter.com, as a
word of its own — a name alone like “Dripwriter” does not count, nor a piece of a
longer name, and an address whose ending has two parts, like .com.co or .co.uk, is left out altogether
(at most 15, kept in Fetchi's database on your Mac; never a site Fetchi chose, never a link read out of
an email, a page or a text: each is an address you said yourself); the names of the apps on this Mac;
and twelve brand names: Gmail, Slack, Notion, Figma, Spotify, Chrome, Safari, Xcode, GitHub, Claude,
ChatGPT, Zoom. Your Contacts are not in it. The full list goes only to recognition that runs on your
Mac: the local Whisper model, dictation, and a spoken turn wherever macOS can recognise it on the Mac.
The wake word is given the assistant's name only. What the wake word answers to, 27 September
2026: “Hey”, “OK”, “Okay”, “Hi” or “Hello”
before the assistant's name, or the name alone as the first word you say (“Fetchi, can you
…”), judged on your Mac. Each judgement is one line in wake.log in Fetchi's folder
on your Mac: which of those shapes it was, how far the heard word was from the name and how far it may be,
and a line when the microphone changes. Never a word you said and never audio; the file stays on your Mac,
is capped at 256 KB and is sent nowhere. On a Mac, or in a language, where macOS can't
recognise speech on the Mac, the recognizer is given the assistant's name, alone and after
“Hey”, and up to 50 app names (the twelve brand names above and the apps on this Mac) as
hints, and nothing else, and those go to Apple with that turn's audio. The list is never sent to
Fetchi's server. A recognizer told to expect a word can write it where a similar one was said: in
testing, a spoken “quillmart.io” came out as a listed “quillmate.io”. Outside
a live voice session, Fetchi never rewrites what was heard: the words it acts on are the recognizer's,
shown in the caption, apart from a leading address such as “Hey Fetchi,” (and an “um”
before it), which is dropped before the words are acted on, typed or spoken alike.
The exception until 0.2.5 (build 107), and it was a big one. This page used to describe it wrongly, twice. Fetchi had a realtime voice lane: your raw microphone audio streamed off your Mac over a websocket and speech came back as speech. While it ran, the paragraph above stopped being true — your voice itself left the machine, not just the text of it.
From 0.2.5 (build 107) that lane is switched off, for everyone (the founder's decision of 27 September 2026). The Mac app opens no realtime session and sends no turn to one: every spoken turn is turned into text as described above, answered by the model, and read out by the one text-to-speech voice. Its code is still in the app, dormant, behind a developer switch that a shipped app ignores. The rest of this box is true of the builds before it.
That audio goes through our server. Until 19 September 2026 this page said the lane skipped our proxy and your Mac dialled OpenAI itself. That was true of the app up to 0.2.0 and of builds 61 to 63; it is not true of the builds after them. There the Mac asks our server for the socket, opens it to our server, and our server relays every frame to OpenAI on our key. It is a pass-through: it reads each frame only far enough to count it for billing, keeps no audio, and writes none of it to a log or to the database. But we are in the path, which is exactly what the old sentence told you we were not.
Until 12 August 2026 this page said that lane was "off by default and has to be deliberately switched on". That was not true of the app we shipped. In the downloaded app, until 0.2.5 (build 107), the lane defaults on, and it runs whenever the account is on a paid plan and signed in. It is the default voice for conversation on Pro and Max in those builds. A free account never reaches it, and a build using your own Anthropic key defaults it off.
We would rather correct this loudly than quietly. If you do not want your audio going to OpenAI on a build before 0.2.5 (build 107), update, or turn the realtime voice lane off in Settings, and Fetchi falls back to on-device speech-to-text — the same ladder it uses when the lane is unavailable for any other reason, with the one exception above on a Mac that can't recognise speech by itself.
What leaves your Mac, and who receives it
Fetchi's default setup routes model traffic through a proxy server we run, rather than having your copy of the app hold an Anthropic key. Here is everything that goes out, in the default configuration of the packaged app.
| What | Goes to | When |
|---|---|---|
| The text of what you said, plus relevant saved memories and recent conversation, and, for 15 minutes after Fetchi has used your Mac's location, your town's name | Our proxy → Anthropic (Claude) or OpenAI: the turns that act on your Mac or the web, and the ones that read your screen, go to Anthropic's Claude by default and to OpenAI's GPT-6 Astra only as the backup, when Claude errors or times out twice partway through a task that drives your screen. An OpenAI model receives the request in full whenever one is handling the turn | Every request that needs the model |
| Name of your frontmost app, its window title, the text of that window read via macOS accessibility, a list of the windows on your screen, and the names of the apps you have open (names only, from macOS's process list) | Our proxy → Anthropic or OpenAI, depending on the model | Attached to every request, so Fetchi knows what you are looking at |
| Screenshots of all attached displays | Our proxy → Anthropic or OpenAI, depending on the model | Only when your wording is visual ("what's this?") or asks Fetchi to operate the machine. Not on ordinary requests, and skipped entirely when a password, banking or sign-in screen is in front. |
| The screen-takeover check: the sentence you said, and one fixed question about it (“should this take over the screen?”). No screenshot, memory, conversation, app or window name, and nothing over 1,000 characters. Your Mac's activity log keeps only the answer (the choice, its probability, how long it took, which road was taken), never the sentence | Our proxy, and onward only if we have turned this route on, to exactly one of OpenAI (its Decisions API), TypeSafe (its Jev model) or OpenRouter (Jev, through OpenRouter). It is off by default: until we choose a provider on our server, the request is refused before it is read and goes nowhere. Our server keeps a cost row and no content | Off by default: nothing is sent. Only if it is switched on to measure is it asked, when Fetchi is about to take over your screen for a sentence without a model having chosen to, and then the answer is only measured and changes nothing; a stricter mode, also off by default, lets a confident “no” send the sentence to the ordinary model instead. Never for a scheduled job |
| The control pick: while Fetchi drives your screen and has decided to click something, the step in the screen model's own words (“the Reply button”, at most 300 characters), the name of the app in front, and for up to 255 of the front window's controls (120 while our server is set to OpenAI) their kind, their name and where they are on screen. A control's name can be private: an email in a list is named by its sender and subject. Never a screenshot, the task you asked for, anything typed in a text field (a field is named only by its label or placeholder) or a password field, and nothing at all from a window with a password field or from a screen Fetchi will not look at (password managers, banking and sign-in pages, a locked screen, an app you switched off). Your Mac's activity log keeps only numbers (whether the pick matched the click, its confidence, how long it took, how many controls), never a name or the step | Our proxy, and onward on the same terms as the screen-takeover check: only if we have turned this route on, to the one provider we chose (OpenAI, TypeSafe or OpenRouter). Off by default on our server: until then the request is refused before it is read and goes nowhere, and your Mac asks again only after half an hour. Our server keeps a cost row and no content. On 14 October 2026 we chose OpenAI for this, for faster screen control: once our server is set to it, the names and roles of on-screen controls (with the step's words, the app's name and, from builds up to 153, each control's size and position) go through our server to OpenAI's Decisions API, which only picks one of them. Our server keeps none of those words, in no table and no log line. While it is set to OpenAI, a window with more than 120 controls is refused at our server and goes no further, and the step goes on the usual way | On by default for screen-driving steps that click. At first it only checks its answer against where Fetchi's screen model clicked and changes nothing; only after it has agreed on at least 90% of 30 clear steps on your Mac may it stand in for a slower lookup, and every click it aims still goes through the same approval rules and cards. It goes back to only checking by itself if its agreement drops. You can switch it to checking-only or off |
| The intent check: when a task reaches the point where Fetchi decides whether taking over your screen needs your approval, the task as Fetchi worded it for the screen (it can repeat words that were on your screen), and two fixed questions about it (“does it only read, or act, or both?” and which of the kinds of act that always ask for your approval it involves — money, a message, a deletion, a call, a password, a security setting, a public post and the like). No screenshot, memory, conversation, app or window name; nothing over 1,000 characters; never a task written after Fetchi read someone else's words (an email, a web page, a file), and never a scheduled job's. Your Mac's activity log keeps only the answer and numbers (the kinds it chose, how sure it was, whether it agreed with Fetchi's own rules, how long it took), never the sentence. It decides nothing: no approval card, road or answer changes because of it | Our proxy, and onward only if we have turned on both the route and this check on our server, to the one provider we chose (OpenAI, TypeSafe or OpenRouter). Off by default on our server: until then the request is refused before anything is forwarded, and your Mac asks again only after half an hour. Our server keeps a cost row and no content | On by default for every task that reaches that point, in the background after Fetchi has already decided, so it never slows a task. It only measures how often a model and Fetchi's own rules agree. You can switch it off |
| A short summary of who you are, drawn from your brain: your name, the people and places you have told Fetchi about, what is coming up — at most 1,600 characters, never an email address or phone number, never health, money, beliefs or legal matters | Our proxy → Anthropic (never the OpenAI voice session) | With every request to Claude |
| One day of your own lines, once a night, to write a short note on the day and pick out facts and dated promises you stated — each one checked on your Mac before anything is saved | Our proxy → Anthropic | Only while consolidation_model_tier is switched on in
~/Fetchi Brain/settings.json, and it is off unless you turn it on. Off, the
nightly pass runs entirely on your Mac and sends nothing. |
| Your turn, in a separate background request to identify facts worth remembering | Anthropic through our proxy when hosted, or a local model when local-only thinking is set | When background memory extraction is enabled. It does not wait for a separate question
about memory. BRAIN_MODEL_EXTRACTION=0 disables that extraction request. |
| The text of Fetchi's spoken replies | Our proxy → OpenAI or ElevenLabs (text-to-speech, whichever our server is set to use) | Every time it speaks, unless you switch to the built-in macOS voice |
| A research request: your words, the searches planned from them, and text from the public pages read. Your Mac downloads those public pages itself, so those sites see its IP address; it sends no cookies and no logins, and nothing from your memory is added. The report is saved on your Mac, in your Fetchi Reports folder in Documents | Our proxy → Anthropic (Claude and its web search); on the Mac, also the public websites the search found | Only when you ask for research or a report ("research…", "compare…", "write me a report on…") |
| Raw microphone audio | Our proxy → OpenAI. Our server relays the frames on our key and keeps none of the audio; it reads each frame only far enough to bill it. Builds up to 0.2.0, and builds 61 to 63, dialled OpenAI without us in the path | Only in the realtime voice lane, which is switched off from 0.2.5 (build 107). In earlier builds it is on by default on the paid plans (never on Free): turn it off in Settings, or update. |
| Whatever a connected account's action requires | Composio, then that service | Only if you connect an account, and only for actions you approve — or, for a kind you switched on under Act without asking (off by default), actions you asked for — and, if you chose Google Calendar as your calendar, the background calendar read under “Clash warnings and the brief's calendar line” (today and tomorrow, at most once every three hours, while Proactive check-ins is on) |
| When you ask about your email and have set up your mailbox in Settings → Connections → Mail: the sender's name and address, subject, date and a preview of up to 160 characters of each message Fetchi read. The app password is kept in your Mac's Keychain and is never sent to a model, to us, or to anyone but your mail server | Your Mac signs in to your mail server directly over IMAP, with nothing of ours and no Composio in between, and opens the inbox read-only; the previews then go to the model that answers, through our proxy → Anthropic or OpenAI. The exact request "read my email" is answered with no model at all, and when the realtime voice reads your mail out itself it is given the sender's name only (that voice exists only in builds before 0.2.5, build 107) | Only when you ask about your mail. Without a mailbox set up, a connected Gmail is read through Composio, then Apple Mail on your Mac. Remove the account in Settings to stop |
| When you ask for someone by name: the cards in your Contacts that match it, at most 8, each as its name, email addresses and phone numbers, plus the addresses you have said yes to mail at that match it. A call to a name puts that card's name and number on the call card and in what the model reads back. In an answer about your messages: a sender's name from Contacts in place of their number. Your address book is read on your Mac, in two ways only — the cards matching a name you asked about, and the cards matching the numbers and addresses in an answer about your messages (at most 25, and only once you have already allowed Contacts; this second way was not listed here before 26 September 2026) — and is never copied or uploaded. Phone numbers were added on 25 September 2026; until then only names and addresses were sent | Our proxy → Anthropic or OpenAI, the model that answers (on a live-voice turn in a build before 0.2.5 (build 107), OpenAI's realtime one) | Only when you ask to email, text or call someone by name, or for their details, or when you ask about your messages with Read my Messages on (then only the senders in that answer). Never the whole book. Don't allow Contacts when macOS asks, or switch Fetchi off in System Settings → Privacy & Security → Contacts, to stop |
| The rows a question to your own database returns (at most 200, long values cut). The connection string itself is kept in your Mac's Keychain and is never sent to a model, to us, or to anyone but the database it opens | Your Mac connects to your database directly, with nothing of ours in between; the rows then go to the model that answers, through our proxy → Anthropic or OpenAI | Only if you add a database in Settings, and only when you ask about it. Reads run read-only, enforced by the database; a change is never run without your yes to the exact statement |
| A phone call you ask Fetchi to place: the number to call, what the call is for in your words, your name, and, when the call is to book something, the times and titles of up to twelve upcoming calendar entries so it can book around them | Our proxy → Twilio, which dials the number, shows your own verified number as the caller, turns what the other person says into text and speaks Fetchi's replies; and our proxy → Anthropic, which is given the purpose, your name, those calendar entries and the running transcript to decide what Fetchi says next | Only when you ask for a call and then confirm it; Fetchi never dials on its own say-so. It works only after you have verified your own number in Settings, and only where our server has been given Twilio credentials. Otherwise the server refuses and nothing is dialled. |
| Text Fetchi, if you turn it on: your mobile number, and the words of every text you send Fetchi and every text it sends you | Twilio, then our proxy, then your Mac, and back the same way. Our server reads each text in order to pass it on and stores none of them. It keeps your number only as a keyed hash and its last four digits. | Off by default. It needs the switch in Settings turned on, your number paired from the Mac, and a Fetchi texting number set on our server. Without that number the server answers as though the feature did not exist. |
| Text your Mac, if you turn it on: the texts you send yourself in Messages on your iPhone, and Fetchi's answers to them | Apple's iMessage, between your own devices, end-to-end encrypted by Apple; our server is not in that path. Your Mac reads the words of only your own thread with yourself and hands its answers to Messages for your own address. A text that asks for something becomes a request to the model through our proxy, exactly like one you type; a YES or NO to a card is settled on your Mac with no model; nothing new is stored on our server. | Off by default. It needs Settings → Connections → Text your Mac turned on, Read my Messages on, and Messages set to Read and act. |
| A friend's email address, when you invite them from the Home screen; and, in the email itself, your own account's address, which the invite names as who asked | Our proxy → Resend, which emails your friend one invite from invites@fetchi.ai. Our server keeps a keyed fingerprint of their mailbox and a masked address, never the address itself (Inviting a friend) | Only when you invite someone from the Home screen's invite card, one address at a time |
| A check for bills and urgent mail: the sender and subject of mail from the last two weeks whose subject mentions a bill, invoice, payment or autopay, and of unread mail when the new-mail check is off. With your mailbox set up in Settings, your Mac reads headers only, with no preview at all | Your own mail server, from your Mac over IMAP, when you have set up your mailbox; otherwise Composio, then Gmail. Nothing is sent to a model | Every half hour between 8am and 10pm. A bill is mentioned at most once a day. Say "stop telling me about bills" to turn that part off. |
| The end-of-day digest: the sender's name (never the address) and subject of up to 25 of today's emails, headers only; the time and title of up to 16 events today and tomorrow (on its schedule: your Mac's Calendar, your calendar server, and Google Calendar if you chose it — or, while you have not chosen a calendar, if it is connected); the titles of notes changed today and of reminders done today or overdue (up to 15 each), never a note's text; and, only while Read my Messages is on, who texted you today and how many, never a message's text. All of it is read on your Mac. Asked for by name ("what happened today"), those lines and which sources were and were not read go in one short request, marked as other people's words, with nothing from your memory; the line naming what was and was not read is written by your Mac, not by a model. Fetchi treats every line as someone else's words, exactly as it treats an email it has read | Your own mail server over IMAP, or Composio then Gmail; your calendars as above; Notes, Reminders and Messages on your Mac; our proxy → Anthropic for the one request | When you ask. The scheduled digest is off until you pick a time in Settings → Permissions → End-of-day digest; then once a day. A paired phone hears only that the digest is ready on your Mac, and a digest said while nobody is at the Mac never puts a permission prompt on your screen. |
| A check for new mail: who sent each new message, its subject, Gmail's short preview, its labels and a handful of headers — never the message itself. With your mailbox set up in Settings, your Mac reads headers only, with no preview at all. For a stranger's mail that sounds pressing, the sender's name and email domain, the subject and the preview of up to five messages at a time | Your own mail server, from your Mac over IMAP, when you have set up your mailbox; otherwise Composio, then Gmail (the check); our proxy → Anthropic (deciding whether a stranger's mail matters) | Every five minutes between 8am and 10pm, only while your mailbox is set up or Gmail is connected. The deciding step is capped at twelve requests a day and carries nothing from your memory. Say "stop keeping me updated about new mail" to turn it off. |
| Where your Mac is — a coarse position, latitude and longitude rounded to two decimal places (about a kilometre) before anything is done with it, and the town name that comes back for that rounded point | Apple (the town name), then Open-Meteo (the forecast) | Only when you ask something that needs it — "what's the weather", with no city named, including in a task you set to run later or on a schedule. macOS asks your permission the first time, and if you say no Fetchi uses the city you tell it instead. The Mac is never asked for its position at launch, and never by Fetchi's own background work: the morning brief, the rain watcher and the check-ins only reuse a position one of your questions was given. The position is never written to disk. For 15 minutes after, the town's name goes with every request to the AI model, background check-ins with nobody at the Mac included, and the rain watcher reuses the rounded position for its forecast check, as does the morning brief. |
| Your IP address, in exchange for a coarse latitude and longitude | ipapi.co, then Open-Meteo | The rain watcher is on unless you turn it off ("stop giving me weather alerts"): every 30 minutes from 8am to 10pm, with nobody at the Mac, it checks the forecast for where your Mac is. With no position saved or held, it looks your IP address up and saves the rough position on your Mac; after that only Open-Meteo is asked. A lookup that fails saves nothing, so it is tried again at the next check until one succeeds. Within 15 minutes of a weather question that used your Mac's own position, it uses that rounded position instead. Until 25 September 2026 this page said the lookup waited for a weather watch you set up; the watcher runs whether or not you ever ask about rain. |
| The weather line in the morning brief: this Mac's rounded position, if one of your questions was given it in the last 15 minutes; otherwise the name of the city you told Fetchi, or your time zone's city | Open-Meteo (a name goes to its place lookup first, then the forecast), and the National Weather Service for a point in the continental US | Once a day with the morning brief, with nobody at the Mac, and only when what Fetchi has learned of your mornings includes checking the weather. It never asks the Mac where it is. Quiet mode ("be quiet") skips the brief. Until 25 September 2026 the brief did ask the Mac for its position, which a question of yours open at that moment could turn into the macOS Location prompt, and this page did not list it. |
| The ticker symbols you asked about (for example AAPL), in a plain request with no account, key or cookie | Yahoo Finance, straight from your Mac, which sees your Mac's IP address | Only when you ask for a stock quote |
| A YouTube video's address, or the words you asked to search YouTube for. Your Mac fetches the video's page information and its captions; no video is downloaded | YouTube, straight from your Mac | Only when you ask about a YouTube video or ask to find one |
The repository, issue, pull request or search you asked about, through GitHub's own
gh program on your Mac, read-only commands only. If you have already signed in with
gh auth login, that session is used; Fetchi never holds a GitHub token |
GitHub, from your Mac | Only when you ask about GitHub, and only if gh is installed |
| Your calendar, over CalDAV: with your mailbox set up in Settings → Connections → Mail at a provider that serves its calendar that way (iCloud, Fastmail, Yahoo and others; not Google), your Mac signs in with that app password, kept in your Mac's Keychain, reads your events for the dates asked about, and moves one only after your yes on a card — or when you ask, if you turned on Act without asking for Calendar | Your own calendar server, from your Mac; nothing of ours in between | When Fetchi reads your calendar (a question about it, the agenda, the end-of-day digest, the morning brief's calendar line, and — while Proactive check-ins is on — the look for clashes and events about to start, every 30 minutes during active hours; added 28 September 2026), or moves an event you approved (or asked it to move, with Act without asking on for Calendar). Set Calendar to Off in Settings to stop it; say “stop warning me about calendar conflicts” to stop the half-hourly look |
| The requests a turn makes to a tool server you added yourself: the tool's name and the details the model chose for it, which can include words from your request, and the server's list of tools | The address you entered for that server (one that runs as a program on your Mac sends nothing over the network) | Only when a turn uses a tool from a server you added. Switch one off or remove it in Settings → Connections |
| Nothing of yours: a request for one connected app's icon picture | The address the connected-apps catalogue gives for that icon | Not in this build: the code exists and records itself on the "What left this Mac" card, but nothing calls it yet. When it is used, each icon is fetched once and kept on your Mac |
| The text of each message Fetchi delivers to you (reminders, nudges, the results of background work), posted to a direct message from a Slack bot | Slack | Only when your Mac is configured by hand with a Slack bot token and your Slack user id; the app you download has neither, so this is off |
| Nothing of yours: a request for the list of releases and, when you choose to download one, the release file itself | fetchi.ai (served by Vercel) for the list; Cloudflare R2 for the release file. Like any web server, each sees your Mac's IP address | The update check: at most once a day, never on the first launch, and whenever you choose Check for Updates in the menu. The download: only when you press Download… on an update. The daily check has no switch in Settings today |
| Nothing of yours: requests for model files your Mac does not have yet — the hand-gesture model, the wake-word model files and the speech-to-text model | Google's storage for the gesture model; GitHub for the wake-word models; Hugging Face for the speech model | Once each, the first time the feature that needs it runs; nothing is fetched again once a file is on your Mac. Every build up to and including 0.2.5 (build 98) broke that for the speech model: at every start, Fetchi asked Hugging Face whether a newer version of the speech model existed, even with the model already on your Mac, and at most once a day the Hugging Face library also fetched its own list of AI coding tools; neither carried anything of yours, and the builds that have “What left this Mac” listed them only as “Not labelled yet”. Fixed in the code on 25 September 2026: the model is loaded from your Mac without asking anyone, only a missing model is downloaded, and that download is listed as “One-time downloads” |
| One History entry you report: when, how you asked, the app, your words, Fetchi's answer and what it did — nothing else from your Mac, no version and no other request | Your own mail app, as a draft to team@fetchi.ai. Fetchi sends nothing itself | Only when you press Report this (the flag) on an entry in History, and only if you then send the draft yourself |
Storage, recall and model requests are different. Your brain is a folder you own. Fetchi searches it locally and sends relevant results with requests that need a model. Background extraction may also send a turn to a model to identify facts. Disabling that extraction does not remove memory context from ordinary requests.
Remote embedding uploads have been removed from the current code, including the old opt-in. Recall uses local embeddings when available, otherwise word matching, which can miss a match phrased differently. That change does not make model requests local.
Older builds are the exception, and this page did not say so until 18 September 2026. Every build up to and including 0.2.0, released on 15 August 2026, sends the text of each saved memory and each recall query to our server to be turned into an embedding, unless a local embedding model is running on the Mac. Our server passed that text to OpenAI, or to Voyage AI when it held a Voyage key; production never held one. Builds made from 24 August 2026 on send it only if an opt-in was set, and builds made from 8 September 2026 on cannot send it at all. That route is now closed. Since 19 September 2026 it answers every request with a refusal, without reading the body it was sent and without calling any provider, and the forwarding code and the Voyage key are gone rather than switched off. An old build loses its semantic recall and falls back to matching words, which is what it already did whenever our server had no embedding key. What those builds uploaded before the door shut is with OpenAI under its retention, not ours.
What left this Mac
The table above says what can leave your Mac. Settings → Privacy & control → What left this Mac shows what did, today and over the last 7 days, grouped by purpose in plain words. Each entry is five facts and nothing else: the purpose, the server's name, how many requests, how many bytes went out, and whether something you asked for caused it. Never the words, addresses, subjects or pages themselves.
The list is kept on this Mac only, for 8 days, and is never sent anywhere. Clear this list on the card empties it. Out of the box it is a record, not a gate: it never blocks, delays or changes a request.
Allow, Ask or Block — your choice, per purpose. On the same card, each purpose can be set to Allow (the default, and what Fetchi has always done), Ask or Block. The check is made before the request is sent, in the one place every part of Fetchi writes itself down, and a test fails if any part sends before it asks. Block: the request is never sent, and Fetchi keeps a REFUSED receipt on this Mac that says why (Settings → Activity → What I did). A tool Fetchi was using for you opens its answer with that sentence, and a quick answer, like the weather or a stock price, opens with it too. Ask: a server that purpose hasn't been allowed to reach asks you on a card, the same card every other approval uses, one card per server at a time; until you say yes, nothing is sent and the request fails, saying so. That includes work in the background with nobody at the Mac: the card waits for you and the background request fails at once — it never waits for your answer. Its question goes up on a card of its own, which never replaces or joins a card you are already looking at. Two kinds of background request put up no card and fail, saying why in What I did: one made while three background questions already wait on their cards, and one to a server you said no to on its card, within the ten minutes after that card went up; a request of yours asks again. A request of yours never puts its question up beside another of your cards still waiting on your answer: the question either replaces that card, or isn't put up and Fetchi says so; background cards stay where they are. A yes allows that server until Fetchi quits; “always” remembers it on this Mac, and Forget these answers removes them. A Block you set later still wins. Ask before anything new leaves is off unless you turn it on: then a server that isn't already in the list asks first, even on a row set to Allow. Ask and Block are checked when a connection opens: one already open when you change the setting, like a page the background browser is loading, carries on until it closes, and the next one is checked. A paired phone's live line is checked at every frame, so it stops at the next one: nothing more is sent to the phone or heard from it, and the line closes. One row is a note rather than a request: A place Fetchi sends things was changed names the new server, or the program a tool server now starts, with no requests and no bytes, whenever your mail or calendar server, a tool server, or where the model runs is changed: by you in Settings, or by something other than Fetchi, which Fetchi also tells you about when it starts, when the list of tool servers changes while it runs (before a new or changed one is first started), and when a change you save in Settings finds one you didn't make. It can't be set to Ask or Block, because nothing is sent.
What can't be held, said next to each such row: your requests to the AI model can't be blocked — Fetchi can't work without them — and neither can signing in and checking your plan. The requests the Mac app makes itself (the update check and download, the premium voice, live voice, Apple's town-name lookup) are listed only. A page Fetchi opens in a browser window it drives is checked at its own address, not at every image and script it then loads; Fetchi's background browser is checked at every site it connects to. Nothing here changes what Fetchi's server keeps: the choices and the answers stay on this Mac.
How it knows every request: each place in Fetchi's code that can reach another machine writes itself down, and a test fails when a new one appears that does not; the Mac app's own requests (the update check and download, the premium voice, live voice, Apple's town-name lookup) write themselves down too; and a catch-all inside the engine lists any connection no part of Fetchi has named yet, as “Not labelled yet”, with the server's name.
What it cannot see. It counts what Fetchi itself sends. Fetchi's background browser is listed by every site it connects to; a page Fetchi opens in a browser window it drives is listed as that one site, not every image and script the page then loads; a page Fetchi opens or moves to in your own Chrome is listed the same way, by its site. Another program Fetchi hands something to — your own browser opening a link, a Terminal command you approved, a local model server fetching a model — makes its own requests, and those are not listed. On a Mac that can't turn speech into text by itself, macOS sends what you say in any turn you speak rather than type (the talk key, the Talk button or its shortcut, or the wake word) to Apple's speech recognition servers; macOS makes that request, not Fetchi, and it is not listed.
Fetchi for Chrome (off unless switched on, and in no shipped build yet): when Fetchi works in your own Chrome, each page it opens there, or moves to on a new site, is listed once, as “Pages Fetchi opened or acted on in your Chrome”, by the site's name. Chrome fetches those pages itself. The extension talks only to the Fetchi app on this Mac, over a private local connection, and to nothing else. The AI model is shown what it is shown of any page Fetchi reads: the address and title, up to 60 of the page's controls by the page's own names for them, and the page's text when it reads it. A password, card, code or birthday field's contents are never shown, only “(filled)”, and the only tabs it can list are the ones Fetchi opened. The switch is Settings, “Use my Chrome”, off by default: turning it on writes one file into Chrome's own settings folder, which tells Chrome where Fetchi's helper is and lets only Fetchi's extension start it, and turning it off removes that file.
Found while building it. Checking every one of those places turned up requests this
page had not named, all of them only on your request or your configuration: stock prices (Yahoo
Finance), YouTube captions and search, GitHub reads through your own gh login, a CalDAV
calendar server you set up, tool servers you add, app icons from the connected-apps catalogue, a
Slack workspace when a Slack bot token is configured, the update check (fetchi.ai) and the update download (Cloudflare R2, where the release file is hosted),
and one-time model downloads (the hand-gesture model from Google's storage, wake-word models, the
speech model). Each is now a named purpose on the card and a row in the table above.
Your notifications
Fetchi does not read your notifications. It never opens macOS's notification database, never asks the system for the notifications you have received, and never reads Notification Center's windows through Accessibility; the list of open windows it reads skips the processes that draw notifications. A test fails if any of that changes. The one honest exception: a screenshot is a picture of the whole display, so a banner that happens to be on screen when you ask “what's on my screen?”, or while Fetchi drives the screen for you, is in that picture like anything else on the display.
Fetchi's own notifications. From 0.2.5 (build 105) on, the Mac app posts macOS notifications of its own, for these moments only: a task you left running finished or stopped, a reminder or timer you set came due, something is waiting on your yes, and — during setup — voice training failed after you had moved on to another step. It posts one only when nobody seems to be at the Mac — no keyboard, mouse or voice for a minute, or the screen locked — because otherwise the notch is already showing it (the setup message is the exception). A notification says what happened, in a few words (“Background task 3 is done. Open Fetchi to see the result.”), never what a task found, what a page said or what a message says; a failure names its cause in Fetchi's own words; a reminder or timer carries the words you set it with; a waiting yes carries only the kind of card and its question (“New Email — Send this?”), never who it is to or what it says; the setup message is written to the Activity log instead of said. What Fetchi said in full stays in the app: clicking the notification opens Fetchi and puts it back on the notch, and it is never handed to macOS. A notification goes to Notification Center on this Mac and nowhere else; macOS keeps it there until you clear it, and shows it on the lock screen if your notification settings allow. When the question is answered or expires, Fetchi removes that notification by its own id, and never posts one for a question already answered; it never reads one back, and none has a button that does anything but open Fetchi — the card is still the only yes. A proactive check-in or suggestion is never posted as a notification. macOS asks permission once: in setup (the optional Notifications row on the permissions step), or — if you skipped it or set Fetchi up before this build — the first time Fetchi promises to tell you something later or has news, or from Settings → Permissions → Ask macOS. Turn them off in Settings → Permissions, under Mac notifications, or in System Settings → Notifications → Fetchi.
What our server stores
The proxy exists to meter usage and bill it, so that you do not have to hold an API key. It is a pass-through. It stores no prompt, no transcript, and no image.
That is a claim about structure rather than a promise about behaviour. Until 19 September 2026 this paragraph said "here is every table" and then named about a dozen of them. Here is the whole schema, grouped. Your account: the account row; the usage ledger; opt-in product events; the build and, if you opted in, the coarse Mac profile. Reaching you and your devices: push-notification subscriptions; two tables for pairing a phone; the number you verified for calling and the rate limiter for verifying one; three for Text Fetchi — your paired number as a keyed hash, a pairing code, and the list of unpaired numbers described above. Credentials: a salted hash of any sign-in or account-deletion code asked for and not yet used (ten minutes, then gone); the extra tokens a sign-in code can mint; retired tokens pointing at their successor; and what Stripe and OpenAI call your account. Limits that have to outlive an account: wrong-guess counters per mailbox, and the free-trial fingerprint described under deletion. Teams: the team, its members, its invitations, and who took a seat recently. Invites: who has been invited to Fetchi, by a friend or from the waitlist, as a keyed fingerprint of each mailbox, with the masked address a Home screen shows. Money: Stripe webhook ids already applied, checkout references, which plan you are on, subscriptions, top-ups, reversals, revenue banked, website purchases that granted nothing, and, only if we switch on the card-required trial of Pro, which subscription your trial is on and when it began. Bookkeeping: which stored OpenAI response your account made, as a hash of your key and a token count; website visit counts and the one key-value row that counter needs; and an audit log of manual admin actions. That is thirty-six tables and not one of them has a column capable of holding message content. When a request comes in, the body is forwarded to the selected model provider and the reply is streamed back; the only thing written down is a row saying how many tokens moved, on which model, at what cost, at what time. Streamed replies are passed straight through and read only far enough to count tokens.
The same is true of the other routes, with two exceptions described next. Text-to-speech records the number of characters spoken, not the words. Realtime audio does pass through the proxy from the builds that still open that lane (those before 0.2.5, build 107), and until 19 September 2026 this page said it did not. Such a Mac opens the websocket to our server and our server relays every frame to OpenAI on our key. It counts the frames to bill them and keeps none of them: no audio is written to the database, to a log, or to disk.
A phone call is the one route where words stay on the server for longer than a request. While a call Fetchi places for you is running, its transcript is held in the server's memory so that your Mac can fetch it and show you what was said. It is never written to the database. A finished call's transcript is dropped five minutes after the call ends, a call that never ended is given up on, and the number of calls held at once is capped. Until 18 September 2026 there was no such expiry and a finished call's transcript stayed in that memory until the server next restarted. Texts to and from Fetchi are handled the way requests are: our server reads each one in order to pass it on and stores none of them.
A paired phone, and what the relay can and cannot read
Pair a phone and it talks to your Mac through our server. Those frames are sealed end to end. The key is made on your Mac and travels in the part of the pairing link that browsers never send to a server; your Mac and the phone hold it and we do not. Everything that rides that channel — what you type or say to the phone, the Mac's replies, its screen, the taps and keys of remote control, your approvals, and the saved memories the two of them sync to each other — is encrypted before it leaves and decrypted after it arrives. Our relay forwards ciphertext. It can see that a frame passed, how big it was and which devices are talking; it cannot read a frame, change one, or make one up. It can drop frames, and against a Mac speaking only the older of the two wire versions it could replay one.
Three things a phone does are not sealed, and we can read all three. They are ordinary requests to our server, protected by TLS like any website and by nothing more.
- Asking a question while your Mac is away. There is no Mac to seal it for, so the phone sends the question, up to the last twenty messages of that conversation, and up to 8,000 characters of the memory the phone keeps, to our server, which puts them in a prompt and sends it to Anthropic. We keep one row saying which model ran and what it cost, and none of the words.
- Having a reply read aloud. When the phone's voice is on, the text of the reply is posted to our server to be turned into speech — including a reply that arrived from your Mac inside the sealed channel, which leaves that channel for this one step. Up to 1,200 characters per utterance. We count the characters and keep no words, and the audio is returned with instructions not to cache it. Turn the phone's voice off and it uses the device's own voice instead, and nothing is sent.
- A notification. On Fetchi builds after 0.2.4 (build 97), your Mac encrypts the notification to your phone browser's own key before sending it, so our server passes on bytes it cannot read. Builds through 0.2.4 (build 97) post the title and body to our server in the clear, and our server does the encrypting. This is described in full under nudges below.
What the iPhone app reads on the phone
The Fetchi iPhone app answers four kinds of request with the phone's own data, and asks iOS for each permission only the first time you ask for something that needs it, never at launch: contacts ("text Mom"), calendars ("what's on tomorrow"), reminders ("remind me at 5") and location ("what's the weather here"). Contacts, calendar events and reminders are read and written on the phone and are never sent to your Mac, to our server or to any AI. A text opens in Apple's Messages app, addressed to the person you named, and goes only if you tap Send there. An agenda is shown on the phone and read aloud in the phone's own voice, never ours. A reminder is saved to your Reminders list.
The weather is the one of the four that needs the outside world. The phone takes one approximate location fix, Apple's geocoder turns it into a town name, and only the town's name goes with your question: to your Mac inside the sealed channel, or, with no Mac, to our server and on to Anthropic like any other question. The location itself is not kept, and we keep none of it.
What the server does log
To be accurate rather than flattering: the proxy does write operational logs, and they are not empty. They record account identifiers, email addresses on signup, plan changes, model names, costs, and — through the standard web-server access log — the IP address, path and status code of each request. No log line contains the content of a message, a transcript, or a screenshot. We checked every logging statement in the server to be able to write that sentence.
Onward to Anthropic, OpenAI, ElevenLabs and the decisions providers
Once your request reaches a model provider, their policies govern it, not ours. Here is what our server tells each of them, as the code sends it, and what their published terms say they do.
- Anthropic (your requests, research, phone calls). Our server calls Anthropic's API with our key. Anthropic offers no per-request "don't keep this" setting; its published API terms say it does not train models on API data by default and deletes API inputs and outputs within 30 days, longer when a request is flagged under its usage policy. We have no zero-retention agreement with Anthropic.
- OpenAI (the backup screen-driving model, spoken replies, and the live voice in builds
before 0.2.5, build 107). OpenAI's
terms say API data is not used for training by default and is kept up to 30 days for abuse
monitoring. Its screen-driving API also stores each response for 30 days unless told
not to: every public Fetchi build tells it not to (
store: false). Spoken replies and the live voice have no such setting. We have no zero-retention agreement with OpenAI; that needs OpenAI's approval. - OpenAI, TypeSafe or OpenRouter (the screen-takeover check, the control pick and the intent check, only while we have turned the route on and pointed it at exactly one of them; off by default in the code, and the intent check also needs its own switch on our server. Our server has it on and pointed at TypeSafe as of 15 October 2026; on 14 October 2026 we chose OpenAI for the control pick, which takes effect when our server is switched to it). What goes is, for the check (off by default on your Mac as well), the one sentence and a fixed question; for the pick, the step's words, the app's name and the names and positions of the front window's controls; for the intent check, the screen task's sentence and two fixed questions. None carries a name, account or session field. OpenAI's general API terms apply to its Decisions API as far as we can tell (a public beta, on its one model, GPT-6 Luna); we have not verified that API's own retention terms. TypeSafe says it does not train on API inputs, and offers zero retention only to enterprise customers. OpenRouter passes the request to the model's host under its own terms and theirs, which we have not verified. We have no zero-retention agreement with any of them.
- ElevenLabs (the premium voice). ElevenLabs has a zero-retention mode, but only for enterprise accounts; ours is not one, so our server does not ask for it. The code sends it once the account is enterprise and the setting is switched on.
If you would rather our server were not in the path at all, you can paste your own Anthropic key in Settings (under Advanced); Fetchi then talks to Anthropic directly on your key and your terms with Anthropic.
The companies that handle your data
Every outside company that touches any part of this, what each one gets, and what it is for. If a company is not on this list or in the note beneath it, it does not receive your data from us.
| Company | What it gets | What for |
|---|---|---|
| Anthropic | Your request: what you said, relevant saved memories, recent conversation, window titles and on-screen text, and screenshots when the request is a visual one or Fetchi is driving your Mac or the web; your town's name for 15 minutes after a location fix | The model that answers you, reads your screen when you ask about it, and by default drives your screen |
| OpenAI | Your request and its relevant saved memories and recent conversation when an OpenAI model handles the turn, with your town's name for 15 minutes after a location fix; the text of spoken replies; in the realtime voice lane of builds before 0.2.5 (build 107), your raw microphone audio; screenshots of the display Fetchi is driving, when Claude errors or times out twice partway through a task on your Mac or on the web and OpenAI's model takes over as the backup, for the rest of that task. In test builds of 0.2.2 before build 89 (never public), OpenAI also stored each of those driving steps, 30 days by default; the correction is under three claims worth checking. From builds up to and including 0.2.0 only, the text of saved memories and recall queries, to be turned into embeddings. Only while our server's decisions route is turned on and set to OpenAI (it is off by default in the code; we chose OpenAI for the control pick on 14 October 2026, and it applies once our server is switched to it): the sentence you said when Fetchi was about to take over your screen, and a fixed question about it, only if that check is switched on (it is off by default on your Mac too); while Fetchi drives your screen, the step's words, the front app's name and the names and positions of the front window's controls; and, only while the intent check is also turned on on our server, a screen task's sentence and two fixed questions about it | Reasoning, the speaking voice, realtime speech (builds before 0.2.5, build 107), driving the screen as the backup, and the screen-takeover check, the control pick and the intent check when they are set to OpenAI |
| TypeSafe | Only while our server's decisions route is turned on and set to TypeSafe (it is off by default): the sentence you said when Fetchi was about to take over your screen, and a fixed question about it; while Fetchi drives your screen, the step's words, the front app's name and the names and positions of the front window's controls; and, only while the intent check is also turned on on our server, a screen task's sentence and two fixed questions about it. Nothing else of yours | Its Jev model answers whether that sentence should take over the screen, which control a step means, and whether a task only reads or acts |
| OpenRouter | The same sentence and question, the same control-pick details and the same intent-check sentence and questions, only while the route is turned on and set to OpenRouter (off by default) | Passing the question to Jev, which answers it |
| ElevenLabs | The text of spoken replies, when our server is set to use ElevenLabs for Fetchi's voice. Our server uses ElevenLabs or OpenAI for this, never both | The speaking voice |
| Twilio | Only if you use calling or Text Fetchi. To verify your number for calling: that number, which Twilio rings so you can key in a code, and which stays on our Twilio account's list of verified caller IDs until you remove it in Settings. For a call Fetchi places for you: the number being called, your verified number as the caller ID, and the audio of the call. Twilio turns what the other person says into text for our server, and speaks Fetchi's replies in an ElevenLabs voice that Twilio calls itself. Fetchi does not ask Twilio to record the call. For Text Fetchi: your mobile number and the words of every text in either direction | Carrying the call or the text. Neither works unless our server has been given Twilio credentials, and Text Fetchi is also off until our server has a Fetchi number to text from and you turn its switch on in Settings. Without those the server refuses the request and nothing reaches Twilio. What Twilio retains is governed by Twilio's own privacy notice. |
| Stripe | Your card details and billing address, which you give directly to them — they never pass through us — plus your email address and which plan you bought | Taking the payment, holding the card, and running the page where you cancel. We store the customer id they give us; we never see a card number. |
| Railway | Everything our server holds, because they host it: the account database described above, and the server's access logs | Running the proxy and storing its database |
| Vercel | Your IP address and browser user-agent when you load this website, as any host would see; aggregated page views and download, signup and pricing events; and, if you join the waitlist, the stored waitlist record | Serving this website, Web Analytics, and holding waitlist signups |
| Cloudflare (R2) | Your IP address when you download the app, as any download host would see | Serving the Fetchi download itself |
| Composio | The authorisation token for any account you connect, and whatever an action you approve (or ask for, with Act without asking on for its kind, or say in full with Ask before acting off) needs to send | Connecting outside services without Fetchi holding your passwords |
| Resend | Your email address, if you join the waitlist — or if you ask for a code, either to get back into an existing Fetchi account or to confirm deleting one, in which case the six-digit code rides in that email too. If you invite a friend, their email address, and yours, which the invite names as who asked | Emailing the founder that you signed up, and emailing you your invite when there’s a spot; emailing you a one-time code you asked for, and a notice to your account's address when a new sign-in uses one; emailing a friend the invite you asked us to send |
| Slack or Discord | Your email address, if you join the waitlist and a chat webhook is configured | Posting the signup to a channel of ours |
| Google, Apple, Mozilla or Microsoft, as your phone's push service | Only if you have paired a phone for notifications: the push address that phone's browser registered, when each notification is sent, and roughly how large it is. The text is encrypted to keys that stay in the phone's browser, so the push service carries it and cannot read it. On builds after 0.2.4 (build 97) your Mac does that encrypting, so our server cannot read it either; on builds through 0.2.4 (build 97) our server does it, so our server can read it | Delivering a notification to your phone. Which company depends on the browser that registered: Google (FCM) for Chrome and most Android browsers, Apple for Safari and iPhone home-screen apps, Mozilla for Firefox, Microsoft for Edge on Windows. Our server sends to no other push host. |
| Apple | A coarse position — latitude and longitude already rounded to two decimal places, about a kilometre — and nothing else, when you ask Fetchi something that needs to know where you are. From the iPhone app, the phone's approximate location, only when you ask about the weather here. And, on a Mac that can't recognise speech on the Mac itself, the audio of any turn you speak rather than type, which macOS sends to Apple's speech recognition, with the assistant's name, alone and after “Hey”, and up to 50 app names (twelve brand names and the apps on your Mac) as hints | Turning that rounded point into a town name, so Fetchi can say "Berkeley" rather than a pair of numbers; and turning that audio into a live caption of what you are saying |
| Open-Meteo | Either that same rounded position, or the name of whatever city you asked about, or the position the rain watcher checks every 30 minutes from 8am to 10pm, or, for the morning brief's weather line, the position a question of yours was given in the last 15 minutes or else the name of the city you told Fetchi or your time zone's city — and no account, no key and nothing that identifies you | The actual weather. It is the free, keyless forecast service Fetchi asks. |
| National Weather Service (weather.gov) | That same rounded position, and nothing else — no account, no key, nothing that identifies you — when the point is inside the continental United States | The temperature a real instrument last measured, rather than a forecast model's guess at this hour. Outside the US, Open-Meteo's own numbers are the answer. |
| ipapi.co | Your IP address, when the rain watcher (on by default) runs with no position saved or held, in exchange for the coarse latitude and longitude it then saves and reuses: once, if the lookup succeeds; at each check until it does | Working out roughly where to watch the weather for |
| Brave Search, Ecosia, Mojeek | Search words, when a question asked from your phone while your Mac is away needs something looked up on the public web. The search is made by a browser running on our server and signed in to nothing, so the search engine receives the words and our server's address, not your phone's address or your account. Brave is tried first, then Ecosia, then Mojeek | Looking something up for a phone question your Mac is not there to answer. It runs only when our server has a browser installed, and on 18 September 2026 the production server did not. Nothing from a lookup is stored. |
| PostHog | Only from the older phone companion web page, the one you set up by pasting a token copied from Settings. That page carries PostHog's analytics script. The events our code sends through it are: the page being opened for the first time, and again on each later day it is opened (with the dates first and last seen and a count of days); a chat turn being sent, as a running count and not the words; and notifications being connected, with the device label you typed. PostHog's script also records what it records by default, which includes page views, your IP address and browser details, and it is set to keep a profile for every visitor id, held in that browser's storage and a cookie. Our code never hands it your email address or account token | Counting whether people come back to that page. In the source as it stands the PostHog key is an unfilled placeholder and the loader stops before it contacts PostHog, so this applies only to a hosted copy of that page that was given a real key. The Mac app, the iPhone app, this website and the phone remote page contain no PostHog code. What PostHog retains is governed by PostHog's own privacy policy. |
| Voyage AI | Nothing, and nothing in the past either. It is on this list because the server route that builds up to and including 0.2.0 used to index memory would have sent that memory text to Voyage AI had the server ever held a Voyage key. It never did, so that text went to OpenAI instead | Nothing now. That route is closed and the Voyage key was removed with it; the note under what leaves your Mac has the dates. It stays named here so the list does not quietly lose a company it once would have reached. |
What this list is not. It names the companies Fetchi and our server send your
data to as part of how the product works. It does not name every website. When Fetchi opens or
reads a page for you, when a skill it has learned queries one of the keyless public data services
it is allowed to use, or when it downloads a model file, that site receives your Mac's IP address
and the request itself, as any site you visit does. Nor does it name a service of your own that you
point Fetchi at — your mail or calendar server, a tool server you added, GitHub through your own
gh login, a Slack bot you configured: each receives what the table of
what leaves your Mac says, and nothing more.
Until 18 September 2026 this list left out Twilio, the push services, the three search engines, PostHog and Voyage AI, while the sentence above it said that a company not on the list received nothing from us. That was wrong.
Two of these are worth a sentence more. Stripe is where your card actually lives: the checkout and the billing page are theirs, not ours, which is why there is no screen in Fetchi where a card number could be typed and no field in our database that could hold one. Railway hosts the server and therefore holds the account database — so "our server" throughout this page means a server running on their infrastructure.
Fonts and scripts are served from this website's own origin. Vercel processes the website analytics described below.
Counting visits to this website
Vercel Web Analytics collects page views and three events: download_click
with device type (Mac or phone), waitlist_submit with signup location
(hero, footer, download instructions or phone), and pricing_view.
A signup event records a successful response, not your email address.
These are aggregated statistics. They include the page path, referring site, time, browser and operating-system information, device type and coarse location. We remove query strings and fragments from the page URL before sending it, and send no form text, email addresses or checkout codes in custom events. No cookies are used. Vercel derives a visitor hash from the request and discards the visitor session after 24 hours; it does not retain an identifier for tracking you across websites. Vercel's analytics data policy describes its processing.
Do Not Track and Global Privacy Control suppress page-view and custom-event collection. The previous counter sent event name, page path and referring site hostname to our Railway server. Its historical rows remain there without IP addresses, user-agent strings, cookies or account identifiers; this page no longer sends that beacon.
What is stored on your Mac
Everything Fetchi remembers is on your machine, in two places. The things it learns about you —
people, projects, preferences — are written as plain markdown pages in ~/Fetchi Brain,
a folder you can open, edit and delete with Finder. Beside it sits a single SQLite file for the
machinery. We have no copy of either and no way to reach them. The SQLite file holds tables covering: things you said you would do, saved memories,
receipts of actions taken, pending actions waiting for your approval, reminders, scheduled jobs, price
watches, errands and the evidence gathered for them, settings, and local usage and spend counters.
Inside the brain folder, a hidden .fetchi folder holds the bookkeeping: counts of what was
learned, how well each fact is known (without its words), how Fetchi's nudges landed (never their
text), and two short lists that do hold words until they are settled — names waiting to be
checked with you, and possible facts waiting for more evidence. Delete it and Fetchi loses its
rankings, never a fact.
Notes you add to your brain (added 27 September 2026). A .md or
.txt file you drop on the Brain page, or pick with Add notes…, is
copied into ~/Fetchi Brain/sources/ — the folder the brain keeps for files you
imported — under its own name (never over another file: a second notes.md becomes
notes 2.md), at most 1 MB a file and 50 files at a time. A hidden
sources/.added-by-you.json beside them records each one’s original name, the day you
added it, and whether it reads like instructions written to an assistant. Adding a note sends
nothing anywhere: nothing is extracted from it, no model reads it to file it, and it never
syncs to your phone (only facts on your brain’s pages do). Fetchi finds a note on this Mac, in
its local index, and only when a request of yours asks it to look through your memory; then the
matching lines go with that request to the model, like any other line of your brain, labelled as your
note’s text and never as instructions, and everything Fetchi would do after reading them waits on
a card, exactly as after reading an email. Delete the file in Finder to remove it.
Say “forget” and name it — “forget where I work” — and after one yes
it is removed from every one of those files, from the recall index, from the database, from the
conversation and from the day's record; the diary in log.md keeps only a line saying
something was forgotten. Fetchi keeps health, money, beliefs or legal matters only when you ask it to,
and never brings them up on its own.
The brain window lists what was learned this week, with two buttons on each line. Wrong moves that line into the page's history straight away — no longer used, still there to read. Forget deletes nothing by itself: it puts the same confirmation on screen, and only your yes removes the words.
That file is not encrypted. It is protected by your macOS user account and by FileVault if you have it on, and by nothing else. Anyone with access to your unlocked Mac can read it. We would rather say that plainly than imply a lock that is not there.
There is one guard in front of it: before anything is written to memory, Fetchi checks the text for credentials — passwords, PINs, card numbers — and drops it if it finds any, so it is neither saved nor sent out to be indexed. This exists because an earlier version did persist a real bank PIN.
Your history (the History screen)
The History screen shows one entry per request — typed or said at your Mac, texted through Text your Mac or Text Fetchi, or sent from your paired iPhone — with Fetchi's answer, what it did and the app it acted in. It reads and writes files on your Mac and sends nothing. History keeps its own log in the SQLite file, filled from Fetchi's activity trail and receipts whenever History opens, before the trail forgets anything, and once a day, so a request stays in History after the trail's 14 days; its search, filters and count are answered there, on your Mac. Every word written to it is masked first, so a pasted database connection string or mail app password is never stored. Keep history, in History's header and in Settings → Privacy, says how long it keeps a request: Until I delete it (the default), 90 days, 30 days or 14 days. A shorter choice removes older requests the next time History opens, and History says “Older entries were removed.”; a daily pass does the same while History is closed. Only you can change it, in those two places. A request from your paired iPhone goes into the activity trail the way a request at your Mac already did. With that change, a database connection string or mail app password in a request is replaced by a marker before it is written there; until 26 September 2026, one pasted at your Mac went into the trail in the clear.
The banner at the top of History says how long each part is kept, and each number comes from the code that enforces it: what you typed or said, and Fetchi's answers, until you delete them or the period you chose, in History's log (the activity trail's copy is 14 days, sooner if it passes 5,000 lines); what Fetchi did, its cards and plans, and texts with Fetchi, until you delete them — a card keeps the words of the request that raised it and a plan keeps the request that started it, so those outlast the trail; the same words on your Brain's day pages, kept where Fetchi did something, otherwise 14 days; and Fetchi's working memory, the latest 40 lines of conversation. It also says what our server keeps of a request that goes through it: each request's model, token count and cost, never its words. With a model key of your own there is no Fetchi server in the path, and the banner says so.
Delete on an entry is your own act on your own data, so there is no confirmation card. It removes that request from History's log and, however old it is, from the activity trail (the request, the answer and the turn's own notes), its receipts, its settled cards (a card still waiting for you is never touched), the record of a plan it started once that plan has finished, its turn on your Brain's day page (the page stays, because facts cite it) and Fetchi's working memory. Undo puts it all back for 8 seconds; the copy kept for that is in the app's memory only. A request whose plan hasn't finished — running, paused on a question, or interrupted and waiting to pick up again — waits until the plan is done. Clear all history asks first, on the page, then removes every entry the same way along with History's whole log, the whole activity trail, every receipt, every settled card, every finished plan's record and the working memory; a plan that hasn't finished keeps its receipts, its record, its card and its row in History. Neither touches what Fetchi learned about you (say “forget” for that, which also removes a request that carried the words from History), your Brain's one-line log of actions you approved, or a turn on your Brain's day pages that History has no row for.
Report this opens a draft to team@fetchi.ai in your own mail app holding only that entry; it goes only if you send it. Copy puts your words and Fetchi's answer on the clipboard.
Asking what is on your screen
“What's on my screen?” takes one picture of the display and sends it for one look, and that is the whole of it: it never takes the mouse, never keeps the Mac awake and never claims to have done anything, because it did not act. The receipt for that turn says it read. Fetchi's own window is cut out of the picture before it is sent, so it cannot read its own last reply back to you as though it were something on your screen. The image is deleted in the same function that made it, and what is in it is treated as untrusted — a screenshot of a phishing page carries its instructions as legibly as any email.
Watching your screen over time
Fetchi can keep a rolling local log of what has been on your screen — app, window title and text read by on-device OCR — so that "what was I reading yesterday?" is answerable. This is off by default. If you turn it on, the text stays in the local database for 14 days and is then deleted, and — like memories — is searched locally. Relevant results may be included in a later model request.
Checking whether you are stuck
Fetchi watches the shape of what you are doing so it can offer help you did not ask for — noticing a dialog that has been waiting on you, or a document you walked away from. This is on by default. Between 8am and 10pm it takes a reading roughly every 25 seconds: which app is in front, that window's title, the titles of up to 24 open windows, how long since you touched the keyboard, and whether the screen is locked or the display asleep. After about eight seconds of stillness it also reads the frontmost window's accessibility tree, including the first 200 characters of any dialog sitting on screen.
Those last two are the whole of what Fetchi knows about whether you are at the Mac. It cannot tell how far away you are — there is no ranging, no camera and no sensor involved. A long enough run with no keyboard or mouse event counts as away, and the next one counts as back.
No language model is involved and none of it is a screenshot. Most of it is held in memory only — a rolling window of about forty minutes. What reaches the database is narrower but real: when Fetchi decides it has something to say, it stores a key so it does not repeat itself, and that key contains the window title or dialog text it noticed. Those entries are pruned after eight hours, but the pruning runs on the next write, so if Fetchi never speaks again the last ones stay.
When the screen looks sensitive — a password field, a banking window — the title is blanked and the accessibility read is skipped. The name of the app is still recorded.
Turn it off in Settings → Permissions, under Proactive check-ins. Turning it off also throws away the readings already held in memory. Saying "quiet mode" stops it too.
The Esc key while a request runs
So that Esc can stop a request Fetchi is working on (added 26 September 2026), the Mac app watches for it while — and only while — a request is thinking or working. It looks at one thing about each key you press in that time, whether it is Esc; it keeps nothing, sends nothing, cannot hold a key back from the app you are typing in, and stops watching the moment the request ends. Esc stops the request only while the notch is open.
Nudges reaching your phone
If you have paired a phone, those check-ins can arrive there as notifications. On Fetchi builds after 0.2.4 (build 97), your Mac encrypts each one before it leaves, to keys that stay in your phone's browser: it asks our server for that browser's public keys, seals the notification, and our server only signs and forwards the sealed bytes to the push service your phone's browser registered with (Google, Apple, Mozilla or Microsoft). Neither our server nor the push service can read it. If our server cannot hand over the keys, your Mac sends only "Fetchi has something for you. Open Fetchi on your Mac to see it." The one case this does not cover is our server lying about the keys on purpose, which is an attack, not something a log could leak. On builds through 0.2.4 (build 97), the text of the nudge — including the window title or dialog text that prompted it — passes through our server in the clear and our server encrypts it for the push service. Either way we log that a notification was sent, never what it said. An alert about new mail, sent while you are away from your Mac, names the sender and the subject line and never the text of the email.
Until 24 August 2026 this fired for every signed-in account, whether or not a phone had ever been paired, while this page said the way to avoid it was not to pair one. That was wrong. It now requires an actual pairing, and there is a switch in Settings.
Usage counts, if you opt in
During onboarding Fetchi asks how to handle your data. The default, Privacy Mode, sends no usage data at all. If you choose Help improve Fetchi, the app sends event names with tiny counts — the app launched, an onboarding step was completed, the app was used today — so we can tell whether people come back. Four event names exist, the server rejects any other, and the payload is capped so small that a sentence would not fit: no transcript, no screen text, no titles of the things you're working on, ever. You can flip this either way later in Settings, and the switch wins over whatever you picked at onboarding.
One thing is sent whether or not you opt in: which build made the request. Every request to our server carries the app's build number and version, and there is no switch for them. They are how the server recognises an out-of-date app and tells it to update; a build with a known hole that could hide its own number would keep running unnoticed. That is the whole of what is always sent — two numbers about the software, nothing about you or the machine.
If you chose Help improve Fetchi, four coarse facts about the Mac ride along with them: the macOS version to the minor number only ("26.0", never the patch), the Mac's region setting from Language & Region ("US" — a setting you picked, not a location anyone looked up), your first preferred language ("en"), and the clock's current offset from UTC in minutes. Without that choice the request says as much and carries none of the four.
Our server samples this at most once per account every ten minutes and keeps a single row: those values, and when they were first and last seen. Each one is checked against a short fixed shape and dropped rather than trimmed if it does not fit. No IP address is stored beside it, no location is looked up from one, and none of it reaches a third party. It exists so the founder's own console can answer "which macOS should we test on" — it reads the rows only as counts per value, and any value held by fewer than three accounts is folded into "other", so a rare combination is never on screen as a count of one. The row is deleted with your account.
Switching back to Privacy Mode turns those four off: requests say so from the next one, and the server clears what it had stored at its next sample, within about ten minutes of use. The build and version are the exception and stay.
Connected accounts
Fetchi can connect to outside services through Composio, which holds the authorisation tokens so that Fetchi never stores your passwords. Nothing is connected until you connect it, and connecting is a deliberate act with the service's own consent screen. Data reaches a connected service only when an action runs, and actions with real-world consequences stop for your confirmation first. With Gmail connected, Fetchi also checks for new mail every few minutes during the day, reading who each one is from, its subject and Gmail's short preview — never the message itself. You can disconnect an app yourself in Settings → Connections (Disconnect, on its row, deletes the connection at Composio), or revoke a connection at the service itself or at Composio, and Fetchi loses that access immediately.
Your mailbox does not have to go through Composio at all. Set it up in Settings → Connections → Mail with an app password from your provider (Gmail, iCloud, Fastmail and Yahoo are filled in for you), and your Mac reads your inbox itself, over IMAP, read-only. The password stays in your Mac's Keychain. Once it is set up, questions about your email are answered from there first, and the check for new mail reads it there too, fetching only each message's headers (who it is from, who it went to, its subject and date) and no preview. Removing it in the same place deletes the password.
The waitlist on this website
If you put your email address into the form on this site, here is the whole of what happens to it.
- It is stored as a small record on Vercel, who host this site. The record contains your email address, the time, the page that referred you, and your browser's user-agent string. The record is stored under an unguessable filename derived from a salted hash of your address, but the storage itself is public-read, which means anyone who knew that exact filename could fetch it.
- New signups are logged separately from the original total. A second Vercel record keeps salted IDs to prevent duplicate counts. The public counter shows the founder's earlier waitlist total, a fixed number, plus each new signup; it publishes numbers only, never email addresses or IDs.
- It is emailed to the founder, through Resend, so that he sees each signup as it lands.
- If a chat webhook is configured, the same notice is posted to a Slack or Discord channel belonging to us.
- When there’s a spot for you, it is used once more, to email you your invite, sent through Resend from invites@fetchi.ai. To send invites the founder downloads the waitlist to his own computer, and he keeps a list there of who has been invited and when, so that nobody is invited twice. Our server also keeps a keyed fingerprint of each address he invites, never the address, on the same list as the invites Fetchi users send their friends, so that nobody is invited by both. If you ask us to delete your record, your address is deleted from both of those too, and its fingerprint from our server.
We do not sell it, rent it, or add it to an advertising audience. You will get one email when there’s a spot for you, with no newsletter or drip campaign. To delete your record, email team@fetchi.ai and we will delete the record.
This site sets no advertising or analytics cookies. Its fonts are served from our own host and it loads scripts from its own origin.
Inviting a friend
While Fetchi is invite-only, a signed-in account can invite a few friends from the Home screen of the Mac app. Here is the whole of what happens.
- If you invite a friend, their email address goes from your Mac to our server, and from our server to Resend, which emails them one invite from invites@fetchi.ai. The invite names you by your account's email address.
- Our server keeps a keyed fingerprint of your friend's mailbox, never their address; their address masked to its first letter and its domain (d***@company.com), which only your Home screen shows; which account invited them, when, whether the email went out, and whether they have signed up.
- It keeps them so your Home screen can list who you invited and count your invites, and so that nobody is invited twice, by you, by another Fetchi user, or from the waitlist.
- It keeps them for good, because forgetting that someone was invited is what would let them be invited again. If you delete your account, your link to each invite and the masked address are deleted, and only the fingerprint stays. If your friend signs up and later deletes their account, every invite to their address is deleted with it. Anyone who was invited can ask team@fetchi.ai to delete theirs.
The fingerprint is made with a key our server holds, the same way as the free-trial fingerprint described under deletion, and what that part says about where the key lives is true of this one too. The invite is the email the waitlist's invite is, apart from its first line and its last, and it comes from the same address.
The switches you actually have
Five of these are Settings controls. Background memory extraction and screen access are configuration variables — there is no Settings switch for them yet.
The microphone stops being open. Fetchi hears nothing until you hold push-to-talk.
BRAIN_MODEL_EXTRACTION=0 stops the separate model request that extracts facts
after a turn. Local learning continues. Relevant saved memories can still accompany ordinary
model requests; this is not a switch for keeping all processing on your Mac.
BURRI_SEE_SCREEN=0 stops Fetchi attaching window contents and
screenshots to requests. This is not the Settings “Computer control”
switch — that one drives the mouse and keyboard.
Optional, and asked for only in context. The first time you ask something that needs to know where you are, macOS asks; say no, or switch Fetchi off later under System Settings → Privacy & Security → Location Services. Fetchi then uses the city you tell it ("I'm in Berkeley") when you ask about where you are. Even when you allow it, your Mac's own position is rounded to about a kilometre before it is used and is never written to disk. Saying no does not stop the rain watcher, which is on by default: it still works out a rough position from your IP address at ipapi.co and saves it on your Mac (the location table above). Say "stop giving me weather alerts" to turn that off.
Off by default. Settings → Privacy & control has one switch and four kinds — emails and messages, calendar, reminders, notes and files, and clicks in websites and apps — each off until you turn it on, on this Mac only; the phone, a text or a sentence to Fetchi cannot turn them on. A kind you turn on runs without a card first; a send waits 5 seconds on the notch with an Undo, and History marks it “done without asking (you turned this on)”. It changes when Fetchi asks, never where anything goes. No switch here reaches spending money, deleting your data, a password, a security setting, a Terminal command or database change, or a public post, and nothing composed after Fetchi read someone else’s email, message or page goes without a card.
Off by default. With it off, three kinds of act go without a card when your own sentence says the whole act: a message or an email to one person you named (their exact address or number, or the one contact whose whole name you said) in words you dictated, which waits 5 seconds on the notch with an Undo first; an event or reminder whose title and time you said; and Wi-Fi or Bluetooth turned on or off. History marks each one “no card — you asked for it yourself”. Money, deleting, calls, public posts, groups, passwords and security settings, commands, anything Fetchi would have to guess, anything after it read someone else’s words, a text to Fetchi and anything done while you’re away still ask. Turn it on in Settings → Privacy & control, on this Mac only, and every card comes back. It changes when Fetchi asks, never where anything goes.
Replies use the built-in macOS voice, spoken on your Mac. In builds before 0.2.5 (build 107), realtime conversation still streams audio to OpenAI when enabled; turn that lane off separately in Settings → Voice.
Fetchi talks to Anthropic directly and our proxy is out of the path entirely. We then see nothing at all, including your usage.
Not offered in Settings today. Answering with a model on your own Mac is kept only as an offline fallback, and for someone who chose local-only thinking in an earlier version, who keeps that choice until they switch back. We would rather say so than list a switch you cannot find.
What we don't do
- We do not sell your data, and we have no advertising business that could want it.
- We do not train models on your conversations. We could not: we do not keep them.
- We do not listen before the wake word, and the listening code is structurally incapable of it.
- We do not read your local database. We have no route to it.
- Fetchi does not spend your money without asking. Payments always stop for confirmation, at every autonomy setting, including the most permissive one.
Your data, and getting rid of it
Most of what Fetchi knows about you is on your own machine, so deleting it is something you can do
without us: remove the ~/Fetchi Brain folder and the Fetchi database
file, and sign out so the Keychain token is cleared.
Deleting the account on our server is real deletion, not a hidden flag. There is no soft-delete to undo it with. You start it in the app: Settings → Account → Delete account, which asks you to type DELETE. From a phone that holds a device token, the same thing is under Settings → Delete account — and unless that phone is the one that created the account, the server first emails a one-time code to the account's own address, so a lost or stolen phone cannot erase it.
Money first, data last. It cancels any Stripe subscription before it touches a row — a card still being charged after "delete forever" would be the worst possible version of this — and if Stripe refuses, nothing is deleted and the account is left exactly as it was. It then releases the grants for any connected app, because those live on Composio's servers keyed to your account, so once the row is gone nobody could ever find them again. If you own a team with other people still on it, the whole deletion is refused rather than taking their plan away; hand the team over or dissolve it first.
What the erase removes
Then, in one transaction: your account row; the usage ledger; your opt-in product events; the build and, if you opted in, the coarse Mac profile; your push subscriptions; every paired phone and every pairing code; your Text Fetchi number and its pairing code; the number you verified for calling; your team membership, and a team you own that has nobody else left on it; every extra sign-in token, every retired token, and any sign-in or deletion code still pending for your address; the Stripe checkout references and the row saying which plan you are on; what Stripe and OpenAI were told to call your account; and the record of which stored OpenAI response your account made. Invitations your team sent go too, and so do invitations other people sent to your address — somebody else typed it, but it is still yours. The same goes for an invite to Fetchi that a friend, or the waitlist, sent to your address: its fingerprint is deleted. So does any website purchase of yours that granted nothing, which was the one place an address sat in our database in the clear.
A few rows have to outlast you, so the person is cut out of them rather than the row being deleted: money that actually arrived, a credit top-up, a verification ring still inside its day, and the log of anything an administrator did by hand. What is left is an amount, a date and an action, naming nobody — and your address is scrubbed out of any note an administrator typed by hand on somebody else's row, too. The invites you sent a friend stay the same way: your link to each one and the masked address are deleted, and only the fingerprint of your friend's mailbox is kept, so that nobody invites them twice.
What we keep on purpose, and why
An honest deletion page has to list what does not go, so here is all of it.
The free-trial fingerprint, and it is written by the erase itself. The trial is one per mailbox, and without a record that outlives the account, deleting and signing up again would mint a fresh $2.50 and fourteen days for the same inbox, as often as anyone liked. So the erase leaves a keyed fingerprint of your mailbox, not your address, with how much of the trial's money had been spent and the day it began. It cannot be turned back into an address. A guessed address cannot be tested against it without the key it was made under — and where that key lives depends on how the server is configured. Given a key as configuration, it is not in the database at all, so a stolen copy of the database does not help. Left unset, the server mints its own key once and keeps it in that same database, which still defeats anyone holding a fingerprint but not anyone holding the whole file. A fingerprint stops counting a year after it was last written, and is deleted the next time any account is erased.
If we switch on the card-required trial, two more fingerprints. It is off today. When it is on, starting the 7-day trial of Pro keeps a keyed fingerprint of your mailbox and a keyed fingerprint of your card, made the same way and forgotten the same way as the one above, so that a mailbox or a card gets one trial even after deleting and signing up again. The card fingerprint is made from Stripe's own digest of the card; we never see or keep the card number. Neither holds your address or a card detail. The record of the trial itself goes with your account.
Two counters keyed to your mailbox by a plain hash, which is weaker. One counts wrong sign-in guesses and codes sent for a mailbox; it has to outlive the account because the same ledger guards codes for a mailbox with no account behind it, and a row goes once its 24-hour windows and any lock have run out, the next time anyone is sent a code. The other records who took a team seat in the last thirty days, so deleting a farmed account cannot hide it from the seat limit, and rows past that window are pruned. Neither is keyed by a secret: no address can be read out of either, but somebody holding the database could test a guessed address against them. Making them keyed is on our list and is not done.
One texting trace, kept for good. Described in the collection table above: a number that texted before it was paired, or that texted STOP, leaves a keyed hash on a list with no account column, so a stranger hears the how-to-pair line once ever and a STOP stays honoured.
Rows that never named you. The ids of Stripe webhooks already applied; the per-subscription and per-customer rows that stop a replayed or late Stripe event re-granting a plan this deletion just cancelled; website visit counts and the server settings row; none of which carry a token or an address.
Three things the erase cannot reach at all, because they are not ours to delete. The customer record Stripe keeps — we cancel the subscription, we do not delete their customer object, and their retention governs it. Our host's log lines, for as long as they keep them. And any backup taken before the erase ran.
And everything on your own Mac. Deleting the account deletes what we
hold. Your ~/Fetchi Brain folder and the Fetchi database stay exactly where they are
until you delete them yourself. That is deliberate: an app that wiped your own notes out from under
you because a server call returned 200 would be a worse bug than this is a gap.
For a waitlist entry, for a copy of what we hold, or if you can no longer reach the app, email team@fetchi.ai. If you are in a jurisdiction that gives you rights of access, correction, export or erasure, use the same address and we will honour them.
That address is the right one to use, and the domain in it matters: fetchi.app
is registered to someone unconnected with us, so mail sent there reaches a stranger rather than us.
Every contact route on this site points at the address above and none of them at that domain.
Changes to this page
Fetchi is early and changing quickly, and this page describes the code as it stands on the date at the top. When what the software does changes, this page changes with it. If we ever start storing something we say here that we do not store, that is a material change and we will say so directly rather than quietly editing this page.
Questions, or something here that does not match what you observe: team@fetchi.ai.