Where Local AI Stores Chats, Models, and Files on Android

Local AI data is a collection, not a single folder

When an AI app says that data stays on your device, the next useful question is: which data, in which storage system, for how long? A working local assistant can create several types of data with different sizes and sensitivity.

• Chats, branches, titles, drafts, and settings are structured records.
• Model weights are large, mostly immutable artifacts.
• Imported documents and images are user files or protected copies.
• Extracted text, OCR results, embeddings, and retrieval indexes are derived data.
• App code and runtime assets make the interface and inference engine available.
• Backups are portable copies that may live outside the app's normal private area.

Android's storage guidance distinguishes app-specific storage, shared storage, preferences, and databases. Internal app-specific storage is intended for sensitive information that other apps should not access. Shared storage is for content the user expects to use outside one app. [1]

That distinction matters for deletion and privacy. Removing a model does not necessarily remove its chats. Deleting an imported source file may not remove extracted passages or a retrieval index. Clearing a browser cache may affect the application shell while a separate database holds conversations. A good local AI product gives each category a clear name and a specific control.

Native Android apps have private and shared storage choices

A native Android app commonly stores private records in its internal app directory or a private database. It can store large app-specific files in directories assigned to that app. Android applies scoped storage rules so one modern app cannot simply browse another app's private directory. [1]

App-specific external storage is still app-specific. The word external in Android documentation does not automatically mean public or cloud storage. It refers to a storage volume and API category. Android notes that app-specific files in these directories are removed when the app is uninstalled, and that modern apps do not need broad storage permission to use their own assigned directories. [2]

Shared storage behaves differently. If a user deliberately exports a document or encrypted backup to Downloads, a document provider, removable media, or another selected location, that copy can survive app deletion. This is usually desirable because an export is meant to remain under the user's control. It also means that deleting the app cannot promise to delete every copy the user created elsewhere.

For a native local AI app, a reasonable layout is:

The exact implementation varies. Treat this table as a review framework, not a claim about every Android application.

Browser and PWA storage is tied to an origin

An installed PWA still uses web storage rules. Its data belongs to an origin, such as https://example.com, rather than to an ordinary folder that the user opens in a file manager. A local AI PWA can combine several browser APIs:

• Cache Storage can retain request and response assets used by the application shell.
• IndexedDB can hold structured records and binary values.
• Origin Private File System (OPFS) can provide private file-like storage for large artifacts.
• Web Storage can hold small string values, although it is not suitable for large models.

Google's web storage guidance recommends Cache Storage for network resources, IndexedDB for general structured data, and OPFS for file-oriented content. [3] These stores are private to the origin from normal web-page access, but they remain managed by the browser.

Origin scope creates two practical consequences. First, the same PWA opened under a different domain, subdomain, or protocol does not automatically see the original data. Second, browser actions that clear all data for that origin can remove several stores together. A user should therefore use the application's backup and deletion tools intentionally instead of treating the browser's generic clear button as a selective model cleanup control.

Installing a PWA does not move its data to a magical permanent container. Installation changes how the app launches and integrates with the operating system. Storage durability still depends on browser policy, available space, origin activity, and whether persistent storage has been granted.

Persistence reduces eviction risk but does not replace a backup

Browser storage is normally best effort. Under storage pressure, a browser can evict data for origins that are not protected by persistent storage. Google documents that an origin can request persistent storage, which reduces automatic eviction when the request is granted. Users can still clear that data themselves. [3]

The Storage API can estimate current usage and quota. A PWA can use that estimate to warn before a multi-gigabyte model download or explain why a write failed. IndexedDB, OPFS, and Cache Storage can report a QuotaExceededError when the origin cannot store more data. [4]

Persistence is useful, but it is not a backup for four reasons:

1. The device can be lost, damaged, or reset.
2. The user can clear browser data.
3. A forgotten vault passphrase can make encrypted content unrecoverable.
4. Application bugs or incomplete writes can corrupt local state.

A durable local workflow needs an export that can be verified and restored. For private AI data, that backup should be encrypted before it leaves the application's private store. Model weights are usually excluded because they are large and can be downloaded again, while chats, project records, document context, and user settings may be irreplaceable.

Android backup is a separate network boundary

Local app storage and cloud backup are different questions. Android's Auto Backup system can upload eligible app data to the user's Google Drive backup area when backup is enabled for the device and allowed by the application. Android documents that apps can include, exclude, or disable backup data through manifest and extraction rules. [5]

This means that “stored in a private app directory” does not, by itself, answer whether the operating system may copy that data into a backup. Review the application's privacy documentation and backup controls. Ask:

• Does the app participate in cloud backup or device-to-device transfer?
• Which files and databases are included or excluded?
• Are model weights excluded to avoid huge or incomplete backups?
• Is private content encrypted independently before export?
• Can the user create a manual backup and test a restore?

Do not assume that uninstalling an app erases a separate backup dataset or an exported file. Do not assume that every app uses Android Auto Backup either. The product must state its policy, and the current build configuration is the authoritative implementation.

For a PWA, browser sync and operating-system device backup can introduce their own behaviour. A site's local database is not automatically the same thing as a browser account sync feature. Verify the browser and platform rather than applying native Android assumptions to a web app.

How to inspect what a local AI app stores

Begin inside the app. A well-designed storage screen should list categories and sizes in language a person can understand: models, chats, files, indexes, OCR packs, embedding packs, backups in progress, and temporary data. The model manager should identify each installed artifact rather than presenting one unexplained total.

Then use Android or browser controls as a second view:

1. Open Android's app information screen and inspect the total app and user-data size.
2. Compare that number before and after downloading one model.
3. Remove the model through the app and confirm storage falls by a plausible amount.
4. Import a non-sensitive test document, ask a question, then remove the document and its project.
5. Check whether the app distinguishes source files from extracted text and indexes.
6. For a PWA, inspect the browser's site-storage entry for the correct origin.
7. Create an encrypted backup, note its chosen destination, and test restore into a fresh installation if the product supports it.

Avoid using confidential material during the test. Storage screens reveal size and category, but they do not prove that nothing was transmitted. Pair storage inspection with the privacy notice and a controlled offline or network-boundary test.

Delete data in the right order

Use the narrowest control that matches your goal. If you only need storage space, remove an unused model. If a project is no longer needed, delete its imported files, derived text, index, and linked chats through the product. If you are leaving the app entirely, export anything you need, review queued online actions, then use the complete local-data deletion control.

A careful deletion sequence is:

1. Cancel any active generation, download, indexing, backup, or report operation.
2. Export an encrypted backup only if you intend to keep the data.
3. Delete user-created backup files you no longer want from their selected destinations.
4. Use the app's complete deletion action and wait for verification.
5. Remove the app or clear the site's data only after the internal deletion completes.
6. Check Android backup, browser sync, and device-to-device transfer settings separately when relevant.

Generic clearing can be appropriate when the application is damaged, but it gives less explanation about what was removed. It may also erase the local credential needed to request early deletion of an optional remote report. Review those edge cases before removing the whole vault.

The CuriousLM storage boundary

CuriousLM states that chats, projects, approved memories, imported files, extracted text, indexes, citations, and downloaded model artifacts are stored on the user's device. Its PWA protects private structured records and files with a local vault. The Android app uses encrypted native storage protected by Android Keystore and device authentication. [6]

CuriousLM separates removable model artifacts from portable user data. Its encrypted .curiouslm backups exclude model weights, which can be downloaded and verified again. The app also exposes controls for deleting conversations, files, models, credentials, reports, and complete local data.

That design does not make local storage immortal. Browser storage can be cleared, a phone can fail, and CuriousLM cannot recover a forgotten vault or backup passphrase. If the work matters, create an encrypted backup, keep the passphrase separately, and test a restore before relying on it.

The central rule is simple: “local” describes location, not durability. Privacy improves when data stays under your control, but control also includes understanding storage, backup, deletion, and recovery.