How Typeme remembers

The three layers

Typeme's context folder defaults to ~/.config/Typeme and can be changed during onboarding or in Settings. Open it at any time from the menu-bar menu. Inside:

~/.config/Typeme/
├── profile.md # long-term facts: role, tone, terminology
├── daily/
│ └── 2026-10-24.md # append-only log, one file per day
├── stories/
│ └── checkout.md # one store per project or topic
├── shots/
│ └── 2026-10-24/ # optional screenshots, opt-in only
└── .index/ # local search index (safe to delete)

Every file is plain Markdown. There is no database to export and no proprietary format to migrate away from.

profile.md

profile.md is the only context that is included in every request. Keep it short and stable: who you are, how you write, and the vocabulary that a model would otherwise get wrong.

# Profile

- Name: Lin
- Role: Backend engineer on the billing team
- Tone: direct, friendly, no exclamation marks
- Terms: "Store" is a Typeme context store; "CPS" is the billing service

## Preferences

- Reply in the language of the incoming message.
- Keep replies under five sentences unless I ask for detail.
- Never invent ticket numbers or dates.

Useful entries are the ones that change output: tone, formality, language rules, product names, and things the model should never do. A biography does not help; a rule like “no exclamation marks” does.

Stores

A store is one project, ticket, customer, or topic. The UI calls it a Store; on disk it is a file in stories/. Each store has a title, a background section, and notes.

# Checkout redirect loop

## Background

CPS-1893. Customers loop between /cart and /checkout when the
session cookie is scoped to the apex domain. Fixed in 2.41.0.

## Notes

- QA signed off on 18 October.
- Rollout is behind the `checkout_v2` flag.
- The old redirect handler is still in the release branch.

Typeme maintains stores automatically: it notices a recurring topic, creates a store, and updates the title and background as new material arrives. Long stores are compressed, but the full record always remains in the daily log. You can edit any store by hand — the background and your notes are always included when that store is selected.

Two ideas are worth keeping separate:

• Which store is used for this request is a context decision. The panel shows the candidate stores, ranked, with the most likely one selected. Click another candidate to switch and re-run.
• Where the record belongs is an attribution decision, made in the background. The store selected in the panel does not determine where the new record is filed.

Attribution tries, in order: your manual choice, assignment rules, a local classifier, the main model with a forced JSON answer, and finally a conservative fallback. When it is not confident, the record is left unassigned — it still lives in the daily log and can be picked up later. This is deliberate: a wrong store silently poisons future context, while an unassigned record costs nothing.

The daily log

daily/YYYY-MM-DD.md is the full record. Every capture — a selection, an OCR region, a panel session — is appended, in order, with the app and window it came from.

## 10:42 — Slack
app: Slack
window: #engineering

> Can you take a look at the checkout redirect before Friday?

The daily log is append-only. Typeme adds to it and never rewrites, reformats, or deletes entries based on their content. That is what makes it trustworthy: it is the source of truth from which stores and the search index can always be rebuilt.

You can edit it. If a capture was wrong — an OCR mistake, a test string, a terminal command you did not mean to keep — open the file and change it. Typeme will not undo your edit. The one thing the app will do on its own is expire whole day files if you set a retention period; the default is to keep everything.

How matching works

When you open the panel, Typeme has more than the selected text: it also has the window title and, for OCR captures, a text snippet. It uses those signals to rank your stores.

1. The decision layer scores candidate stores locally first, then asks the decision model when the local result is not confident.
2. The panel shows the ranked candidates. The top one is selected by default.
3. If nothing is clearly relevant, no store is selected. The request still runs with your profile and recent log entries.
4. If you pick a different candidate, the action re-runs with that store's background.

This is why a well-written store background pays off twice: it improves matching, and it is the text the model actually sees when the store is chosen.

What is actually sent

Context files stay on your Mac. When you run an action, the request contains:

• The text you selected, or the OCR result.
• The active window title.
• The matched store's title and background.
• Up to eight recent log entries, each capped at 500 characters.
• Your profile.md.
• The action's prompt.

If you use the default Typeme Cloud provider, the request goes through Typeme's Worker and Cloudflare AI Gateway to the model. If you configure your own provider, the assembled prompt goes directly to that provider. In both cases, API keys and the rest of your context folder stay local — see Bring your own model.

Editing and rebuilding

Edit profile.md and store files in any text editor. Changes apply to the next request; there is nothing to import.

If stores drift out of shape, Settings › Advanced › Rebuild stores rebuilds the derived data from the daily log. It replays the log from oldest to newest, recreates the stores, and rebuilds the local index. It is safe to run more than once, and it does not touch daily/.

The same rule applies if you want to start clean: deleting stories/ and .index/ throws away derived data only. The daily log remains, and the next rebuild recreates everything from it. Never delete daily/ to “reset” — that is the record, not a cache.

Questions