ReMyndthe real cost of context switching
context switching costs less time than you think and more attention than you would like.
that is the uncomfortable finding in the best controlled experiment on the subject. people who get interrupted do not take longer. they speed up, cut corners, and pay in stress instead. the bill arrives in a currency you cannot see on a calendar.
as of september 2026 most advice about context switching at work still quotes a recovery time the underlying research does not support. here is what was actually measured, and what it means for how you set up your day.
what the research actually measured
the paper is "the cost of interrupted work: more speed and stress", by gloria mark, daniela gudith and ulrich klocke, presented at the chi conference in 2008.
the design was tight. participants answered a batch of email in three conditions: no interruption, interruption on the same topic as the task, and interruption on an unrelated topic. interruptions arrived by telephone or instant message. the team measured completion time, error count, message length, politeness, and the standard nasa workload ratings on a scale of 1 to 20.
they expected same topic interruptions to hurt less. they were wrong, and the direction of the main result surprised them too. nothing in the design involved a mac, a phone notification or a slack ping, which is worth remembering before extrapolating too far.
why interrupted work finished faster
people who were interrupted completed the task in less time than people who were left alone.
| condition | time to complete task | vs baseline | avg words per email |
|---|---|---|---|
| no interruption | 22.77 minutes | 0% | 31.49 |
| interruption, same topic | 20.31 minutes | 11% faster | 29.17 |
| interruption, different topic | 20.60 minutes | 10% faster | 30.16 |
the gap between the two interrupted conditions was not significant. the gap against the uninterrupted baseline was. error rates did not differ across conditions, and neither did politeness.
the emails did get shorter, by about 7% in the same topic condition. that is the first hint at what is really going on: interrupted people did not become more efficient, they became more compressed.
what it cost instead
the workload ratings moved in one direction, and they moved hard.
| measure, scale 1 to 20 | no interruption | same topic | different topic | worst case change |
|---|---|---|---|---|
| stress | 6.92 | 9.46 | 9.13 | 37% |
| frustration | 4.73 | 6.63 | 6.48 | 40% |
| time pressure | 11.02 | 12.69 | 12.17 | 15% |
| effort | 9.50 | 11.04 | 11.52 | 21% |
| mental workload | 10.02 | 10.83 | 11.50 | 15% |
stress rose by 37% against baseline. frustration rose by 40%. these were significant at p<.01, which for a sample of this size is not a marginal result.
so the trade is real and it is bad. you buy back a couple of minutes by spending attention you do not get back, and the full paper is worth reading before you quote any round number about interruptions.
why reconstruction is the real bill
the part the experiment could not measure is the part that hurts most in real work.
a lab task is small enough to hold in your head. real work is not.
come back to a half finished analysis after two hours in meetings and the expensive step is not restarting. it is rebuilding the state: which tab had the number, which version of the query you ran, what the reviewer objected to, what you had already ruled out.
that state was never written down. it lived in twelve open windows and your short term memory, and one of those two got wiped. task switching between apps is cheap. rebuilding the state inside them is not.
the study found individual differences here. a regression on personality measures showed that openness to experience and need for personal structure together explained about 14% of the variance in how long an interrupted task took to finish. some people rebuild context cheaply. most do not.
machines pay the same tax
this is not only a human problem, which is a useful thing to notice.
anthropic's documentation on context windows describes a phenomenon it calls context rot: "as token count grows, accuracy and recall degrade".
the lost in the middle paper from 2023 found the same shape experimentally. model performance "is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts".
a claude model with a 1m token window and a person coming back from a meeting have the same failure mode. more raw material does not equal better recall. what matters is whether the relevant piece can be retrieved on demand.
how much of the working day is already this task? per the anthropic economic index for may 2026, searching electronic sources is the top work task in sampled claude conversations at 4.95%, with reference searching second at 3.74%.
work accounts for 43.36% of classified conversations, and 51.38% of usage is augmentation rather than automation, meaning long sessions where a person and a model think together. every one of those sessions starts by rebuilding context, whether it runs on claude, chatgpt or gemini.
that is the whole argument for context engineering: curate what goes back in, rather than hoping the pile is searchable by accident.
what actually reduces the cost
you are not going to eliminate interruptions, so attack the reconstruction step instead.
- write the state down before you leave it. one line saying what you were doing and what is next beats twenty minutes of re-derivation.
- keep the artefacts, not just the conclusions. the query, the tab, the error string. those are what you will search for.
- make the record searchable by content, not by filename. you will remember a phrase you saw, not what you called the file.
- stop relying on open windows as memory. a tab you keep open is a bookmark with a cpu cost, and it disappears on the next restart.
- batch the switches you control. the ones you do not control are the ones the research measured, and they are not going away.
a screen memory tool is one way to do points two and three at once, because it records the artefacts as a side effect of you looking at them.
point three is where most systems fail. spotlight search indexes files, and the thing you need to recover usually never became one. chatgpt, claude and gemini all hold a conversation, not your week, which is the gap taken apart in ai memory compared.
where remynd sits
remynd is aimed squarely at step three. it records the focused window on a mac, runs optical character recognition on device, and keeps the resulting text in a local index, so coming back to a task can start with a search instead of a reconstruction.
the practical version is asking "what was i doing on tuesday afternoon" and getting the actual windows, in order, with the text that was in them. since august 2026 that archive is also exposed to claude code and codex over a local connector, so an agent can pick up where you left off.
the scope, stated exactly: capture is the focused window, ocr and storage stay on your mac, recordings default to 30 days of retention, and you can exclude specific apps or sites from capture entirely. in a measured install the recordings were about 95% of the 26gb on disk and the searchable index only 5%. asking a question sends the retrieved slices to a cloud model, and there is no local model option today. optional backup is encrypted and exports to your own s3 bucket, so the honest line is that the archive lives with you rather than that nothing ever leaves your machine.
if the reconstruction problem is what brought you here, read how to find something you saw on your screen next, and why you forget what you read for the memory side of it.
download remynd free for mac → free to download, runs locally, no card.