Very interesting. The state management is the really insightful find here. I always wondered how these large AI companies managed access for millions of simultaneous users without having to allocate a dedicated LLM instance for each user. Pushing the complete state down to the user after every call makes perfect sense. The LLM itself stays memoryless and ready to respond to an arbitrary prompt. Very nice.
Fooling around with encrypted reasoning blobs
21–30 of 36 posts
Re: Fooling around with encrypted reasoning blobs
#22Earlier quoted context omitted.
the exchange rate between text and its representation in memory is brutal. here's a bit from a recent article: >An 82 GB footprint in DDR3 on a 2016 Xeon. About 25 GB of weights and 56 GB of KV cache at the full 262K context. The KV cache is larger than the model. 262k tokens is not much at all. with ~5 characters per token, that's only 1.3 MB of plaintext.
The providers must have a more efficient approach. Most cache every request for 12+ hours, and they certainly can't spare 100GB of ram per request for 12 hours.
have things changed around this recently? I know openai optionally allows 24 hours but thought it was ~1h without that, and anthropic used to quote 5-15 minutes or something.
Re: Fooling around with encrypted reasoning blobs
#23Awesome write-up. Seems like a great way to play with model responses now that prefill is gone.
Re: Fooling around with encrypted reasoning blobs
#24Very interesting. The state management is the really insightful find here. I always wondered how these large AI companies managed access for millions of simultaneous users without having to allocate a dedicated LLM instance for each user. Pushing the complete state down to the user after every call makes perfect sense. The LLM itself stays memoryless and ready to respond to an arbitrary prompt. Very nice.
While it seems like a good idea, resending a growing context window is very inefficient and costly. Instance pinning would make a huge efficiency gains but also collapse LLM provider revenue. This is something open models could better solve.
Re: Fooling around with encrypted reasoning blobs
#25Very interesting. The state management is the really insightful find here. I always wondered how these large AI companies managed access for millions of simultaneous users without having to allocate a dedicated LLM instance for each user. Pushing the complete state down to the user after every call makes perfect sense. The LLM itself stays memoryless and ready to respond to an arbitrary prompt. Very nice.
N.B. This is exactly how seaside, vba, and even arc[1] do server-side state generally : by encrypting the blob-representing-state and sending to the client to be sent back on future requests (where it will be decrypted and rehydrated). It's an old trick that everyone designing protocols should know, since there are lots of applications beyond AI companies. [1]: As in, pg's lisp: https://arclanguage.github.io/ref/srv.…
Re: Fooling around with encrypted reasoning blobs
#26Earlier quoted context omitted.
The providers must have a more efficient approach. Most cache every request for 12+ hours, and they certainly can't spare 100GB of ram per request for 12 hours.
> 12 hours have things changed around this recently? I know openai optionally allows 24 hours but thought it was ~1h without that, and anthropic used to quote 5-15 minutes or something.
The #1 was to make Claude code token quota go further is to never let the 5 minute cache TTL expire. Either send a new request within the window, or use /clear and copy/paste, or use /clear and a framework that automatically generates session state that gets replayed from files after /clear.
Re: Fooling around with encrypted reasoning blobs
#27Earlier quoted context omitted.
N.B. This is exactly how seaside, vba, and even arc[1] do server-side state generally : by encrypting the blob-representing-state and sending to the client to be sent back on future requests (where it will be decrypted and rehydrated). It's an old trick that everyone designing protocols should know, since there are lots of applications beyond AI companies. [1]: As in, pg's lisp: https://arclanguage.github.io/ref/srv.…
And don't forget the venerable .NET Forms with its kilobytes of __VIEWSTATE
cute
Re: Fooling around with encrypted reasoning blobs
#28Re: Fooling around with encrypted reasoning blobs
#29Why do reasoning blocks even get encrypted? Reasoning can’t contain information that is more ‘sensitive’ than assistant response. It is annoying to be not able to see reasoning tokens.
Re: Fooling around with encrypted reasoning blobs
#30Why do reasoning blocks even get encrypted? Reasoning can’t contain information that is more ‘sensitive’ than assistant response. It is annoying to be not able to see reasoning tokens.
Yeah, I get that you can jailbreak and get that info anyway. Also that this is specific to front ends like web chat and less about API usage. But as a sibling points out it's also a good way to make post training other models harder. Mostly a "win/win" for the provider.