ETOS LLM Studio follows a “Local-first” design philosophy. Most core data stays on your own device and remains under your control.
We do not automatically store your chat content, voice recordings, image attachments, or API keys on developer-controlled servers. That said, the app does store chats, configuration, memory data, and request logs locally on-device so it can provide sync, statistics, Daily Pulse, annual recap, and similar features.
2. On-Device Storage and Local Processing
Chats and session data: chat history, session settings, attachment references, worldbooks, memory data, Daily Pulse data, feedback history, and app settings are stored inside the app sandbox on your device.
API provider configuration and API keys: provider configuration (such as model lists, header overrides, and proxy settings) and API keys are stored in a local SQLite configuration database. If an older version wrote keys to Keychain, migration will merge and clean up the legacy credential storage.
Local request and response logs: the app can locally save complete HTTP request and response bodies plus diagnostic fields such as duration, status, and token usage. This feature has its own master switch and hides chat text by default. Text is retained only if you explicitly enable plaintext message logging; Base64 data for images, audio, and files is always hidden. These logs are never uploaded automatically.
Feedback ticket cache: if you use the feedback assistant, the app stores ticket numbers, ticket tokens, status, update timestamps, and public URLs locally so you can track progress later.
Local Linux: the optional bundled AArch64 RootFS, workspaces, task logs, and diagnostics stay inside the app sandbox. Environment variables are stored in the encrypted-capable SQLite configuration database and injected only when a selected Linux process starts; they are not automatically added to model prompts.
3. AI Requests, Audio, and Images
Text chat: your messages are sent directly to the third-party AI providers you configure yourself (such as OpenAI, Anthropic, Google, OpenAI-compatible services, or self-hosted models). We do not proxy or store that content on developer-controlled servers.
Voice and audio: microphone access is only used when you actively record or trigger voice input. Audio is sent only to your current model provider or the speech/transcription service you choose.
Images and files: the app only accesses images or files when you choose them. Those attachments are sent to your current model provider, or to a local debugging endpoint that you intentionally connect.
Browser Agent and local MCP: Browser Agent requests go directly to websites opened in an app-owned WebKit view. A local stdio MCP server runs inside Local Linux. External folders are exposed to Linux only after you select and authorize them, and browser cookies are not mounted into Linux.
4. Sync, Local Network, and Apple Services
iPhone / Apple Watch sync: live sync between your iPhone and Apple Watch uses WatchConnectivity and does not pass through developer-operated servers.
iCloud sync: if you explicitly enable iCloud sync, selected data may sync between your own devices through Apple’s iCloud / CloudKit stack, including provider configuration data that may contain API keys.
Local network and debugging: local network permission is only used for optional LAN debugging / remote file access features. If you connect your own desktop debugging tool, related app files or request traffic may be sent to a local endpoint that you control.
5. Feedback Assistant
Data is sent to the feedback service only when you actively choose to submit feedback.
User-entered content: feedback type, title, description, reproduction steps, expected behavior, actual behavior, and extra context.
Environment snapshot: platform, app version, build number, OS version, device model identifier, locale, and time zone.
Anti-abuse verification: feedback requests also include challenge, timestamp, signature, and proof-of-work related fields to limit spam submissions.
Status refresh: when you later refresh a ticket in the feedback center, the app uses the locally saved issue number and ticket token to query the feedback service for updates.
Before upload, feedback text goes through a basic sanitizer that tries to mask common Bearer tokens, API key labels, and a few common secret formats. However, this is not a full data loss prevention system. Please do not put secrets, government IDs, addresses, health data, or similar sensitive information into feedback submissions.
6. Performance Telemetry and Diagnostics
“Help Improve ETOS LLM Studio Performance” is enabled by default and can be turned off under Settings > About. It is independent of local request logging. Turning it off stops collection and clears unsent telemetry.
Data sent: aggregate CPU, memory, launch, hang, disk, and network metrics and anonymous diagnostic call stacks supplied by Apple MetricKit; fixed-stage timing for launch, database work, requests, streaming processing, and Markdown recorded with MXSignpost; and app version, build, distribution channel, iOS version, device model class, architecture, and report time.
Data not sent: chat content, request or response bodies, API keys, credentials, configured server addresses, session IDs, persistent device IDs, advertising IDs, or other user identifiers.
Timing and on-device retention: MetricKit delivers reports on the system’s schedule. The app only attempts to upload data written during a previous launch and deletes each local file immediately after explicit server confirmation. Pending files are retained for at most 14 days and 20 MiB total, with diagnostic call stacks prioritized.
Server and archive retention: the receiving service temporarily stores data by UTC date, subject to 30-day and 2 GiB limits. The developer may transfer it to a controlled Mac for long-term performance analysis and manually delete it when no longer needed. A source IP may be used briefly for in-memory rate limiting, but is not written to telemetry files or used as a persistent identifier.
Visibility and purpose: you can inspect the exact upload content under App Logs > Performance Telemetry. Diagnostic addresses require the dSYM from the matching Xcode Cloud build. Data is used only to locate battery, heat, hang, launch, memory, disk, and network performance problems—not for advertising, user profiling, or training chat models.
7. Third-Party Services, Analytics, and Server Boundaries
Third-party AI providers: process the chat, image, and audio requests that you intentionally send.
Apple system services: such as WatchConnectivity and iCloud / CloudKit are governed by Apple’s own policies.
Developer-operated feedback service: used only when you intentionally submit or refresh feedback tickets.
Developer-operated performance telemetry service: automatically receives the non-content data listed in Section 6 while performance telemetry is enabled.
Not uploaded automatically: chat content, local memory, local request and response logs, annual recap data, and API keys are not automatically uploaded to developer-controlled servers.
Ads and general analytics SDKs: apart from the MetricKit performance telemetry described in Section 6, the codebase does not include third-party ad SDKs or general-purpose behavioral analytics SDKs.
Apple analytics sharing: if you choose to share analytics with developers at the system level, Apple may collect anonymous crash logs or diagnostic information under Apple’s own rules.
8. Disclaimer
Neutral tool: this app is a general LLM client. It may prefill some service endpoints or feedback service addresses, but it does not ship with ready-to-use commercial model credentials.
Content responsibility: all AI-generated output comes from third-party providers you configure yourself. We cannot guarantee the accuracy, legality, or suitability of that output.
Service choice: any API service, sync capability, or feedback service you use should be evaluated by you based on its own privacy policy, terms, cost, and risks.
9. Contact Us
If you have any questions about this Privacy Policy, please contact: