Bookmark sync cost calculator

The three rates and two behaviours that decide the answer

Billing is per resource, so page size is the cost unit

This is the part that surprises people. A request is free; the resources it returns are not. Asking for max_results=100 to discover five new bookmarks returns 100 posts and bills 100 post reads — $0.50 instead of $0.05. Because paginating is free inside the per-user rate limit (180 requests per 15 minutes on the bookmarks endpoint), a smaller page is strictly cheaper, and the only thing a larger page buys is waste.

For a walk that stops at the first post it already has, the waste is p − (k mod p) for page size p and k new bookmarks — bounded by page size and independent of k. That is why the sizing this calculator models holds pages at five for the first twelve pages and then doubles: minimum waste in the common case, bounded request count when catching up.

Deduplication is why sync frequency matters more than sync size

Because a resource is billed once per 24-hour UTC window, re-reading the same bookmarks twice in one day is free and re-reading them tomorrow is not. Two consequences fall out of that. Polling hourly multiplies cost by the number of polls and discovers nothing extra, so a scheduled sync should run once per UTC day. And a user-triggered "sync now" later the same day is nearly free, because the overlap has already been paid for — which means manual sync can be offered generously rather than rationed.

Read the detail on what a post read is and on how the 24-hour window works.

The $0.005 probe

The bookmarks endpoint returns newest-first, so max_results=1 returns the single most recent bookmark for one post read. If its ID matches the one already stored, there is nothing new and the sync stops there. A dormant user therefore costs $0.005 a day — about $0.15 a month — instead of the $0.50 a day a naive full page would cost. That single decision is a hundred-fold difference on an idle account, and it is why the ongoing number in this calculator is so much smaller than the intuitive one.

What is arithmetic here, and what is an estimate

With author profiles switched off, every figure on this page is arithmetic on a published rate: resources counted, multiplied by $0.005. Switch author profiles on and one modelled number enters — the share of a bookmark library that resolves to a distinct account, which falls as the library grows because people re-bookmark the same people. That share is fitted to measured figures (about 70% distinct at 100 bookmarks, about 22% at 5,000) and is labelled as an estimate wherever it is used. The amortisation of the one-time import into a per-user-per-month figure assumes a twelve-month customer lifetime, which is an assumption about your business, not about X.

The uncomfortable conclusion

The ongoing cost of a bookmarks product is small and predictable. The import is neither: it is a spike, paid in full before the customer has paid anything. A single signup from someone with 5,000 saved bookmarks costs about $25 before any revenue exists. This is why Sift's free plan imports the newest 100 bookmarks and no more, and why paid history is backfilled in weekly slices rather than all at once. Not a limitation we are hiding — the number above is the reason.

X describes its prices and caps as subject to change, and the Owned Read interpretation above is one we would want confirmed by X support before betting on it. If it were ever read per-authenticated-user rather than per-app-owner, unit cost would drop five-fold. We plan at $0.005 and treat anything better as upside.