Introducing Image Caching

We’re updating our Terms of Service to introduce a new feature designed to speed up your image generation experience: Image Caching.

**What’s Changing?
**When you upload images for e.g., character references or base images, our service will now temporarily encrypt & cache these input images with a client-provided encryption key. If you reuse the same image across multiple generations — such as using the same character reference for a series of images — your browser won’t need to re-upload those images each time you click generate.

We’re approaching this temporary image storage with the same privacy-first mindset we’ve had from day one. Cached images are fully encrypted, and no one — including us — can read them without a secret key that stays only in your browser. We never store or log this key.

When you generate an image using a cached image, your browser sends the key so we can decrypt the image only for that request. Once generation finishes, we discard the decrypted image and the key. In practice, this is the same privacy model as re-uploading the image each time: we can only access the image data while we’re processing your request, and not before or after.

For more technical details, keep reading.

**Why are we doing this?
**Over the past few weeks, we have been investigating timeouts that a small percentage of our users have been randomly experiencing when generating images. We’ve found that this appears to be related to general “slow network” issues when large image generation requests are transmitted across the internet from your browser to our servers. While image caching does not fix the internet, it should alleviate the symptoms. The smaller the request, the better.

Plus, even for “good” network conditions, image caching will reduce the overall delay you experience when using the same images across multiple generations.

Technical Privacy Breakdown
We understand that temporarily storing uploaded images sounds concerning, so we want to take a moment to explain the encryption scheme:

When the frontend uploads an image for an image generation request, it now provides an encryption key that is derived from the raw image data and a temporary un-guessable session secret that is stored only in memory in your browser (and nowhere else). When you close your NovelAI tab, that encryption secret is lost, and any images cached on our end become effectively irrecoverable. Each cached image gets its own encryption key.

Our servers take that client-provided secret key, enhance it with our own server-side secret (to protect against 3rd party clients using weak keys via API), and then encrypt the raw image with that final encryption key. Encrypted cached images are stored within CoreWeave, our trusted provider that much of our infrastructure is already running on.

Encryption keys are never stored or logged anywhere on our servers.

To decrypt the cached encrypted image, the frontend provides the image’s secret key with each generation request. The backend keeps the secret in memory only while handling the image generation request, and discards it (along with the decrypted image) once the request is finished.

The caching duration of cached images is short. We’re still experimenting with the most economical TTL, but it is in the realm of a few hours. Once you stop using an image, the encrypted cached data is automatically deleted. To ensure we never keep the encrypted images around longer than needed, even in failure scenarios, we have two independent and redundant mechanisms in place that clean up encrypted image data.

As always, the encryption algorithms we use are taken from reviewed, industry-standard libraries. At the time of writing, we use a combination of HMAC, SHA256, and AES-256-GCM to derive the encryption keys and encrypt the images.