Your Daily AI Stew from Robin, on Salty Talk. Today we start with a ChatGPT HTML-preview exploit, move to how coding agents organize work, then look at local inference trade-offs and an experiment that puts a small model inside a larger one.
A message slipped past ChatGPT's preview sandbox
How can HTML that should be locked inside a preview window reach private account data? Parameter Labs described a ChatGPT exploit chain that joined several normally separate pieces: the HTML preview sandbox, MathLive's virtual-keyboard message interface, and a YouTube endpoint allowed by the content-security policy.
The problem appeared when a message crossed the window boundary. Researchers found that MathLive's virtual-keyboard interface accepted postMessage requests from an iframe, while the parent page inserted the received content with innerHTML. An attacker could use that path to create a new iframe without sandbox restrictions, then use the permitted YouTube oEmbed endpoint to execute JavaScript under ChatGPT's own origin. The boundary meant to isolate untrusted content was bypassed.
According to the researchers, before the fix a signed-in user who opened a malicious ChatGPT share link could trigger the chain. The script could call APIs for private data, exfiltrate it through an image reference, and act on the user's behalf. OpenAI closed the issue and paid a $5,000 bug bounty. The lesson for developers is the message handling outside the sandbox: isolating preview content is not enough; how the parent accepts messages from it determines whether the isolation holds. Source: Simon Willison
Prospero gives coding agents a native desktop
Moving from the preview window to the development window, nullprogram's Prospero tries another coding-agent experience. It uses C++ and Dear ImGui to build a native graphical interface and move the tool layer that generates, checks, and edits code into a desktop application.
Prospero supports Windows, macOS, and Linux, connects to local or remote models, and offers subagents, MCP, desktop control, and prepackaged task instructions called skills. The practical question is how developers work alongside an agent: how a task is assigned, how output is inspected, and how the next operation is started.
The discussion also reaches concrete interface details. Some developers want to click an agent's output and open the relevant file in a sidebar; others want asynchronous batch answers and richer prompt orchestration. Reports say Prospero uses roughly two orders of magnitude less memory than a typical Web stack, but the available material does not provide a formal benchmark. For now, the interesting question is whether a native interface can make agent operations easier to organize, not whether the performance claim is settled. Source: nullprogram
DeepSeek Harness sends repository requests to independent sessions
The interface is only one part of the problem. How should several agents work around the same codebase? DeepSeek Harness published “Exploring Super-agent Design: Towards a More Autonomous Agent System” and released a runnable portion of the design in the dsh-superagent-prototype repository.
The research prototype focuses on one GitHub repository and uses a router-worker pattern: a router turns permitted requests from GitHub, or optionally Feishu, into work items that can run in parallel, then assigns them to separate agent sessions. It gives developers something concrete to inspect — how an entry point receives a request, how the router splits and dispatches it, and how each worker session handles its part.
The project is MIT-licensed and is a design-validation prototype, not an official DeepSeek product. The public version was adapted for release and differs from the internal implementation; some ideas in the article remain future directions. Its value is as a runnable sample for experimenting with multi-session collaboration in one repository and with agents that proactively suggest fixes. Source: Reddit r/LocalLLaMA
tandem.cpp keeps common experts on the GPU
After talking about agents, let us look at how models run locally. tandem.cpp is an independent llama.cpp patch for single-user decoding. It keeps frequently used mixture-of-experts (MoE) experts on the GPU and sends the rest to system memory for CPU-assisted computation. The project is not affiliated with ggml-org.
An MoE model activates only part of its experts for each token, but it still needs somewhere to store every candidate expert's weights. tandem.cpp targets models that do not fit entirely in VRAM and tries to improve decoding speed through expert placement. In the author's tests on an i5-12400F, 64 GB of DDR4, and an RTX 4090, greedy decoding for Qwen3.8-Flash-Next with IQ3_S plus MTP rose from 29.8 to 97.3 tokens per second over llama.cpp, about 3.3 times faster; gpt-oss-120b rose from 27.8 to 51.5.
Those are self-reported results on limited consumer hardware, and the current implementation is tuned specifically for Qwen3.8. The deployment idea is concrete: when VRAM cannot hold every expert, study which experts should stay on the GPU and which should be computed by the CPU. The gain still needs to be measured against the exact model, quantization, and machine. Source: Reddit r/LocalLLaMA
Betelgeuse lets the SSD join expert scheduling
What happens when system memory is tight as well? Reddit user /u/zyxciss says the Betelgeuse llama.cpp branch ran a 68 GB quantized Qwen 3.8 Flash Next, using GSQ-RCO-IQ2_XS, on a CachyOS/Arch Linux system with an RTX 3060 12 GB, single-channel 16 GB DDR4, and MemoryMax=12G.
The author reports 16.80 tokens per second on the first decode, 22.03 sustained, and local peaks of 48 without pruning experts. The source does not distinguish runs, warm-up, or workload conditions, so the first-token and sustained figures should not be treated as a controlled cold-versus-warm comparison. The system keeps dense layers and other components in about 3.2 GB of VRAM, then uses expert slots, a RAM cache, and an io_uring pager to schedule weights while reducing physical SSD reads to 12.43 MiB per token.
The author also says that 28,080 routing records and 576 generated tokens matched the unmodified output byte for byte. For small-VRAM, small-memory machines, the experiment is about moving weights among VRAM, RAM, and NVMe while retaining every selected routing expert. The cost is a specialized expert loader: the reduced files are not directly usable with stock llama.cpp, Ollama, or LM Studio. These are author-reported results without a complete method description or independent reproduction. Source: Reddit r/LocalLLaMA
Basalt asks what the speedup left out
The previous two items were about where experts live and how they move. Basalt's developer pushes the question to the output: how much quality does it cost to change expert selection to reduce transfers? The tests used Qwen 3.8 Flash Next on RTX 5090 and RTX 5060 Ti systems with 128 GB of DDR5, comparing exact quantization with routing bias and tail-expert skipping.
Routing bias favors experts already resident on the GPU; tail skipping omits low-ranked experts that are not in VRAM. Both reduce transfers, but both change which experts take part in the original computation. In a test using only an RTX 5090 with the expert cache limited to 5 GB to simulate small VRAM, IQ3_S prose throughput rose from 192 to 299 tokens per second, while the ladder score fell 5.2 points and factual accuracy fell 2.3 percentage points.
With more aggressive settings, Q8_0 factual accuracy fell from 38.1% to 2.7%, with nonsense answers and loops. With enough VRAM, the optimizations barely changed NVFP4 speed, from 272 to 271 tokens per second. The result depends on the configuration and operating point. The author notes that the experiment covers one hardware setup and one model, uses one seed for the ladder task and three for the factual task, and measures speed in a single cold run. Basalt currently disables these switches by default and displays a warning. The practical question for local inference is simple: when throughput improves, did the selected experts — and the final answer — change too? Source: Reddit r/LocalLLaMA
QwenPU puts a small language model inside Qwen weights
The final item changes the question from “where does the model run?” to “what can run inside the model?” Developer divagr18's QwenPU proof of concept compiles a 32-bit RISC-V CPU and vector unit directly into Qwen 3.5-4B weights, uses Gated DeltaNet state as memory, and runs Andrej Karpathy's 260,000-parameter stories260K inside the outer model.
The small model has 260,000 parameters and is itself a C program. Its weights live in Qwen's own memory, with no external tool required. The NPU that performs matrix multiplication, softmax, and attention is also compiled into the outer model weights, and all three implementations are bit-exact. The experiment puts the CPU, memory, and vector operations inside the model and uses them to carry another language model's computation.
The material available for this episode says the code and weights are public, while the full technical article is still being written and the developer is still optimizing performance and size. The snapshot has no benchmark, so it cannot establish the project's current speed or memory efficiency. It is a reproducible research example of a model inside a model, not yet evidence of a production deployment advantage. Source: Reddit r/LocalLLaMA
Taken together, today's stories expose concrete engineering problems both outside and inside models: HTML previews must protect message boundaries; coding agents must organize interfaces and work dispatch; local inference must place weights carefully and check whether speed changes the output. QwenPU moves computation into the model itself. That is today's Daily AI Stew — a look at how these systems run and at the trade-offs each design brings.
🎧 This episode is also available as a podcast: listen to Daily AI Stew · 2026-11-02.
