🏡

August 22, 2026
1. 🔗 WerWolv/ImHex Nightly Builds release
  Nightly
  
  9d34b95 Changelog
  - fix: Guard BACKTRACE_HEADER check
  - fix: Get proper size for disk partitions on Windows
  - build: Add elfutils stacktrace backend on Linux
  - fix: Set ImGui GetMouseDragDelta lock threshold to 0 (#2858)
  - fix: Cursor getting snapped to end of line unexpectedly on higher scaling factors
  - impr: Give diff view a proper border
  - build: Fix use of plugs in classic snap
  - fix: Focus not getting restored correctly when interacting with menu bar
  - fix: Crash on exit due to stored http request
  - fix: Exporting of disassembly listing skipping instructions with no mnemonic
August 21, 2026
1. 🔗 PrimeIntellect-ai/prime-agent Beta (v0.8.0-beta.543.1.e319a66) release
  
  Automated beta build from main (e319a66d7351c75abe7f040d02d9a8d6e25028e9).
2. 🔗 smol-machines/smolvm smolvm v1.9.2 release
  What's Changed
  - Relocate libkrun.dylib's Homebrew dylib references to @loader_path so macOS packed launchers boot by @BinSquare in #1013
  - Point the install.sh sync note at the real website path so the website copy is kept in sync by @BinSquare in #1017
  - Widen the read window for the whole flatten so a large pack does not fail with a spurious EAGAIN by @Bnjoroge1 in #957
  - Name machine options that were written after -- instead of silently ignoring them by @Bnjoroge1 in #958
  - Skip the /workspace fallback for volumes mounted below it, not only at it by @NickyHeC in #1005
  - Support automatic CUDA replay and distributed multi-GPU execution by @BinSquare in #998
  - Use as_chunks instead of chunks_exact with a constant size in the gpu_loopback example so clippy passes by @BinSquare in #1019
  - Reject unknown fields on the exec and run API so a mis-cased safety field can't be silently dropped, and clarify that --storage bounds the writable disk by @BinSquare in #1018
  - Grow an existing storage/overlay disk to the requested size instead of booting the stale one by @Bnjoroge1 in #956
  - Bump libkrun to the build with aarch64-KVM snapshot and fork support so machine fork works on Linux aarch64 by @BinSquare in #1021
  - Stage archive-flatten scratch on the storage disk instead of the guest tmpfs by @BinSquare in #1014
  - Bump the workspace to 1.9.2 by @BinSquare in #1022
  Full Changelog : v1.9.1...v1.9.2
3. 🔗 PrimeIntellect-ai/prime-agent v0.8.0 release
  - Fixed an OAuth login that finishes after its server was retargeted arming the old-endpoint token against the new URL: credentials are endpoint-bound at issuance, and the host and kernel only use a token bound to the configured endpoint. Breaking : generic MCP OAuth credentials stored before this release lack the binding and require one /mcp login <server>.
  - Fixed mcp add keeping a stored mcp:<name> credential when the entry was new: any add now drops the name's credential, so tokens for authored non-catalog skills (e.g. slack) cannot replay to a user-configured URL.
  - Fixed kernel MCP shutdown budgets exceeding the host's kill deadline; graceful close now finishes inside it, and a kernel that exits without a shutdown_reply no longer stalls shutdown for the full deadline.
  - Fixed a shutdown race that could leave an MCP server process running after its generation was dropped from the registry.
  - Fixed the kernel MCP regression test and the Python runtime tests not running in CI.
  - Fixed first IPython calls after an upgrade failing with a raw "Operation was not possible or timed out": kernel startup now tolerates cold venv boots (30s budget; crashes still fail fast via the exit handler), and zmq socket-teardown rejections surface as actionable retriable kernel errors.
  - Fixed headless completion reporting a clean finish when a post-compaction continuation failed to start: ACP and print-mode idle waiters now see the failure, while interactive idle behavior is unchanged.
  - Added a pre-imported generic MCP API and shell/TUI commands to manage persistent Streamable HTTP and stdio servers in user settings.
  - Breaking : removed the documented catalog-name override — an mcpServers entry named after a built-in integration (e.g. linear) no longer repoints the built-in at a custom url/bearerTokenEnvVar; it now disables the built-in skill and is not served by the generic runtime. Rename the entry (e.g. linear-proxy) to keep using a custom endpoint via the generic API. This closes a credential-replay surface where name-keyed tokens could be sent to an override URL.
  - Fixed agents overlooking enabled generic MCP connections by advertising their names and pre-imported mcp API usage in the system prompt.
  - Fixed /mcp management feedback disappearing during resource reload and limited server details in TUI output to names and transports.
  - Fixed credentials configured as env var names resolving to the literal variable name when the variable is set but empty; an empty env var now reports a missing credential (#1468).
  - Fixed ACP rejecting an immediate follow-up prompt when injected work restarted the session; follow-ups now queue behind in-flight work, and cancellation drops queued follow-ups before they start.
  - Added correlated ACP terminal-quiescence metadata, resident session settlement, and fail-closed daemon input fencing; prevented recovery state from persisting runtime credentials or model configuration.
  - Fixed explicit RLM child deletion leaving hidden unsettled work after runtime teardown, including reporting cleanup failures and notifying the parent when deletion completes.
  - Added changelog fragments (packages/<pkg>/.changes/*.md) with a CI check and release-time aggregation, eliminating [Unreleased] merge conflicts.
  - Fixed the queued-message browse controls (Option+Up) rendering in the same style as typed prompt text inside the input box; the header is now dimmed like other hints so it cannot be mistaken for part of the prompt.
  - Fixed IPython kernels and forkserver processes outliving their owner after a hard crash: kernels now arm ipykernel's parent-death poller via JPY_PARENT_PID, the forkserver watches its parent pid, and both pids are registered in the orphan process journal for supervisor recovery.
  - Fixed a pid-reuse race for forked IPython kernels: signaling and liveness now go through the forkserver (the kernels' parent) instead of raw pid operations from Node, and the orphan journal's inactive record is only written on a confirmed kill outcome.
  - Added session-scoped ACP MCP servers through the kernel MCP program API (#1378 by @hallerite).
  - Changed the subagents summary under the prompt into a bordered agents tile with color-coded running/idle/inactive counts and a right-aligned open hint.
  - Enabled /fast with OpenAI API-key authentication for GPT-5.4/GPT-5.5/GPT-5.6 and updated the unavailable message (#1595).
  - Fixed /goal re-prompting a parent that had correctly delegated to subagents and ended its turn: the continuation now waits until descendant work settles, then resumes automatically.
  - Changed post-compaction continuation error classification to typed AgentContinueError codes instead of matching error message text.
  - Fixed the working-status elapsed timer (e.g. "Waiting · 5s") restarting at 0s after leaving and re-entering a session or re-attaching to it; the timer is now anchored to the in-flight turn's user message and keeps counting.
  - Added a session_before_refine extension hook: extensions can replace /refine and auto-refine planning with their own proposal (for example using a cheaper model — see examples/extensions/custom-refinement.ts) or skip a refinement round; rollbacks bypass the hook and extension edits go through the normal apply-time validation. Also documents refine_complete.
  - Added a durable [refinement] transcript message after each refinement showing the applied harness edits (expandable to exact before/after diffs via the shared tool-output toggle), and a live loader while a user-issued /refine runs.
  - Fixed the Agents View heartbeat refresh failing entirely ("Cannot list heartbeats while session worker is failed") when any resident worker was terminally failed: failed workers are now excluded from the global catalog while recovering and disconnected workers still fail closed.
  - Refreshed MCP providers immediately after server changes so OAuth connections can be started without restarting Prime Agent.
4. 🔗 backnotprop/plannotator v0.27.6 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  v0.27.5 | Annotate your running app, Agent TUI placement, collapsed lockfiles, VS Code theme fix, Pi fixes
  v0.27.4 | Portable Guided Review exports, guides.show share links, guide CLI, favicon switcher, jj Call Flow
  v0.27.3 | Folder watcher freeze fix on large repos, first SBOM-attested release pipeline
  v0.27.2 | Mobile plan and code review, Codex CLI 0.147 fix, folder annotate cold-start, configurable markdown extensions
  v0.27.1 | Open-in-editor launch fix, file headers respect Viewed/Git-add visibility toggles
  v0.27.0 | Call Flow analysis, --tailscale remote reviews, review panel remembers your view, Pi rebuild (breaking command rename), focus-mode shortcut
  v0.26.8 | Placed comment markers on HTML pages, shift-click multi-select, live app annotation
  v0.26.7 | Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing
  v0.26.6 | Fixed empty environment variables in sandboxed sessions (Bun 1.3.14 builds)
  v0.26.5 | HTML pinpoint element annotations, durable annotate submissions, installer fallback for old git, vim HUD cursor fix
  v0.26.4 | Skill-menu hover jitter fix (same-day patch on v0.26.3)
  v0.26.3 | Skill references in comments with / or $, reachable remote session URLs, worktree switcher tooltips
  
  What's New in v0.27.6
  
  You can now annotate your running app. Point plannotator annotate at a localhost URL and the actual application opens inside the annotate UI: click any element to comment on it, press Esc to use the app normally, and send it all back to your agent. This works on Claude Code and Pi. The release also brings configurable Agent TUI placement, collapsed lockfiles in code review, and a wave of fixes across Pi, VS Code, and the annotation surface. Nineteen PRs, three from first-time contributors.
  
  Note: v0.27.6 is v0.27.5 plus same-day Pi support for live app annotation; these notes cover both.
  
  Annotate your running app
  
  plannotator annotate http://localhost:5173 no longer converts the page to a snapshot. A per-session loopback proxy mirrors your dev server and opens the real, running app inside the annotate UI, hot reload and SPA navigation included. Click any element to pin a comment on it, shift-click to join more elements into the same comment, and use placed numbered markers to track everything. --static forces the old conversion; --app forces live mode and fails loudly if the server is not reachable.
  
  The security boundary is deliberate: the proxy binds loopback only, validates the Host header before touching your app, authenticates every message between the page and the editor with a per-session token, and refuses to run at all in remote or tailnet-published sessions (use --static there). Live sessions write no session content to disk beyond your annotation draft, which is keyed per target app.
  
  Pi users get the same feature. The proxy's decision logic (injection, host validation, security gates, redirect handling) lives in one shared core used by both server runtimes, and the Pi extension ships its own Node transport with every security guard test-covered, including working hot reload through the proxied WebSocket. /plannotator-annotate http://localhost:5173 on Pi opens the live app.
  
  One behavior change to know: under PLANNOTATOR_REMOTE, annotating a localhost URL previously converted the page silently. It now exits with a clear message asking for --static, because silently converting when you asked for the live app hides what you are actually reviewing.
  
  This closes the oldest open feature request in the tracker. Thanks @JulianS- Uni for the original ask in #642, and @notxcain, who saw this feature early and built the first working take on a preview proxy in #1049 before we landed a from-scratch implementation.
  - #1352, #1363, #1364, #1366 by @backnotprop, closing #642
  One interaction model for HTML and live pages
  
  HTML and live-app annotate sessions now open with annotation armed: hover outlines what you are pointing at, a click opens the comment composer. Press Esc and you are in interact mode, where clicks, forms, and navigation reach the page itself. The pen button in the header (or Mod+Shift+A) re-arms annotation, text selection comments work in both modes, and the eye button hides every floating control when you just want to read. These surfaces are comment-only now: the markup-delete and label tools were markdown concepts that never fit pages, and removing them made the whole flow simpler. On phones and tablets the same controls live in the Options menu.
  
  This also fixes the class of bug where a JS-driven page could not be used at all during annotation, reported by @Chrysweel in #1360 for slide decks.
  - Part of #1352 and #1363, closing #1360
  Put the Agent TUI where you want it
  
  The annotate-mode agent terminal can now dock Left or Right, or stay Hidden until you ask for it. The preference persists in ~/.plannotator/config.json, and the terminal's Position control lives in its Display popover with a matching entry in Settings. A bug fix rides along: entering wide mode used to unmount the terminal and kill a running agent session; it now stays alive in the background.
  - #1050 by @leoreisdias
  Lockfiles stop burying your review
  
  Generated files (lockfiles, minified bundles, source maps, and anything marked linguist-generated in .gitattributes) now start collapsed in the all-files review view, the way GitHub treats them. The patch itself is never filtered; a visible notice shows what was collapsed and one click expands any of it.
  - #1346 by @backnotprop, closing #1317 reported by @FluxxField
  Your VS Code theme choice wins
  
  The VS Code extension used to force the IDE's colors onto the panel, so choosing Plannotator's light theme in a dark IDE gave you a broken mix. Now your chosen theme always wins and only the System setting follows the IDE, with a one-time migration so panels upgraded from older versions follow a light IDE again instead of being stuck on an auto-seeded dark.
  - #1357, #1362 by @backnotprop, closing #1053 reported by @it-sha
  Pi fixes
  
  Three fixes for the Pi extension. thinking: "max" in phase config is accepted now (the whitelist predated Pi adding the level) and unrecognized values warn instead of vanishing, closing #1304 reported by @edision. Hosts that do not expose Pi's project- trust capability get an honest warning instead of being told to update Pi, closing #1353 reported by @materemias from OMP. And turning plan mode off can no longer leave stale planning instructions steering the session, closing #1320 reported by @nwhitley-trAIner.
  - #1356, #1355, #1348 by @backnotprop
  Additional Changes
  - Shift+1-4 switches annotation mode from the keyboard, and the shortcuts yield when you are typing into the comment toolbar. #1244 by @galmadar
  - The review annotation toolbar stays on screen when the sidebar is closed, clamped exactly to the viewport. #1354 by @unexge
  - Concurrent settings writes no longer lose changes : config saves take a bounded advisory lock, and two server processes sharing a data dir both land their writes. Part of #1364
  - guides.show touches : two real example guides linked on the landing page, a "Made with Plannotator" link in the viewer header, and a footer credit to diffs.com. #1339, #1340, #1342, #1347
  - Docs caught up with the code : the annotate command page covers live apps, and the config reference documents the new Agent TUI settings. #1361
  - Security scanning : guides.show share links are allowlisted in gitleaks so encrypted share URLs stop tripping secret scanning. #1343
  Install / Update
  
  macOS / Linux:
```
curl -fsSL https://plannotator.ai/install.sh | bash
```
  Windows:
```
irm https://plannotator.ai/install.ps1 | iex
```
  Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".
  
  Pi: Update @plannotator/pi-extension to 0.27.6 and restart Pi.
  
  OpenCode: Clear cache and restart:
```
rm -rf ~/.bun/install/cache/@plannotator
```
  What's Changed
  - guides-show: drop the @ redirect on the 2x screenshot, credit diffs.com in the footer by @backnotprop in #1339
  - guides-show: "Made with Plannotator" link in the viewer header by @backnotprop in #1340
  - guides-show: link two real example guides under the screenshot by @backnotprop in #1342
  - ci(security): allowlist guides.show share links in gitleaks by @backnotprop in #1343
  - feat(review): collapse generated files by default in the all-files view by @backnotprop in #1346
  - guides-show: landing copy fix by @backnotprop in #1347
  - fix(pi): countermand stale plan-mode instructions on toggle-off by @backnotprop in #1348
  - feat(ui): Shift+1-4 shortcuts to switch annotation mode by @galmadar in #1244
  - feat(annotate): live local app annotation through a loopback reverse proxy by @backnotprop in #1352
  - fix(review): clamp annotation toolbar to viewport by @unexge in #1354
  - fix(pi): accept Pi's full thinking-level range and warn on unknown values by @backnotprop in #1356
  - fix(vscode): user-chosen theme wins over IDE theme sync by @backnotprop in #1357
  - fix(pi): honest capability warning when the host lacks ctx.isProjectTrusted by @backnotprop in #1355
  - feat(annotate): configurable Agent TUI placement with durable config and Hidden state by @leoreisdias in #1050
  - docs: align AGENTS.md and public docs with the v0.27.5 behavior by @backnotprop in #1361
  - fix(vscode): migrate the legacy auto-seeded dark theme cookie to system by @backnotprop in #1362
  - fix(annotate): armed-mode interaction fixes from the v0.27.5 QA gate by @backnotprop in #1363
  - fix(server): live-proxy injection and config write hardening by @backnotprop in #1364
  - feat(pi): live local app annotation through a shared proxy core and Node transport by @backnotprop in #1366
  New Contributors
  - @leoreisdias made their first contribution in #1050
  - @galmadar made their first contribution in #1244
  - @unexge made their first contribution in #1354
  Contributors
  
  Three first-time contributors landed code in this release. @leoreisdias built the Agent TUI placement feature, and it arrived alongside a stack of other PRs from them that are working through review; more of that work lands soon. @galmadar added the Shift+1-4 annotation mode shortcuts. @unexge fixed the review toolbar drifting off screen, with before/after recordings that made the review easy.
  
  @notxcain gets a special mention: their PR #1049 was the first working take on live localhost annotation, months before this release shipped it. We missed the PR at the time, which was our failure, not theirs.
  
  Community reports that shaped this release:
  - @JulianS-Uni requested website annotation in #642, the oldest request closed by this release
  - @Chrysweel reported slide decks being unusable during annotation in #1360
  - @it-sha reported the VS Code light theme bug in #1053
  - @edision reported the ignored thinking: "max" setting in #1304
  - @materemias filed the detailed OMP compatibility report in #1353
  - @FluxxField requested collapsed generated files in #1317
  - @nwhitley-trAIner reported the plan-mode toggle bug in #1320
  - @felipebn shared the OpenCode per-agent model config pattern in #1059
  Full Changelog : v0.27.4...v0.27.6
5. 🔗 backnotprop/plannotator v0.27.5 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  v0.27.4 | Portable Guided Review exports, guides.show share links, guide CLI, favicon switcher, jj Call Flow
  v0.27.3 | Folder watcher freeze fix on large repos, first SBOM-attested release pipeline
  v0.27.2 | Mobile plan and code review, Codex CLI 0.147 fix, folder annotate cold-start, configurable markdown extensions
  v0.27.1 | Open-in-editor launch fix, file headers respect Viewed/Git-add visibility toggles
  v0.27.0 | Call Flow analysis, --tailscale remote reviews, review panel remembers your view, Pi rebuild (breaking command rename), focus-mode shortcut
  v0.26.8 | Placed comment markers on HTML pages, shift-click multi-select, live app annotation
  v0.26.7 | Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing
  v0.26.6 | Fixed empty environment variables in sandboxed sessions (Bun 1.3.14 builds)
  v0.26.5 | HTML pinpoint element annotations, durable annotate submissions, installer fallback for old git, vim HUD cursor fix
  v0.26.4 | Skill-menu hover jitter fix (same-day patch on v0.26.3)
  v0.26.3 | Skill references in comments with / or $, reachable remote session URLs, worktree switcher tooltips
  v0.26.2 | Single-file diff tabs render fully, no more silently dropped review files, light/dark theme pairs, palette-matched code blocks
  
  What's New in v0.27.5
  
  You can now annotate your running app. Point plannotator annotate at a localhost URL and the actual application opens inside the annotate UI: click any element to comment on it, press Esc to use the app normally, and send it all back to your agent. This release also brings configurable Agent TUI placement, collapsed lockfiles in code review, and a wave of fixes across Pi, VS Code, and the annotation surface. Eighteen PRs, three from first-time contributors.
  
  Annotate your running app
  
  plannotator annotate http://localhost:5173 no longer converts the page to a snapshot. A per-session loopback proxy mirrors your dev server and opens the real, running app inside the annotate UI, hot reload and SPA navigation included. Click any element to pin a comment on it, shift-click to join more elements into the same comment, and use placed numbered markers to track everything. --static forces the old conversion; --app forces live mode and fails loudly if the server is not reachable.
  
  The security boundary is deliberate: the proxy binds loopback only, validates the Host header before touching your app, authenticates every message between the page and the editor with a per-session token, and refuses to run at all in remote or tailnet-published sessions (use --static there). Live sessions write no session content to disk beyond your annotation draft, which is keyed per target app.
  
  One behavior change to know: under PLANNOTATOR_REMOTE, annotating a localhost URL previously converted the page silently. It now exits with a clear message asking for --static, because silently converting when you asked for the live app hides what you are actually reviewing.
  
  This closes the oldest open feature request in the tracker. Thanks @JulianS- Uni for the original ask in #642, and @notxcain, who saw this feature early and built the first working take on a preview proxy in #1049 before we landed a from-scratch implementation.
  - #1352, #1363, #1364 by @backnotprop, closing #642
  One interaction model for HTML and live pages
  
  HTML and live-app annotate sessions now open with annotation armed: hover outlines what you are pointing at, a click opens the comment composer. Press Esc and you are in interact mode, where clicks, forms, and navigation reach the page itself. The pen button in the header (or Mod+Shift+A) re-arms annotation, text selection comments work in both modes, and the eye button hides every floating control when you just want to read. These surfaces are comment-only now: the markup-delete and label tools were markdown concepts that never fit pages, and removing them made the whole flow simpler. On phones and tablets the same controls live in the Options menu.
  
  This also fixes the class of bug where a JS-driven page could not be used at all during annotation, reported by @Chrysweel in #1360 for slide decks.
  - Part of #1352 and #1363, closing #1360
  Put the Agent TUI where you want it
  
  The annotate-mode agent terminal can now dock Left or Right, or stay Hidden until you ask for it. The preference persists in ~/.plannotator/config.json, and the terminal's Position control lives in its Display popover with a matching entry in Settings. A bug fix rides along: entering wide mode used to unmount the terminal and kill a running agent session; it now stays alive in the background.
  - #1050 by @leoreisdias
  Lockfiles stop burying your review
  
  Generated files (lockfiles, minified bundles, source maps, and anything marked linguist-generated in .gitattributes) now start collapsed in the all-files review view, the way GitHub treats them. The patch itself is never filtered; a visible notice shows what was collapsed and one click expands any of it.
  - #1346 by @backnotprop, closing #1317 reported by @FluxxField
  Your VS Code theme choice wins
  
  The VS Code extension used to force the IDE's colors onto the panel, so choosing Plannotator's light theme in a dark IDE gave you a broken mix. Now your chosen theme always wins and only the System setting follows the IDE, with a one-time migration so panels upgraded from older versions follow a light IDE again instead of being stuck on an auto-seeded dark.
  - #1357, #1362 by @backnotprop, closing #1053 reported by @it-sha
  Pi fixes
  
  Three fixes for the Pi extension. thinking: "max" in phase config is accepted now (the whitelist predated Pi adding the level) and unrecognized values warn instead of vanishing, closing #1304 reported by @edision. Hosts that do not expose Pi's project- trust capability get an honest warning instead of being told to update Pi, closing #1353 reported by @materemias from OMP. And turning plan mode off can no longer leave stale planning instructions steering the session, closing #1320 reported by @nwhitley-trAIner.
  - #1356, #1355, #1348 by @backnotprop
  Additional Changes
  - Shift+1-4 switches annotation mode from the keyboard, and the shortcuts yield when you are typing into the comment toolbar. #1244 by @galmadar
  - The review annotation toolbar stays on screen when the sidebar is closed, clamped exactly to the viewport. #1354 by @unexge
  - Concurrent settings writes no longer lose changes : config saves take a bounded advisory lock, and two server processes sharing a data dir both land their writes. Part of #1364
  - guides.show touches : two real example guides linked on the landing page, a "Made with Plannotator" link in the viewer header, and a footer credit to diffs.com. #1339, #1340, #1342, #1347
  - Docs caught up with the code : the annotate command page covers live apps, and the config reference documents the new Agent TUI settings. #1361
  - Security scanning : guides.show share links are allowlisted in gitleaks so encrypted share URLs stop tripping secret scanning. #1343
  Install / Update
  
  macOS / Linux:
```
curl -fsSL https://plannotator.ai/install.sh | bash
```
  Windows:
```
irm https://plannotator.ai/install.ps1 | iex
```
  Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".
  
  OpenCode: Clear cache and restart:
```
rm -rf ~/.bun/install/cache/@plannotator
```
  What's Changed
  - guides-show: drop the @ redirect on the 2x screenshot, credit diffs.com in the footer by @backnotprop in #1339
  - guides-show: "Made with Plannotator" link in the viewer header by @backnotprop in #1340
  - guides-show: link two real example guides under the screenshot by @backnotprop in #1342
  - ci(security): allowlist guides.show share links in gitleaks by @backnotprop in #1343
  - feat(review): collapse generated files by default in the all-files view by @backnotprop in #1346
  - guides-show: landing copy fix by @backnotprop in #1347
  - fix(pi): countermand stale plan-mode instructions on toggle-off by @backnotprop in #1348
  - feat(ui): Shift+1-4 shortcuts to switch annotation mode by @galmadar in #1244
  - feat(annotate): live local app annotation through a loopback reverse proxy by @backnotprop in #1352
  - fix(review): clamp annotation toolbar to viewport by @unexge in #1354
  - fix(pi): accept Pi's full thinking-level range and warn on unknown values by @backnotprop in #1356
  - fix(vscode): user-chosen theme wins over IDE theme sync by @backnotprop in #1357
  - fix(pi): honest capability warning when the host lacks ctx.isProjectTrusted by @backnotprop in #1355
  - feat(annotate): configurable Agent TUI placement with durable config and Hidden state by @leoreisdias in #1050
  - docs: align AGENTS.md and public docs with the v0.27.5 behavior by @backnotprop in #1361
  - fix(vscode): migrate the legacy auto-seeded dark theme cookie to system by @backnotprop in #1362
  - fix(annotate): armed-mode interaction fixes from the v0.27.5 QA gate by @backnotprop in #1363
  - fix(server): live-proxy injection and config write hardening by @backnotprop in #1364
  New Contributors
  - @leoreisdias made their first contribution in #1050
  - @galmadar made their first contribution in #1244
  - @unexge made their first contribution in #1354
  Contributors
  
  Three first-time contributors landed code in this release. @leoreisdias built the Agent TUI placement feature, and it arrived alongside a stack of other PRs from them that are working through review; more of that work lands soon. @galmadar added the Shift+1-4 annotation mode shortcuts. @unexge fixed the review toolbar drifting off screen, with before/after recordings that made the review easy.
  
  @notxcain gets a special mention: their PR #1049 was the first working take on live localhost annotation, months before this release shipped it. We missed the PR at the time, which was our failure, not theirs.
  
  Community reports that shaped this release:
  - @JulianS-Uni requested website annotation in #642, the oldest request closed by this release
  - @Chrysweel reported slide decks being unusable during annotation in #1360
  - @it-sha reported the VS Code light theme bug in #1053
  - @edision reported the ignored thinking: "max" setting in #1304
  - @materemias filed the detailed OMP compatibility report in #1353
  - @FluxxField requested collapsed generated files in #1317
  - @nwhitley-trAIner reported the plan-mode toggle bug in #1320
  - @felipebn shared the OpenCode per-agent model config pattern in #1059
  Full Changelog : v0.27.4...v0.27.5
6. 🔗 @binaryninja@infosec.exchange Hopefully you won't need this one very often, but Sidekick 26.1 now has mastodon
  
  Hopefully you won't need this one very often, but Sidekick 26.1 now has Revert. Sidekick already groups related database changes into transactions. Now you can view those changes as a diff and revert any committed transaction without having to unwind everything that came after it. More here: https://sidekick.binary.ninja/blog/sidekick-26-1-a-proper-home-for- sidekick/#revert-for-when-you-need- it
7. 🔗 smol-machines/smolvm smolvm v1.9.1 release
  What's Changed
  - Use as_chunks instead of chunks_exact with a constant size across the workspace by @BinSquare in #1008
  - Make image pulls work behind a proxy: thread it through the init bake and inherit it from the environment by @BinSquare in #1007
  - Join a keep-alive container for fork-clone exec instead of launching a fresh container each call by @BinSquare in #1009
  - Keep a forkable golden forkable across a config-change VM restart by @BinSquare in #1010
  - Rebuild a damaged imported layer cache from the source artifact instead of trusting the extraction marker by @BinSquare in #994
  - Bump the workspace to 1.9.1 by @BinSquare in #1012
  Full Changelog : v1.9.0...v1.9.1
8. 🔗 r/LocalLLaMA DeepSeek-V4-Flash-Vision-Exp rss
  
  | submitted by /u/Xhehab_
  [link] [comments]
  ---|---
9. 🔗 Rust Blog Enabling the next-generation trait solver on nightly rss
  After nearly 4 years of active development, the next-generation trait solver is close to stabilization. We are enabling it by default on nightly to surface any remaining issues and plan to stabilize it in the next months. This is the largest single change to the Rust compiler since its initial release. It completely replaces how we prove where-clauses, normalize associated types, and much more. Please try out the latest nightly andopen an issue if you encounter any bugs or regressions.
  
  This is an internal component of the compiler. The main benefits of this rework will come in the future. The removal of the old implementation will unblock features such as Type Alias Impl Trait and Return Type Notation, allow us to add new implicit default trait bounds (e.g., Move and Forget), and enable us to fix the remaining type system unsoundnesses.
  
  Even so, this already fixes a huge number of issues. As an underapproximation, we currently know of more than 200 issues on GitHub fixed by this change. This also has a significant impact on compile times; more on that later. When developing on nightly, you may accidentally rely on behavior only supported by the new trait solver.
  
  This is an incredibly big change which results in a non-trivial amount of breakage. Most of these changes are intended improvements to type inference or the removal of undesirable behavior. We are tracking the known issues and breakage in a pinned GitHub issue.
  
  What can I do?
  
  Please update to the latest nightly version by using rustup update nightly and use it to test your existing projects and libraries.
  
  ⚠️ While the next-generation trait solver has been enabled on our main branch, this change will only be accessible on the nightly channel starting from Saturday 22nd August. You can already test it before then by providing -Znext-solver=globally as a command-line argument ⚠️
  
  Please tell us if you encounter any breakage, compile-time performance regression, or bad diagnostics. We have not yet spent too much time on error messages for the next-generation trait solver, so we would also appreciate you using this nightly for development to find poor diagnostics and other bugs in our error handling.
  
  If you encounter any issue, take a quick look at the pinned GitHub issue to see if the affected crate is already listed, and if not, please open a new issue! To disable the next-generation trait solver on nightly, you can pass -Znext- solver=coherence to rustc, use RUSTFLAGS=-Znext-solver=coherence, or change your project's .cargo/config.toml configuration file:
```
[build]
rustflags = ["-Znext-solver=coherence"]
```
  What exactly does this mean?
  
  We will go into more detail about the next-generation trait solver, how we got here, and what it changes when fully stabilizing it. This is a quick summary of its main impact.
  
  impl Trait handling
  
  The way opaque types — return-position impl Trait (RPIT), but also the unstable Type Alias Impl Trait (TAIT) and Return Type Notation (RTN) — are handled in the type system has nearly completely changed. This fixes a lot of bugs and edge cases with them and should make their behavior a lot more consistent in general. This change is why the next-generation trait solver is necessary to stabilize TAIT and RTN.
  
  The implementation change mostly does not matter for RPIT as we special-cased impl Trait from the method signature when type checking the method body. This means the only way to observe the old behavior is via recursive function calls. The following snippet errors with the existing implementation, but compiles with -Znext-solver enabled: godbolt
```
fn foo(b: bool) -> impl Sized {
    if b {
        // The old implementation errored here.
        foo(false) + 1
    } else {
        0
    }
}
```
  Associated types in higher-ranked types
  
  The most impactful change is way we handle associated types referencing bound variables, i.e., lifetimes from a for<'a> binder, for example, the type for<'a> fn(<T as Trait>::Assoc<'a>). While most users don't encounter such types directly, there are widely used crates which do. This change impacts existing code by removing incorrect type inference, such as in bevy and minijinja.
  
  It also fixes a bunch of unnecessary errors like in the following example: godbolt
```
trait OtherTrait {
    type Assoc<'a>;
}
impl OtherTrait for u32 {
    type Assoc<'a> = &'a u32;
}


trait Trait {}
impl<T: OtherTrait> Trait for (T, for<'a> fn(<T as OtherTrait>::Assoc<'a>)) {}


fn impls<T: Trait>() {}

fn main() {
    // The old implementation failed to prove
    // the where-bound of `impls`.
    impls::<(u32, for<'a> fn(&'a u32))>();
}
```
  Compile-time performance
  
  co-authored with jana :3
  
  We've spent a lot of time on the compile-time performance of the next- generation trait solver. There have been many cases where it performed quadratically or even exponentially slower than the old solver.
  
  Especially the last few weeks were mainly spent on improving performance. This work was shared by many people, with major contributions by Nick Nethercote, jana, Rémy Rakic, and mira.
  
  As part of this effort, Rémy Rakic compared the performance of both implementations for the top 20,000 crates on crates.io. Below you is a visualization of the performance changes over the last two months.
  
  On the left and the right, the major outliers can be found. Note that the sample of crates here is biased towards such crates, because those are more interesting to us. Nearly all crates we tested in the top 20k had effectively the same performance with both implementations.
  
  This graph shows that we've mainly focused our efforts on the negative outliers and made significant progress there. While many of the crates that previously took more than twice as long to compile with the new solver are still slightly slower, our work has made a few of them actually compile faster than with the old solver.
  
  We will continue to improve its performance over the coming months, and there are still a lot of optimization opportunities compared to the existing implementation. My expectation is that, in the long term, nearly all crates will benefit from the next-generation trait solver. I am especially excited about the huge performance benefits for some trait-heavy crates.
  
  As an example, a Chess implementation in Rust's type system hangs with the old implementation while taking a minute with the new one. There are also more practical crates with huge performance benefits, e.g., the datafusion crate compiles more than 8x faster now. For more details about the recent performance work, see this blog post by jana.
  
  Again, thank you for testing with the latest nightly and opening a GitHub issue if you encounter any issues! We're excited to fully stabilize the next-generation trait solver soon.
10. 🔗 matklad Rust Glancer rss
  Rust Glancer
  
  Aug 21, 2026
  
  Rust Glancer, a functional LSP server for Rust which uses two orders of magnitude less RAM, is incredibly cool. Go check it out! This post started as a comment on lobste.rs, but I figured it out that it’s better to publish it somewhat more prominently. Don’t expect polished writing though!
  
  Some thoughts:
  
  rust-analyzer uses rowan for syntax tree representation
  
  Yeah, rowan is garbage :P I was really thinking about
  - incremental parsing,
  - incremental, DOM-mutation style refactorings,
  And Rowan is pretty good for that. But that’s 1% use case. The 99% use case is all the code in your 6666 dependencies which you won’t ever look at, but which needs to be at least shallowly analyzed. Even for incremental tool whose main goal is refactoring, the primary AST structure should be just a list of arrays. There might be a real post about that at some point, see https://youtu.be/G93oYL1ry70 as a teaser.
  
  Rust workspaces genuinely have a lot of information that must be indexed: thousands of functions, structures, traits, relationships between these, function bodies and statements in them, etc. Each of these needs to be analyzed and remembered, and you can’t really cheat if you want to have things like “find all references to this structure”.
  
  If I understand correctly, Rust Glancer wants to process each function body. I think that part can perhaps be made lazy (but not incremental!) with little overhead? Index all items, but, for functions, do only the currently opened file? This might combine some of the better parts of both worlds.
  
  Would be interesting to compare memory usage with Rust Rover. Net of the IDE GUI itself, I would expect RR to be more compact.
  
  Some features are unlikely to be supported though, such as build scripts / proc macros support via proc macro invocation
  
  I might be rationalizing/misremembering things, but IIRC it’s exactly around adding proc macros that the thing began to feel unreasonably bulky. Expanding proc macros is slow as we are running real code, we can’t really do normal IDE cheats. And proc macros generate a lot of code. At one point I measured, it was like 30% of rust-analyzer binary size was attributed to JSON parsing code. If no one sees the code, it can’t harm anybody, right?
  
  One potential approach here is to pull the Sorbet trick, where you don’t run meta programming at all, and instead have a plugin interface to “explain” the effects of what that would have done. Instead of running serde, we just add a shim that injects imp Serialize for T {} with an empty body.
  
  I’m not sure why, but in rust-analyzer I’ve observed that when agents edit the code, inlay hints can get out of place
  
  Rust analyzer’s core data model is very pedantic about always observing consistent snapshots of the code, and does its best to ensure that the language client and server have a shared, strictly serializable view of the world. It’s a shame that LSP doesn’t allow that to be correct , only heuristically right, unlike the older Dart Analyzer protocol, which has sound data synchronization.
  
  However our implementation of file watching is sketchy! First, there are two backends: we can ask the editor to do watching for us, or we can use server side watching. Try changing this option and see if it helps? But then, yeah, my recollection is that our native watcher’s API was fundamentally racy, and I didn’t do the messy platform-specific work of making it correct.
  
  But the main thing I want to write, and why I moved from the cozy lobste.rs text area to the luxurious comforts of an Emacs buffer, is that right now rust-analyzer is a bit like that half-drawn horse meme, except that it’s only the head half of the horse.
  
  One Big Idea of IntelliJ is that it’s PSI API (essentially AST with resolved types) is really an interface, and there are multiple provides. And in a typical usage, there’s at least three backends in play:
  - For the files opened in the editor, actively modified by the user, the PSI is backed by the concrete syntax trees.
  - For the rest of the project files, the PSI is backed by the so called Stub Tree, a compact on disk representation storing only the “externally visible” parts of the file (so, without function bodies). If the user navigates to a new file, its PSI transparently switches from stubs to syntax tree.
  - For dependencies, the PSI is often backed by the compiled .class files, produced by javac. If you navigate there, the IDE just decompiles stuff four you! Super cool!
  This is how I think such things should work. rust analyzer shouldn’t use salsa for all those 6666 dependencies you still haven’t looked at. It should just use rustc’s .rmeta files, switching to salsa, transparently, only when the user starts messing around their ~/.cargo/registry/src folder.
  
  The prerequisite for that is defining the abstract API for accessing Rust code. That was always the plan, and we did start on that at some point:
  
  https://hackmd.io/ytd82QNiT_Ku2XFr1EAtiQ
  
  rmeta-transparent – source code might not be available for some crates, the API should support pre-compiled rmeta files as inputs.
  
  But I don’t think that work was ever completed.
  
  This still seems to me to be the lowest-hanging watermelon here — split the world into arcy-pointy incremental tip of the iceberg, and mostly read-only, on disk, compact, dark, moist breeding ground for supply chain attacks.
  
  Such glance analyzer architecture would be great, imo!
11. 🔗 Ampcode News Explain Usage rss
  You can now ask Puck about your token, credit, and orb usage.
  
  Try questions like:
  - Which threads used the most tokens today? Orb time?
  - Which models did I use the most in my 5 most expensive threads today?
  - In my monorepo, based on my latest threads, can I use a smaller orb size or would that make stuff too slow?
  - Is it orbin' time? To the millisecond, how much orbin' time have I had in my threads from the last 3 hours?
  Puck reads your personal usage and per-thread usage to answer these questions for you. Just ask Puck, or click Explain Usage on those pages.
  
  You can also run amp usage --details and amp threads usage <thread-id> --details to get the data yourself, or to make a cool visualization of your Amp usage in an orb portal.
August 20, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-20 rss
  IDA Plugin Updates on 2026-08-20
  
  New Releases:
  - ida-nexus v0.7.0
  - ida-nexus v0.6.2
  Activity:
  - claude-marketplace
    
    d5fcc2e2: Switch to latest branch
  - ida-nexus
    
    c0ee04b1: Automatically update latest branch to latest release
    
    3c194b45: 0.7.0
    
    255a6b8f: Fix type checking
    
    9340c825: Fix deadlock in DatabaseManager
    
    e0052bbe: Merge pull request #33 from HexRaysSA/idb-events
    
    3b24fbc3: Address review comments for IDB event feature
    
    6ad62f0e: Extend remote decorator to allow entire modules
    
    fdf6126f: Allow declaring list of helpers for @remote_ida
    
    974f618a: Initial POC for @remote_ida decorator magic
    
    918f24b1: Label GUI and REPL IDB events
    
    493ac14d: Expose structured IDB events with provenance
    
    e56e1923: Harden loopback HTTP request handling
    
    df3d8406: Properly wait for database to be closed on the last lease
    
    cc431f98: Update descriptions
    
    cb809c24: Fix rename mishaps
    
    3757fdf3: 0.6.2
    
    07c32e7c: Rename the project to IDA Nexus
  - IDAPluginList
    
    cd3cddf4: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
  - twdll
    
    65f9cf2b: docs(credits): add credits and acknowledgements section and credits.md
    
    54dbfee7: docs(readme): clarify development requirements and add direct dev bui…
    
    869eb0e1: feat(build): support 32-bit Linux cross-compilation via clang-cl + xw…
    
    4355c873: docs(attila): clean internal offsets, structure ldoc descriptions, an…
    
    16cd95cf: Merge remote-tracking branch 'origin/master'
    
    7e6f155a: docs(agents): add conventional commits convention to AGENTS.md
    
    238258d5: feat(security): add host process validation to prevent execution outs…
    
    26626dcb: Add host process validation to prevent execution outside Attila.exe
    
    4554feec: feat(core): implement twdll.core.GetBuildSha to inspect active binary…
    
    44e4429b: docs(changelog): format signatures consistently and strip internal C+…
    
    2db02fda: docs(changelog): clean up obsolete Changed note regarding loyalty and…
    
    38b476b7: docs(changelog): fix CreateAgent parameter description and add strict…
    
    6063cba0: feat(attila): add character name manipulation and immortality API suite
    
    9eb93379: feat(attila): implement CHARACTER_SCRIPT_INTERFACE:TransferToFaction
    
    040cc1c9: feat(attila): implement FACTION_SCRIPT_INTERFACE:CreateAgent
    
    fcd019ea: feat(character): implement TransferToFaction method with army repleni…
2. 🔗 exe.dev We Taught sqlc to Invalidate Our Caches rss
  
  People connecting to sites hosted on exe.dev are contacting a proxy server that routes the connection to the correct VM. Routing depends on details about the connection, such as the HTTP Host header or an SSH public key. It also depends on details of exe.dev internal network, such as where the VM is running and how to access it. These details are, naturally, stored in a database.
  
  exe.dev proxies run all over the world. We don’t want every incoming connection to have to check with a single centralized database; that would introduce unnecessary slowness. We also don’t want to replicate the entire database to every proxy; most of the information in the database is irrelevant to the proxy, and some of it is potentially sensitive, such as links to billing information.
  
  The natural approach is for the proxy to cache the information that it needs. The first time somebody uses a particular proxy to contact a particular VM, we do a slow query of the centralized database. After that, each subsequent connection is handled out of a local cache.
  
  Of course, information changes over time. People can change the sharing status of their VMs, VMs can move to different hosts, and in general the routing information that the proxy is using can change. So while using a cache is efficient, it means that we have to handle what is notoriously one of the two hard problems of computer systems: cache invalidation (the other hard problem is naming; also, off-by-one errors).
  
  sqlc
  
  Before we tackle cache invalidation, let’s back up and discuss database access.
  
  Our code is written in Go, and our database access uses the excellent sqlc tool. The sqlc tool is a code generator that parses SQL commands and generates type-safe functions to execute those commands. This brings the advantage of compile-time static type checking to the dynamically typed SQL language. The sqlc tool understands how to parse SQL statements for various databases. For every database operation, it generates a type-safe function that performs the operation. At exe, all of our database access goes through functions generated by sqlc.
  
  Table and Row Information
  
  Given that we are already using tooling for database access, it was a small extension to that tooling to support cache invalidation. We tweaked our copy of sqlc to emit additional code in each generated function.
  
  In a function that reads from the database, we record a mapping from a database table name to the field/value pairs used to select rows from the table. The mapping is stored in the Go context value, so that it accumulates across a set of database operations that share a context.
  
  In a function that writes to the database, we call a user-supplied function for each write operation, again passing a mapping from a database table name to the field/value pairs used to select rows from the table. We don’t record the changed fields, we only record the fields used to select the row (in SQL terms, this is the WHERE clause). We only call the function when the transaction is committed.
  
  Cache Invalidation
  
  When a proxy needs information that isn’t cached locally, it contacts the central database. During this operation it records the database tables and rows that are accessed. Because this is done via the sqlc generated code and the Go context value, there is no need for the code to know ahead of time what database information is relevant, and the recorded information is always accurate even as the program changes or the database is rearranged. We record the table and row information in a cache invalidation data structure.
  
  All database changes, wherever they originate, go through a single writer process to reach the database. That is the one we instrument via sqlc. The sqlc hooks check the cache invalidation data structure. If the write affects a table that some cache depends upon, we send a cache invalidation message to all proxies that accessed the data. The message includes the fields and values used to select the row.
  
  When the proxy receives the message, it knows the database table that was modified, and the field values used to select the row. That is enough information to clear the cache elements that may have been modified. We don’t attempt to be precise about modification. If some field changed for a particular VM, we simply discard all cached information for that VM. The proxy will refetch the data from the central database when and if it is needed.
  
  For example, a proxy may need information about the VM with ID 789. It will ask the centralized database for that information, which will send all relevant information about the VM, including the ID and owner and routing information. The database server will record that the proxy got information from the VM database table. Later something about that VM may change, perhaps because we are changing all information about VMs owned by the user baz. The writer process will see that the table changed, and send a notification to the proxy saying that a VM owned by baz changed. The proxy, which knows the ID and owner of all VM information it has cached, will discard from the cache all information about VMs owned by baz.
  
  This approach automatically detects the information that is cached, and automatically detects the cases where the cached information may be out of date. That is enough for reliable cache invalidation, and reliable VM routing.
3. 🔗 HexRaysSA/ida-nexus v0.7.0 release
  What's Changed
  - Add /idb_events endpoint and remote decorator by @mrexodia in #33
  Full Changelog : v0.6.2...v0.7.0
4. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +3 releases, ~12 changed rss
```
sync repo: +1 plugin, +3 releases, ~12 changed

## New plugins
- [ida-nexus](https://github.com/hexrayssa/ida-nexus) (0.6.2)

## New releases
- [AutoRE](https://github.com/a1ext/auto_re): 2.3.0
- [efiXplorer](https://github.com/rehints/efixplorer): 6.3.0

## Changes
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - 0.6.1: download URL changed
  - 0.6.0: download URL changed
  - 0.5.3: download URL changed
  - 0.5.2: download URL changed
  - 0.5.1: download URL changed
  - 0.5.0: download URL changed
  - 0.4.1: download URL changed
  - 0.4.0: download URL changed
  - 0.3.2: download URL changed
  - 0.3.1: download URL changed
  - 0.3.0: download URL changed
  - 0.2.0: download URL changed
```
5. 🔗 The Pragmatic Engineer The Pulse: Meta’s self-inflicted resignation-wave rss
  Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from last week 's The Pulse issue. Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .
  
  Two months ago, I covered how Meta seemingly deliberately started destroying its once-standout engineering organization. The company did 10% layoffs at a time when revenue and profits hit an all-time high, and reassigned about 20-30% of software engineers to data labeling with basically no notice.
  
  The result was that a good chunk of software engineers at Meta - even those not reassigned - were starting to interview elsewhere:
  
  Why so many engineers at Meta are looking for a way out, visualized. Source:Why is Meta destroying its engineering organization?
  
  I said - and still maintain - that the layoffs were an unforced, self- inflicted error on Meta's part. Coupled with forced reassignment, they struck disaster. And I've now gathered new details that confirm that Meta is bleeding top engineering and product management talent:
  
  Some layoffs reversed, in the 11th hour
  
  In the UK, mass layoffs require a notification to those potentially affected, before the cuts can happen. A few weeks after this notification, a good chunk of folks were "un-notified," I confirmed. But those on notice had already started to look for jobs, obviously.
  
  Retainer equity grants offered to IC6+ engineers resigning
  
  Meta started to offer large retainer equity grants to those resigning and leaving for Google, Anthropic, and OpenAI: a practice not done before. Talking with long-time Meta engineers, Meta simply didn't make counteroffers or negotiate when an engineer handed in their resignation. But this practice has been abandoned. Here's a story of a senior, long-tenured engineer I confirmed to have happened:
  - This dev was force-reassigned to one of the AI data labeling teams
  - They thought "oh no, this is not what I want to do" and started to interview
  - Got a Google offer, but compensation was below their current one. Google basically lowballed them.
  - Decided to leave anyway. Told their new manager they were resigning.
  - New manager asked for some time, then presented a large, one-off, retainer equity grant, vesting over 3 years
  - The engineer went back to Google, telling the company, unfortunately, they are a key engineer and showed them the retainer amount Meta is paying for them to stay
  - Google upped their offer, out-bidding Meta's retainer offer
  - The engineer who was desperate to leave - even for lower compensation! - was thrilled, and happily left for Google.
  Retainer equity seems to be offered for most IC6 engineers who resigned in the last few weeks. I talked with seven such people, who were all IC6 (staff-level engineer) and IC7 (principal-level engineers), who shared more details. They are not aware of IC4 (mid-level engineer) or IC5 (senior-level engineers) getting such offers.
  
  Retainer equity offered is $400K to $1M+ , and vests over 3 years, for the folks who got these offers. The $1M+ offers were all for engineers with Anthropic or OpenAI offers, and I confirmed a $400K and a $600K grant for engineers with an offer for other, smaller AI startups.
  
  A current Meta engineer who is interviewing asked me if these folks needed to present their offer letter to get a counteroffer. I asked two of these folks with counteroffers, and neither had to do so, but they both indicated they were handing in their resignation. Upon receiving this notification, their director, together with HR, offered a discretionary retainer equity, should they stay.
  
  Anthropic and OpenAI on a hiring spree from Meta
  
  Anthropic and OpenAI seem to be on a hiring spree, signing Meta engineers that Meta wants to retain now that it is too late! I have confirmed that three engineers who received an offer from Anthropic were also offered large, $1M+ equity grants (vesting over 4 years) as counter-offers to stay. Two out of the three rejected it and joined Anthropic, and the third one initially accepted the offer and then still left for Anthropic a month later, forfeiting this grant.
  
  OpenAI is having similar success, and the two AI labs seem to be the main destination for now ex-Meta engineers to bounce to. It makes sense: these companies can match Meta's total compensation, and although neither OpenAI nor Anthropic is publicly traded, both companies organize secondary equity sales, and their respective IPOs are likely to happen in 3-12 months' time.
  
  AI startups also successful in hiring infra experts from Meta
  
  I had an in-depth discussion with another long-tenured AI infra engineer at Meta, who was considering whether to stay, or to go. This person wrote up their situation, and shared it with me, writing:
  
  "With the current situation at Meta (layoffs, forced drafting to do AI work, general sense of disruption at work, low moarale, and almost zero productivity across teams, plus multiple reorgs) I started to look around, on the market, a few weeks before the 20 May layoffs. I figured I have a 50% chance of being let go.
  
  I did not get laid off, but I got offers from startups, and one from a high- growth AI startup I like, and also an offer from Google.
  
  Now, the pros to staying a Meta:Context, relationshipsScale that few others haveBig Tech perks, relatively "chill" WLB in terms of oncallHigh TC
  
  The cons:Terrible morale, hard to "move" work through mostly unmotivated teams all around meRe-orgs continue, I have very low confidence in middle management (Directors, VPs) to navigate this churnFurther layoffs are likely: it's clear that there's more bloat, surely Zuck will do another round in 2027. And no one is safe during a layoffA 'doom loop' for anyone who stays: low morale -> unmoitivated bith highly compensated engineers -> a bloated organization that moves slow"
  
  After a new reorg, this engineer got a supportive manager, who made it clear they would help them thrive inside of Meta. So the engineer rejected both the AI startup's offer and that of Google, deciding to stay… but only for a month!
  
  The AI startup's founder spent more time with this engineer, increased the equity in the package significantly, and convinced this engineer that at the startup they matter as a person, while at Meta they would be doing soulless work, worrying about the next layoff, probably early 2027.
  
  So this engineer also handed in their resignation. And it all started with the layoffs: the engineer assumed there was a 50% chance of being let go and wanted more career stability!
  
  Those deciding to not resign: stay for the money?
  
  There are engineers staying - at least until the end of the year, to wait for the stock refershers -- which we'll talk about in just a moment.
  
  Another engineer I talked to decided to quit Meta with morale so low, and start his own thing. Management convinced him to stay until the end of the year, hinting at large equity refreshers being handed out around January, which could be in the $1M+ range for this specific engineer.
  
  The 2022 stock price causing a TC decrease for many?
  
  One reason there's speculation about large equity refreshers being handed out at the end of the year is that Meta's stock price was very low in 2022 and 2023, when equity refreshers and new hire grants were handed out. In both March 2022 and March 2023, the stock price was around $200 - which is about a third of this year's stock price (which has been fluctuating between $520- 680, currently sitting at $540.) By March 2024, the stock price rose to $500, and then to $580 in March 2025.
  
  Because of this, those who joined Meta in 2022 have seen their equity grants nearly triple, and the 2023 equity is worth nearly 3x as well. But for these lucky folks, total compensation is set to drop by the end of this year, and their equity refresher would need to be higher than in past years to avoid a compensation drop.
  
  Inside of Meta, engineers who I talked to are split between expecting further attrition (those leaving whose total compensation drops steeply) and those who think that there will be more attrition unless there are higher-than-usual equity refreshers.
  
  A "mercenary" culture at Meta?
  
  I wonder if Meta made a massive mistake by treating engineers as "commodities" and turning their culture into a "mercenary" one. Between March and June, Meta treated engineers as replaceable commodities that could be thrown out or moved between teams, while stripping them of any autonomy. The reassignments to AI labeling were not explained, nor were managers or individuals asked about preferences: from above, someone said that Alice and Bob , starting on Monday, are no longer with the team, but are training up Meta AI. Never mind that these were the two most experienced engineers on the team, or that Bob was the team's infra expert, and Alice the "fixer" engineer on the team.
  
  And all this damage was done, for what? It was to allow Meta to restart its AI coding model development efforts, and release Meta Muse Spark: an AI model that is currently the 7th most capable AI model as per Artificial Intelligence Analysis, tied with Grok 4.5. Credit where it's due: with this model, Meta is now well ahead of Google's Gemini in capability.
  
  With the damage done, there is little motivation for anyone to stay at Meta - unless they are on a visa, or if it's about the money. You can have an OK engineering culture with a team who is mostly interested in making more money than what they would elsewhere: but this is more of a mercenary culture, and companies run by mercenaries are more easily out-executed by teams where people believe in the mission of the company.
  
  If you work at a company that would love to hire from Meta: now is (still) your opening! So go for it.
  
  And if you're at Meta: you are so in-demand, outside of the company, at places where engineering is still treated as a profit center. As Ryan Nystrom, currently building AI at Notion, put it:
  
  "Meta friends: the industry is exhilarating right now. Get out. Go build something. The handcuffs are an illusion.
  
  I'm having the time of my life at Notion. Come, and have fun again."
  
  Read the full issue of last week 's The Pulse, or check out this week 's The Pulse. This week's issue covers:
  1. More on the "great engineering leader career break." The industry is changing fast, and the VPE and CTO roles also need to adapt. And don't forget that these are the roles from which you can drive change that reorganizes engineering in ways that work better.
  2. We need to talk about migrations with AI. Asana needed to migrate off testing framework Enzyme, but it meant doing a massive rewrite of test cases. With AI, the project was completed in two weeks: without AI, this work would surely have been kicked down the road. Airbnb and Uber share similar stories, and AI seems like a superb fit for framework migrations.
  3. Are AI startups making the Gartner Magic Quadrant irrelevant? Gartner ranked AWS, Microsoft and IBM above Anthropic, Cursor and OpenAI in their "AI code modernization tools" ranking. This is most likely because the first three pay large sums of money to Gartner, but AI labs and vendors refuse to pay this "Gartner tax."
  4. Industry Pulse. Another hours-long GitHub outage, GitHub alternatives are here and fighting for market share, Slack launches Slack Code, text generated by Claude to be watermarked, and Uber open sources SubmitQueue.
  Read the full The Pulse.
6. 🔗 r/LocalLLaMA Ladies and gentlemen I present to you Qwen3.8 27b 1bit brain damage quant rss
  
  | I wanted to just test the unsloth 1bit quant of qwen 3.8 27b as I have just 8gb vram and ngl it gave me a good laugh submitted by /u/Ok-Health-7096
  [link] [comments]
  ---|---
7. 🔗 cloudflare/capnweb capnweb-validate@0.3.0 release
  Minor Changes
  - #253 46de5a7 Thanks @ndisidore! - Fixed methods declared to return Promise<RpcStub<T>> producing broken stub-of-stub result types; they now type the same as Promise<T>. If you annotated such a result as RpcPromise<RpcStub<T>>, write RpcPromise<T> instead.
8. 🔗 cloudflare/capnweb capnweb@0.12.0 release
  Minor Changes
  - #253 46de5a7 Thanks @ndisidore! - Fixed methods declared to return Promise<RpcStub<T>> producing broken stub-of-stub result types; they now type the same as Promise<T>. If you annotated such a result as RpcPromise<RpcStub<T>>, write RpcPromise<T> instead.
  - #242 9751a4e Thanks @ndisidore! - RpcPromise can now be constructed from a Promise: pipelined calls queue in order until it settles, so you can publish a capability that doesn't exist yet.
  Patch Changes
  - #241 2de5871 Thanks @ndisidore! - Fix RPC argument and capture leaks on failure paths: call arguments are now reliably disposed when a call is rejected, delivered to a broken or disposed stub, or fails to serialize.
  - #251 7a6e5da Thanks @ndisidore! - The RpcPromise constructor now applies the same stub elision as method result types: wrapping a Promise<RpcStub<T>> produces the same RpcPromise<T> a method declared to return that stub would, plain-interface stub payloads keep their stub type, and promises resolving to inline object literals with methods now infer correctly.
  - #243 7e864a8 Thanks @ndisidore! - Fix WritableStream stubs leaking call arguments when the stub was already disposed or the call path was invalid. All failure paths in WritableStreamStubHook.call() now dispose the copied arguments, matching ReadableStream behavior.
9. 🔗 HexRaysSA/ida-nexus v0.6.2 release
  
  Full Changelog : v0.6.1...v0.6.2
10. 🔗 Kagi release notes August 21st, 2026 - A new Stocks widget and a better everyday Assistant experience rss
  Kagi Search
  
  Bringing Stocks up to speed
  
  We've revamped our Stocks widget. It should appear more often when you need it. It can now display information about exchange-traded funds in addition to stocks. Most importantly, it now features a price chart, with animations between time windows that instantly contexturalize how big the price fluctuations you're seeing are compared to the wider story:
  
  As well, we've added a setting for removing paywalled links from search results automatically.
  
  Kagi Assistant
  
  Everyday use just got smoother
  
  Richer messages
  User messages now render links, Markdown, and LaTex. #6674 @oxlvlnle, #3283 @EvacuatedTerminal
  
  More powerful search
  Search across all your threads, sort by recency or alphabetically, and start with / to filter by folder.
  
  More control with calmer settings
  Now you can choose whether temporary threads stick around for 24h, 7 or 30 days. All within a calmer, easier-to-scan settings experience.
  
  Other improvements and bug fixes
  
  Kagi Search
  - Direct URLs for search pages with our built-in lenses are now easier to use, with names replacing numbers: https://kagi.com/search?lens=forums
  - Shortcuts should not trigger with modifiers held #9385 @poacher2k
  - kagifeeedback xss vuln tag fix #10767 @unknown
  - Upstream connect error or disconnect/reset before headers. reset reason: connection termination #10680 @TheToby
  - Select text and Search in Assistant #11242 @mb
  - Homepage Companions - Random or Rotate #9077 @Anonymous12
  - Extract API returns empty data for an entire batch when one page times out #11176 @fredcy
  - Currency conversion widget does not handle official name of currency #11175 @Keli
  - A way to find similar websites #1152 @Protech
  - Blocked domains are used as sources in Quick Answer #11257 @bausauce
  - "CHATGPT" Wikipedia article is flagged as slop #10192 @fxgn
  - Surveillance Watch for play.google.com goes to a page about Zalo #9146 @pma_snek
  - Assistant no longer decodes URL encoding from !ai bang #11096 @arijan
  Kagi Assistant
  - Ability to export all Assistant chats in one go #5221 @Thibaultmol
  - In Assistant, add an option to require ⌘+⏎ to submit a prompt #6110 @dudeofawesome
  - "Click to Expand" on "Thinking" Section #8004 @KagiFeedbackDuder
  - Assistant: do not close thinking block if user opened it during extended thinking #6675 @DomW
  - Assistant prompt code fence syntax highlighting #4775 @slater
  - FIXED - !ai bang - Query not working #11077 @fanged_bagful
  - Prevent Search Engine Indexing of Shared Assistant Threads #7867 @Hanbyeol
  - Web Search toggle state not maintained between app switches #11140 @ryonic
  - Improvement to code snippet input #6254 @Leward
  - Choppy animation in Assistant app #11134 @Temanor
  - Assistant prompt code fence syntax highlighting #4775 @slater
  - Speech-to-text doesnt support pauses in Android Assistant app #11265 @jeroenpelgrims
  Assistant Mobile Apps
  - Keyboard shortcut preference to submit prompts on iPads with connected keyboards
  - Back swipe on left side of Kagi Assistant interferes with Android guestures #11126 @mb
  - After opening Kagi Assistant, back swipe on the right side closes the app #11127 @mb
  - Choppy animation in Assistant app #11134 @Temanor
  - Web Search toggle state not maintained between app switches #11140 @ryonic
  - Cannot Login Kagi Assistant 1.0.4 on iOS #11146 @hirsheykiss
  Kagi Translate
  - Kagi Translate Reloads the page when using website translate #10852 @tijol
  - Kagi Translate extension RSS feed 503 error #10831 @Albi
  - Translate extension context menu options don't work everywhere #10813 @WorstWizard
  - Alternative-translations request payload has blank "context" string in new update #11278 @Drexont
  - Regression: saved presets do not automatically apply context to translations #11218 @Drexont
  - American alias for English (US) #11143 @mb
11. 🔗 Anton Zhiyanov Going freestanding rss
  Creating a subset of Go that translates to C (which I named Solod) was never my end goal. I liked writing C code with Go, but without the standard library it felt pretty limited. So the next logical step was to port Go's stdlib.
  
  At some point I decided to make as many packages as possible freestanding — independent of any libc implementation or specific OS runtime. That went pretty well. Solod now has 37 standard library packages, and 31 of them work in freestanding mode.
  
  This post describes the techniques I used to get there. There's nothing genuinely novel, and if you're experienced with C, you probably already know all of them. Still, I think it's useful to document the approach — both for me and for anyone interested.
  
  Freestanding mode • Headers • Builtins • Memory • Atomics • Pure C • Allocation • Values • Hooks • Hosted- only • Testing • Final thoughts
  
  Freestanding mode
  
  C has two types of environments. In a hosted environment, you get the full standard library — either the one required by the C standard or, even better, POSIX. In a freestanding environment, you get almost nothing.
  
  The compiler tells you which one you're in:
```
#if __STDC_HOSTED__
// libc is available
#else
// you're on your own
#endif
```
  Pass -ffreestanding and link with -nostdlib, and that's it: you no longer have printf, or malloc, or even memcpy. There is no entropy source, no file system operations, and no clock. If libc itself is "hard mode", this is "impossible".
  
  Despite its limitations, freestanding mode can be really useful for microcontrollers, WebAssembly sandboxes, kernels, and anything else without an operating system to rely on.
  
  Freestanding headers
  
  Freestanding does not mean "just the C language". The C standard guarantees some headers even without libc, because they define types and macros rather than functions:
```
float.h   stdalign.h  stdbool.h  stdint.h
limits.h  stdarg.h    stddef.h   ...
```
  Everything that requires actual function implementations is gone:
```
assert.h  math.h   stdlib.h  time.h
errno.h   stdio.h  string.h  ...
```
  To reflect the hosted/freestanding split, let's introduce builtin.h, a common header included in every standard library package:
```
#if __STDC_HOSTED__

#include <assert.h>
#include <inttypes.h>
#include <stdalign.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define so_build_hosted

#else

#include <stdbool.h>
#include <stdint.h>
#include <stdalign.h>
#include <stddef.h>

#endif  // __STDC_HOSTED__
```
  Individual packages follow the same approach: branch on so_build_hosted to distinguish between the hosted and freestanding implementations.
  
  Compiler builtins
  
  GCC and Clang implement some C standard functions without relying on libc. These are known as compiler builtins.
  
  __builtin_trap causes the program to terminate abnormally. You can use it to implement poor man's assertion and panic:
```
#ifdef so_build_hosted

#define so_panic(msg)                                     \
    do {                                                  \
        fprintf(stderr, "panic: %s\n  %s:%d (func %s)\n", \
                msg, __FILE__, __LINE__, __func__);       \
        exit(1);                                          \
    } while (0)

#else

#define assert(cond)                   \
    do {                               \
        if (!(cond)) __builtin_trap(); \
    } while (0)

#define so_panic(msg)     \
    do {                  \
        (void)msg;        \
        __builtin_trap(); \
    } while (0)

#endif // so_build_hosted
```
  From now on, I'll mainly show the freestanding versions and omit the hosted versions to keep things simple.
  
  The __builtin_alloca function allocates memory on the stack. Its bounded wrapper limits the size of each allocation:
```
#define alloca __builtin_alloca

// The maximum size that can be allocated
// with alloca (64 KB by default).
#ifndef SO_MAX_ALLOCA_SIZE
#define SO_MAX_ALLOCA_SIZE (64 << 10)  // in bytes
#endif

#define so_alloca(size) ({                                \
    size_t _size = (size_t)(size);                        \
    if (_size > SO_MAX_ALLOCA_SIZE)                       \
        so_panic("alloca: size exceeds maximum allowed"); \
    _size ? alloca(_size) : NULL;                         \
})
```
  Memory operations
  
  The memxxx functions from string.h have matching builtins too, so you might expect a freestanding build to provide them for you:
```
// int memcmp(const void* lhs, const void* rhs, size_t n);
#define memcmp __builtin_memcmp

// void* memcpy(void* dst, const void* src, size_t n);
#define memcpy __builtin_memcpy

// void* memmove(void* dst, const void* src, size_t n);
#define memmove __builtin_memmove

// void* memset(void* dst, int ch, size_t n);
#define memset __builtin_memset
```
  Unfortunately, there's no free lunch here.
  
  __builtin_memcpy is not a separate memcpy implementation. If n is small and known at compile time, the compiler expands it into a few loads and stores. But if n is large or only known at runtime, it emits a call to the real memcpy — the same symbol that libc would provide.
  
  Even worse, you don't need to mention memcpy explicitly to use it. Suppose you copy a large struct like this:
```
typedef struct { char buf[4096]; } Big;

void copy(Big* a, const Big* b) {
    *a = *b;
}
```
  When you compile the code for aarch64-freestanding, the object file contains an undefined reference to memcpy. Zero-initializing a local array produces the same issue with memset. Neither name appears in the source; both are introduced by the compiler.
  
  So the freestanding environment must still provide memcpy, memmove, memset, and memcmp for memory operations to work in the general case.
  
  WebAssembly covers three of the four: memcpy, memmove, and memset lower to the memory.copy and memory.fill instructions. There is no instruction for comparison, so memcmp stays a real function call even there. On other targets, the toolchain often provides all four, as zig cc does (even with -nostdlib). If it doesn't, provide a plain C implementation:
```
#undef memcpy
void* memcpy(void* dst, const void* src, size_t n) {
    unsigned char* d = dst;
    const unsigned char* s = src;
    while (n--) *d++ = *s++;
    return dst;
}

#undef memset
void* memset(void* dst, int ch, size_t n) {
    unsigned char* d = dst;
    while (n--) *d++ = (unsigned char)ch;
    return dst;
}

#undef memmove
void* memmove(void* dst, const void* src, size_t n) {
    // omitted for brevity
}

#undef memcmp
int memcmp(const void* lhs, const void* rhs, size_t n) {
    const unsigned char* l = lhs;
    const unsigned char* r = rhs;
    for (; n--; l++, r++) {
        if (*l != *r) return *l - *r;
    }
    return 0;
}
```
  The defines (#define memcpy __builtin_memcpy and others above) are still worth keeping, even if you implement the functions yourself. This way, the compiler can still use its own implementation when applicable.
  
  Fun fact: at -O2 and above, GCC can fold your custom memcpy implementation back into a call to memcpy, which is infinite recursion. -ffreestanding prevents this because it implies -fno-builtin, but the guarantee is weak. You can use -fno-tree-loop-distribute-patterns to disable this behavior for good.
  
  The rest of string.h is not covered. No compiler provides memchr or strlen, so those you always have to write yourself — more on that below.
  
  Atomic operations
  
  Another useful group of compiler builtins is __atomic_xxx, which provide atomic, thread-safe memory access. They operate on regular objects rather than _Atomic objects:
```
// so_atomic_load atomically loads the value at p.
#define so_atomic_load(p) \
    (__atomic_load_n((p), __ATOMIC_SEQ_CST))

// so_atomic_store atomically stores v at p.
#define so_atomic_store(p, v) \
    (__atomic_store_n((p), (v), __ATOMIC_SEQ_CST))
```
  This makes porting Go's sync/atomic types straightforward. All types — atomic integers, unsigned integers, booleans, and pointers — use the same two load/store macros:
```
// Bool is an atomic boolean value. The zero value is false.
typedef struct atomic_Bool {
    bool v;
} atomic_Bool;

// Load atomically loads and returns the value stored in x.
bool atomic_Bool_Load(atomic_Bool* x) {
    return so_atomic_load(&x->v);
}

// Store atomically stores val into x.
void atomic_Bool_Store(atomic_Bool* x, bool val) {
    so_atomic_store(&x->v, val);
}
```
  A separate atomic_Bool type isn't strictly required — atomic_Bool_Load and atomic_Bool_Store would work with a plain bool*. Still, it can be useful. With a plain pointer, *x = true creates a silent data race that looks like ordinary code, while the wrapper makes you explicitly write x->v = true.
  
  No stdatomic.h include is needed. However, the CPU must natively support the integer width you use. For example, a 64-bit atomic on a 32-bit target becomes a call to libatomic instead of a single instruction. But that's a different story.
  
  Pure C implementations
  
  If the compiler doesn't provide an implementation, you have to write one yourself. Preferably, use the libc name so all call sites remain unchanged.
  
  A good example is memchr, which is required by bytes.IndexByte. There is a __builtin_memchr, but it is not an implementation, so you need to provide your own:
```
#ifndef so_build_hosted
// memchr implementation for freestanding environments.
static inline void* memchr(const void* s, int c, size_t n) {
    const unsigned char* p = s;
    unsigned char target = (unsigned char)c;
    while (n--) {
        if (*p == target) return (void*)p;
        p++;
    }
    return NULL;
}
#endif
```
  Some of these DIY implementations aren't trivial, of course. Fortunately, Go's standard library includes many standalone algorithms, such as the string-to- number conversion functions in strconv or integer math in math/bits. Porting them to C is almost mechanical:
```
// Go version.
const m3 = 0x00ff00ff00ff00ff

// ReverseBytes32 returns the value of x
// with its bytes in reversed order.
func ReverseBytes32(x uint32) uint32 {
    const m = 1<<32 - 1
    x = x>>8&(m3&m) | x&(m3&m)<<8
    return x>>16 | x<<16
}



// C version.
static const int64_t m3 = 0x00ff00ff00ff00ff;

uint32_t bits_ReverseBytes32(uint32_t x) {
    const int64_t m = ((int64_t)1 << 32) - 1;
    x = ((x >> 8) & (m3 & m)) | ((x & (m3 & m)) << 8);
    return (x >> 16) | (x << 16);
}
```
  Memory allocation
  
  Memory allocation calls for a different technique. A naive approach would be to implement a freestanding malloc that uses a static buffer:
```
extern char so_heap[SO_HEAP_SIZE];
extern size_t so_heap_offset;

static inline void* malloc(size_t size) {
    // Simplified version without alignment.
    if (size > SO_HEAP_SIZE - so_heap_offset) {
        return NULL;
    }
    void* ptr = &so_heap[so_heap_offset];
    so_heap_offset += size;
    return ptr;
}
```
  It might be sufficient for testing, but I'd avoid using it in production.
  
  Instead of reimplementing malloc, let's remove the need for it, and make the caller bring the memory. Start with an allocator interface, so callers don't depend on a specific implementation:
```
// Allocator defines the interface for memory allocators.
// Simplified version without Realloc and alignment.
typedef struct {
    void* self;
    so_R_ptr_err (*Alloc)(void* self, so_int size);
    void (*Free)(void* self, void* ptr, so_int size);
} mem_Allocator;
```
  What's with the so-types?
  
  so_int is an integer of the target width:
```
#if SIZE_MAX == 0xFFFFFFFFu
typedef int32_t so_int;
#else
typedef int64_t so_int;
#endif
```
  so_String is a pointer to the underlying string bytes and their count:
```
typedef struct {
    const char* ptr;
    so_int len;
} so_String;
```
  so_Error is an interface value that wraps the error data:
```
typedef struct {
    void* self;
    so_String (*Error)(void* self);
} so_Error;
```
  so_R_ptr_err is a result-type implementation for a (pointer + error) pair:
```
typedef struct {
    void* val;
    so_Error err;
} so_R_ptr_err;
```
  There are other similar types like so_R_int_err (int + error) or so_R_f32_bool (float32 + bool).
  
  Then provide an arena allocator, which is freestanding by design:
```
// Arena is a memory allocator that bump-allocates
// linearly within a fixed buffer.
typedef struct {
    so_Slice buf;
    so_int offset;
} mem_Arena;

mem_Arena mem_NewArena(so_Slice buf) {
    return (mem_Arena){.buf = buf};
}

so_R_ptr_err mem_Arena_Alloc(void* self, so_int size) {
    // Simplified version without alignment.
    mem_Arena* a = self;
    assert(size > 0 && "mem: invalid allocation size");
    if (size > so_len(a->buf) - a->offset) {
        return (so_R_ptr_err){.val = NULL, .err = mem_ErrOutOfMemory};
    }
    void* ptr = &so_at(so_byte, a->buf, a->offset);
    a->offset += size;
    return (so_R_ptr_err){.val = ptr, .err = (so_Error){}};
}

void mem_Arena_Free(void* self, void* ptr, so_int size) {
    // Free in arena is a no-op.
    (void)self; (void)ptr; (void)size;
}

void mem_Arena_Reset(void* self) {
    mem_Arena* a = self;
    a->offset = 0;
}
```
  Usage example:
```
typedef struct Point {
    so_int x;
    so_int y;
} Point;

// Prepare the arena.
so_byte data[1024];
so_Slice buf = {.ptr = data, .len = sizeof(data)};
mem_Arena arena = mem_NewArena(buf);
mem_Allocator alloc = {
    .self = &arena,
    .Alloc = mem_Arena_Alloc,
    .Free = mem_Arena_Free};

// Allocate a Point. mem_Alloc is a macro that calls
// the Alloc "method" and panics on failure.
Point* p = mem_Alloc(Point, alloc);
p->x = 11;
p->y = 22;
```
  On a freestanding target, an arena is a better choice than a buffer-backed malloc, because the caller decides how much memory is available and when it's released.
  
  Values, not pointers
  
  Constructor functions in Go typically return a pointer:
```
// A string reader.
type Reader struct {
    s        string
    i        int64 // current reading index
    prevRune int   // index of previous rune; or < 0
}

// NewReader returns a new Reader reading from s.
func NewReader(s string) *Reader {
    return &Reader{s, 0, -1}
}
```
  This roughly translates to the following code, using the memory allocator from the previous section:
```
// A string reader.
typedef struct {
    so_String s;
    int64_t i;
    so_int prevRune;
} strings_Reader;

// NewReader returns a new Reader reading from s.
// The returned reader is allocated; the caller owns it.
strings_Reader* strings_NewReader(mem_Allocator alloc, so_String s) {
    strings_Reader* r = mem_Alloc(strings_Reader, alloc);
    r->s = s;
    r->i = 0;
    r->prevRune = -1;
    return r;
}
```
  Rather than blindly following Go idioms, it's better to get rid of allocations altogether and return a value:
```
// NewReader returns a new Reader reading from s.
strings_Reader strings_NewReader(so_String s) {
    return (strings_Reader){.s = s, .prevRune = -1};
}
```
  This isn't a technique specific to writing freestanding code, but rather a useful practice for pretty much any C library.
  
  Target hooks
  
  Some things you can't write in a target-agnostic way at all. Only the target knows how to print a byte, read the clock, or generate a random number; these all depend on the hardware.
  
  What you can do is declare functions (hooks) and let the user's code define them:
  
  Hook | Description
  ---|---
  so_write_out | send some bytes to the output
  so_crand_read | read some random bytes
  so_time_wall | get the current wall clock time
  so_time_mono | get the current monotonic time
  so_time_sleep | pause for a given duration
  
  Then the user can call specific APIs available on their hardware:
```
so_int so_write_out(const uint8_t* buf, so_int size) {
    return board_uart_write(buf, size);
}

int64_t so_time_mono(void) {
    return (int64_t)board_uptime_ms() * 1000000;
}
```
  What happens if the user doesn't provide an implementation? You still want the standard library to compile and work unless someone calls the missing functions. To achieve that, use weak definitions:
```
// so_write_out drops the bytes and reports a full write,
// so panic and fmt print nothing and report no error.
__attribute__((weak)) so_int so_write_out(const uint8_t* buf, so_int size) {
    (void)buf;
    return size;
}

// so_crand_read reads no bytes. The interpretation is left to the caller.
__attribute__((weak)) so_int so_crand_read(uint8_t* buf, so_int size) {
    (void)buf;
    (void)size;
    return 0;
}

// so_time_wall panics, because no default date is correct.
__attribute__((weak)) so_R_i64_i32 so_time_wall(void) {
    so_panic("time: define so_time_wall for this target");
}
```
  Now every hook gets a default, and a definition in the user code silently wins over the default one.
  
  Note that the defaults above behave differently on purpose. Dropping output is fine because a board with no UART (serial interface) has nowhere to print. Inventing a date is not fine, because no date would be correct.
  
  The same reasoning makes crypto/rand panic instead of falling back to a software generator. A "random" source that quietly returns predictable bytes would be a terrible idea:
```
// crand_read fills buf with size cryptographically secure random bytes.
// Panics if the target does not define so_crand_read.
static inline void crand_read(uint8_t* buf, so_int size) {
    if (size <= 0) return;
    if (so_crand_read(buf, size) != size) {
        so_panic("crypto/rand: no entropy source");
    }
}
```
  You can still use a random fallback when cryptographic security isn't needed, such as for hashing map keys or math/rand:
```
// runtime_Seed returns a random 64-bit seed.
static inline uint64_t runtime_Seed(void) {
    uint64_t seed = 0;
    // Use cryptographically secure random if available.
    if (so_crand_read((uint8_t*)&seed, 8) == 8 && seed != 0) {
        return seed;
    }
    // Fallback to deterministic xorshift64 sequence.
    // ...
}
```
  Hosted-only
  
  Some things aren't worth solving with hooks, such as the os and net packages, which require a lot of target-specific code. In these cases, it's better to use a header-level guard that fails in freestanding mode:
```
// so/os/os.h
#include "so/builtin/builtin.h"

#ifndef so_build_hosted
#error "os: hosted environment required"
#endif
```
  If user code imports os in a freestanding environment, the compiler reports an error at compile time instead of at link time or runtime.
  
  Testing
  
  "Compiles without libc" is easy to believe and easy to get wrong. The only way to be sure is to test the freestanding implementation.
  
  My approach in Solod is to run the freestanding packages' test suites with a WASI runtime and a small harness. The harness defines all five hooks from the Target hooks section as WASI imports:
```
// ciovec is the buffer descriptor that fd_write reads.
// The WASI ABI is 32-bit, so both fields are 32-bit.
typedef struct {
    const uint8_t* buf;
    uint32_t len;
} ciovec;

// wasi_fd_write writes the buffers to the file descriptor
// and stores the number of bytes written in nwritten.
__attribute__((import_module("wasi_snapshot_preview1"), import_name("fd_write")))
extern uint32_t wasi_fd_write(uint32_t fd, const ciovec* iovs,
                              uint32_t iovs_len, uint32_t* nwritten);

// so_write_out writes size bytes to the standard output of the WASI host.
so_int so_write_out(const uint8_t* buf, so_int size) {
    ciovec iov = {.buf = buf, .len = (uint32_t)size};
    uint32_t written = 0;
    if (wasi_fd_write(1, &iov, 1, &written) != 0) {
        return 0;
    }
    return (so_int)written;
}
```
  The freestanding make task builds tests from stdlib packages into a single wasm32-freestanding module and runs it with wasmtime. This covers the freestanding logic with the same tests that run in hosted mode, so no separate tests are needed.
  
  Final thoughts
  
  Here's a summary of the approach I used write a freestanding stdlib in C:
  - Choose between hosted and freestanding at compile time.
  - Use the compiler builtins when possible.
  - Implement the missing parts and port the standalone code.
  - Use explicit allocators; prefer values to pointers.
  - Declare hooks for the hardware, with weak defaults.
  - Fail fast for packages that can't work in freestanding.
  - Test in a freestanding build, not just hosted.
  I hope you find it useful too.
  
  If you're interested in trying this in practice, take a look at Solod's README — it has everything you need to get started. Or try it online without installing anything.
12. 🔗 r/LocalLLaMA I just built a mini Kimi-K3 from Scratch under 250$. Already beats GPT-2 (124M)! rss
  
  | I pre-trained a 1.02-billion-parameter on Kimi K3 replica trained on 5.00 billion decontaminated tokens for $250. This model has 1.02 billion parameters, of which 145 million are active per token. It is roughly one two-thousandth of K3 by total size. It saw 5,000,003,584 tokens, which is a rounding error against the corpora frontier models are trained on. It has never been instruction-tuned, and it has only ever done one thing: predict the next token. What it does have is K3's architecture: - Kimi Delta Attention, Gated MLA, Attention Residuals - LatentMoE with the same aux-loss-free balancer - Same activation function with the same two constants - K3's own 163,840-token tokenizer, unmodified. I report a 33.4% HellaSwag which beats the GPT-2 124M score of 28% Read the entire tutorial here: https://books.vizuara.ai/book/pretraining-a-mini-k3 submitted by /u/OtherRaisin3426
  [link] [comments]
  ---|---
13. 🔗 smol-machines/smolvm smolvm v1.9.0 release
  What's Changed
  - macOS: name the missing hypervisor entitlement when a boot fails with -22 by @Bnjoroge1 in #948
  - Detach the API test server from the test pipe by @BinSquare in #969
  - Bring the opt-in smolfile and virtio-net suites up to date by @BinSquare in #970
  - Enforce the resolved egress policy when a machine run is served from the image cache by @BinSquare in #972
  - Repack artifact-sourced machines whose layer cache is tar-form by @BinSquare in #971
  - Delegate cgroup2 controllers at agent boot by @BinSquare in #973
  - Constrain machine names to lowercase DNS labels by @BinSquare in #975
  - Hostname containers after their machine by @BinSquare in #974
  - Write the default /etc/hosts when the image ships one with no entries by @BinSquare in #976
  - Stop egress-events from panicking when its output pipe closes early by @BinSquare in #978
  - Revert the machine-name DNS-label restriction by @BinSquare in #979
  - Fail guest connections fast when the host cannot reach the destination by @BinSquare in #981
  - Verify layer extraction reached the disk before trusting the layer cache by @BinSquare in #980
  - Let image machines without an entrypoint boot to the bare agent by @BinSquare in #985
  - Auto-shrink a machine's disk by reclaiming freed blocks to the host by @BinSquare in #984
  - Update h2 to 0.4.16 to clear the RUSTSEC-2026-0258 advisory by @BinSquare in #995
  - Fix isatty() reporting a macOS virtiofs-mounted file as a terminal by @BinSquare in #993
  - Support segmented CUDA graph capture by @BinSquare in #987
  - Add uid, gid and mode flags to machine cp and land streamed uploads inside the running workload container by @BinSquare in #997
  - Resolve guest file and socket operations in the namespace the workload actually runs in by @BinSquare in #878
  - Inject a bundled Venus Vulkan driver into GPU workload containers so stock images get Vulkan with no setup by @BinSquare in #1001
  - Use shared COW disk bases for VM-mode creates by @depombo in #991
  - Bump the workspace to 1.9.0 by @BinSquare in #1002
  Full Changelog : v1.8.3...v1.9.0
14. 🔗 r/LocalLLaMA Qwen3.8-27b has the highest level of "agency" I've ever seen in a local model rss
  
  | Off a single prompt, given my credentials and the name of my university, qwen3.8-27b was able to successfully pull my class schedule from the kinda shitty and convoluted web of university websites. It needed no human intervention, and executed 80 tool calls. Another time, I asked it to investigate a user on a social media network, and it found one public video, downloaded it, extracted frames every few seconds so it could "watch" the video, and installed fucking openAI whisper and ran a transcription to understand the context, before selectively zooming in on and brightening some frames to see the action. That this shit is running on my own hardware (single RTX 3090) is fucking incredible, the general public doesn't realize how cyberpunk our reality already is. Quant: Unsloth's Q4_K_S (kv cache quantized to q8) Context: 150k submitted by /u/synth_mania
  [link] [comments]
  ---|---
15. 🔗 Rust Blog Supply chain attack on arrayref rss
  What happened
  
  On 2026-08-20 at 7:15 UTC we got a report that the proc-macro1 crate was malicious.
  
  The Rust Security Response Team verified this to be the case: the crate had a build script that was downloading a malicious payload.
  
  This crate proc-macro1 and others like it (proc-macro-en, aovine, arone, aronenao, tinymember) have been deleted.
  
  Furthermore, we discovered that the popular arrayref crate had recently been republished and made to depend on this crate, with the most recent versions yanked. We have removed the malicious version and unyanked the maliciously- yanked versions. Other crates by that author (internment, append-only- vec) were also affected so we have done the same for those, and locked the account as a precaution. We do not believe the author of arrayref to be acting maliciously, but their computer or credentials are likely compromised, and we are attempting to contact them.
  
  What you need to do
  
  We recommend you check your local dependencies to ensure these crates were not pulled in. Here are the malicious versions that we deleted from crates.io:
  - append-only-vec@0.1.9: published at 2026-08-20T07:37:49Z, deleted at 2026-08-20T09:25:24Z. Online for 107 minutes.
  - arrayref@0.3.10: published at 2026-08-20T07:15:00Z, deleted at 2026-08-20T08:41:40Z. Online for 86 minutes.
  - internment@0.8.7: published at 2026-08-20T07:34:07Z, deleted at 2026-08-20T09:04:11Z. Online for 90 minutes.
  - proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember (any versions).
  You can quickly check if these crates have been used locally by going through ~/.cargo/registry/cache with this command:
```
find ~/.cargo/registry/cache -type f $ \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
$ -print
```
  Thanks
  
  We'd like to thank the Research Team at Nextron Systems GmbH for initially discovering this and reporting it to us. We'd also like to thank Emily Albini, Manish Goregaokar, Marco Ieni, Tobias Bieniek, Ubiratan Soares, and Walter Pearce for participating in the response here.
16. 🔗 Rust Blog Announcing Rust 1.98.0 rss
  The Rust team is happy to announce a new version of Rust, 1.98.0. Rust is a programming language empowering everyone to build reliable and efficient software.
  
  If you have a previous version of Rust installed via rustup, you can get 1.98.0 with:
```
$ rustup update stable
```
  If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.98.0.
  
  If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!
  
  What's in 1.98.0 stable
  
  Algebraic floating-point methods
  
  The floating-point types f32 and f64 now have "algebraic" methods for addition, subtraction, multiplication, division, and remainder. These allow optimizations on these operations using the algebraic properties of real numbers, even though these properties do not hold with the limitations of floating-point representations. The exact set of optimizations is not specified, but may be similar to the kind of optimization you would see with the -ffast-math option in other languages.
  
  For example, floating-point addition is not associative, so a sum like a + b + c + d must be evaluated in the left-associative order in which it is parsed, like ((a + b) + c) + d. If you write the same sum as a chain of algebraic_add calls, then the compiler is free to reorder it, perhaps like (a + b) + (c + d) to evaluate the partial sums simultaneously. Broader loop-vectorization is often enabled by using these algebraic methods as well.
  
  These methods are non-deterministic, since the compiler is free to choose different optimizations, but they never cause undefined behavior. See the library documentation and the original API change proposal for more details.
  
  Buffered integer formatting
  
  All of the primitive integer types now have a format_into method that takes a &mut NumBuffer<Self> parameter, which is a buffer that is large enough to hold the decimal format of any value of that type. The buffer itself is opaque, but the method returns the formatted &str with a lifetime borrowed from that buffer.
  
  This method also bypasses much of the dynamic dispatch that you would get with buffered write! formatting, which can be a boon to performance. The itoa- benchmark repo now shows that format_into performs similarly to itoa itself, so this could serve as a standard replacement for that dependency and others like it.
  
  Fix interaction between ManuallyDrop and Box
  
  Prior to Rust 1.96.0, there was a bug in the Rust compiler, which made the following code undefined behavior:
```
let mut x = ManuallyDrop::new(Box::new(1));
unsafe { ManuallyDrop::drop(&mut x) };
let x = x; // UB!
```
  This is because the compiler considers it undefined behavior to move a Box that has been dropped (deallocated), and ManuallyDrop used to propagate that, such that moving ManuallyDrop<Box<_>> where the box has been dropped would also be considered UB.
  
  In Rust 1.96.0 we fixed this, so this code was no longer UB. In this release we have updated the ManuallyDrop documentation, providing a stable guarantee that this code will continue to not be UB in the future. See ManuallyDrop docs and the related RFC 3336 for more information.
  
  Stabilized APIs
  Other changes
  
  Check out everything that changed in Rust, Cargo, and Clippy.
  
  Contributors to 1.98.0
  
  Many people came together to create Rust 1.98.0. We couldn't have done it without all of you. Thanks!
17. 🔗 matklad Better Batteries rss
  
  Better Batteries
  
  Aug 20, 2026
  
  One of the eternal schisms in programming is over the question of whether the standard library should be minimal or encompassing. This is the wrong question to ask. The right one is:
  
  Which social architecture creates a high-quality standard library?
  
  Python is always brought up as example of leaky batteries exploding in slow motion, but this has nothing to do with size. The problem with Python’s stdlib is its, ahem, uneven quality. Some standard library modules don’t follow language naming conventions! You know which unittest module I am talking about :-)
  
  But even that is not a mistake. It’s actually Python core’s advantage — that it makes functionality available early, not thinking about the future too much. That’s how we ended up with ossified cAPI which makes CPython the language, but that is also how we ended up with Python powering data scientific revolution.
  
  The Go standard library is similarly encompassing, but it is held in a high regard. Go team has institutional capacity to deliver well-designed API for the standard library, and then some: https://pkg.go.dev/golang.org/x
  
  Rust is an interesting case. The 1.0 standard library APIs are brilliant. Collections and iterators are a work of art. But it also feels that, while the current team has the capacity to preserve existing APIs and fill in some gaps, the capacity to execute design decisions is limited. While golang.org/x captures excess capacity, rust-lang-nursery is a graveyard. Maybe I am over-indexing on my favorite hobby- horse, but it seems that the reason for Rust not having an API to get a stream of random bytes from the OS in 2026 is that, while it is an easy technical problem, it requires tricky organization architecture (including getting money in peoples’ pockets, of course) to actually get solved in the high-stakes environment of a world-wide coordination problem called a programming language.
18. 🔗 Console.dev newsletter TanStack Table v9 rss
  
  Description: Headless tables.
  
  What we like: Provides underlying functionality for sorting, paging, selection, spans, pinning, columns, and filtering data grid UIs. You maintain control of styles and interactions. Integrates into various frameworks e.g. React, Vue, Solid, Svelte. Lots of focus on performance.
  
  What we dislike: Potential bundle size increased 14 kB in v8 to 25 kB in v9, but tree shaking will help reduce that to just the required features.
19. 🔗 Console.dev newsletter TurboVec rss
  
  Description: Rust vector index.
  
  What we like: Built on Google’s TurboQuant algorithm. Add vectors without any training step or tuning. Bundles optimized kernels for various architectures. Runs locally and self-hosted. Integrates into common frameworks (LangChain, LlamaIndex, Haystack, Agno).
  
  What we dislike: Good integration docs, but minimal operational docs about how to run it.
August 19, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-19 rss
  IDA Plugin Updates on 2026-08-19
  
  New Releases:
  - auto_re x86 support + more linux funcs
  - efiXplorer efiXplorer v6.3.0
  Activity:
  - auto_re
    
    bae56138: Add more support for linux (#13)
  - efiXplorer
    
    241dd3c5: fix: remove 64 suffix from macos build artefacts, bump version (#148)
  - ida-codemode
    
    aeba51a8: Harden loopback HTTP request handling
  - ida-domain
    
    68fea78e: Bump gitpython to 3.1.59 and cryptography to 50.0.0
  - idawilli
    
    5bd3435d: Merge pull request #146 from mrexodia/no-blocking-wait
    
    a74b7e41: Do not call ida_auto.auto_wait on the UI thread
2. 🔗 PrimeIntellect-ai/prime-agent v0.7.4 release
  - Fixed model searches ranking stronger matches ahead of weaker signed-in matches while preferring signed-in providers for equivalent results (#539 by @eliebak).
  - Fixed large IPython variables repeatedly slowing later turns by excluding them from persistent snapshots and removing them when context is compacted.
  - Fixed daemon socket paths being used verbatim in identity derivations: on supported platforms, --daemon-socket spellings differing only by duplicate or trailing slashes now normalize to one canonical path, so worker-descriptor namespaces, daemon log files, and persisted descriptors agree.
  - Added a thinking option to rlm.run for spawning subagents with an explicit reasoning level; invalid levels for the resolved child model fail spawn.
  - Changed opening the agents view (full or scoped) with a draft prompt to auto-stash the draft instead of refusing; the draft is restored into the editor when the session is reopened.
  - Fixed Shift+Enter no longer inserting a newline in terminals that send a literal \n (for example a Ghostty shift+enter=text:\n mapping): the byte decoded as ctrl+j and triggered the new edit-diff toggle instead of the editor newline.
  - Removed a system prompt paragraph referring to an async bash() kernel helper and managed jobs that do not exist in the runtime.
  - Changed RLM guidance to orchestrate independent workers in parallel, use available async shell helpers safely, end the turn instead of sleeping, polling, or blocking on long awaits, provide proactive outcome-focused progress updates from root agents, and use simplified technical English for user-facing prose.
  - Fixed new top-level daemon sessions inheriting an RLM child depth from the supervisor process.
  - Fixed active goals stalling after a mid-goal automatic compaction when the previous continuation prompt was already running: only undelivered continuations deduplicate, so a fresh continuation is queued instead of being suppressed.
3. 🔗 Simon Willison Conceptual integrity and counting lines of code rss
  
  Last week I recorded an episode of the Talking Postgres podcast with Claire Giordano on the subject of "How AI is changing software development". We had a really great conversation. Here are a couple of my highlights from a lightly edited transcript (prompt to Claude: "very minor edits to remove disfluencies").
  
  This is the latest version of an argument I've been trying to build about why sometimes it does make sense to talk about lines of code as an indicator of productivity with coding agents, at 35:01:
  
  A lot of people will tell you it makes no sense to measure productivity in lines of code. I’d actually disagree, because there’s a hard limit. In the before-times, a software engineer could produce a few hundred lines of production-ready code per day — and 200 lines of working, debugged, production-level code is an incredibly good day. Most days you’d produce 50 or 60.
  
  If agents let you produce a thousand lines of debugged code, that really is a very meaningful improvement — as long as the code is the same quality: maintainable, tested, all of that. You can get to that point with agents, but it takes a huge amount of skill and knowledge and experience. That’s what senior engineers are made of.
  
  I can do way more work as a single engineer than I could without agents. So you could argue, why should a company have more than one engineer? Beyond the obvious bus factor thing — a team of one is a very badly designed team — the answer is that the new limiting factor is cognitive capacity. I can churn out code a hundred times faster. I don’t have the cognitive capacity to stay on top of 100 times the amount of code. So you still need a team of engineers, so you can load balance that cognitive capacity across the team.
  
  And this section on conceptual integrity at 46:03, which Claire equated to the Winchester Mystery House!
  
  Simon: There’s a concept in The Mythical Man-Month — conceptual integrity — where well-designed software has an integrity to it: there are no surprises in it, it covers exactly the right domain of things, everything fits together and makes sense. That’s so much harder with coding agents, where you can have an idea for a feature, run a prompt, and five minuteslater you’ve got the feature. Your software grows little weird bumps in funny different directions.
  
  Claire: You know my analogy for that? The Winchester Mystery House.
  
  Simon: It’s got 140 rooms, because the woman who built it was the widow of the guy who invented the Winchester rifle, and her psychic told her she’d be haunted by the ghosts of everyone killed with that rifle unless she kept building the house forever. So for 40 years she kept adding new rooms. That’s exactly the problem with coding agents and software: it’s very easy to keep adding new rooms, because the cost of adding those rooms is so much cheaper. What you end up with is something where the conceptual integrity falls apart — and then it’s harder to make decisions about it.
  
  It all keeps coming back to discipline. It used to be that the discipline was enforced on you by the amount of time it took. You’d come up with an idea for a crazy feature and think “yeah, but that would take me a week — I cannot justify that, so I’ll forget about it.” If it takes an hour, it’s so much easier to justify.
  
  (Side-note: the Wikipedia article includes credible sources that dispute the story about the psychic.)
  
  You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.
4. 🔗 HexRaysSA/plugin-repository commits sync plugin-repository.json rss
```
sync plugin-repository.json

No plugin changes detected
```
5. 🔗 r/LocalLLaMA Introducing Qwen3.8-27B Dynamic v3 Unsloth GGUFs rss
  
  | Hey everyone! We’re releasing new Qwen3.8-27B GGUFs with 10% higher accuracy for the same size. This uses a new version of Dynamic v3.0 Unsloth Dynamic V3 outperforms others by >10% on Div-300, KLD & more benchmarks. We also release 1-bit quants that retain 77% accuracy. Run on 8GB RAM. Some of you already saw we updated our quants a few hours ago. No, nothing was broken, nothing needed fixes (I don't know why people even said this since it's a complete fabricated story). This was purely an update to make them EVEN BETTER. We do not train on the imatrix calibration dataset, and we do NOT use QAT or QAD. Everything is done through post-training quantization. Our imatrix file used is available for the community to test, evaluate, and use. We encourage researchers and developers to create variations and fine-tunes of Qwen3.8 using our Unsloth quants/imatrix. You can read our over fitting analysis as well. Blog with all details and more benchmarks: https://unsloth.ai/docs/basics/dynamic-3.0-ggufs GGUF: https://huggingface.co/unsloth/Qwen3.8-27B-GGUF Enjoy! We also will be doing a new Unsloth Desktop update today: https://github.com/unslothai/unsloth We had A LOT of updates and will be introducing auto compaction, allowing external APIs to do tool calling and more. submitted by /u/danielhanchen
  [link] [comments]
  ---|---
6. 🔗 The Pragmatic Engineer The Pulse: Grok’s CLI caught uploading all your local files to the cloud rss
  Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from a previous The Pulse issue. Full subscribers received the article below four weeks ago. If you 've been forwarded this email, you can subscribe here .
  
  Last week, xAI (Elon Musk's AI company, now part of SpaceX) released the Grok 4.5 model, built by Cursor (an acquisition), trained on SpaceX GPUs, and branded "Grok." It's a pretty good model; benchmarking as close in coding capability to Opus 4.8 and GPT 5.5 - while being 60-70% lower cost.
  
  Grok 4.5 can be used via API, but is easiest used via the Grok Build coding CLI. So, that's what many devs did. Some of them have noticed something really weird: the CLI is uploading all their local files in their working directories! Here's an independent AI safety researcher known as 'Cerblab' documenting what is happening (emphasis mine):
  
  "xAI's official Grok Build coding CLI (grok), on a normal consumer login, does three things worth documenting precisely:It transmits the contents of files it reads -- including a .env secrets file -- to xAI, verbatim and unredacted. The secret appears in two channels: the live model turn (POST /v1/responses) and a session_state archive uploaded and accepted (HTTP 200) via POST /v1/storage -- the endpoint the binary routes to the grok-code- session-traces GCS bucket (see section 5).It uploads the whole repository -- every tracked file's content plus git history -- independent of what the agent reads. Grok packages the workspace and uploads it via POST /v1/storage. Proven directly: on a real codebase, with the prompt "reply OK, do not read any files", Grok uploaded the entire repo as a git bundle (POST /v1/storage -> 200); git cloning the captured bundle recovers a file the agent was told not to open -- src/_probe/never_read_canary.txt -- with its unique marker verbatim, plus the full git history (appendix uploaded_repo.bundle). And it scales: on a 12 GB repo of never-read random files, /v1/storage moved 5.10 GiB, all HTTP 200 (truncated mid-stream), while the model-turn channel moved just 192 KB -- a ~27,800× ratio that pins the upload to the codebase, not to what was read. No storage upload failed; the only non-200s were a model-usage quota (402/429) on /v1/responses and one unrelated 404 -- not a storage size cap.The storage destination is a Google Cloud Storage bucket, grok-code-session-traces (not AWS S3) -- named verbatim in the binary and in a captured metadata.json (gs://grok- code-session-traces/…). I did not find this mechanism surfaced in the CLI's install/quickstart materials (not an exhaustive docs audit -- §7), it is active by default, and disabling "Improve the model" does not turn it off (/v1/settings still returned trace_upload_enabled: true; §6).
  
  None of this proves xAI trains on the data -- that is a policy question addressed in [section] 6. What is proven is transmission, acceptance, and storage."
  
  There's so much wrong with this approach! To name a few:
  - Sending your codebase over the context window is not normal. All AI agents send over their context window to the server that runs the LLM. That's where tokenization happens and the context is appended to the session. This means that other AI agents send over some part of the code that they read in their context window.
  - No need to send over the source code to index it. Indexing the codebase is important for efficient code lookup, and we covered how Cursor does this in a privacy-conscious way by indexing a user's codebase locally, creating embeddings, and sending those embeddings to the server. Cursor's server does not store any of the user's codebase though. Except that Grok CLI transferred all users' codebases to a cloud bucket! Given Cursor and Grok are now combined as part of SpaceX, it 's a real head scratcher why the Grok CLI isn't doing what Cursor always has.
  - Sending over unencrypted .env files is reckless. Local .env files store secrets, database access tokens, service access tokens, and more. These are sensitive pieces of information that need to be handled with care. If transmitted, they should be encrypted at the very least. Grok / SpaceX storing them on the GCP storage bucket - likely unencrypted - is flat-out unacceptable and reason enough for any sensible company to ban usage of Grok CLI.
  - No good reason to upload git history. Sure, seeing Git history could be helpful when training an AI model.
  - It 's malicious to not tell devs anything about it. Developers using Grok CLI haven't been asked to opt into this data upload, nor notified of it. Most evidently had no idea this has been happening, and are understandably furious after Cerblab's writeup went viral.
  SpaceX throws devs "under the bus"
  
  Caught red-handed, Grok CLI disabled file uploads with a remote feature flag. AWS engineer Wes Eklund started tracking upload functionality with the CLI, finding that the uploads suddenly stopped due to a feature flag being flipped by the Grok team, pausing data collection.
  
  But the code functionality to stream all local files to the server, unencrypted, remained present in the CLI, even in later updates. Read an in-depth analysis by Wes.
  
  SpaceX 's official response was pretty laughable, not explaining why .env files and .git history were uploaded, and adding that enterprise customers with zero data retention (ZDR) enabled were the only ones unaffected by underhanded, secret uploading of users' local files:
  
  Translation: "Enterprise users with ZDR turned on were not impacted. To everyone else: we didn't tell you about this hidden/privacy command, but it's your fault. Source: SpaceX
  
  My initial reaction is what a condescending response by SpaceX, swiftly followed by the question: does Grok CLI even have enterprise customers? It might be few, given how reckless the team evidently is by uploading unencrypted secrets! SpaceX CEO Elon Musk chimed in with a post that seemed to be almost trolling angry users. He wrote:
  
  "SpaceX policy regarding data retention.
  
  It is actually helpful for debugging issues if we can retain some amount of data, so allowing this would be appreciated, but your privacy settings are always respected."
  
  This makes it worse because SpaceX has been secretly uploading far more data than is "useful for debugging!" Uploading the git history and sensitive .env files is not , in any way, useful for debugging. Also, Grok/SpaceX did not upload "some amount of data"; it uploaded every last file it could find in your local folder.
  
  The developer community is justifiably upset to read SpaceX and Musk pretending that Grok has only uploaded scraps of data purely for debugging purposes. This time, even fans of SpaceX and Grok are speaking out against Musk and his company's behavior. AWS engineer Wes Eklund:
  
  "Elon, firstly, huge fan of everything you work on. Completely understand the need for some trace data to improve customer experiences.
  
  From what I've researched, it seems to be much more than just trace debugging issues. It seems to be entire code repos with sensitive information just collected entirely.
  
  Your Google Cloud blob storage must have petabytes of code repos from us.
  
  Not ideal."
  
  Sam Altman pushes Grok to open source Grok CLI
  
  OpenAI CEO, Sam Altman, also posted, using a term Musk often employs when commenting on things he disapproves of in society, and hinting at the benefits of Codex which doesn't upload your whole local filesystem, or mess with .env files and the git history. The Codex harness is open source, so secretive file-upload functionality would be visible in the source code:
  
  Altman uses Musk 's trademark "concerning" remark against him. Source: Sam Altman
  
  Musk clearly read it and responded a few hours later:
  
  Musk committing to open sourcing Grok CLI. Source: Elon Musk
  
  A day later, (15 July), SpaceX did indeed open source Grok CLI. Altman's comment seemingly hit home. Also, SpaceX has stated it is deleting data from its servers, writing:
  
  "We disabled default retention for all Grok Build users starting on July 12th. Additionally, we are deleting all coding data that was previously retained, ensuring every user's preferences are respected. With these steps, Grok Build goes beyond other major coding products to protect user privacy."
  
  The open sourced repo is rushed, unsurprisingly. Kernel engineer Elliot Arledge used the repo and reported what he found:
  
  "Out of the box, cargo test --workspace doesn't compile. 190+ errors, all one bug class: cross-crate test helpers hidden behind #[cfg(test)], which Bazel's per-target test builds tolerate but Cargo doesn't, because a dependency is never compiled in test mode. The default-bazel feature is declared in ~20 manifests and wired to nothing. Ungating the benign helpers and putting the signing-key test seam behind a dev-dependency-only feature gets the suite running for the first time on the published tree: 24,663 passed, 28 failed, and every one of the 28 is a pre-existing bug the broken build had been hiding (tests reading your real ~/.claude/settings.json, a tool missing from the registry, macOS /var symlink breakage, one Theme::current() race).
  
  Questions for the team:
  
  Did anyone try downloading this repo and running it before publishing?"
  
  In fairness, it's clear from the outside that the dev team was instructed to open source the repo ASAP, and did just that. I would expect improvements to allow the developer community to compile the repo and run tests will come later.
  
  On a side note, I wonder what the mood within Grok is. A mandate to open source the product - that was not built to be open sourced! - and doing it in a couple of hours hints what it's like to work there. Some folks doubtless would find it thrilling and a big challenge, while others likely find it pretty stressful having the "Eye of Sauron" (the CEO) upon them!
  
  Can companies trust Grok now?
  
  To hand it to Grok/SpaceX, the last 24 hours of this incident saw some impressive execution. In contrast, everything that took place beforehand screams "amateur hour":
  - Did no one in teams that wrote the functionality to upload the complete local codebase raise concerns that this would be unacceptable to devs?
  - How did uploading secrets without encryption not raise alarm bells?
  - Why greenlight any of it without opt-in and do it in a secretive manner?
  For sensible companies generating revenue with software, vendors who are allowed to access their codebase are limited to those that can be trusted. Grok has demonstrated it is unprepared to handle codebases with security fundamentals in mind.
  
  There's now frantic backpedaling and rapid open sourcing, but my impression is that this is simply because Grok/SpaceX was caught red-handed, and understands the risk of losing enterprise contracts caused by this flagrant breach of trust. This is why SpaceX's communication mentioned that enterprise customers with zero data retention have not been impacted!
  
  Trust is earned in drops and lost in buckets; SpaceX/Grok will likely learn this. By secretly uploading codebases and secrets, Grok CLI revealed itself as an untrustworthy coding agent that's a risk to use. Meanwhile, all the major competitors - Claude Code, Codex, OpenCode, Gemini CLI - have never violated user trust this way.
  
  Grok CLI can rebuild trust, but it'll likely take years of no security-related incidents to prove they are an open source-first product (that they were not, just a day ago!), and also demonstrate that they care about "normal" developers, and not just enterprise clients with ZDR turned on.
  
  This incident is a good reminder of why planning and process can slow shipping speed, but increase revenue generation. I would wager that the Grok team has shrunk SpaceX's enterprise subscription prospects for the foreseeable, in the name of saving a few hours on security reviews, learning what other coding harnesses do with codebase uploads, or even just asking the Cursor team!
  
  I predict Grok/SpaceX will have to offer very high usage limits inside the Grok CLI to convince devs to take a risk on running this software on their system. And they will have to undercut OpenAI and Anthropic API pricing massively for any security team to greenlight use of a CLI that just last week was sending .env secrets unencrypted to their GCP buckets.
  
  Of course, SpaceX/Grok will be just fine as it has the capital to fix things. It will now just be a lot more expensive and time-consuming to fix something that was likely caused by a few engineers wanting to make debugging easier!
  
  Read the _full _The Pulse issue__ , or check out this week 's The Pulse . The full issue additionally covers:
  1. New trend: concern about massive increase in code review load. Top of mind for engineering leaders: what to do about the ever-growing code review load, and how devs are starting to review code less thoroughly than before? Many questions, but few proven solutions. Send comments about what you see working.
  2. Are more devs at enterprises upset about enterprise pricing by AI labs - and does it matter? I got a message from a reader baffled to learn their company pays 20-30x the price for tokens than their own $20/month Claude Code / Codex subscription. It may show how valuable AI coding tools are.
  3. Linux creator: AI "clearly useful." Inside the Linux kernel maintainers group, the discussion veered onto whether Linux should consider banning AI contributions, similar to how some FOSS projects have done so. Linus Torvalds weighed in and made it clear that AI is useful, everyone should decide whether to use it, but no one is allowed to tell others what tools to use. Given AI is an increasingly capable tool, it would be foolish to not use it as such.
  Read the full The Pulse
7. 🔗 @binaryninja@infosec.exchange Sidekick can use the terminal now! With the new run_terminal_command tool, mastodon
  
  Sidekick can use the terminal now! With the new run_terminal_command tool, agents can jump into bash or PowerShell right alongside their Binary Ninja analysis. Unpack an archive, run binwalk, poke through git history, curl a URL, or inspect files that never even made it into Binary Ninja. Commands still require your approval by default. https://sidekick.binary.ninja/blog/sidekick-26-1-a-proper-home-for- sidekick/#sidekick-can-use-the- terminal
8. 🔗 r/LocalLLaMA Stop Anthropomorphisizing Intermediate Tokens: Qwen3.8 doesn't "overthink" rss
  
  | Intermediate tokens, called "thinking" or "reasoning" actually are nothing like it. Humans do step-by-step reasoning leading to the conclusion. LLMs use intermediate traces to augment their prompt. This explains why sometimes the answer is very good but the "reasoning" is verbose. Flooding your context window or fighting compaction are different issues. edit: I love this section from the main research they linked.
  
  Our findings consistently challenge the prevailing narrative that intermediate tokens constitute a semantically meaningful reasoning process. First, we observe a pronounced lack of correlation between solution correctness and trace validity—models frequently produce invalid reasoning traces even when they arrive at correct solutions. Second, and more strikingly, models trained on corrupted or semantically irrelevant traces achieve performance comparable to, and often exceeding, that of models trained on correct traces, especially on out-of-distribution tasks. Third, although post-training with reinforcement learning improves solution accuracy across both in- and out-of-distribution settings, it does not consistently enhance trace validity. In fact, we find cases where reinforcement learning decreases trace validity while simultaneously improving solution accuracy for models trained on correct traces. Moreover, models trained on corrupted traces continue to outperform their correct- trace counterparts across domains while consistently generating invalid reasoning traces. Finally, we find that the length of the generated traces is largely agnostic to the difficulty of the underlying problem, undermining the notion that it reflects problem-adaptive computation. Together, these results suggest that the effectiveness of intermediate tokens does not arise from their seemingly interpretable semantic content. By systematically disentangling trace semantics from the underlying problem, our study demonstrates that if performance is the objective, assuming human-like or algorithmically interpretable trace semantics are ideal or even achievable is not only unnecessary but potentially misleading.
  
  https://openreview.net/forum?id=gDE7YcRC3F submitted by /u/ThirdWaveCat
  [link] [comments]
  ---|---
9. 🔗 MetaBrainz Growing pains: An update on the ListenBrainz service status rss
  TL;DR: The growth of ListenBrainz has caught up with us, and our limited team is working on replacing central parts of our infrastructure. In the meantime, many features are unstable.
  
  We are victims of our success. While in the long term this is a good problem to have, the sharp increase in users over the past year and a half has left our infrastructure cracking at the seams.
  
  The good news: Your listens are being stored and imported without issue, even if there are delays. The core service is not compromised and we ask that you please keep submitting your listens. Your stats and playlists will be back!
  
  However, we know that every other week your statistics, weekly playlists, and other features fail to generate for everyone, and cause crashes. We know it is frustrating, and we share that feeling.
  
  While we are aware of the issues, fixing them is far from simple and requires us to completely rework all the crucial parts of our infrastructure.
  
  In the interest of transparency, here are our main issues and what we are doing to fix them:
  
  How many listens?
  
  Our database dumps have become too big for us to process.
  We went from 0 to 1 billion listens in 7 years - then to 2.5 billion in the next one and a half years.
  
  Generating and copying our (now huge) database dumps causes crashes as our limited servers run out of memory and disk space.
  
  We are working on improvements, but for each change we need to wait two days to be able to run tests.
  
  In addition, we are moving away from TimescaleDB, a Postgres database extension for time-series data, in favour of vanilla Postgres with a new partition scheme.
  
  We found that TimescaleDB was not adapted for our use case of working with historical imports or deleting listens and users (and all their listens), as well as large gaps between listens, all causing some very slow queries.
  
  Where are my stats, goddammit?
  
  Our statistics and playlist calculation infrastructure, a Spark cluster of 5 servers, is running out of memory and crashing, from one task or another. This used to happen once every few months but is now a weekly occurrence.
  
  This is the issue which is breaking stats, playlists, user similarity, unlinked listens, fresh releases and more.
  
  We are moving to using Clickhouse instead for all statistics calculations, which will free up the Spark cluster to be used for generating playlists and other tasks.
  This move is taking some time, as a single person in the team carries the responsibility of rewriting essential code and testing everything carefully.
  
  This will eventually open the door to requesting stats for an arbitrary time range instead of being limited to this and last week/month/year, a hotly requested feature that is not possible with our current system.
  
  The scraping situation
  
  To make matters worse, the entire internet is being bombarded by unscrupulous bad actors (looking at you, AI companies) that don't follow the rules and try very, very hard to evade any measure meant to limit them.
  
  They rent botnets of millions of residential IPs so they can scrape our APIs and websites incessantly, over and over again, while evading detection, all for data that they could download for free.
  
  They cause surges of 5x the usual traffic across all our projects and slow everything down on our resource-constrained infrastructure.
  It also forces us to spend time dealing with these DDOS- like surges instead of working on our other pressing issues.
  
  For ListenBrainz specifically, we have had to disable some features/endpoints that during scraping waves made the website completely unreachable for everybody.
  
  But wait, there's more…
  
  The loss of our founder in late February was big blow to our team.
  
  Rob was one of the custodians of Listenbrainz infrastructure, but also a central ListenBrainz team member.
  
  We have had to cross-train our ListenBrainz dev team -it is only three of us- to deal with infrastructure and other new aspects, as well as reorganize priorities to deal with the day-to-day operations while the foundation was in the process of hiring a new executive director.
  
  We have been so greatful for the wonderful patience and kindness shown to us by you, our users and community, as we work through these growing pains. Keep submitting listens and let's grow together!
  - your ListenBrainz Team
10. 🔗 r/LocalLLaMA Thoughts About Scaling Law - Z.ai rss
  
  |
  
  Thoughts About Scaling Law
  
  Scaling, but not only of parameters. Every model release now ends with the same question: how many parameters? It isn't a question that can be answered on its own. Parameter count is only meaningful alongside three others — how much data you have, where you intend to spend your compute, and who will run the model, under what conditions. The field learned this the hard way. Kaplan et al. (2020) fit an exponent that told everyone to grow parameters faster than data — roughly 2.7:1 — and the industry complied: GPT-3, Gopher, MT-NLG. Hoffmann et al. (2022) redid the experiment across four hundred models and found the compute-optimal split is closer to 20 tokens per parameter, and that with sufficient compute the two should grow at the same rate rather than drifting apart. The error in the earlier fit compounded with every order of magnitude of compute, which is why the largest models of that generation were the most misallocated. The trillion-parameter round was, in retrospect, a detour the whole field took together and then reversed. Chinchilla wasn't the end either. It optimized training compute for models that would be trained once and evaluated. Today a model is called billions of times a day and inference dominates lifetime cost. Put inference into the objective and the optimum moves toward smaller models trained far longer — deliberate over- training, which is what Llama-2-7B and Gemma-2-9B were doing at roughly 290 and 889 tokens per parameter. Sparsity moved the target again. In a MoE model two quantities have to be kept apart: total parameters govern roughly how much the model can hold — knowledge, facts, the long tail — while activated parameters and effective depth govern roughly how far it can think, how many steps of a causal chain it can carry before it comes apart. A dense 20:1 ratio does not transfer. And the ratio isn't a single number at all: Roberts et al. (2025) find the optimal tokens-per-parameter is task-dependent, with memorization favoring more parameters and reasoning favoring more data. Follow-up work on MoE observes that at fixed TPP, pushing total parameters higher actually degrades reasoning, while activating more experts reliably helps it. This matters for what we are building toward. Finding a vulnerability is not a retrieval problem. It doesn't come from having memorized more CVEs; it comes from carrying a twenty-step chain of inference to the end without losing the thread. That capability does not live in total parameter count. Which brings us to this release. Total parameters appear to matter up to a threshold — enough to hold the world — after which additional capability comes from scaling elsewhere: effective depth per forward pass, and above all post-training. GLM-5.3 is our controlled experiment on that claim. Same base, same architecture, same total and activated parameters as GLM-5.2. One month of scaling long-horizon environments and RL. The gains are not marginal. Well, scaling has more than one dial. We turned the post-training one this time because it had the most slack left in it — not because the others are finished. Base model size, pretraining data, compute spent per forward pass: all of them are still on the table, and we will come back to each. What this experiment taught us is that the dials do not have to be turned together, and that the one worth turning next is rarely the one that was worth turning last. We are not done scaling. Next time, maybe mid- training, pre-training, and even more. Tweet : https://xcancel.com/jietang/status/2089941544581403107#m EDIT : Found Retweet with more stuff - https://xcancel.com/auto_grad_/status/2089970913408380932#m submitted by /u/pmttyji
  [link] [comments]
  ---|---
11. 🔗 r/LocalLLaMA New midsize Qwen 3.8 model coming next week (hopefully) according to community manager! rss
  
  Community manager mentioned this in the Qwen Ambassador Discord, put an X reaction on someone asking for 35B... and said
  
  We'll have a new midsize open weight model coming next week (hopfully), This midsize model won't provide early access due to the schedule
  
  Thinking it's going to be over 100B.
  
  Exciting!!
  
  submitted by /u/sleepy_roger
  [link] [comments]
12. 🔗 Armin Ronacher What Is Reasoning rss
  A few weeks ago a paper was shared that showed how to extract reasoning traces from closed-weight models. Together with online discussions about tricking models into leaking them, it made me investigate it more out of curiosity. Twitter seems full of half-truths and confusion about how this works, so perhaps this helps some to understand what is happening.
  
  Hiding Traces
  
  Reasoning traces are usually hidden from us. We have lamented this, but mostly have to accept it. Open-weight models thankfully reveal them, and from their behavior you can see that their traces can be long and confusing. This is probably a good reason to separate them from what is normally shown to users.
  
  At minimum, UIs need to detect them. The industry has done a good job at making reasoning traces sound special and exotic, but they really are just text: the model is trained to emit its thinking into a scratchpad as part of its response, before its final answer.
  
  GPT-OSS's Harmony response format makes this easy to see:
```
<|channel|>analysis<|message|>
I need to work this out ...
<|end|><|start|>assistant<|channel|>final<|message|>
The answer is ...
<|return|>
```
  The markers are special tokens, but the reasoning between them uses "the same text" as the final answer (just that GPT chain-of-thought text sounds really funny). When the model samples the analysis channel token, a parser routes the following text into a separate stream exposed through the Responses API. For closed models, presumably a simple model redacts and summarizes it.
  
  Reasoning Effort
  
  How much budget goes to reasoning? Earlier APIs exposed reasoning token budgets, making it seem like a property of the sampling process. In reality, reasoning effort is baked into the system prompt. GPT-OSS puts this into the system prompt:
```
Reasoning: low
```
  That's it. Training produces the resulting behavior, such as emitting the token sequence that switches to the analysis channel. This also explains why changing the effort invalidates the KV cache. I think closed GPT models call reasoning effort "juice," since you can ask most models how much juice they have.
  
  In DwarfStar for DeepSeek with max reasoning this is added to the system prompt:
```
Reasoning Effort: Absolute maximum with no shortcuts permitted.
You MUST be very thorough in your thinking and comprehensively decompose the
problem to resolve the root cause, rigorously stress-testing your logic against
all potential paths, edge cases, and adversarial scenarios.
```
  Don't Think
  
  The destination of reasoning tokens is therefore a learned convention: the model is trained to keep scratch work out of the final channel. Trick it into thinking it is in that channel and it may leak tokens. We have even seen older models, when thinking is disabled, reason into the bash tool and echo their thoughts to /dev/null.
  
  So in some sense the only "special" behavior for some models is not to think. That at times is done by "mechanically" removing the model's usual ways to think. In DwarfStar, disabled thinking uses the prefill </think>, while enabled thinking uses <think>, which are the tokens that close and start thinking. GPT-OSS doesn't prefill but lets the model decide either way on its own.
  
  But presumably, some inference APIs prefill the opening token when reasoning is enabled, so the model never samples it itself and might prevent the sampling of the reasoning token when disabled since it can be trivially detected. This may explain why a custom think tool can trick models into putting some reasoning where it should not go — but only when native reasoning is disabled.
  
  Fun fact: this blog post triggered safey checks
  
  Hilariously enough I was unable to use GPT 5.6 terra for spell and grammar checking on this blog post because of safety filters. Had to switch to Kimi.
13. 🔗 New Music Releases Cult of Luna - A Way Back rss
  Cult of Luna - a new release is available:
  - 2026-08-19: A Way Back (Single)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
14. 🔗 Ampcode News MCP in Orbs rss
  You can now connect remote MCP servers on ampcode.com and use them in orbs, the TUI, and with Puck.
  
  To add an MCP server:
  1. Visit ampcode.com/settings/mcp-servers,
  2. Select a pre-configured server or click "Add MCP Server"
  3. Log into the server using OAuth,
  4. Start a thread in an orb, the TUI, a runner, or talk to Puck:
  Amp supports connecting hosted MCP servers using Streamable HTTP with OAuth or Bearer tokens, personal and workspace configuration of MCP servers, and the use of MCP-provided tools.
  
  MCP Apps, Resources, and Prompts are not supported.
15. 🔗 Ampcode News Pass the Orb to the Left Hand Side rss
  
  You can now bring your team into your orb.
  
  Use @ to tag members of your team, and they'll be able to view, drive, and send chat messages to the thread.
  
  We've been having a lot of fun with this feature recently. Here are a few examples:
  
  1 / 9