> For the complete documentation index, see [llms.txt](https://wiki.crosswatch.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.crosswatch.app/getting-started/limitations.md). # Limitations CrossWatch is **not** built for very large libraries. It is a UI-first tool with metadata enrichment, images, and safety checks. **It is not a bulk-sync engine.** Big libraries create heavy API traffic and large JSON files. {% hint style="warning" %} If your main goal is syncing massive datasets fast, CW is the wrong fit. {% endhint %} ### Size guidance These are **approximate** limits. Provider behavior matters more than hardware. On a normal machine or NAS, overall library size is rarely the first bottleneck. The tighter limits below are about API pressure and JSON file sizes CW recommends these rough upper bounds for normal use: * **Watchlist**: `~2,500` * **History**: `~10,000` * **Ratings**: `~10,000` Lower counts are better. Higher counts may still work, but they are less tested and harder on providers. ### Large `state.json` files CW stores sync state, history data, and provider mappings in `state.json`. This file stays small during normal use. Large histories, watchlists, ratings, or provider datasets can grow it significantly. Large files can slow the Web UI, API responses, and startup after a restart. They also increase memory use while CW reads or rewrites state. Views that scan, filter, or summarize state feel this most. Multiple browser tabs can make the slowdown more noticeable. As a rough guide, `75–100 MB+` may affect responsiveness on systems. Background syncs can still complete successfully. Local state may have grown beyond the size CW currently optimizes for. For large libraries: * Sync history once then use watcher after you cleaned the state through Maintenance ### Provider account limits Some limits come from the provider, not CW itself. If you have large watchlist volumes, disable TMDb enrichment first. ### Provider request limits CW also throttles upstream APIs to reduce `429 Too Many Requests` errors. Default request limits: * **SIMKL**: `10` GET/sec, `1` write/sec * **Nuvio**: `100` GET/sec, `100` write/sec * **MDBList**: `10` GET/sec, `1` write/sec * **PublicMetaDB**: `20` GET/sec, `3` write/sec, plus hourly rating quotas * **Trakt**: `3.33` GET/sec, `1` write/sec Most installs should keep these defaults. Only tune them if you see repeated `429`, temporary `5xx`, or timeout errors. See [Provider rate limiting](/crosswatch/advanced-and-api/rate-limiting-and-retries.md) for the short version and the full tuning reference. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wiki.crosswatch.app/getting-started/limitations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.