I notice that AWS Quick for desktop now supports per machine installation. Typically much space in the user profile does Quick for desktop need? We are still using Application settings persistence on Amazon Workspaces Applications so have upto 5gb profiles which has generally been fine up to now? docs.aws.amazon.com/quick/latest/userguide/desktop-enterprise-mdm.html

Here's what Quick Desktop told me: Amazon Quick for Desktop — Data Storage & Non-Persistent VDI Guidance Prepared for: Partner deployment planning Context: Non-persistent VDI on Amazon WorkSpaces Applications, using Application Settings Persistence (up to 5 GB profiles) Date: 9 September 2026 --- ## 1. Where Amazon Quick keeps user data Amazon Quick for desktop is architecturally a thin client over a cloud runtime. The agent itself runs in the Amazon Quick cloud runtime; the desktop app acts as a lightweight local "outpost" that executes local-machine work (file access, browser automation, screenshots, notifications) only when a task requires it. The practical consequence for a VDI deployment: | Data category | Where it lives | Persists per-user profile? | |---|---|---| | Conversation history | Cloud runtime | No — server-side | | Long-term memory | Cloud runtime | No — server-side | | Knowledge graph | Cloud runtime | No — server-side | | Activity feed | Cloud runtime | No — server-side | | App settings & preferences | Cloud runtime | No — server-side | | The user's own local files | Stay on the machine; read only on demand, never copied into Quick's own store | N/A | | Local cache / config / logs | Local app data | Yes (disposable) | | Optional local LLM model | Local app data | Yes (large — see §3) | Because conversation state, memory, knowledge graph, feed, and settings are keyed to the corporate sign-in identity and stored in the cloud, they re-hydrate automatically on whatever machine the user next signs into. This is precisely why the same account and conversations follow a user across the desktop, web, and mobile apps. Bottom line: the data a user would care about preserving is not held in the local profile — it comes back on sign-in. In a non-persistent model this is favorable: you generally do not need to persist Quick's local profile data to preserve the user experience. --- ## 2. Per-machine installation (recommended for this scenario) Amazon Quick for desktop now supports per-machine installation, which places the application binaries in a machine-wide location instead of inside each user's profile. For non-persistent VDI this is the right choice: - The application itself no longer lands in each roaming/persisted profile, reducing the per-user profile footprint. - The app is present on the image for every session, so there's no per-user (re)install cost at logon. --- ## 3. The one footprint lever to watch: Local Processing (local LLM) Amazon Quick has an optional Local Processing feature that downloads a local LLM for offline inference. When enabled, that model download is multi-gigabyte and lands in local/app data. For a non-persistent deployment with ~5 GB profiles, you should ensure Local Processing is disabled so a large model isn't being downloaded into (or attempting to persist within) each user profile. With it off, the residual local data is just cache, config, and logs — which is well within a 5 GB Application-Settings-Persistence budget and can safely be treated as disposable. --- ## 4. Recommended configuration summary For non-persistent VDI on Amazon WorkSpaces Applications with Application Settings Persistence: 1. Use per-machine install — keeps binaries off the per-user profile. 2. Disable Local Processing — avoids a multi-GB local model competing for profile space. 3. Do not treat Quick's local profile data as something that must be persisted — user state (history, memory, knowledge graph, settings) is cloud-side and restores on sign-in. Local cache/config/logs are disposable. 4. Existing 5 GB Application Settings Persistence profiles are more than adequate once the above are in place. --- ## 5. Caveat — for an exact byte figure The in-product guidance does not publish a specific number for the desktop app's local user-profile footprint (cache/config/logs), nor the exact per-user Windows paths (AppData\Local vs Roaming). For a precise sizing figure and path list, that's a packaging/deployment question best confirmed with the Amazon Quick / EUC deployment team. The architectural design above, however, means an exact number is unlikely to be a blocker: with per-machine install and Local Processing off, the persisted-per-user data is small and non-critical.

Thanks Stephen