This media is not supported in your browser
VIEW IN TELEGRAM
Gemini 3 is live
Thought signatures are encrypted representations of the model's internal thought process and are used to preserve reasoning context across multi-turn interactions. All responses include a thought_signature field. As a general rule, if you receive a thought signature in a model response, you should pass it back exactly as received when sending the conversation history in the next turn. Failure to circulate thought signatures may cause the response to fail. Check the thought signature documentation for more explanations of signatures overall.
https://ai.google.dev/gemini-api/docs/image-generation#thought-signatures
https://ai.google.dev/gemini-api/docs/thought-signatures
https://ai.google.dev/gemini-api/docs/image-generation#thought-signatures
https://ai.google.dev/gemini-api/docs/thought-signatures
may be a stupid question but, why is there no context handling system that just discards tokens from processing if they are not deemed required so that it doesn't clutter with useless tokens?
Do It by Code
may be a stupid question but, why is there no context handling system that just discards tokens from processing if they are not deemed required so that it doesn't clutter with useless tokens?
The short answer is: we are trying to build exactly that, but it is incredibly difficult to define "useless" before it's too late.
In fact, there is a lot of active research into this (techniques like "Token Pruning," "Sparse Attention," or "Selective Context"), but they haven't become the standard yet for a few specific reasons.
### 1. The "Whodunit" Problem (Predicting Relevance)
The main issue is that a token's "usefulness" is not a static property. A word that seems like filler in sentence 1 might be the critical key to understanding a reference in sentence 50.
* Dynamic Importance: To know if a token is useless, the model effectively has to "read" it and understand its relationship to the *future* response. By the time it has done the math to figure out "I don't need this," it has already spent the compute processing it.
* Hindsight is 20/20: Systems that do this often have to guess. If they guess wrong and discard a token that turns out to be crucial later, the model creates a "hallucination" or loses coherence because the context is literally missing.
### 2. The "Attention Sink" Phenomenon
This is a really weird quirk of how Transformer models (the architecture behind GPT, Claude, Gemini) work mathematically.
* Researchers found that models often dump a huge amount of "attention" score onto tokens that seem meaningless (like the very first token in a sentence, or random punctuation).
* If you delete these "useless" tokens, the model's math breaks down and it starts spewing nonsense. These are called "Attention Sinks." The model essentially uses these tokens as a garbage dump for extra probability mass so it doesn't get confused. You can't just delete them without retraining the model to handle it.[1]
### 3. It Breaks the Flow
Language is a sequence.[1] Even "useless" filler words (like "um," "so," "basically") carry prosody and structural information that helps the model maintain a conversational rhythm.
* If you aggressively strip these out, the model might turn into a keyword-generating robot rather than a fluent assistant.
* LazyLLM & Sparse Attention: There are newer techniques (like *LazyLLM* or *H2O*) that try to dynamically keep only the "heavy hitters" (tokens that get high attention scores) and drop the rest. This is working in labs, but deploying it at scale without degrading quality is still a massive engineering hurdle.
### Summary
We essentially have to choose between speed/efficiency (pruning tokens) and intelligence/accuracy (keeping everything just in case). Currently, it's safer to just "eat" the cost of processing useless tokens than to risk throwing away the one key detail that changes the answer.
===
Citations:
===
Model: Gemini 3 Pro (Preview) (high reasoning, with search)
In fact, there is a lot of active research into this (techniques like "Token Pruning," "Sparse Attention," or "Selective Context"), but they haven't become the standard yet for a few specific reasons.
### 1. The "Whodunit" Problem (Predicting Relevance)
The main issue is that a token's "usefulness" is not a static property. A word that seems like filler in sentence 1 might be the critical key to understanding a reference in sentence 50.
* Dynamic Importance: To know if a token is useless, the model effectively has to "read" it and understand its relationship to the *future* response. By the time it has done the math to figure out "I don't need this," it has already spent the compute processing it.
* Hindsight is 20/20: Systems that do this often have to guess. If they guess wrong and discard a token that turns out to be crucial later, the model creates a "hallucination" or loses coherence because the context is literally missing.
### 2. The "Attention Sink" Phenomenon
This is a really weird quirk of how Transformer models (the architecture behind GPT, Claude, Gemini) work mathematically.
* Researchers found that models often dump a huge amount of "attention" score onto tokens that seem meaningless (like the very first token in a sentence, or random punctuation).
* If you delete these "useless" tokens, the model's math breaks down and it starts spewing nonsense. These are called "Attention Sinks." The model essentially uses these tokens as a garbage dump for extra probability mass so it doesn't get confused. You can't just delete them without retraining the model to handle it.[1]
### 3. It Breaks the Flow
Language is a sequence.[1] Even "useless" filler words (like "um," "so," "basically") carry prosody and structural information that helps the model maintain a conversational rhythm.
* If you aggressively strip these out, the model might turn into a keyword-generating robot rather than a fluent assistant.
* LazyLLM & Sparse Attention: There are newer techniques (like *LazyLLM* or *H2O*) that try to dynamically keep only the "heavy hitters" (tokens that get high attention scores) and drop the rest. This is working in labs, but deploying it at scale without degrading quality is still a massive engineering hurdle.
### Summary
We essentially have to choose between speed/efficiency (pruning tokens) and intelligence/accuracy (keeping everything just in case). Currently, it's safer to just "eat" the cost of processing useless tokens than to risk throwing away the one key detail that changes the answer.
===
Citations:
[1] lesswrong.com
===
Model: Gemini 3 Pro (Preview) (high reasoning, with search)
Critical RCE Vulnerabilities in React and Next.js
Severity: 10/10
- react blog
- github advisory
- vercel blog
- fix-react2shell-next (quick fix repo by vercel)
#rce #react #nextjs #cve
Severity: 10/10
The important part to know:
- Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.
- The vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack
- Some React frameworks and bundlers depended on, had peer dependencies for, or included the vulnerable React packages. The following React frameworks & bundlers are affected: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.
- react blog
- github advisory
- vercel blog
- fix-react2shell-next (quick fix repo by vercel)
#rce #react #nextjs #cve
Do It by Code
Critical RCE Vulnerabilities in React and Next.js Severity: 10/10 The important part to know: - Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components. - The vulnerability…
from HN comments:
our exploitation tests so far have shown that a standard Next.js application created via create-next-app and built for production is vulnerable to CVE-2025-66478 without any specific code modifications by the developer - so this is essentially exploitable out-of-the-box.
our exploitation tests so far have shown that a standard Next.js application created via create-next-app and built for production is vulnerable to CVE-2025-66478 without any specific code modifications by the developer - so this is essentially exploitable out-of-the-box.
Do It by Code
Critical RCE Vulnerabilities in React and Next.js Severity: 10/10 The important part to know: - Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components. - The vulnerability…
wow vercel is emailing all of their users about it
"of two competing theories, the simpler explanation of an entity is to be preferred."
https://en.wikipedia.org/wiki/Occam%27s_razor
https://en.wikipedia.org/wiki/Occam%27s_razor
Do It by Code
Critical RCE Vulnerabilities in React and Next.js Severity: 10/10 The important part to know: - Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components. - The vulnerability…
apparently there are so many AI-generated slop PoC out there for this that it takes hours to find a proper working PoC among them
most of them are just nonsense
I found a few that don't seem to be AI slop:
- msanft/CVE-2025-55182
- acheong08/CVE-2025-55182-detection
- mrknow001/RSC_Detector
- emredavut/CVE-2025-55182
one of the AI-generated ones made its way to the official cve website and people complained in its issue section
most of them are just nonsense
I found a few that don't seem to be AI slop:
- msanft/CVE-2025-55182
- acheong08/CVE-2025-55182-detection
- mrknow001/RSC_Detector
- emredavut/CVE-2025-55182
one of the AI-generated ones made its way to the official cve website and people complained in its issue section