Skip to main content
@talosjs/cache gives you one interface, ICache, with two backends sitting behind it: the filesystem and Redis. Both expose the same methods (get, set, delete, deleteByPrefix, has, clear), so code you wrote against the filesystem keeps working after you point it at Redis. Values are JSON-serialized for you, and any key can carry a TTL. A few things worth knowing up front: get<T>() and set<T>() thread your value type through serialization, so reads come back typed. TTLs are in seconds and per-key. deleteByPrefix() wipes a whole group of related keys at once, while clear() empties everything. And you register a cache class with a decorator, then pull it out of the container wherever you need it.

How it works

You pick a backend (or write your own) and register it. Reads and writes go through the ICache methods, and the backend takes care of serialization, namespacing, and expiration. The built-in backends differ in where data lives, not in how you call them: A TTL of 0 (or omitted) means the entry never expires. Redis backends namespace every key (default cache:) to avoid collisions on a shared instance.

Environment variables

FilesystemCache needs no environment variables; it defaults to a .cache directory in the working directory.

Usage

The API is the same regardless of backend.
A common pattern is read-through caching: serve from the cache, fall back to the source on a miss, then populate it for next time.
Invalidate on writes so callers never read stale data:

Decorator and usage

@decorator.cache()

Registers a cache class with the container. It accepts an optional scope (defaults to singleton). Use it to register a built-in backend under your own name, or a custom backend that implements ICache.
Resolve it from the container and inject it where needed:

Exceptions

The component throws CacheException when a backend is misconfigured or an operation fails. It carries a machine-readable key, a human-readable message, and a data object.

A few habits that pay off

Pick a stable key scheme such as user:123 or session:abc. The structure isn’t cosmetic — it’s what lets deleteByPrefix() find and clear related entries later. Give volatile data an explicit TTL. Anything derived or fetched from elsewhere should expire on its own so a stale value can’t linger forever, and invalidate the key whenever its source changes. For derived keys, pair delete() with a deleteByPrefix() to catch the rest. Keep stored values JSON-friendly. They round-trip through JSON.stringify/JSON.parse, so class instances, functions, and circular references won’t survive the trip. Treat a cache read as best-effort, too: on a miss, go to the source of truth rather than assuming the key is there. Choosing a backend is mostly an environment decision. Filesystem is fine for local work; Redis is the one you want when several instances share a cache. The calling code doesn’t change either way. And in a custom backend, throw CacheException with a constant key and stash the variable detail in data.

CLI command

Scaffold a cache adapter and its test file with the generator. It writes the class under modules/<module>/src/cache/<Name>Cache.ts and installs @talosjs/cache if it is missing.
The generated class starts as an ICache stub, ready for you to implement each method against your backend:
See cache:create for the full command reference.

Use with Claude and Codex

The generator ships a matching cache:create skill. It runs the scaffold and then guides your AI agent through completing the adapter — implementing get, set, delete, and has against a real backend and wiring up its client. Initialize the skills once for your agent:
Then ask Claude in natural language — it maps the request to the generator, runs it, and fills in the implementation:
Prompt
For example, the prompt above maps to cache:create --name=Session, then implements the ICache methods against a Redis client.