Privacy Policy

Effective date: 2026-08-21

1. What Libyx is

Libyx is a local desktop application for translating EPUB books using large-language-model (LLM) APIs. There is no Libyx server, no Libyx cloud account, and no backend operated by this project. Everything Libyx does happens on your machine or directly between your machine and your chosen LLM provider.

2. What data Libyx stores on your machine

All files Libyx creates or modifies are stored under your user data directory:

• macOS: ~/Library/Application Support/Libyx/
• Windows: %LOCALAPPDATA%\Libyx\

Files stored there include:

Libyx does not create any other files outside this directory (aside from temporary files that are cleaned up on startup).

3. What data leaves your machine

Your EPUB content — book text, chapter contents, and any custom instructions you provide — is sent directly from your machine to the LLM provider you have configured (Anthropic, OpenAI, Mistral, Google, DeepSeek, OpenRouter, or an OpenAI-compatible endpoint you point Libyx at yourself). Libyx acts as a local client: it formats the requests and sends them over your internet connection. No copy of this traffic passes through any Libyx server, because no such server exists.

Providers differ in where that text is processed, and the choice of model is therefore also a choice of jurisdiction. Mistral is EU-hosted; DeepSeek processes your text on servers in China. Libyx states this on the DeepSeek key screen as well, but it is worth repeating here.

The Libyx project never receives, sees, processes, or stores any of your book content, translation output, or API requests.

What goes to each provider, how they use it, and how long they retain it is governed by their own terms and privacy policies — see §6.

4. API keys

You supply your own API keys for each LLM provider you use. Libyx stores these keys in api_keys.json inside your user data directory, with file-system permissions restricted to your user account (mode 0600 on macOS/Linux; restricted to your user via the %LOCALAPPDATA% ACL on Windows). Keys are read into memory at runtime and injected as environment variables into the Python sidecar process. They are not written to any other location, logged, or transmitted anywhere except to the corresponding provider's API endpoint when making requests.

You are responsible for securing your machine and your user account. If you believe a key has been compromised, revoke it in the provider's console and set a new one in Libyx Settings.

5. Logs

Libyx writes a rotating log file (sidecar.log) to your data directory. The active log is capped at 2 MB; up to 3 rotated backup copies are kept. Logs record pipeline events, errors, and debug information. They do not contain your API keys (keys are redacted before any log write). They do contain file paths, book metadata, and translation progress details. When you fetch an article in Collect, the log also records that page's host name and title, and the address of any picture that could not be fetched.

Logs stay on your machine at all times. If you use the Report a bug feature in Settings, Libyx generates a diagnostic report from the log tail and your current app state. Before the report is shown to you:

• Your user name is removed from home-directory paths: /Users/you/Books/x.epub becomes /Users/<USER>/Books/x.epub. The rest of the path is kept, because it is what makes a fault legible.
• In the report's job section, book title, author, and filename are replaced with <REDACTED>.
• The attached log tail is path-redacted only. It can still contain book titles, file names, and the host names and titles of articles you fetched in Collect.

You control whether to copy and share that report — read it before you send it. Nothing is sent automatically.

6. Third-party LLM providers

When you add an API key for a provider, you enter into a direct relationship with that provider. Libyx has no visibility into how providers handle the data you send them. You are responsible for reading each provider's terms of service and privacy policy before use:

Different providers have different data-retention and training-use policies. Some offer opt-outs or zero-data-retention tiers via their API. Review those options directly with each provider.

If you use a custom OpenAI-compatible endpoint, there is no third party to name here: the text goes to the address you entered, and whatever runs there is governed by whoever runs it — you, if it is on your own machine.

7. Telemetry and analytics

Libyx collects no telemetry, usage analytics, crash reports, or diagnostic data of any kind.

Automatic update checks. A few seconds after Libyx starts, it contacts https://libyx.app/updates/latest.json once to ask whether a newer version exists. That request transmits: your IP address (visible to the server) and standard HTTP metadata — a User-Agent naming the updater component that makes the call. It carries no Libyx version number: which version you are running is compared on your own machine, against the same file everyone else receives. (Measured on the server's own request log, 2026-09-03.) No API keys, book content, glossary data, or file paths are transmitted. It happens once per launch — there is no repeating background check — and Settings has a button that asks the same question by hand. There is currently no setting that switches the launch check off; if the machine is offline, or the address cannot be reached, the request fails quietly and Libyx carries on.

The News panel. A few seconds after Libyx starts, it also contacts https://libyx.app/news.json once, to fetch the short list of notices behind the News button in the top-right corner — things like a provider's API being down, or a known problem in the version you are running. It transmits your IP address, the Libyx version number (in the User-Agent, unlike the update check above), and standard HTTP metadata. Nothing is sent about you, and nothing is sent back to the Libyx project: the file is the same static file for everyone. Where a notice concerns a single provider, or a particular range of versions, Libyx decides on your own machine whether it applies to you, after downloading the whole list — so the fact that you use one provider and not another never leaves your computer. Once per launch, no repeating background check. The last copy fetched is kept on disk so the panel still works offline; if the address cannot be reached, the request fails quietly and Libyx shows what it fetched last.

Provider status. In the same few seconds after Libyx starts, it also contacts https://libyx.app/status.json once. That file says whether each LLM provider's own status page is currently reporting a problem — Libyx reads it so you can tell "my key is out of credit" from "the provider is down", and shows the result in the News panel. It is the same kind of request as the News fetch above, and transmits the same three things: your IP address, the Libyx version number, and standard HTTP metadata. Libyx never contacts a provider's status page itself — a request straight to Anthropic's or OpenAI's status page would tell them your IP, and the pattern of which pages you asked for would tell them which providers you hold keys for. Instead one file covering all of them is fetched, and your own machine picks out the providers you use, after the download. Once per launch, no repeating background check — deliberately, because a status check that repeated while a translation ran would reveal how long your translation took. The last copy fetched is kept on disk so the panel still works offline.

Pictures in pasted articles. When you paste an article into Collect and it contains pictures, those pictures are not part of what your computer copied — the text carries only their web addresses. If you leave "Fetch pictures" switched on, Libyx requests each of those addresses over your internet connection so the pictures can be stored inside the article. The sites hosting them see your IP address and the User-Agent of the HTTP client Libyx uses; no cookies, no login, and nothing identifying you are sent. No record of what you collect leaves your machine, and Libyx never requests an address that was not in the article in front of you. Switch the option off and the article is created without them, with a marker where each picture stood.

Fetching an article from its address. Collect also accepts a web address instead of pasted text, in two places. In both, Libyx makes one request to that address from your machine — following redirects, as a browser does — and reads the article out of the page that comes back. That request identifies itself as a desktop browser, because a page you could already open in your browser is exactly what it is asking for; it carries no cookies, no login, and nothing about you beyond the IP address any visit would show. There is no intermediary: your machine talks to the site directly, and no record of what you fetch reaches the Libyx project or anyone else. If the site will not hand the page to a program, Libyx says so, nothing is kept, and it suggests opening the page in your browser and pasting instead.

Where a fetched article lands, and what happens to its pictures. The two places differ, and the difference is worth knowing. Paste an address into the field at the top of the Collect tab, press Add, and the article is filed straight into your pile once it arrives — you are not shown it first, and its pictures are always requested, because the Fetch pictures switch belongs to the paste dialog and does not reach that field. Press Paste text… instead and the Fetch button in the dialog that opens puts what comes back in front of you, in the same field a paste would land in — shown, not stored — so nothing enters your pile until you press Add to pile, and there the Fetch pictures switch decides whether pictures are requested. Either way the article stays on your machine, and you can read, rename or remove it from the pile afterwards.

Aside from the update check, the News panel, the provider-status check, and the two Collect requests described above, every outbound network call Libyx makes goes to an LLM provider you have configured yourself — or to the endpoint address you entered, if you use a custom one.

Apart from the three checks at launch described above, every network call Libyx makes originates from something you did (translating a book, saving settings that validate an API key, pasting an article that contains pictures, or fetching one from its address).

8. GDPR and data-controller role

Libyx is a local processing tool. The Libyx project does not collect, receive, or control any personal data you process with the application. The project therefore does not act as a data controller or data processor under the GDPR in relation to your content.

When you send book content to an LLM provider, you (the user) are the party initiating that processing. The provider's role depends on your agreement with them. Libyx is the tool you use to initiate that transfer — it is not a party to the relationship between you and the provider.

If your use of Libyx involves personal data (e.g., translating documents that contain names, addresses, or other personal information), you are responsible for ensuring that your use of the relevant LLM provider complies with applicable data-protection law.

9. Children

Libyx is not directed at children under 13 (or under 16 where EU law sets a higher threshold). If you are a parent or guardian and believe a child has used Libyx to send content to an LLM provider, contact that provider directly — Libyx has no copy of the data.

10. Changes to this policy

This policy may be updated in future Libyx releases. Changes will be visible in the project's git history. Once the repository is made public, you can view the full revision history at the project URL. Continued use of a version of Libyx that ships an updated policy constitutes acceptance of that update.

11. Contact

Questions about this privacy policy: [email protected]