The cost of keeping personal context fresh

A sync engine can spend most of its day asking whether anything happened. Consider six connected accounts checked every five minutes. Even if no file moves and no meeting changes, that schedule makes 51,840 requests in a 30-day month. The number is not a Zortex measurement. It is six times twelve checks per hour, times 24 hours, times 30 days. It tells us what kind of bill a poorly chosen refresh policy can create before anyone has asked an AI a question.

A personal world model must stay current enough to be useful. It also needs to survive expired authorizations, missed events, deleted files and a laptop that has been asleep. We put request counts and storage sizes beside three synchronization choices to expose their different costs.

Six connectors, three refresh schedules

Our model has six independently refreshed sources, one person, a 30-day month and a single result page per refresh. We compare three policies. Frequent polling checks each source every five minutes. Hourly polling does so once an hour. An event-backed policy receives 2,400 modeled change notifications during the month and performs one nightly catch-up check per source: 6 × 30, or 180 checks. Every notification is counted as a separate API call. We exclude retries, subscription renewals, pagination, initial imports and rate-limit backoff.

Each block represents approximately 2,600 calls. The scale is approximate; the counts are exact under the stated assumptions.

Figure: Modeled monthly connector request counts under three explicitly stated synchronization assumptions..

The event-backed count depends on change density. Notifications can arrive in bursts, repeat, or require a follow-up fetch to discover what changed. Google Drive's changes API uses a saved page token to retrieve changed files; a watch notification says there is something to inspect, rather than supplying the changed file itself. Microsoft's Graph delta API tracks additions, updates and deletions in message folders using continuation and delta links. Gmail's push-notification documentation says a mailbox watch must be renewed at least every seven days. A watch is a maintained subscription, not magic free synchronization.

Under our deliberately simple model, the event plan has 180 fixed reconciliation calls plus one call for each notified change. Hourly polling has 4,320 calls regardless of how many changes occur, as long as each response remains one page. The counts meet at 4,140 event calls per month. Below that point, an event-backed plan makes fewer requests; above it, a one-call-per-event implementation makes more.

Figure: modeled crossover in API calls between hourly polling and event-backed synchronization.. Actual providers often coalesce multiple changes into one delta fetch, or paginate a busy result into many calls. A real connector chooses a policy from measured change density, allowable staleness, provider quotas and the ability to recover missed notifications. The table isolates one trade-off; it does not benchmark three shipping connector implementations.

The bytes behind the links

Now assume a personal index holding 30,000 lightweight item records averaging 1,500 bytes, 100,000 relationship records at 80 bytes, and one 768-dimensional float32 vector for each item. Those assumptions give approximately 45 MB of item metadata, 8 MB of relationships and 92 MB of raw vectors: about 145 MB before search indexes, database pages, encryption overhead or backups.

Doubling that figure as a rough allowance for indexing and maintenance would put this modeled state around 290 MB. Storing five gigabytes of original files or attachments would change the storage picture completely. The relevant design decision is whether the world model needs copies of original content, a minimal representation with source pointers, or a configurable mixture. Neither a five-gigabyte cache nor a 290 MB index is a measured Zortex footprint.

The initial import is another category of work. Reading 30,000 objects once is not equivalent to maintaining them when 2,400 change in a month. If each changed item needs a new 400-token representation, the monthly embedding workload is 960,000 input tokens. If only a timestamp changed, re-embedding may be unnecessary. If one message changes which project it belongs to, updating two graph edges may be more useful than embedding the message again. Stale or unauthorized entries need invalidation, not merely another retrieval pass.

These distinctions also prevent misleading dollar totals. API requests are not billed at one universal price; quotas, scopes and paid tiers depend on the provider. Embedding prices depend on model and deployment. Disk, backup, sync bandwidth and CPU time have different costs on a user's computer and in a hosted service. An honest per-user cost model must multiply each measured quantity by its actual unit rate, then include errors, idle capacity and support. We have modeled workload counts here, not a production invoice.

What local-first really changes

The product described in the Zortex early-access page builds a private work model from a person's apps, keeps it on their computer when run locally, and lets them decide what connected AIs can see. There is also an optional cloud mode described for reaching context while the device is off. Those are product commitments, not findings established by our numerical workload.

A local-first design changes who stores and processes the working state. It can avoid retaining another complete centralized copy of personal work and move indexing work onto an already-owned machine. It does not make CPU cycles, electricity, storage wear or backup free. It also does not excuse a connector from handling authorization expiry or a source deletion: a private index can still be privately wrong.

For an engineering review, we would therefore record five counters before publishing any per-user cost figure: source requests by connector and response type; changed bytes; records and edges recomputed; representation tokens or local inference time; and the time between a source change and correct searchable state. A sixth measure, deleted or revoked records still retrievable after invalidation, is a safety requirement rather than an efficiency metric.

The point of the model is narrow. Asking about change is sometimes more expensive than processing change, and refresh strategy can dominate request count even before model inference begins. The crossover moves when the workload moves. Engineers who can explain that boundary have a better basis for choosing local indexing, event delivery and periodic reconciliation than a flat promise that synchronization is cheap.

Reproduce the workload calculation

Both figures, including the geometric cover drawing, are generated by the chart source. The six-source, 30-day figures are calculated from the stated workload assumptions. Provider behavior comes from the linked Google and Microsoft documentation; the source script regenerates the two figures.