No, I think the comment you're responding to is actually correct. Look at this quote from the Anthropic blog post again:
> The design should have been simple: if a session has been idle for more than an hour, we could reduce users’ cost of resuming that session by clearing old thinking sections. Since the request would be a cache miss anyway, we could prune unnecessary messages from the request to reduce the number of uncached tokens sent to the API. We’d then resume sending full reasoning history. To do this we used the clear_thinking_20251015 API header along with keep:1.
They clearly make the same distinction between the cache and the context. They're saying "we could reduce users’ cost of resuming that session by clearing old thinking sections". They intentionally created a behavior different between cached and uncached requests, specifically they clear thinking sections from the context for requests that miss the cache.
What would be the point of embedding Redis into an application? What's the advantage of using Redis over using the builtin (or third party) data structures of the language the application is developed in?
I'm asking as a non-webdev who never quite got what Redis actually does, but would love to learn.
To me the thing I like about Redis is that it gives you a storage engine very suitable for caches; it handles TTLs and memory pressure, as well as built-in serialization with the ability to get better performance by allowing for some data loss. At the same time, many users will be deploying small programs to individual machines. If you could just have Redis be embedded this would make it very operationally simple: no additional daemons and a single file to backup if you want to.
It would also be useful because of the ability to switch modalities. When running a multi node service, you can use Redis to share data between nodes and use Redis pubsub as a communication bus. If you wanted to support a simple single node configuration too, then it wouldn't need to be a special case, it could just go through the same mechanism but with an embedded Redis instance.
It's pretty similar to SQLite: being able to embed more or less a complete storage engine into your app can be very convenient and powerful.
Well the most basic redis replacement would be just a global hashmap to replace GET and SET, possibly with a background thread to periodically delete expired keys. But obviously that stops working as soon as you get a second node.
The entire value of redis IMO is that is ISN'T inside your normal application, but rather some shared storage that all nodes can use to coordinate and that survives deploys, but that provides more ergonomic data structures than SQL databases. Caches are only one type of such shared data, but things like feature flags, circuit breakers and rate limiters are also super common (and super useful).
Neat. Write that up, match parity, and give all the function calls with the same name as redis, and you're both happy! You get to hand roll something, he gets to use a library that others have perfected over the years!
Unfortunately I have never really used Erlang outside of deploying RabbitMQ. I mostly use Go, Rust, Python, sometimes C/C++.
However, Mnesia seems like it is quite a bit more of a complete distributed database engine than Redis. To me the nicest thing about Redis is just the convenience of what it offers: very fast data structures, serialized, optimized (at least by default) for cases where speed is more important than durability. It is simple on many levels and somewhat constrained in scope. Mnesia seems to be aiming more generally in the distributed database category.
Really it would be more like Nebulex/Cachex which provide a really nice caching interface across ETS (what Mnesia is built off of) or other data stores.
Probably because Redis gives you a very well-defined/understood set of rich data structures with built-in behavior like TTL, atomic operations, eviction, and persistence. These things are otherwise usually scattered across native types, helper classes, or entirely separate libraries.
Language's own native data-structures are generally much more capable and vast. 99%+ developers use only a very limited set of those capabilities. This approach packages those most used ones into a nice, consistent DSL.
It's similar in effect to what busybox does to shell utilities, though the motives are different.
Doesn’t depend on the language? Actually I am thinking of the standard library… Python’s in kinda huge and some are hard (for me) to grasp. Golangs seem pretty simple.
Can you name a single language that can talk to redis and doesn't have these in a form of a library that integrates with an app better than mystical embedded redis?
Every language you can talk to redis most likely has a library to do that, and it probably works much better with the rest of application than "embedded redis". If it doesn't, it probably has C-FFI and there is "fast, robust and well understood" implementations in C.
Sure. But if Redis was embeddable you'd get a robust C-FFI style implementation of those data structures which has been tested a lot more than some random library that has almost no existing users or active maintenance.
(I'm not personally sold on embedded Redis myself, but the question was "Aren’t your own programming language’s constructs much more well-defined / understood?")
> you'd get a robust C-FFI style implementation of those data structures which has been tested a lot more than some random library that has almost no existing users or active maintenance.
What are these mystical random libraries you're talking about? There is a solid C implementation of every data structure on this planet.
Why does it need to be pure C? There are C++ implementations. It's an algorithm not a social media app, it doesn't need to be updated once a week, C also not node.js - it doesn't break compatibility every release. What is wrong with these 10+ years touched ones?
Even the redis version of HLL isn't updated all that often.
That's exactly what I'm arguing for here: it would be useful if Redis data structures like that were available to be easily embedded in other programs.
"You can just adapt X from Redis" is the whole point of this hypothetical.
A few nice things about doing this in no particular order:
Embedding would make local dev/CI integration testing convenient.
Embedding replicated Redis with each application instance would give you HA benefits while infra-management complexity.
Embedded redis (even via local RPC) is still going to be faster than a lot of languages or frameworks’ built-in data structures. Large array operations in, say, Python are gonna slower than RPCing to Redis (assuming that the data structures are built gradually and not built all at once); to beat Redis you’d have to use numpy or something—-which is definitely preferable, but is extra work if your app already uses Redis for other things.
Just like choosing SQLite over e.g. LMDB or RocksDB, embedded Redis would be a nice future proofing option for small apps during the prototype phase; less would have to be changed to move Redis out of the app than if a different cache or persistence service were chosen.
I have 15 processes handling API requests over HTTP. I want rate limiting, so users don't DoS my API. I need shared state across these processes to store information about rate limits for each client key. I store those in redis.
Or queues, caching, pub/sub... Redis can do a lot, it's really (and i mean really) fast, very easy to get up and running and the protocol is pretty simple.
Network hops are not free! Those milliseconds are an eternity compared to local function calls.
The optimal architecture is something like what Service Fabric or Orleans can do with their distributed dictionary types: reads are generally in-process and take only nanoseconds (but writes require a synchronous replica copy to a remote host.)
Obviously this requires load balancers to steer traffic consistently, but that’s a common feature… outside of the public clouds where they forgot latency exists.
A typical (meaningful) example might be communication between threads or actors in a single process, or idempotent tests.
As with SQLite, an external xxx that does this for you is certainly better, etc. but it’s convenient sometimes, to have an application that doesn’t go “now before you run this install Postgres…”.
It’s seldom useful for a web app where you control everything.
In practice, mostly scaling sessions and ephemeral data (caching) across multiple intances of a microservice on multiple machines. Seperating the kv store and the application allows upgrading each application while retaining availability and avoiding loss of session data.
I mostly use redis for pub/sub communication between services. If the app wasn't a collection of knative functions, and instead a monolith, it would be cool to also use redis for event based communication.
For simple cases, it is probably a total overkill to even consider it, but for something heavier, embedding the database gives you a chance to trivially migrate later to a separate database server.
A key-value database, or key-value store, is a data storage paradigm designed for storing, retrieving, and managing associative arrays, a data structure more commonly known today as a dictionary.
Using this sampling-based approach you get correct covariance modeling for free. You have to only sample leaf values that are used in multiple places once per evaluation, but it looks like they do just that: https://github.com/mattt/Uncertain/blob/962d4cc802a2b179685d...
Memory efficiency just for one. For most programs, and especially in the embedded space, 64b systems carry around (and process) a lot more zeros than 32b systems do. You can still do 64b math when you need it, but you don’t have to pay for it when you don’t.
Given that software is always too big, this can often be a product-making distinction.
32 bit is still very common for smaller CPUs that aren't in the "application processor" class.
They are cheaper because they use less area, and they're also more memory efficient because pointers are all half as big. On these CPUs you don't have 4GB of RAM so you don't need a big address space.
It's good enough for the majority of use cases and systems; even an eight bit MCU is sufficient for many cases. If you design a product, saving power and cost makes the difference.
As far as I know, webassembly only supports a 32 bit address space on all platforms at the moment. There’s a memory64 proposal, but it doesn’t look to be widely adopted yet.
That switch-case gets optimized and compiled down to logic gates by the synthesis tools. It'll be a different set of gates from the original netlist (which might also have used a more regular grid structure for this), but it won't be _that_ different. It's not somehow running this switch-case in software emulation on a different CPU instantiated in this design.
> The design should have been simple: if a session has been idle for more than an hour, we could reduce users’ cost of resuming that session by clearing old thinking sections. Since the request would be a cache miss anyway, we could prune unnecessary messages from the request to reduce the number of uncached tokens sent to the API. We’d then resume sending full reasoning history. To do this we used the clear_thinking_20251015 API header along with keep:1.
They clearly make the same distinction between the cache and the context. They're saying "we could reduce users’ cost of resuming that session by clearing old thinking sections". They intentionally created a behavior different between cached and uncached requests, specifically they clear thinking sections from the context for requests that miss the cache.
reply