🏡

↔
→

September 18, 2026
1. 🔗 smol-machines/smolvm smolvm v1.16.2 release
  What's Changed
  - Allow releases after the version bump has merged by @BinSquare in #1281
  - Resolve registry credentials from the host Docker config, credential helpers included by @BinSquare in #1279
  - Avoid recopying retained checkpoint disks on every restore by @BinSquare in #1283
  - Persist checkpoint filenames before reporting success by @BinSquare in #1282
  - Reuse protected checkpoint RAM when restoring branchable machines by @BinSquare in #1285
  - Use a plain fsync per checkpoint object on macOS instead of a whole-device flush by @BinSquare in #1286
  - Trust present checkpoint objects on reuse and leave content verification to restore by @BinSquare in #1287
  - Speed up incremental checkpoint saves by @BinSquare in #1288
  - Speed up saves that reuse checkpoint data by @BinSquare in #1289
  - Speed up checkpoint verification during restore by @BinSquare in #1290
  - Speed up incremental checkpoint capture by @BinSquare in #1291
  - Store checkpoint chunks through a pool of worker threads by @BinSquare in #1293
  - Restore checkpoint chunks across worker threads by @BinSquare in #1294
  - Restore checkpoints as a diff against the last restored one by @BinSquare in #1295
  - Stop the GPU docs pinning a guest Vulkan ICD by architecture by @BinSquare in #1298
  - Keep concurrent checkpoint restores on a consistent base by @BinSquare in #1300
  - Bound checkpoint workers across simultaneous saves and restores by @BinSquare in #1301
  - Verify cached checkpoint data before reusing it during restore by @BinSquare in #1302
  - Clean up exited branches without waiting for the server by @BinSquare in #1308
  - Extract image layers on the host and describe their ownership to the guest by @BinSquare in #1306
  - Record registry-cache recency on a marker file so a cache hit no longer fails a concurrent verification by @BinSquare in #1310
  - Verify a restored clone's holes from one extent walk instead of a seek per chunk by @BinSquare in #1317
  - docs: add practical READMEs for published Rust crates by @BinSquare in #1320
  - Trust a restore base this process wrote until its files change by @BinSquare in #1318
  - Update libkrun so Linux virtiofs shares can serve recorded ownership by @BinSquare in #1313
  - Cover the blob cache's upgrade path so a marker-less blob keeps its atime recency by @BinSquare in #1311
  - Let the export helper's disk be resized and name it when it fills by @BinSquare in #1312
  - Stream the merged layer tar to the host instead of staging it in the guest by @Bnjoroge1 in #1321
  - Fix interactive stdin buffer bug on unix by @louix in #1314
  - Prepare SmolVM v1.16.2 for release by @BinSquare in #1325
  - Stop a frozen fork base instead of waiting for an acknowledgement its paused guest cannot send by @BinSquare in #1324
  New Contributors
  - @louix made their first contribution in #1314
  Full Changelog : v1.16.1...v1.16.2
2. 🔗 HexRaysSA/plugin-repository commits sync repo: +3 releases rss
```
sync repo: +3 releases

## New releases
- [augur](https://github.com/0xdea/augur): 0.10.0
- [haruspex](https://github.com/0xdea/haruspex): 0.10.0
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 20260918.0.1
```
3. 🔗 anthropics/claude-code v2.1.277 release
  What's changed
  - Added AGENTS.md support: in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead; change it under "Project instructions" in /config (not yet on Bedrock, Vertex or Foundry)
  - Added CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1 for Claude apps gateways whose only egress is a forward proxy: every outbound request hands the proxy the hostname instead of resolving it locally
  - Added an optional headers: map on Claude apps gateway upstreams, to send static headers to a proxy you run in front of a provider
  - Added a line saying a background task's update is waiting when it finishes while a panel such as /tasks is open
  - Fixed claude -p and Agent SDK sessions that could hang with no result after an internal error; they now report the error and exit with code 1
  - Fixed conversations failing every request with "text content blocks must be non-empty" when an earlier assistant turn held an empty text block beside other content, including after --resume
  - Fixed being unexpectedly logged out when an older Claude Code build (for example an IDE extension's bundled CLI) runs on the same machine as the current one
  - Fixed interactive start-up hanging or showing an error for ANTHROPIC_API_KEY users when ~/.claude.json holds a malformed customApiKeyResponses value
  - Fixed update checks erroring every 30 minutes, and claude update hanging when a minimum or maximum version is set, if a proxy returns an invalid version; a malformed minimumVersion is now ignored
  - Fixed claude update on winget- or apk-managed installs reporting "up to date" when the version lookup failed
  - Fixed claude plugin install sometimes failing and breaking the installed copy when reinstalling a plugin version that a session or another program was using; an unchanged copy is now left alone
  - Fixed Grep and Glob reporting no matches when the search could not start because the system was out of processes, memory or file handles; they now return an error saying so
  - Fixed the Write tool silently ending the turn as a declined permission when the target path is an existing directory; it now reports a clear error
  - Fixed the Edit tool treating an escaped backslash followed by uXXXX text as a \uXXXX escape, which could make an edit of a non-ASCII character rewrite an escaped backslash sequence instead
  - Fixed the Edit tool reporting "Invalid regular expression: regular expression too large" instead of "String not found in file" when a very large edit containing non-ASCII text did not match the file
  - Fixed a turn ending early with "Path contains null bytes" when a tool call's file path contained \u0000 written as an escape sequence; escaped control characters now stay as literal text
  - Fixed background sessions (claude --bg) exiting when a plugin's LSP server exited or closed its stdin
  - Fixed a crash ("Type error") when opening /mcp or /plugin manage with a malformed claudeAiMcpEverConnected value in ~/.claude.json
  - Fixed a crash at launch when ~/.claude.json holds a malformed theme value
  - Fixed a crash ("unrecoverable interface error") when the prompt held text containing terminal color codes, for example a prompt recalled from history or text loaded from the external editor
  - Fixed a crash when resuming a session whose saved history holds an assistant message stored as a plain string
  - Fixed sessions on slow or heavily loaded machines sometimes exiting with "Claude Code exited after an unrecoverable interface error" when the first spinner appeared
  - Fixed a rare case where the screen could stop updating for the rest of the session after an internal rendering error
  - Fixed a rare case on Windows where a turn could stop with an error such as "Out of memory" right after Claude replied, so that reply's tool calls never ran
  - Fixed sessions continued after /clear (restart, --continue, --resume) missing part of their first message when a SessionStart hook printed output, causing a full prompt-cache miss
  - Fixed messages from other agents (such as a subagent's SendMessage) that arrived mid-turn showing up below the "Ran N shell commands" row instead of where they arrived
  - Fixed the "copied" notice not appearing after drag-selecting text in the fullscreen /resume picker and other panels that cover the prompt area
  - Fixed $TMPDIR expanding empty in Bash commands that run outside the sandbox while sandboxing is enabled
  - Fixed WebFetch and WebSearch in Cowork cloud sessions not telling Claude why a request was refused, such as a used-up fetch budget or an admin policy
  - Fixed the Claude apps gateway's telemetry relay ignoring a collector hostname or domain listed in NO_PROXY when a proxy is set
  - Fixed one malformed strictKnownMarketplaces or blockedMarketplaces entry silently disabling the whole enterprise marketplace policy
  - Fixed failed auto-updates leaving large staged downloads behind in ~/.cache/claude/staging
  - Fixed /plugin not stripping terminal control characters from messages on the Installed tab, such as the error of a failed plugin update
  - Fixed /plugin → Installed and /skills crashing when a skill or legacy command is named like a built-in Object property such as constructor or toString
  - Fixed /plugin closing with no message when every install in a multi-select failed
  - Fixed uninstalled plugins reappearing as "failed to load" rows in /plugin Installed, and Remove not clearing such a row
  - Fixed plugins from the official marketplace being recorded without their commit in installed_plugins.json, and installed_plugins.json keeping the old commit after updating a pinned-commit plugin
  - Fixed plugin reload previews keeping every previewed copy of a plugin archive unpacked until exit, and overwriting the cached --plugin-url archive a reload falls back to when its download fails
  - Fixed Remote Control session bookkeeping failing when ~/.claude.json holds a malformed placeholder record
  - Fixed the error after a revoked claude.ai login blaming an expired Anthropic profile; it now leads with /login
  - Fixed typed or pasted text occasionally coming out scrambled in the claude agents dispatch input during key repeat or very fast input
  - Fixed a crash ("unrecoverable interface error") when resuming a session whose saved transcript contains a stop hook summary without a well-formed hook list
  - Fixed Enter on a selected agent panel row doing nothing when keybindings.json rebinds Enter in the Chat context, for example to chat:queueSubmit
  - Fixed PDF page reads on Windows failing when the working folder's path is long (about 120 characters or more)
  - Fixed a headless resume (claude -p --resume, the SDK, a VS Code extension window reload) starting the session's cost and usage totals at zero; headless sessions now save their totals at exit
  - Fixed project skills from the main repository not loading in --worktree sessions when .claude/skills is untracked
  - Fixed a sandbox.excludedCommands glob exempting an entire compound Bash command from the sandbox when only one part matched; every part must now match
  - Fixed resumed subagents and teammates re-rendering the MCP tool definitions they had loaded, which broke prompt caching for that agent
  - Fixed rate-limited artifact publishes telling Claude to stop retrying; Claude is now told nothing was published and when to send the same publish again
  - Fixed attachments recorded earlier in a conversation being re-rendered after a resume or relaunch, which dropped extended thinking and missed the prompt cache
  - Fixed Console sign-in showing only "Request failed with status code 400" when the server refuses to create an API key; it now shows the server's message
  - Fixed messages typed while Claude is still working sometimes being ignored by the model
  - Improved session start-up for SDK and headless (-p) use: the first turn no longer waits on the per-directory CLAUDE.md lookup
  - Improved the Claude apps gateway's loopback error messages to name CLAUDE_GATEWAY_ALLOW_LOOPBACK
  - Improved /plugin Installed: an MCP server listed apart from its plugin now shows which plugin it belongs to
  - Improved claude plugin install on an already-installed plugin: it now says when the marketplace offers a newer version and names the claude plugin update command
  - Improved the startup notice overflow line under the logo: it now reads "N more notices hidden" instead of "+N more · /status"
  - Improved prompt handling: invisible Unicode formatting and tag characters in a prompt are removed and the cleaned prompt is shown for review before it is sent
  - Improved /ultrareview when there's nothing to review: messages say which case you're in, offer a command that reviews your latest commit, and a new repository's first commit is reviewed in full
  - Improved artifact link handling so Claude reads claude.ai artifact links with the Artifact tool instead of WebFetch when that tool is available
  - Improved the dangerous-rm permission prompt to name the flagged rm command and suggest a ${VAR:?} guard, so headless runs can recover
  - Improved the Artifact tool's permission prompts: shorter sentences, pages and artifacts named by title or file name, and links listed after the text
  - Changed Fable to always appear in /model on the Anthropic API; it is greyed out only when your organization's settings disable it
  - Changed the Bash sandbox instructions on Bedrock, Vertex and Foundry to the first-party wording, which frames the sandbox as the boundary of what the task was given
  - Changed /ultrareview in non-interactive sessions to refuse when the repository has no base branch or shared history
  - Changed subagent results to reach the main agent under a header marking them as subagent output, with the result indented, so text in a subagent's result cannot pass as the session's own instructions
  - Changed workflow scripts' computed agent() prompts on Bedrock, Vertex and Foundry to reach the subagent framed as script-authored text, so the safety classifier does not read them as the user
  - Removed the background Haiku auto-title request from claude -p runs launched outside an SDK or IDE
  - Removed the deprecated TaskOutput tool; Claude reads a background task's output file with Read instead, and the taskOutputMaxChars setting and TASK_MAX_OUTPUT_LENGTH no longer have any effect
  - [VSCode] Added a Sign out row to the panel menu, with /logout in the typed command menu
  - [VSCode] Added background shells and other running tasks to the agent map, each with a Stop, and a typed /tasks that opens it
  - [VSCode] Added a Copy response button on responses and a typed /copy
  - [VSCode] Added a one-time notice when inactive sessions are archived automatically, and an "Unarchive all" action on the Archived sessions group
  - [VSCode] Added the session's cost and token usage to the Account & usage dialog and the session manager where plan limits do not apply (Vertex, Bedrock, Foundry, API key)
  - [VSCode] Fixed the "General config" menu row showing /config usage text instead of opening settings, and made typed /mcp, /hooks, /memory, /rewind and similar commands open their dialogs
  - [VSCode] Fixed the effort slider's level not persisting into later sessions on a model that already had a level saved with /effort
  - [VSCode] Fixed Auto missing from the mode picker for conversations opened in an already-used panel when the saved model setting is a differently-cased alias such as "Sonnet"
  - [VSCode] Fixed /fast not saving fast mode as the default, so it was lost when the extension relaunched Claude Code
  - [Claude Code on the web] Added Personal and Organization sections to the environment picker on Team and Enterprise plans, and admins can now share a personal environment with the organization
  - [Claude Code on the web] Changed organization environments to open as a read-only summary from the Code tab on Team and Enterprise plans, with editing under Admin settings → Cloud environments
  - [Claude Code on the web] Fixed a cloud environment saved with Custom network access and no domains silently reverting to Trusted; the dialog now asks for at least one domain
  - [Claude Code on the web] Changed the admin Claude Code setting labeled "Web" to "Cloud sessions" and removed the redundant read-only Mobile row beneath it
  - [Claude Tag] Fixed routines created in a Slack channel on an Enterprise Grid org-wide install failing to read other public channels in their workspace when they ran
  - [Claude Tag] Fixed the "Learn more" links on credential presets in Claude Tag access bundles to open each vendor's credential-setup page instead of a generic API reference
  - [Claude Tag] Changed the Pylon credential preset in Claude Tag access bundles so admins can point it at Pylon's EU host
  - [Claude Tag] Fixed Google Cloud credential forms in Claude Tag access bundles: a refused key file now says why, the website and scopes stay locked, and a rejected rotation keeps the pasted key
  - [Claude Tag] Fixed the network events log in Claude Tag admin settings showing no response status for requests through connections that use AWS signing, client certificates or a custom CA
4. 🔗 3Blue1Brown (YouTube) The last IMO problem AI could not solve rss
  
  Full video: https://youtu.be/Nbwv5wHQoj0
5. 🔗 3Blue1Brown (YouTube) The last IMO problem AI could not solve rss
  
  A beautiful puzzle that eluded AI, and the intuition it requires. Check out our virtual career fair: https://3b1b.co/talent See new videos early: https://3b1b.co/support An equally valuable form of support is to simply share the videos. Home page: https://www.3blue1brown.com
  
  Evan Chen also wrote up nice solution notes for this problem, along with all the others on that year's test. https://web.evanchen.cc/exams/IMO-2025-notes.pdf
  
  The channel Dedekind Cuts has a video about this solution: https://youtu.be/fgXg9CdCDcs
  
  Timestamps: 0:00 - The one that AI missed 4:09 - Problem statement 6:45 - Finding the Optimal Construction 18:51 - A weak lower bound 23:45 - 3b1b Talent 24:41 - Proving the Construction is Optimal 34:08 - One final conjecture 39:42 - The Erdos-Szkeres Theorem 45:56 - Reflections on AI in Math
  
  Secret Endscreen Vlog: https://youtu.be/UbHoWA0X1e8
  
  These animations are largely made using a custom Python library, manim. See the FAQ comments here: https://3b1b.co/faq#manim
  
  Music by Vincent Rubinetti. https://vincerubinetti.bandcamp.com/album/the-music-of-3blue1brown https://open.spotify.com/album/1dVyjwS8FBqXhRunaG5W5u
  
  3blue1brown is a channel about animating math, in all senses of the word animate. If you're reading the bottom of a video description, I'm guessing you're more interested than the average viewer in lessons here. It would mean a lot to me if you chose to stay up to date on new ones, either by subscribing here on YouTube or otherwise following on whichever platform below you check most regularly.
  
  Mailing list: https://3blue1brown.substack.com Twitter: https://twitter.com/3blue1brown Bluesky: https://bsky.app/profile/3blue1brown.com Instagram: https://www.instagram.com/3blue1brown Reddit: https://www.reddit.com/r/3blue1brown Facebook: https://www.facebook.com/3blue1brown Patreon: https://patreon.com/3blue1brown Website: https://www.3blue1brown.com
6. 🔗 exe.dev Programming Is a Game rss
  
  It’s no longer news that AI agents have gotten very good at programming very quickly. LLM chatbots, on the other hand, haven’t improved all that much in the past year. Why is that?
  
  While I don’t work on building AI agents, it’s generally acknowledged that the programming improvements are in large part because programs come with feedback in the form of tests. An agent can write code, write a test, and verify that the code passes the tests. This means that an agent is required to solve any given problem using two completely different approaches: coding and testing. And it’s required to ensure that both approaches agree.
  
  Approaching a problem in two different ways helps avoid the common mistakes of chatbots, such as errors and hallucinations. Of course the agent can completely misunderstand the assignment: a human is still required to verify that the program solves the right problem. Fortunately, it’s easier for a human to verify the big picture than it is to check all the details. If you’ll excuse the buzzword, this is a genuine example of synergy.
  
  There are other aspects of programming that make it suitable for agents: lots and lots of existing high-quality examples in the form of open source and source-available software, and a rigid, documented set of rules that programs must follow just in order to build and run in the first place.
  
  As it happens, there is something else that has tests, examples, and rigid rules: strategy games like chess or Go. AI agents of course reached superhuman levels of play at those games several years ago. Though I at least did not predict or expect it, in retrospect, it’s not terribly surprising that they were able to carry this approach forward into a different arena with the same essential characteristics.
  
  A natural question is what other areas of human endeavor might fit this pattern.
  
  One possibility is the legal system: lots of examples, relatively rigid and documented rules. Unfortunately for agents, while tests are available in the form of actual lawsuits, each lawsuit takes months or years to resolve. That is not a recipe for fast development.
  
  Although medicine is often cited as an area where AI will make great strides, it does not fit this pattern. The rules of medicine are undocumented, the test cycle for new treatments is very slow, and medicine is full of unanticipated side effects (which we might call reverse synergies). While AI’s search capabilities may produce good results for rare diseases that get little human attention, by definition the general population does not have rare diseases. Medical breakthroughs that help most people will require significant new breakthroughs in AI approaches.
  
  In the meantime we can at least enjoy increased programming productivity.
7. 🔗 tomasz-tomczyk/crit v0.20.2 release
  What's Changed
  
  Thank you to all the new contributors! I feel really privileged to have your support, whether you submit issues or PRs or just spread the word about the value Crit is bringing to you! ❤️
  
  crit resume
  
  crit resume lists every review in ~/.crit/reviews (newest first) and reconnects you to the one you pick. Stopped sessions can be resumed from another directory when review.json has a recorded cwd; reviews whose directory no longer exists are greyed out.
  - feat: add crit resume to reopen a stored review (#934) by @tomasz-tomczyk in #934
  Round-complete and comment anchoring
  - fix: keep the reader's scroll position across round-complete (#947) by @schrek1 in #947 - Thank you!
  - fix: keep range focus pinned across round-complete (#945) by @komase in #945 - Thank you!
  - fix: remap carried comments against the previous round's content (#930) by @usadamasa in #930 - Thank you!
  - fix: keep comment IDs stable across review rounds (#937) by @tomasz-tomczyk in #937 - Thank you @gmatev for suggesting!
  - fix: keep comments anchored when a clause is cut from a line (#936) by @tomasz-tomczyk in #936
  - fix: persist remapped comments on git round-complete (#925) by @tomasz-tomczyk in #925
  - fix: carry comments across file renames (#917) (#920) by @tomasz-tomczyk in #920
  - fix: publish lazy file loads under the session lock (#935) by @tomasz-tomczyk in #935
  Daemon and sessions
  - fix: preserve sandboxed daemon sessions (#933) by @jalopez in #933 - Thank you!
  - fix: keep session file when SIGTERM is denied (#941) by @tomasz-tomczyk in #941
  - fix: keep session file when StopDaemon Kill is denied (#952) by @tomasz-tomczyk in #952
  - fix: treat Windows access-denied process probe as alive (#940) by @tomasz-tomczyk in #940
  Diffs and VCS
  - fix(vcs): treat unresolvable submodule gitlink as no-content, not fatal error by @miyataka in #950 - Thank you!
  - perf(vcs): avoid full untracked scans when possible (#949) by @mattnworb in #949 - Thank you!
  - fix: preserve scoped diff revisions for staged/unstaged (#915) (#918) by @tomasz-tomczyk in #918 - Thank you @mariaines for reporting!
  Story mode
  - fix: keep Story hunk anchors stable when ignoring whitespace (#943) by @John-Isr in #943 - Thank you!
  - Fix story chapter mark button staying stale after per-file Viewed toggles (#924) by @tomasz-tomczyk in #924
  General
  - feat: add sponsorship and story mode tips to waiting modal (#951) by @tomasz-tomczyk in #951
  - chore(deps-dev): bump stylelint from 17.14.1 to 17.15.0 (#927) by @app/dependabot in #927
  - chore(deps-dev): bump eslint from 10.9.1 to 10.10.0 (#929) by @app/dependabot in #929
  - test(e2e): stabilise the Windows-flaky perf and stack-popover specs (#944) by @tomasz-tomczyk in #944
  - test: settle lazy bodies after perf scroll (#921) by @hermes-tomczyk in #921
  New Contributors
  - @usadamasa made their first contribution in #930
  - @jalopez made their first contribution in #933
  - @John-Isr made their first contribution in #943
  - @komase made their first contribution in #945
  - @schrek1 made their first contribution in #947
  - @mattnworb made their first contribution in #949
  - @miyataka made their first contribution in #950
  Full Changelog : v0.20.1...v0.20.2
8. 🔗 r/LocalLLaMA 768gb vram for less than the price of one RTX 6000 rss
  
  | I have always posted about budget builds on here, and often asked how we are going to run the next big models. Often Plenty of downvotes too or folks telling me that it's not running if I'm getting 5tk/sec. But whatever, the hunger and desire to go big has always kept me on the edge and looking for deals. Here's my latest build, 12x64gb cmp170hx. For less than 1 RTX 6000 pro costs. I also have it connected with fiber to my other rig for RPC when I need more memory. I haven't been posting much since I built this rig, because it's now more fun to talk to my machine. I run GLM5.3, DSv4.1Flash, Qwen3.8Flash, Qwen3.8-2.4T, KimiK3 and MiniMaxM3. Performance is great, a single RTX 6000 or M3 Mac Studio wish they could. Inference with vllm or llama.cpp I look forward reading the replies how API usage is cheaper, or how it will take 52 light years to break even or the noise, or the electrical cost. NOT. There will be more opportunities in the future, keep looking for them and pounce on them when they come. up, the demand is going to be high for compute for a long time. https://preview.redd.it/dunixwu6caqh1.jpg?width=4080&format=pjpg&auto=webp&s=a76a56c53aa0b9206383dbebde679bf3690fd5d2 https://preview.redd.it/glpcbg5cbaqh1.jpg?width=3072&format=pjpg&auto=webp&s=462e9677bb1f3ada6431b61cf46e2d3705eccab9 submitted by /u/segmond
  [link] [comments]
  ---|---
9. 🔗 r/LocalLLaMA Made the horizontal open-source model for Jev with RLCD, and it surpasses all the Jev benchmarks. HF space, benchmark, model, repo rss
  
  | Thanks for the exceptional support (https://www.reddit.com/r/LocalLLaMA/comments/1wijo3e/i_literally_built_the_jev_architecture_one_year/) and for the dozens of requests to make a generic model, run benchmarks, and create an HF space so anyone can test it. So here you go, guys. I trained an improved model on a large data corpus, its now called Laya. It is trained on a single RTX 6000 Pro (96 GB VRAM); the model architecture is a 421M-parameter non-autoregressive decision model pairing a bidirectional ModernBERT-large encoder with a scratch Transformer head that scores [MASK] option markers to resolve typed schemas in a single ~35 ms forward pass. The dataset is a 100% human-annotated corpus of over 25,000 real-world examples across intent routing, fact-checking, moderation consensus, prompt guardrails, rubric scoring, and multi-turn conversation trajectories, without synthetic data shortcuts. The RLCD(unofficial, btw) I did is a policy-gradient reinforcement learning approach that kinda optimizes decision models against strictly proper scoring rules, ensuring maximum reward is achieved only when outputting true, mathematically calibrated probabilities. NB: It can be run on low end PC as its a small 421M model, cheers HF space to try: https://huggingface.co/spaces/convaiinnovations/laya-demo GitHub Repo: https://github.com/NandhaKishorM/laya HF Repo: https://huggingface.co/convaiinnovations/laya Thank you to everyone who supported me, shared the story, gave personal DM. It will need more refinement, of course. If anyone wishes to buy me a coffee, here is the link: https://github.com/NandhaKishorM submitted by /u/Nandakishor_ml
  [link] [comments]
  ---|---
10. 🔗 anthropics/claude-code v2.1.276 release
  What's changed
  - Fixed every request failing with 400 … Input tag 'advisor_20260301' when ANTHROPIC_BASE_URL points at a proxy or gateway (2.1.275 regression)
11. 🔗 New Music Releases O.A.R. - Three Tinted Windows rss
  O.A.R. - a new release is available:
  - 2026-09-18: Three Tinted Windows (Album)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
September 17, 2026
1. 🔗 anthropics/claude-code v2.1.275 release
  What's changed
  - Added the signed-in account to Claude apps gateway sign-in: when the gateway names it, you confirm it before the credential is saved, and /status shows it
  - Added a send-now key (ctrl+enter, or ctrl+x ctrl+s) that interrupts the current turn and sends all queued messages at once; sent and queued messages show in gray until the model receives them
  - Added a startup warning when a configured otelHeadersHelper fails, so sessions that silently export no telemetry are noticed
  - Added syncing of the skills and plugins enabled on your claude.ai account to terminal sessions signed in with it; opt out with syncClaudeAiSkills: false or syncClaudeAiPlugins: false
  - Added /plugin install <plugin> --marketplace <source>, which offers to add the marketplace before installing the plugin
  - Fixed a restored memory file's age note changing between requests after a compaction or resume, which caused prompt cache misses
  - Fixed --forward-subagent-text stream-json and SDK output dropping the messages of subagents spawned by a context: fork skill, and of forked skills invoked by a subagent or another forked skill
  - Fixed @-mention file suggestions being buried below MCP resources when using a custom fileSuggestion command or typing @./@./
  - Fixed fullscreen mode placing background-task completion notices beneath a long turn's collapsed tool row instead of where they arrived; each notice now closes the open row
  - Fixed claude plugin marketplace update deleting a GitHub marketplace's local copy when the fetch failed and the marketplace was named after its repository
  - Fixed plugin and marketplace messages, logs and claude plugin marketplace list showing a password or token stored in a git, ssh or marketplace URL
  - Fixed a resumed cloud session leaving an unanswered question open in the transcript after a queued message superseded it
  - Fixed vim mode placing the cursor one character right after a dot-repeated "!" or a fast-typed "i!" switched a non-empty prompt into shell mode
  - Fixed fullscreen mode freezing or blanking for several seconds when scrolling up past a large file diff
  - Fixed a stray </ccmemory>-style closing tag occasionally appearing in responses
  - Fixed plugin messages, logs and the VS Code plugin dialog showing the wrong server for some git addresses
  - Fixed a terminal API Error: 400 on every turn for users behind a network gateway that rewrites API error responses when a beta request header is rejected
  - Fixed sandboxed Bash commands on Linux reporting exit code 0 for failed commands when the shell is zsh
  - Fixed the Read tool hanging instead of reporting an error when part of a large file could not be decoded under memory pressure
  - Fixed --resume, the resume picker preview, resumed background agents and the transcript view failing on a session whose saved history contains a malformed task-reminder or @-file attachment entry
  - Fixed a crash when resuming a conversation whose transcript contains a malformed message entry, and a fullscreen crash when such a conversation received new messages while scrolled up
  - Fixed sessions failing to resume or start when their saved transcript contains a malformed message content block
  - Fixed Grep, Glob and @-file suggestions hanging or running out of memory on searches over the 20MB output cap, and system ripgrep reporting "no matches" instead of an error after a flood of warnings
  - Fixed /rewind in a forked or background session restoring a zero-filled or truncated file when the session's file-history backups could not be fully copied
  - Fixed fullscreen sessions sometimes exiting with "Claude Code exited after an unrecoverable interface error" when typing fast or holding a key with the slash-command dropdown open
  - Fixed background sessions crashing and restarting their worker when a command fed through stdin ran on a machine that had run out of file descriptors
  - Fixed a crash at launch when ~/.claude.json holds a malformed mcpNeedsAuthNoticed value
  - Fixed --resume and --continue dropping a conversation's earlier thinking when a built-in tool it started with has since been switched off by a server-side flag
  - Fixed text selected with the mouse in the fullscreen claude --resume session picker never reaching the clipboard
  - Fixed plugin reload previews replacing a running session's extracted plugin files when the plugin was loaded from a --plugin-dir or --plugin-url archive
  - Fixed self-hosted runners with --drain-wait-sec losing the final result of a turn that finished during a SIGTERM drain; the runner now waits briefly for the turn to be reported
  - Fixed SubagentStop hooks with a specific matcher firing for every stopping subagent whose agent type was empty
  - Fixed sandboxed Bash commands being unable to write to project directories named hooks/ or config/
  - Fixed Artifact updates failing with "File not found" after a session resumes on another machine or its scratchpad is cleared: the page's last published version is restored
  - Fixed /update-config writing Write(path) permission rules, which file permission checks don't match, instead of Edit(path) rules
  - Fixed four dead documentation URLs (Pricing, Computer Use, Skills, CLI) in the bundled claude-api skill's live-sources table
  - Improved prompt caching for a --system-prompt that contains a __SYSTEM_PROMPT_DYNAMIC_BOUNDARY__ line: the text above it is now cached globally, as the SDK's array form already is
  - Improved the /desktop error when Claude Desktop does not open: it now says why and what to do next
  - Improved the Artifact tool's publish and read results: they now say who can open the page and what the owner's Share menu offers
  - Improved artifact publish results: they name the tab icon sent, warn when the page contains a NUL byte, and retry a flaky fetch of the newer page to merge after a stale publish
  - Improved pasted and attached images: they are now saved where Claude can open them as files without a permission prompt, including in Desktop and VS Code
  - Improved the Artifact tool's guidance so Claude updates a shared artifact in place when you were given edit access to it, instead of publishing a separate copy
  - Improved plan-usage reads: editor windows and non-interactive sessions on one machine now share a read made in the last minute instead of each calling the usage endpoint
  - Improved the ListPlugins tool description so Claude knows it lists plugins enabled on your claude.ai account, not plugins installed locally with /plugin
  - Improved responsiveness when the terminal is slow or paused: output no longer falls further behind while the terminal catches up
  - Improved Write and Edit results for files in the synced account-skills folder: they now say the change is not saved to your account and how to save it
  - Updated /logout for Claude apps gateway sign-ins to also end the session on gateways that advertise token revocation
  - Changed hosted sessions to keep an unanswered permission prompt up after a container restart, instead of asking again
  - Changed the Artifact tool to ask for a one-word tab icon on a first publish instead of an emoji favicon
  - Changed Claude in Chrome in auto mode to skip the extension's per-site check for classifier-approved calls, as bypass mode does, fixing browser_batch "Permission denied" after a redirect
  - Changed plugins installed from an npm source to be fetched with npm pack --ignore-scripts and integrity-verified, so a package's install scripts no longer run
  - Changed scheduled and Run now routine runs to save data to, and republish the page of, an artifact you can edit without asking; public artifacts, first publishes and deletes still ask
  - Removed the startup notice that told you a one-off scheduled routine had run since your last session
  - [VSCode] Added viewing, editing and deleting a saved memory inside the Memory dialog
  - [VSCode] Added sending an attached image without typing any text
  - [VSCode] Added a Retry link to the MCP servers dialog when the server list fails to load
  - [VSCode] Added accept and reject buttons under each change in the proposed-change diff tab, so an edit can be reviewed change by change
  - [VSCode] Fixed the transcript creeping toward the bottom in small steps while a permission card waits and content keeps arriving
  - [VSCode] Fixed rewound and forked conversations not keeping the permission mode you had picked for the original conversation
  - [VSCode] Fixed an empty CLAUDE_CONFIG_DIR entry in the environmentVariables setting making Claude Code keep its files in the workspace
  - [VSCode] Fixed plugin install links opening the Manage plugins dialog for plugin names and marketplace addresses that can't be used in a link
  - [VSCode] Fixed Remote Control staying shown as connected after a turn-off that Claude Code reported as failed; it now shows as off
  - [VSCode] Fixed the scroll to the bottom on send stopping short of the reply when the reply starts arriving during the scroll
  - [VSCode] Fixed the agent map showing agents a crash left unfinished as stopped instead of failed once the session is reopened
  - [VSCode] Fixed the "Continuing the step" notice not appearing, and the continue limit resetting, after a reload that follows a crash with background tasks still running
  - [VSCode] Fixed the session list showing when a session was last reopened, such as after a window reload, instead of when its last message was sent
  - [VSCode] Fixed "Fork conversation from here" failing on the message right after one sent while Claude was working
  - [VSCode] Fixed the prompt cache clock showing too few minutes after reopening a session with a message sent while Claude was working
  - [VSCode] Fixed a background agent that finished while Claude was running a tool losing its completion notice, and its result on the agent map, after a window reload
  - [VSCode] Fixed a rare case where text selected in a git-ignored file could be sent to Claude after the extension was unresponsive for several seconds
  - [VSCode] Fixed renaming a running session reverting to the generated name (regression in 2.1.269)
  - [VSCode] Fixed some claude.ai/code sessions opening in VS Code as an empty conversation with no messages
  - [VSCode] Fixed slash commands typed while Claude is responding being sent to the model as text instead of running once the response finishes
  - [VSCode] Fixed unreadable code in the plan preview and the Hooks and Permission rules dialogs with the High Contrast Light theme
  - [VSCode] Fixed /remote-control being ignored while Remote Control is still connecting: running it again now turns Remote Control off immediately
  - [VSCode] Fixed the conversation pulling you back to the bottom while a reply streams after you scroll up, and added a claudeCode.scrollToBottomOnSend setting to turn off the jump on send
  - [VSCode] Fixed the Manage plugins dialog showing a password or token that was typed into a marketplace URL
  - [VSCode] Improved the agent map: the pill counts running agents and turns red after a failure, the main agent stays in view while the map scrolls, and agents sort by state then end time
  - [VSCode] Changed New session in a Claude editor tab to open in the sidebar when Preferred Location is set to Sidebar, instead of always opening another tab
  - [VSCode] Changed a message sent while Claude is working to wait at the bottom of the conversation until Claude starts on it
  - [Claude Code on the web] Added a "New routine" button to the page shown when a routine link no longer resolves, next to the link back to your routines list
  - [Claude Code on the web] Fixed routine "paused" and "on hold" notifications being cut off mid-sentence; the paused-subscription notice now says to turn the routine back on yourself
  - [Claude Code on the web] Fixed cloud environments with a very long allowed-domains list saving fine and then failing every session start; saving now fails up front and says how much to trim
  - [Claude Code on the web] Fixed Claude's guidance when a cloud session on a personal account is denied GitHub access: it now links to claude.ai/connect-github instead of an admin settings page
  - [Claude Code on the web] Improved what Claude tells you when asked to edit, delete or run a routine it didn't create: it now links to the routine's page so you can do it yourself
  - [Claude Tag] Added attach conditions for access bundles in Claude Tag settings: an Owner can let a bundle also apply in channels with guests or Slack Connect channels, not just member-only
  - [Claude Tag] Added Amazon CloudWatch, CloudWatch Logs, Amazon SNS, Google Cloud Monitoring and Cloud Logging presets to an access bundle's Credentials tab in Claude Tag admin settings
  - [Claude Tag] Added Datadog presets for the US3, AP1, AP2 and US1-FED sites; new Datadog connections are now limited to Datadog's read and query API routes
  - [Claude Tag] Fixed S3 uploads from recent AWS CLI and SDK versions failing with a 502 error when sent through an AWS connection
  - [Claude Tag] Fixed Claude treating a channel as inactive, and skipping untagged messages there, while it was still posting in that channel from a routine or a thread
  - [Claude Tag] Fixed a thread's "Claude [task]" display name reverting to plain "Claude" after the session behind that thread was refreshed or restarted
  - [Claude Tag] Fixed the model you switched to in a Slack thread silently reverting to the channel's default after that thread's session was restarted or refreshed
  - [Claude Tag] Fixed Claude sometimes replying twice when another app or bot @mentioned it in a top-level channel message
  - [Claude Tag] Improved Claude's notices in Enterprise Grid channels shared across workspaces: they now say when no workspace is set up yet, or why only organization defaults apply
  - [Code Review] Fixed reviews occasionally dropping part of their analysis when one of the reviewing agents returned its findings in an unexpected format
  - [Code Review] Fixed pull requests with more than 100 Claude reviews getting a full re-review on every clean merge from the base branch instead of the lighter merge-focused review
2. 🔗 r/LocalLLaMA Ternary Bonsai 2 (27B) just released on Hugging Face. At <6GB in size, it can even run locally in-browser on WebGPU. rss
  
  | The model is derived from Qwen3.8-27B, a 27B hybrid-attention causal language model (architecture unchanged), but uses ternary weights to shrink model size down to <6GB in size. According to the model card, it's 9x smaller than FP16 while retaining 98.2% of the intelligence.
  - Collection: https://huggingface.co/collections/prism-ml/bonsai-2
  - Demo: https://huggingface.co/spaces/webml-community/ternary- bonsai-2-webgpu-kernels submitted by /u/xenovatech
  [link] [comments]
  ---|---
3. 🔗 r/LocalLLaMA Thank you :) Swift Qwen 3.8 27B now has 100k+ downloads, is #1 finetune and #9 model on HuggingFace Trending rss
  
  | Hey everyone, Jovan from UkisAI here, a small lab building the tech to make tiny frontier LLMs possible (and doing it open-source!) The purpose of this post is simply to thank the community for all the amazing finetunes, quantizations and overall improvements over our original release which made our model get attention and the support for us to continue building in this direction! If it weren't for you guys going out of the way to contribute we wouldn't have half the results of this. For context: Swift Qwen 3.8 27B is our first open-source model release. It is proof of how penalizing pathological overthinking patterns inside of small LLMs can bring their token usage down -58.3% and speed x1.95 without losing accuracy by not training them to think shorter directly but rather to think more efficiently. We are continuing to build and are about to drop: - Swift1.5 Qwen3.8 27B (an improved checkpoint of the model with some training bugs fixed and more RL) - Swift Qwen3.8 Flash Next in the upcoming week week, we are now running the benchmark suite to not give out premature or incomplete results. This time we ran even more benchmarks as you guys suggested, including more coding and long horizon! It would be amazing if those of you who tried Swift would let us know what quants, features, changes you want to see in our upcoming model releases so we can do it better this time as we didn't even think about half of the stuff you guys were requesting last time :) Let the era of non-slop finetunes begin! EDIT: Links - https://huggingface.co/ukisai/Swift-Qwen3.8-27b https://huggingface.co/ukisai/Swift-Qwen3.8-27B-GGUF https://huggingface.co/bartowski/ukisai_Swift-Qwen3.8-27b-GGUF submitted by /u/Secure_Recording_472
  [link] [comments]
  ---|---
4. 🔗 HexRaysSA/plugin-repository commits sync repo: +4 releases, -4 releases rss
```
sync repo: +4 releases, -4 releases

## New releases
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 2026.917.2, 2026.917.1
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.12.2, 0.12.1

## Changes
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - removed version(s): 0.5.2, 0.5.1, 0.5.0, 0.4.1
```
5. 🔗 r/LocalLLaMA I literally built the Jev architecture one year back and completely open-sourced it with model, dataset and paper rss
  
  Update: I made a generic model and beaten the jev in all of the benchmarks. Code and details available at https://www.reddit.com/r/LocalLLaMA/s/bbwyiOprUs
  
  Everyone now talks about the architecture that's not auto regressive and does lightning fast probability prediction with a json schema. I worked on this literally one year back in March 2025, published an arxiv paper, pushed the model to huggingface along with the pypi package and training dataset. And then one year later, a
  
  frontier lab came, proposing the same idea like literal breakthrough without technical papers, open weights and no open dataset. I posted my approach in this subreddit. For anyones information the main guiding model is RL not embedding model or LLM
  
  Reddit post: https://www.reddit.com/r/LocalLLaMA/s/6eGEwsAz43
  
  Paper: https://arxiv.org/abs/2503.23303
  
  Model: https://huggingface.co/DeepMostInnovations/sales-conversion-model- reinf-learning
  
  Dataset: https://huggingface.co/datasets/DeepMostInnovations/saas-sales- conversations
  
  Also the second work published in September 2025 was exactly the same one jev proposed now
  
  Paper: https://arxiv.org/abs/2510.01237
  
  My model uses PPO over sequence embeddings to output turn-by-turn conversion trajectories (probabilities from 0.0 to 1.0).
  
  Jev uses parallel sampling (trained via RLCD) to output confidence distributions and schema choices.
  
  It's incredibly frustrating that the thing that you made with months of hard work, sweat and sleepless night is architecturally similar with the vertical use case and don't get the support you deserve because frontier lab build something horizontal. The open-source story in general 🙂
  
  submitted by /u/Nandakishor_ml
  [link] [comments]
6. 🔗 r/LocalLLaMA I literally built the Jev architecture one year back and completely open-sourced it with model, dataset and paper rss
  
  Update: I made a generic version. Full details at https://www.reddit.com/r/LocalLLaMA/s/bbwyiOprUs It includes code, benchmark and hf repo
  
  Everyone now talks about the architecture that's not auto regressive and does lightning fast probability prediction with a json schema. I worked on this literally one year back in March 2025, published an arxiv paper, pushed the model to huggingface along with the pypi package and training dataset. And then one year later, a
  
  frontier lab came, proposing the same idea like literal breakthrough without technical papers, open weights and no open dataset. I posted my approach in this subreddit. Links are. For anyones information the main guiding model is RL not embedding model or LLM
  
  Reddit post: https://www.reddit.com/r/LocalLLaMA/s/6eGEwsAz43
  
  Paper: https://arxiv.org/abs/2503.23303
  
  Model: https://huggingface.co/DeepMostInnovations/sales-conversion-model- reinf-learning
  
  Dataset: https://huggingface.co/datasets/DeepMostInnovations/saas-sales- conversations
  
  Also the second work published in September 2025 was exactly the same one jev proposed now
  
  Paper: https://arxiv.org/abs/2510.01237
  
  My model uses PPO over sequence embeddings to output turn-by-turn conversion trajectories (probabilities from 0.0 to 1.0).
  
  Jev uses parallel sampling (trained via RLCD) to output confidence distributions and schema choices.
  
  It's incredibly frustrating that the thing that you made with months of hard work, sweat and sleepless night is architecturally similar with the vertical use case and don't get the support you deserve because frontier lab build something horizontal. The open-source story in general 🙂
  
  submitted by /u/Nandakishor_ml
  [link] [comments]
7. 🔗 anthropics/claude-code v2.1.274 release
  What's changed
  - Added a visible warning when memory usage is critical, with steps to free memory or restart safely
  - Added CLAUDE_CODE_MCP_STARTUP_WAIT_MS to bound how long the first non-interactive turn waits for connecting MCP servers (0 = don't wait)
  - Added effort attribute to the claude_code.llm_request OpenTelemetry trace span, matching the api_request event
  - Added claude_code.managed_settings_resolved OTel event: managed-settings sources and policy helper state; redacted settings and digests with OTEL_LOG_MANAGED_SETTINGS=1
  - Added store.connect_timeout_seconds to the Claude apps gateway config to lengthen the Postgres connect timeout (default 5 seconds), and improved the boot error when the database is unreachable to point to store.postgres_url and the configured timeout
  - Added enduser.sub, the IdP subject, to the telemetry Claude Desktop and Cowork send through a Claude apps gateway
  - Added a Claude apps gateway warning when a replica has more requests open than the 256 it sends upstream at once, and a startup log line showing that limit
  - Added click-to-expand for collapsed teammate and agent messages in fullscreen mode
  - Fixed sessions getting stuck endlessly retrying "unexpected tool_use_id" 400 errors: corrupted transcripts now self-heal where possible, and otherwise a clear error (with a /rewind hint) ends the loop
  - Fixed MCP servers configured as http that only speak legacy HTTP+SSE failing to connect when they answer the first request with 422 or another 4xx error
  - Fixed Streamable HTTP MCP tool calls timing out after about 5 minutes even when a longer per-server timeout was set
  - Fixed MCP prompts and resources not refreshing when a server sends list-changed notifications without declaring listChanged
  - Fixed MCP tool calls refused with 403 insufficient_scope being reported as an expired sign-in: the error now names the missing permissions and points to /mcp re-authentication
  - Fixed hook-driven sessions (such as an active /goal) ending with "Prompt is too long" instead of compacting when the context overflowed again after a reactive compaction
  - Fixed an active /goal being lost when resuming (--continue / --resume) a session that had compacted
  - Fixed claude agents losing --model, --effort, --permission-mode, --allow-dangerously-skip-permissions and --agent after an auto-update relaunch
  - Fixed a per-turn slowdown when a language server publishes project-wide diagnostics for thousands of files
  - Fixed subagents with model: "opus" on Bedrock, Vertex or Foundry leaving the session's model when its id has no recognizable model family (unless ANTHROPIC_DEFAULT_OPUS_MODEL is set)
  - Fixed self-hosted runner sessions failing every turn with a 401 after a few failed token refreshes, until the next scheduled refresh; the runner now keeps retrying, and fetches a new token after a 401
  - Fixed clickable links to local file paths doing nothing in VS Code and other terminals that require a file:// URI
  - Fixed the transcript renumbering ordered lists in your own messages (typing "3. 2. 1." displayed "3. 4. 5."); numbers and "N)" markers now show as typed
  - Fixed AskUserQuestion preview notes being attached to a previously chosen option instead of the highlighted one
  - Fixed AskUserQuestion preview mode dropping the highlighted option when submitting a note with Enter
  - Fixed a resumed background agent keeping half of an interrupted tool batch when one of its calls was approved with a message
  - Fixed a local claude -p --resume started with CLAUDE_CODE_RESUME_INTERRUPTED_TURN not reporting background tasks the previous process left unfinished
  - Fixed the first turn of a cloud session sometimes starting without the tools of an SDK-hosted MCP server that was still connecting
  - Fixed background agent notifications claiming the agent had no live background work when it was still waiting on its own background task and would resume
  - Fixed error hints in Claude Desktop sessions to suggest slash commands like /usage-credits instead of CLI flags that cannot be used there
  - Fixed /schedule saving a routine's prompt without its message role when Claude writes the routine in the shape that listing routines returns
  - Fixed /status not showing the apiKeyHelper failure that its own error banner told you to check
  - Fixed /fast on in non-interactive sessions reporting on and then turning off under an organization's managed fast mode policy; it now says the organization has disabled it
  - Fixed the Artifact tool asking you to approve an update to an artifact that it then refused because the session had not read the latest version
  - Fixed Cowork and claude.ai cloud sessions with network access on treating reads of a teammate's artifact as if network access were off
  - Fixed a plugin or marketplace directory with no git repository of its own taking its version from an enclosing git repository, such as a git-managed ~/.claude
  - Fixed --strict-mcp-config with an empty --mcp-config holding the first non-interactive turn for up to MCP_TIMEOUT on incidental MCP servers
  - Fixed Stop prompt hooks re-sending their whole prompt on every block in a conversation; repeat blocks now name the condition with a 500-character label
  - Fixed extra empty editor windows opening at startup on Linux under Wayland when running inside the Cursor or VS Code terminal
  - Fixed an unhandled promise rejection in the Claude apps gateway when Postgres drops a connection during a spend check
  - Fixed Claude apps gateway cutting every open stream on SIGTERM: it now lets in-flight requests finish for up to 25 seconds before exiting (CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS)
  - Fixed installed_plugins.json being rewritten on nearly every start-up when plugin policy comes from remote managed settings, which made Claude Desktop reload every open session's plugins
  - Fixed headless and SDK sessions making a separate model call for every background task that finished; completions already queued are now answered by one call
  - Fixed the Bash tool re-sourcing the shell profile (a multi-second stall on the next command) after every plugin reload; it now does so only when the plugins' bin/ directories changed
  - Fixed plugins with a top-level $schema in hooks/hooks.json showing an "unknown key" notice
  - Fixed MCP connection errors and the MCP login tool's description showing secrets resolved from ${VAR} placeholders in MCP configs
  - Fixed Bash permission checks for commands that loop over or assign certain special shell variables; these commands now ask for permission
  - Fixed worktree-isolated sessions accepting Bash commands with certain nested shell expansions; these are now refused
  - Fixed the Edit permission prompt preview sometimes showing a different location than the approved edit in files with multi-byte characters
  - Fixed background commands being stopped after 30 idle minutes on machines under mild memory pressure; they're now stopped only when memory is critically low, and the debug log says why
  - Fixed a message a subagent sends to the main session disappearing from the Claude Desktop transcript after a relaunch
  - Fixed a plugin loaded from a .zip being served from a stale extraction after several overlapping reloads
  - Fixed a sub-agent's progress summary being replaced by a runaway multi-paragraph reply
  - Improved startup in --input-format stream-json sessions: the first turn no longer waits up to 2s for still-connecting MCP servers whose tools tool search defers; they arrive on a later turn
  - Improved Monitor tool notifications: a script's final output and its exit now arrive as one notification instead of two, saving a model turn
  - Improved Artifact tool errors: when you are not signed in to claude.ai the terminal now says so on the first attempt, and Claude is told to stop retrying a rejected call sooner
  - Improved artifact publishing: a publish built on an older version is stopped before it is sent, with the newer page to merge
  - Improved safety checks before removing an agent worktree that contains submodule checkouts
  - Improved OTEL_LOG_RAW_API_BODIES=file:<dir> output: a new index.jsonl and request_body_id / message.id event attributes link each response to its request file and transcript message
  - Improved Claude apps gateway boot: it now tries the first Postgres connection up to three times before exiting, so a database that is reachable a few seconds late no longer fails the boot
  - Improved the Claude apps gateway's spend-limit check under load: it now takes one database round trip instead of four, so fewer checks time out on a busy gateway
  - Improved Claude apps gateway sign-in rate limit errors: /login now explains the refusal, and the gateway log says which limit was hit and which setting to change
  - Changed Bedrock, Vertex, Foundry and telemetry-disabled installs to use the v2 MCP client and MCP 2026-07-28 negotiation with direct HTTP servers by default, as other installs already do (opt out: MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy)
  - Changed /code-review to use leaner inline review prompts for every model that has no tuned settings of its own, instead of spawning many review subagents
  - Changed "type": "sdk" MCP entries in .mcp.json, settings, plugins and agent files to be skipped with a warning: only an SDK host application can register in-process servers
  - Changed artifact watching in local sessions: a new version published elsewhere no longer starts a turn; Claude learns of it from a later Artifact tool result
  - Changed plugin and marketplace clones to leave Git LFS files as pointers instead of downloading them; git lfs pull in the checkout fetches them
  - Changed self-hosted runners to skip a read-only repository the git host refuses at the access check instead of failing the session start
  - Changed the /status GitHub line to read "Cloud sessions", and /web-setup, /ultrareview, and teleport messages to say "cloud session" instead of "Claude Code on the web"
  - [VSCode] Added continuation of the step a window reload interrupted, labeled in the chat, with a Claude Code: Continue After Reload setting to turn it off
  - [VSCode] Added Memory and Instructions entries to the Customize menu: Memory shows the auto-memory toggles, the saved memories and the memory folders, and Instructions edits the CLAUDE.md files
  - [VSCode] Added a claudeCode.lockEditorGroups setting to stop Claude from locking the editor groups it opens in
  - [VSCode] Fixed a /btw side question asked in a new conversation's first seconds occasionally showing another session's side-question history
  - [VSCode] Fixed a brief freeze when the extension first looks up your global gitignore file
  - [VSCode] Fixed a message sent while Claude was running a tool disappearing from the conversation after a window reload
  - [VSCode] Fixed the Manage Plugins enable toggle and MCP servers dialog rows being unreachable from the keyboard
  - [VSCode] Fixed sign-ins and sign-outs made in a terminal not showing until a reload after CLAUDE_CONFIG_DIR changed in the Environment Variables setting
  - [VSCode] Fixed Edit diffs in the chat being cut off at the bottom at some panel widths and for long wrapped lines; diff boxes now fit the rows shown
  - [VSCode] Fixed overlapping settings writes from the extension leaving ~/.claude/settings.json unparseable or dropping a setting
  - [VSCode] Fixed Open in New Tab (Ctrl/Cmd+Shift+Esc) sometimes leaving the new tab's message box unfocused, so typing went nowhere until you clicked it
  - [VSCode] Fixed reopening a closed Claude tab splitting the editor layout when its locked group still holds another Claude tab and a file
  - [VSCode] Fixed New session opening another locked editor group whenever a file tab shared the group with your Claude tab
  - [VSCode] Fixed session names shifting sideways in the session picker while typing a search query
  - [VSCode] Fixed the plan review card cutting off its Send feedback button and reason field when a plan has several comments; the comment list now scrolls
  - [VSCode] Fixed inline code and code blocks in chat replies being unreadable under the High Contrast themes
  - [VSCode] Improved screen reader navigation of the conversation: each message is announced as "You" or "Claude", with the tool name for tool steps
  - [VSCode] Changed the default global gitignore file to $XDG_CONFIG_HOME/git/ignore when XDG_CONFIG_HOME is an absolute path
  - [Claude Code on the web] Added a "Compare against" branch picker to a cloud session's diff view, so you can diff its changes against any branch instead of only the base branch
  - [Claude Code on the web] Fixed git operations in cloud sessions failing with "service unavailable" when GitHub's token renewal briefly errors
  - [Claude Code on the web] Fixed editing a routine occasionally making it fire twice or re-enabling a routine that had just been paused
  - [Claude Code on the web] Fixed commits in cloud sessions occasionally failing with a signing error for a few minutes after the session's credentials refreshed
  - [Claude Code on the web] Fixed the toast after saving a routine whose GitHub trigger couldn't be linked to show the reason, such as a per-repository trigger limit, instead of only "edit to retry"
  - [Claude Code on the web] Fixed sessions sometimes flipping back to unread right after you mark them read
  - [Claude Code on the web] Changed routines to skip a run and retry for up to 72 hours when the owner's GitHub connection is missing, instead of switching the routine off at the first failed check
  - [Claude Code on the web] Changed a routine's on-hold notice: when your subscription is paused it now tells you to turn the routine back on yourself instead of promising an automatic resume
  - [Claude Tag] Added a Guests setting to the Add channel and Add workspace forms in Claude Tag admin settings, so owners can pick Inherit, Allow, Channel only or Restrict up front
  - [Claude Tag] Fixed Claude not answering when another Slack app or bot @mentions it; the tag now gets a reply and wakes Claude in a channel it had stopped following after days of inactivity
  - [Claude Tag] Fixed Claude missing another app's message that tagged @claude right after a new Slack channel was created; it's now delivered once Claude has joined
  - [Claude Tag] Fixed Claude folding a follow-up sent minutes after its last Slack message into it as a silent edit; late updates such as blockers now post as a new reply that notifies
  - [Claude Tag] Fixed Claude's Slack search failing with an error whenever it searched within a single channel; it now returns that channel's matching messages
  - [Claude Tag] Fixed a safety-filter stop silently resetting a Slack thread's context when nobody was waiting; Claude now always says so and no longer cancels background work still running
  - [Claude Tag] Fixed email addresses in Claude's Slack replies rendering with a visible mailto: prefix; they now show as the plain, clickable address
  - [Claude Tag] Fixed Claude refusing to watch an Enterprise Grid channel shared with the whole organization when asked from another workspace in the grid
  - [Claude Tag] Fixed the Environment picker in Claude Tag admin settings showing a raw environment ID instead of the environment's name for archived or app-created environments
  - [Claude Tag] Improved Claude's live progress checklist in Slack: capped at 2,000 characters, reposted at most every 15 minutes in busy threads, with older "Latest task list" links updated
  - [Claude Tag] Removed the repeated guest-attribution note Claude appended to a Slack canvas each time it edited one in a channel using the "Channel only" guest setting
  - [Code Review] Fixed re-reviews occasionally leaving a fixed finding's thread open when the new review also filed a lower-severity note under it
  - [Code Review] Fixed rare reviews ending with "Code review encountered an error" when GitHub or an internal service failed transiently at launch; they now wait and retry
  - [Code Review] Improved how Code Review words each posted finding: short plain sentences that say who is affected, where the code goes wrong, and the fix up front
  - [Code Review] Improved the check-run card and PR comment when a review is skipped because of an organization limit: each cause now links the admin page that fixes it
8. 🔗 Rust Blog Be alert: targeted attacks on prominent Rustaceans rss
  
  We believe that there is an ongoing campaign targeting rust-lang members and owners of popular crates that is attempting to compromise devices and accounts in order to use them to publish malware.
  
  What we've seen
  
  A video call is set up for something positive — maybe for a job, maybe for a project, maybe for a contract opportunity — and then that's used as a vector to either get the target to install something on their computer (such as a purportedly missing audio codec) or execute another command (for example, via putting a command on the clipboard).
  
  These attackers are setting up new but legitimate seeming company profiles, including plausible LinkedIn presences, in order to pass cursory inspection.
  
  A previous attack of this form targeted many prominent Rust developers in June, and, last month, the arrayref crate was briefly compromised through similar attacks. At this moment we do not know if these are all a part of the same campaign.
  
  This attack style is known to be used by the DPRK, and has been seen outside of the Rust community as well.
  
  What you can do
  
  Please take extra care in the near term. Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust — ideally, try to be the one who sets up the call on a platform you already use.
  
  Please also re-check that your accounts look normal: MFA enabled, no unexpected logins on platforms that can track that, and so on.
  
  If you have any concerns about your accounts, please reach out to help@crates.io (for crates.io account concerns) and/or security@rust-lang.org (for any other concerns). We're very happy to help.
9. 🔗 seanmonstar Micro: Reading LLM text makes us worse writers rss
  
  The top advice given to anyone wanting to get better at writing, besides just writing, is to read more. Especially good writing. Because we imitate that which we experience more of.
  
  So then, perhaps obviously but it took way too long for me to realize, reading LLM output influences how we write. And since writing is thinking, it seeps in, ablating the voice in my head. I’m, as one says, horrified.
  
  I value LLMs for their ability to understand hyper-specific search queries. But I want to consider how much of the generated text I read; it’s better to read the human source. Or other non-forced exposure.
  
  Reply via: Email · Bluesky · Mastodon
10. 🔗 Console.dev newsletter htmx 4 rss
  
  Description: Enhance HTML.
  
  What we like: Simplifies the approach to adding attributes to HTML tags for dynamic features. Now uses fetch(). Makes it easy to implement features like infinite scroll, form post, search as you type, polling, and streaming responses. Still pretty minimal (11kb) and no dependencies.
  
  What we dislike: Lots of attributes littered all over your HTML, but that is the point.
11. 🔗 Console.dev newsletter Solo rss
  
  Description: Loader for Linux static binaries.
  
  What we like: Makes static binaries for GPU-accelerated code actually work. Makes it easy to build self-contained applications that can benefit from acceleration. Compile to musl, but still use common shared packages.
  
  What we dislike: Incomplete ABI coverage: unsupported glibc calls currently abort. Musl has its own compatibility issues.
12. 🔗 Ampcode News One Runner Is Now Enough rss
  A runner can now serve many directories, not just the one it was started in. You can point it at specific projects and directories or let it find your Git repositories.
  
  Start a runner and tell it which directories to serve with --dir. Repeat the flag for each one:
```
$ amp --no-tui --runner-id mac-mini --dir ~/code/amp --dir ~/code/sandcastle
```
  Or start it in the directory that holds your checkouts and let it find them:
```
$ cd ~/code
$ amp --no-tui --runner-id mac-mini --discover-dirs
```
  --discover-dirs serves every Git checkout up to two levels beneath the current directory and picks up new ones as you clone them.
  
  Checkouts somewhere else, or deeper than two levels? Give --discover-dirs a path, repeat it for more, and set --discover-depth to look further down:
```
$ amp --no-tui --discover-dirs=~/work --discover-dirs=~/code --discover-depth 4
```
  Add or remove directories while the runner is running, without restarting it:
```
$ amp runner dirs add ~/code/new-repo
$ amp runner dirs list
$ amp runner dirs remove ~/code/dotfiles
```
  The runner remembers the directories you add this way and serves them again the next time you start it from the same directory.
  
  Oh, They Can Update Themselves Too
  
  Runners now update themselves too. If you leave an amp --no-tui runner running, it keeps checking for new releases about once an hour and installs them. Once no thread is running on it, it restarts into the new version, at most once every 12 hours. It keeps its runner ID, its directories, and the rest of its flags.
  
  Turn it off with amp.runner.autoUpdate.enabled: false in your settings.
  
  Read more about serving multiple directories and runner updates in the runner docs.
September 16, 2026
1. 🔗 r/LocalLLaMA Qwen 3.8 27B Running for 63 hours on a RTX 3090 to solve the Riemann hypothesis rss
  
  I let Qwen 3.8 27B 4bit quantized with 100K context window run autonomously for 63 hours (50 million+ tokens) to try to solve the RH.
  
  Of course it did not solve it, but the experiment still shows it's internal work, memory organization, strategies used and more.
  
  The interesting thing is that it never hallucinated an answer and never stopped trying new ideas to solve it.
  
  Multiple times it corrected it's own mistakes.
  
  I am really hopeful that one of the unsolved millenium prize problems will be solved by an agent or a swarm of agents powered by an open source model in the next 12 months.
  
  If you want to check out it's internal memories, code, strategies and more I published everything on HF: https://huggingface.co/datasets/gr0010/artificium-riemannhypothesis- experiment
  
  My next goal is to actually use an agent perhaps powered by a smarter open model like GLM 5.3 flash or a swarm of agents, to solve an open math problem.
  
  Please let me know if you tried something similar, what problem you'd suggest to tackle next, and if you have any question.
  
  If you have GPUs consider getting in touch with me, we could run multiple agents to create a swarm and get them to tackle a simple yet open math/coding problem.
  
  submitted by /u/GuiltyBookkeeper4849
  [link] [comments]
2. 🔗 r/LocalLLaMA Xiaomi MiMo 2.6 Live Training Dashboard rss
  
  Cool to see this as it happens!
  
  submitted by /u/skeole
  [link] [comments]
3. 🔗 facebookresearch/faiss v1.15.1 release
  
  See CHANGELOG.md for the full list of changes.
4. 🔗 r/LocalLLaMA China's open-weight AI models are now just 4 months behind frontier US offerings, Mozilla report claims — models still lag in some benchmarks but are drastically cheaper to use rss
  
  | submitted by /u/DustNearby2848
  [link] [comments]
  ---|---
5. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases, -1 release rss
```
sync repo: +2 releases, -1 release

## New releases
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.11.2
- [mcrit-ida](https://github.com/danielplohmann/mcrit-plugin): 1.1.10

## Changes
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - removed version(s): 0.4.0
```
6. 🔗 r/LocalLLaMA Hey, Meta. Where's those Muse Spark weights? rss
  
  | It was well over a month since Meta promised to release the weights for Muse Spark. Back then (10th August), they were on Spark 1.2. Now we're on 1.3 and still nothing's been released. So it begs the question: will they be releasing the 1.2 weights when 1.4 drops? Or will we get whatever's then-current as open weights? It's ironic given Mark Zuckerberg said at the same time that we can't delay the release of models by "even a month," due to the competition with China. It's been well over a month. He was arguing in the context of new regulations delaying models, but I think it applies equally to the open weights contest as it does to the closed models one. After all, the Chinese models are all open. That's the competition and point of comparison. Have Meta given any sort of explanation for why they're sitting on the weights or how much longer it'll take for them to honour their promise? Will we even get them in light of all the attempts at regulatory capture and dire warnings about how AI is dangerous? submitted by /u/RishiFurfox
  [link] [comments]
  ---|---
7. 🔗 New Music Releases Trivium - Dead Inside of Me rss
  Trivium - a new release is available:
  - 2026-09-16: Dead Inside of Me (Single)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
8. 🔗 New Music Releases Thy Catafalque - Búcsú a piros madártól rss
  Thy Catafalque - a new release is available:
  - 2026-09-16: Búcsú a piros madártól (Single)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
September 15, 2026
1. 🔗 r/LocalLLaMA Don’t buy a $9K RTX 5090.... instead. rss
  |
  1. Fly to Taipei. Round-trip from Orlando: $1,081.
  2. Go to the largest retailer in Taiwan to Spend NT$129,990 ≈ US$4,093.
  3. Hang out in Taiwan for two weeks. Eat good food. Touch international grass.
  4. Fly home and flex on r/LocalLLaMA.
  https://preview.redd.it/vtve8s6wgrph1.png?width=287&format=png&auto=webp&s=fcc391187f458d2ca023a929e554b880bf425560 https://preview.redd.it/guffjq55hrph1.png?width=340&format=png&auto=webp&s=04cb074f89467c4ad73e36ac6e0570d14d228443 https://preview.redd.it/fe1obue0hrph1.png?width=1095&format=png&auto=webp&s=e3955e613ce4e53d65972b7f6e69e1468b6d6396 submitted by /u/DegenDataGuy
  [link] [comments]
  ---|---
2. 🔗 Quarkslab's blog Overview of Passive Optical Networks (PONs) Security rss
  You're watching a video on your favourite streaming platform. The platform sends video frames over HTTPS (encrypted), encapsulated in an IP packet with your IP address, ultimately forwarded to your fibre router inside an Ethernet frame. What you might not expect is that this Ethernet frame, containing your encrypted video, is actually received by all your neighbours' routers as well.
  
  The technology behind this behaviour is Passive Optical Networks (PON) : the optical signal received by your router is the same signal received by your neighbours, containing data for several nearby subscribers. It is effectively like having access to your neighbours' Ethernet cables from inside your home, but in one direction only.
  
  What can be extracted then depends entirely on what the subscriber is doing. If protocols are encrypted, the ONU only receives unencrypted metadata (source/destination addresses, ports, etc.), which can still reveal internet habits. If protocols are unencrypted, such as unencrypted DNS, unencrypted VoIP traffic, or legacy protocols, the entire payload is exposed.
  
  Several mechanisms can be activated to encrypt and authenticate each part of the signal so that only the intended recipient can decrypt and process it.
  
  ℹ️ Glossary
  
  There are many acronyms and definitions used in this article. The glossary is available at Annex A: Glossary.
  
  Fibre networks
  
  Internet Service Providers (ISPs) and companies often use Passive Optical Networks (PONs) to connect end-user devices to their infrastructure using optical fibre in the last kilometre (Fibre-to-the-x (FTTx)). If you have fibre internet in France or Europe, your router is probably using this technology, Gigabit-capable PON (GPON) or 10-Gigabit-capable (Symmetric) PON (XG(S)-PON) in particular.
  
  Before examining the security aspects of PONs, we will first review the evolution of the specifications, how PONs work, and how data is structured on the link.
  
  PON specifications
  
  Over the years, several iterations of PON specifications have been published by the ITU-T (International Telecommunication Union Telecommunication Standardization Sector):
  
  PON specifications timeline based on first specification publication date
  
  All the iterations in the timeline above are currently in use (although XGS- PON might be preferred to XG-PON) and can often coexist. While GPON has been around for more than 20 years, it is still standard for basic internet plans in France.
  
  As for the latest specification, 50-Gigabit-capable PON (50G-PON), released 5 years ago, some ISPs are only now starting to make real-world deployments. Orange, a French multinational ISP, made a small-scale demonstration of 50G-PON in October 2025 which it calls "the future standard for transmission systems in fibre access networks (FTTH)"1.
  
  Newer PON specifications can be grouped by the PON development phase they belong to:
  - Next-generation PON 1 (NG-PON1): XG-PON, XGS-PON.
  - Next-generation PON 2 (NG-PON2): NG-PON2.
  - Higher Speed PON (HSP): 50G-PON.
  - Very High Speed PON (VHSP): in development.
  We will stop at HSP/50G-PON, as it is the latest PON specification that has been released.
  
  Competing standards from the IEEE exist as well, to cite a few:
  - Ethernet PON (EPON): 1 Gbps symmetric.
  - Asymmetric 10G-EPON: 10 Gbps downstream, 1 Gbps upstream.
  - Symmetric 10G-EPON: 10 Gbps symmetric.
  We will focus on the ITU-T standards as they seem to be prevalent in France and Europe.
  
  Passive Optical Network (PON)
  
  ONUs, OLTs and the ODN
  
  PONs are optical fibre networks connecting Optical Line Terminations (OLTs) to Optical Network Units (ONUs) through Optical Distribution Networks (ODNs).
  
  ODNs used to be built around passive optical filters, splitters and combiners; hence the "Passive" Optical Network designation. However, newer specifications have introduced active elements such as Range Extenders, so the passive part depends on how the ODN is deployed.
  
  The ONU is the component of the router interfacing with the PON and it is sometimes a separate device connected to the router. When a single subscriber uses an ONU, it may also be called an Optical Network Termination (ONT).
  
  A simple description of an ONU would be that it is a device extracting Ethernet frames from the optical signal and forwarding them to the router. However, ONUs support other protocols as well (such as VoIP), have Quality-of- Service features (for time-sensitive signals), Layer-2/Layer-3 features (VLANs, IP configuration, TCP/UDP services, etc), configuration of xDSL if the ONU has xDSL ports, configuration of the security features, etc. The ONU Management and Control Interface (OMCI) specification, which defines the protocol used to configure the ONU, is 700 pages long. ONUs are more complex than they seem.
  
  ONUs are connected to an OLT which can be described as a fibre switch/router, through the ODN. The OLT is located on the service provider's side (ISP for instance).
  
  ONU (top) connected to the OLT (bottom) through an optical fibre. The ONU is plugged on one of the passive optical splitter ports, the splitter is integrated with the OLT here.
  
  The Optical Distribution Network: multiplexing optical signals
  
  One key aspect of an Optical Distribution Network (ODN) is that the signal is carried over a reduced number of optical fibres up to a splitter where individual fibres will carry the signal to the end user.
  
  To multiplex signals over a single fibre, several techniques are used depending on the specification or implementer's choice: Wavelength Division Multiplexing (WDM) , Time Division Multiplexing (TDM) or combining both using Time and Wavelength Division Multiplexing (TWDM).
  
  WDM uses different light frequencies to carry multiple signals. Due to carefully chosen frequencies, GPON, XG(S)-PON, NG-PON2 and 50G-PON can coexist on the ODN using a coexistence element (see ITU-T G.980519). For NG-PON2 and HSP, WDM is also used to increase the overall bandwidth by creating several channels that each use a different frequency pair. WDM can also designate the separation of transmit/receive frequencies to use on a single fibre, as opposed to using an individual fibre for each direction.
  
  Taking GPON as an example, the downstream signal is carried on a single fibre from the OLT up to a passive splitter. WDM is used: the upstream and downstream signals use separate wavelengths. The signal is then split (copied) between up to 128 users in the last kilometre and carried using individual fibres. Instead of running 128 individual fibres over up to 60km, only the last few metres will require individual fibres, which reduces the cost and complexity. However, this also means that all 128 users on the same ODN will receive the same downstream signal containing all users' data.
  
  Downstream PON
  
  As for the upstream signal, it uses Time Division Multiple Access (TDMA) , a specific type of TDM : each ONU sends bursts on a timing provided by the OLT, which enables all the individual optical signals from the ONUs to be passively aggregated again before reaching the OLT.
  
  Upstream PON
  
  For HSP and NG-PON2, the combination of WDM and TDM to create channels is designated as TWDM.
  
  The impact of PON architecture on security
  
  As the downstream signal is passively split between all the ONUs, they all receive the same downstream signal which contains their data but also their neighbours'. Basically, all downstream communications are broadcast at the link level, which mandates specific security measures.
  
  As for the upstream signal, it is not carried to other users. However, it can still be intercepted on each individual fibre or when aggregated by the combiner en route to the OLT.
  
  In both cases, authentication and encryption are desirable to avoid eavesdropping, tampering, or man-in-the-middle attacks, which brings us to the threat model of PON specifications.
  
  The PON's protocol stack
  
  In the previous sections, we learned how PONs are structured. This section presents the protocols used to configure the PON link and how data is framed. The objective is to present a condensed view of the frame structure; it can be glossed over and used as a reference for the next security-focused part.
  
  Three main configuration channels: Embedded OAM , PLOAM and OMCI
  
  Before going into the frame structures, let us mention three protocols used by GPON, XG(S)-PON, NG-PON2 and 50G-PON:
  - Embedded layer Operation, Administration and Maintenance (Embedded OAM): fields embedded in the frame headers for low latency access, for instance, the frame identifier or the upstream bandwidth allocation.
  - Physical layer Operation, Administration and Maintenance (PLOAM): used for other information not sent by the above that relates to the link layer, information that is less time-sensitive but used to configure the connection. For instance, sending the serial number to the OLT, the ONU ID, sending the data encryption key, etc.
  - ONU Management and Control Interface (OMCI): the protocol used for high-level configuration of the ONU (the channel is actually called ONU Management and Control Channel (OMCC)). The protocol is defined in the ITU-T G.988 ONU management and control interface (OMCI) specification 15. It uses a Management Information Base (MIB) synchronised between the ONU and the OLT, and allows complex mutual authentication, Layer 2 and Layer 3 configuration, ONU debug, etc.
  Four layers
  
  GPON, XG(S)-PON, NG-PON2 and 50G-PON all have similar frame structures, sharing a few similar characteristics:
  - When TDM is used (which is most of the time), the upstream frame structure is slightly different from the downstream frame structure.
  - The frames have four layers: Physical Medium Dependent (PMD) layer, Transmission Convergence (TC) PHY Adaptation Sublayer, TC Framing Sublayer (FS) and TC Service Adaptation Sublayer.
  - The lower layer is the PMD layer, which defines how data is encoded on the optical line.
  - The layer between the PMD and user functionalities (Service Data Units, SDUs) is the TC layer. It's called GTC for GPON4, XGTC for XG-PON9, XGS-PON TC10 for XGS-PON, TWDM TC for NG-PON214 and ComTC (for Common TC) for 50G-PON (HSP)17. 50G-PON/Higher Speed PON generalises the TC layer from XG-PON onwards.
  - The TC service adaptation sublayer contains (X)GEM frames ((10) Gigabit PON Encapsulation Method) which encapsulate the actual data payload (Ethernet frames for instance).
  The diagram below represents a downstream frame and its separation into different layers. This representation deliberately shows only a few fields which are relevant to explain how PON works or are security-related. Technically, it only applies to XG(S)-PON, NG-PON2 and 50G-PON, but GPON is similar. Moreover, while the name and overall purpose of a field might be the same between PON versions, the structure can differ.
  
  XG(S)-PON, NG-PON2 and 50G-PON downstream frame structure
  
  The fields shown on the diagram have the following use:
  - Superframe counter (SFC) : 51-bit (XG(S)-PON, NG-PON2 and 50G-PON), 30-bit (GPON), wraps around to 0. It is used in the data encryption process for the counter mode of operation.
  - PLOAMd : used by the OLT in the PLOAM configuration protocol, for instance to request a new data encryption key.
  - BWmap : not directly security-related, but contains the timings on which upstream frames can be sent for each ONU (for TDMA). More precisely, the OLT assigns Allocation IDs (Alloc-IDs) to the ONUs (a default one is always assigned for OMCI). These Alloc-IDs are then associated with Transmission Containers (T-CONs) which represent a group of logical connections which can be assigned a bandwidth. Finally, each downstream frame contains the bandwidth assignment for the Alloc-IDs, which means each Alloc-ID/T-CON will have a dedicated time to send an upstream burst. Note that the TC layer is only concerned with Alloc-IDs, T-CONs are managed through OMCI and another structure could map to Alloc-IDs. T-CONs are then mapped to (X)GEM ports, the smallest connection entity. Grouping (X)GEM ports into T-CON enables managing bandwidth for QoS (Quality-of-Service) purposes, to prioritise real-time signals such as voice audio.
  - Encryption key index : only for XG(S)-PON, NG-PON2 and 50G-PON. Indicates if the downstream payload is: unencrypted, encrypted using key 1, encrypted using key 2 (key index relative to the key slot). GPON does not have such a field: the OLT does not select a key slot but sends a Superframe counter value to the ONU through PLOAMd at which the new key (to be sent) will be used.
  In GPON, the FS Header and PSBd are actually merged as a single header (named GTC Header or PCBd) with a similar purpose. Another difference is that while the PLOAMd , BWmap and SFC fields are present in all PON versions, the Encryption key index is only present in XG(S)-PON, NG-PON2 and 50G-PON.
  
  The diagram below represents an upstream frame for XG(S)-PON, NG-PON2 and 50G-PON; it differs slightly for GPON, but it is overall very similar:
  
  XG(S)-PON, NG-PON2 and 50G-PON upstream frame structure
  
  The upstream frames are sent in bursts. Each Alloc-ID is given an opportunity to send data according to the BWMap field sent in the downstream frame. Alloc-ID bandwidth allocations that belong to the same ONU and are consecutive (in time and thus in the BWMap) are called an allocation series. They start with an FS Header and end with an FS Trailer.
  
  Threat models of GPON, XG(S)-PON, NG-PON2 and 50G-PON
  
  All the ITU-T PON specifications referenced have a threat model, which has greatly improved from GPON to XG-PON. XGS-PON/NG-PON2/50G-PON share the XG-PON threat model for the most part.
  
  The GPON4 threat model can be summarised as such:
  - An attacker or user having reprogrammed an ONU, or having otherwise access to the incoming optical signal, can access all downstream communications including data from all the other OLT users.
  - Other threats such as eavesdropping on the upstream link are considered impractical because the attacker would have to tap into the fibre, sometimes in public places and in a noticeable way for the PON.
  The XG-PON specification9 as well as XGS- PON9 10, NG- PON214 and 50G-PON17 have gone back on this model, taking upstream threats into account as well:
  - An attacker or user having reprogrammed an ONU, or having otherwise access to the incoming optical signal, can access all downstream communications including data from all the other OLT users.
  - An attacker or user having reprogrammed an ONU can impersonate another ONU and forge packets.
  - An attacker could intercept or generate traffic at any point on the ODN (which sometimes spans 60 km) between the OLT and the ONU, impersonating the OLT or an ONU.
  - An attacker or user could use any of the scenarios above to record and replay packets transmitted on the PON, or modify the packets (bitflips for instance).
  Overall, the threat model has improved significantly since GPON, considering security issues in both directions (OLT to ONU and ONU to OLT), as well as eavesdropping anywhere between the OLT and ONUs. This translates into improved security features as well.
  
  Additionally, a study group with members from China Telecommunications Corporation, Verizon, Huawei Technologies Co., Ltd. and ZTE Corporation has published recommendations named "Practical aspects of PON security" starting from 2022. A first supplement has been published20, with the objective "to guide the security experts on operators' expectations about the security of their access networks and on the criteria of a valuable security proposal, as well as the reference to the operators on configuring their networks to achieve the best possible security performance.".
  
  The improved threat model in the supplement separates the threats into several categories:
  - Eavesdropping: downstream and upstream.
  - Theft of service: unauthorised access to the PON.
  - Denial of service.
  - Theft of data.
  - Impersonation.
  - Disruption of operations: disruption from a single ODN to a larger scale (entire ISP for instance).
  The supplement insists that "regardless of how strong the link-level encryption strength is, no end-to-end data security property can be derived from it". Indeed, PON specifications are only concerned with establishing a secure channel between an ONU and an OLT, at the link level. This channel is not established between an end user and a service provider directly.
  
  Overall, the supplement gives more context to the threat model and makes recommendations on key management and handling of ONU identifier duplication. The XG-PON ITU-T G.987.39, NG- PON2 ITU-T G.989.314 and 50G-PON ITU-T G.9804.217 specifications' latest amendments actually recommend using this supplement for best practices related to key management. As it is recommended by the specifications, it probably must be implemented.
  
  One threat that does not seem to be mentioned in any of the threat models is the exploitation of vulnerabilities in the OMCI Management Entities, which have a large attack surface. The implementation of the OMCI Management Entities functionalities is down to the manufacturer so this might be outside the specification perimeter however.
  
  PON security measures
  
  Authentication and cryptographic schemes
  
  Authentication in ITU-T PONs can be surprisingly complex, as there are multiple identifiers and schemes available. They are sometimes combined, and the authentication methods do not all ensure the same level of security.
  
  We will separate the use of these identifiers into two categories:
  - Identification: the OLT requests an identifier, but there is no secure channel bound to this identifier. In GPON, the OLT can request an identifier and then request an encryption key, but the key is not bound to the identifier, which is why only one authentication scheme is considered for GPON (OMCI-based).
  - Authentication: the OLT (and the ONU if the authentication is symmetric) uses a cryptographic scheme to authenticate its counterpart. The results of this authentication can be used to establish a secure channel between the two devices. Keep in mind that, as we'll see in the next sections, a successful authentication does not mean the secure channel is activated, only that it can be.
  All PON versions start with an identification step: at the very start of its connection to the OLT, the ONU sends its serial number.
  
  Then, for GPON, cryptographic authentication is entirely optional. For XG-PON and later, a Registration ID -based authentication will always be performed after ONU initialis ation, whether Registration_ID is the default null string or a provisioned one. If a Registration_ID is not provisioned, it will not provide meaningful authentication.
  
  After the mandatory identification or authentication steps, the OLT can start a new authentication process at any point, or request other identifiers. For authentication, up to three cryptographic schemes are available depending on the PON version. Some of these schemes allow for mutual authentication (ONU to OLT, but also OLT to ONU), all of them lead to the creation of a Master Session Key (MSK) which can then be used to establish a secure channel.
  
  Authentication decision diagram
  
  The Logical ONU ID (LOID) / LOID password identifiers often present in ONU web interfaces can be a bit confusing. They seem to be both implemented in custom OMCI Management Entities (as is the case for the Management Entity 65530 used by Huawei ONUs) and in the standard "ONU-G" OMCI Management Entity. The O3 Labs website21 lists several vendor-specific OMCI Management Entities.
  
  Note that a combination of these identifiers and schemes can be used at different steps during the configuration of the ONU. For an XGS-PON link the following sequence could be used:
  1. Identify the ONU through the serial number sent at the start of the link initialisation.
  2. Request the Registration ID from the ONU, derive an MSK using the corresponding cryptographic scheme and enable encryption.
  3. Start the OMCI cryptographic scheme and transition to the new MSK.
  The (mutual) secure authentication mechanisms
  
  In the previous section, we mentioned three authentication mechanisms based on cryptography: Registration ID-based, OMCI-based and IEEE 802.1X-based.
  
  Only the last two are mutual authentication schemes that authenticate both the ONU and the OLT.
  
  Registration ID-based authentication
  
  Only available in XG(S)-PON, NG-PON2 and 50G-PON. This is the default authentication mode based on a 36-byte value called Registration_ID and it is not mutual. The Registration_ID is requested by the OLT during the ONU activation process and can be queried at any time through a PLOAM message, which is unencrypted.
  
  This mechanism is thus vulnerable to several threats, for instance:
  - An attacker can unplug the target optical fibre, plug it in their OLT, request the Registration_ID , derive the keys and use them to decrypt the encrypted data encryption key transmitted through PLOAM after the device has been plugged back to the original OLT.
  - An attacker could tap at any point between the targeted user and the OLT and see the Registration_ID in clear form, derive the keys and use them to decrypt the encrypted data encryption key transmitted through PLOAM.
  The Registration_ID is not meant to be changed regularly, the attacker can query it once and reuse it at any time. Moreover, if it is unchanged, the default is used.
  
  A key consideration is that Registration_ID \def\pelican{\textrm{pelican}^2} \text{Registration\ID} has a default value (0x00)36 \def\pelican{\textrm{pelican}^2} (0x00){36}, which will be used for the Registration ID-based authentication unless a Registration_ID has been provisioned. Thus, the specifications effectively allow the use of one of the cryptographic authentication schemes with a known (weak) secret. Having the possibility to use an unauthenticated/unencrypted channel, which would not provide a false sense of security, would seem preferable.
  Registration ID-based MSK derivation
  
  Let:
  
  Registration_ID \def\pelican{\textrm{pelican}^2} \text{Registration\_ID} be the 36-byte Registration ID.
  
  TMSK \def\pelican{\textrm{pelican}^2} T_{MSK} be the required MSK length.
  
  K \def\pelican{\textrm{pelican}^2} K be the 128-bit AES key used in the AES-ECMAC definition.
  
  M \def\pelican{\textrm{pelican}^2} M be the input message used in the AES-ECMAC definition.
  
  Tlen \def\pelican{\textrm{pelican}^2} Tlen be the requested MAC output length in bits.
  
  MlessLastBlock \def\pelican{\textrm{pelican}^2} M_{\text{lessLastBlock}} be the M \def\pelican{\textrm{pelican}^2} M with its final 16 octets removed.
  
  MSK \def\pelican{\textrm{pelican}^2} MSK is derived the following way:
  
  MSK={AES-128-CMAC&af((0x55)16,Registration_ID,128),TMSK=128AES-128-ECMAC&af((0x55)16,Registration_ID,256),TMSK=256 (50G-PON/HSP) \def\pelican{\textrm{pelican}^2} MSK = \begin{cases} \operatorname{AES-128-CMAC}\left((\text{0x55}){16}, \text{Registration\_ID}, 128\right), & T{MSK}=128 \\[6pt] \operatorname{AES-128\text{-}ECMAC}\left((\text{0x55}){16}, \text{Registration\_ID}, 256\right), & T{MSK}=256 \text{ (50G-PON/HSP)} \end{cases}
  
  where
  
  AES-128-ECMAC&af(K,M,Tlen)={AES-128-CMAC&af(K,M,Tlen),Tlen≤128AES-128-CMAC&af(K,MlessLastBlock,128)&smidAES-128-CMAC&af(K,M,128),Tlen=256 \def\pelican{\textrm{pelican}^2} \operatorname{AES-128\text{-}ECMAC}(K, M, Tlen) = \begin{cases} \operatorname{AES-128-CMAC}(K, M, Tlen), & Tlen \leq 128 \\[4pt] \operatorname{AES-128-CMAC}\left(K, M_{\text{lessLastBlock}}, 128\right) | \operatorname{AES-128-CMAC}(K, M, 128), & Tlen = 256 \end{cases}
  OMCI-based authentication
  
  This is one of the two mutual secure authentication mechanisms, now defined in ITU-T G.98815 (originated in ITU-T G.984.45 for GPON). The scheme assumes a Pre-Shared Key (PSK \def\pelican{\textrm{pelican}^2} PSK) has been provisioned on both the ONU and OLT beforehand.
  
  A three-step challenge-based mutual authentication is used:
  Three-step OMCI authentication
  
  The OLT sends its list of supported MAC (Message Authentication Code) functions and OLT random challenge \def\pelican{\textrm{pelican}^2} OLT\ random\ challenge to the ONU.
  
  Then, the ONU selects one of the supported OLT MAC functions, then sends the ONU random challenge \def\pelican{\textrm{pelican}^2} ONU\ random\ challenge and the following MAC to the OLT: MACFunction(PSK,(selected_cryptographic_capabilities&smidOLT random challenge&smidONU random challenge&smid(0x00)16)) \def\pelican{\textrm{pelican}^2} \text{MACFunction}(\text{PSK}, (selected\cryptographic\_capabilities|OLT\ random\ challenge|ONU\ random\ challenge|(0x00){16}))
  
  Finally, OLT then sends a MAC to the ONU as well: MACFunction(PSK,(selected_cryptographic_capabilities&smidONU random challenge&smidOLT random challenge&smidONU Serial Number)) \def\pelican{\textrm{pelican}^2} \text{MACFunction}(\text{PSK}, (selected\_cryptographic\_capabilities|ONU\ random\ challenge|OLT\ random\ challenge|ONU\ Serial\ Number))
  The OLT advertises its supported MACFunction \def\pelican{\textrm{pelican}^2} MACFunction in the "OLT crypto capabilities" attribute of the OMCI "Enhanced security control" Management Entity. Then, the ONU chooses one of these MACFunctions \def\pelican{\textrm{pelican}^2} MACFunctions and sets the "ONU selected crypto capabilities" attribute of the OMCI "Enhanced security control" Management Entity. It is then used as onu_selected_cryptographic_capabilities \def\pelican{\textrm{pelican}^2} \text{onu\_selected\_cryptographic\_capabilities}.
  
  MACFunction \def\pelican{\textrm{pelican}^2} MACFunction is chosen from the following list:
  - AES-CMAC-128 (default, must be supported).
  - HMAC-SHA-256.
  - HMAC-SHA-512.
  Master Session Key derivation
  
  Finally, the MSK \def\pelican{\textrm{pelican}^2} MSK is derived from the PSK \def\pelican{\textrm{pelican}^2} PSK and the challenges. The following formula is used when a 128-bit MSK \def\pelican{\textrm{pelican}^2} MSK is required, which is always the case for GPON, XG(S)-PON and NG-PON2:
  
  OMCI-based 128-bit MSK \def\pelican{\textrm{pelican}^2} MSK derivation
  
  MSK=MACFunction(PSK,(OLT random challenge&smidONU random challenge)), take the 128 most significant bits. \def\pelican{\textrm{pelican}^2} \text{MSK} = \text{MACFunction}(\text{PSK}, (OLT\ random\ challenge | ONU\ random\ challenge))\text{, take the 128 most significant bits.}
  
  However, 50G-PON also supports 256-bit MSKs. When combining the ITU-T G.988 (OMCI)15 and ITU-T G.9804.2 (50G-PON)17 specifications, it is unclear how MSK \def\pelican{\textrm{pelican}^2} MSK should be derived in this situation. ITU-T G.9804.2 also defers to ITU-T G.987.39 for OMCI authentication.
  
  When MACFunction=AES-CMAC-128 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{AES-CMAC-128}, the equation is clear:
  
  OMCI-based 50G-PON 256-bit MSK derivation for MACFunction=AES-CMAC-128 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{AES-CMAC-128}
  
  MSK=AES-128-ECMAC&af(PSK,(OLT random challenge&smidONU random challenge),256) \def\pelican{\textrm{pelican}^2} \text{MSK} = \operatorname{AES-128\text{-}ECMAC}\left(\text{PSK}, (OLT\ random\ challenge | ONU\ random\ challenge), 256\right)
  
  where
  AES-128-ECMAC&af(K,M,Tlen)={AES-128-CMAC&af(K,M,Tlen),Tlen≤128AES-128-CMAC&af(K,MlessLastBlock,128)&smidAES-128-CMAC&af(K,M,128),Tlen=256 \def\pelican{\textrm{pelican}^2} \operatorname{AES-128\text{-}ECMAC}(K, M, Tlen) = \begin{cases} \operatorname{AES-128-CMAC}(K, M, Tlen), & Tlen \leq 128 \\[4pt] \operatorname{AES-128-CMAC}\left(K, M_{\text{lessLastBlock}}, 128\right) | \operatorname{AES-128-CMAC}(K, M, 128), & Tlen = 256 \end{cases}
  
  When MACFunction=HMAC-SHA-256 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{HMAC-SHA-256} or MACFunction=HMAC-SHA-512 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{HMAC-SHA-512} are used, the specifications imply one of two things:
  - Following ITU-T G.9804.2 Annex C "Secure mutual authentication", the output of MACFunction \def\pelican{\textrm{pelican}^2} \text{MACFunction} is truncated to 256 bits, as HMAC-SHA-256 \def\pelican{\textrm{pelican}^2} \text{HMAC-SHA-256} generates a 256-bit value and HMAC-SHA-512 \def\pelican{\textrm{pelican}^2} \text{HMAC-SHA-512} a 512-bit value.
  - ITU-T G.988 requires MSK \def\pelican{\textrm{pelican}^2} MSK to be truncated to 128 bits. According to ITU-T G.9804.2 clause 9.13, MSK \def\pelican{\textrm{pelican}^2} MSK must be extended to 256 bits using the same process as the "OMCI-based 50G-PON 256-bit MSK derivation for MACFunction=AES-CMAC-128 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{AES-CMAC-128}" equation above.
  The key contradictory quotes are available in Annex C: Contradictory specification quotes relative to the derivation of a 256-bit MSK \def\pelican{\textrm{pelican}^2} MSK for HMACs with an output size of 256-bit or more.
  
  As both the ONU and OLT must derive the same MSK \def\pelican{\textrm{pelican}^2} MSK, a manufacturer testing this specific case with different ONUs or OLTs would notice any implementation mismatch. A clarification of the specification would make clear what is actually implemented, but all manufacturers should have the same implementation eventually. As 50G-PON is not widely deployed, they might not have faced this choice yet, especially with these specific MACFunctions \def\pelican{\textrm{pelican}^2} \text{MACFunctions}.
  
  IEEE 802.1X-based authentication
  
  This is the second mutual secure authentication mechanism, only available in XG(S)-PON, NG-PON2 and 50G-PON. Its implementation is mostly detailed in Annex D of ITU-T G.987.39.
  
  IEEE 802.1X supports many authentication methods through the Extensible Authentication Protocol (EAP)23. EAP- GPSK24 which is based around a pre-shared key, must be supported according to ITU-T G.987.39. EAP- TLS25 is also mentioned in the specification and allows the use of public-key cryptography. Any EAP method that supports mutual authentication and the generation of a secret MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{EAP} can be used.
  
  RFC 374823 mentions that the MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{EAP} generated must be at least 64 bytes long, however we need only 16 bytes or 32 bytes (50G-PON only).
  
  IEEE 802.1X-based MSK derivation
  
  Let TMSK \def\pelican{\textrm{pelican}^2} T_{MSK} be the required MSKPON \def\pelican{\textrm{pelican}^2} MSK_{PON} size in bits. MSKPON \def\pelican{\textrm{pelican}^2} MSK_{PON} is derived from MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{EAP} as follows:
  
  MSKPON=TMSK most significant bits of MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{PON} = T_{MSK}\text{ most significant bits of } MSK_{EAP}
  
  A note on Forward Secrecy
  
  Only one authentication scheme, the IEEE 802.1X-based scheme with the right EAP (EAP-TLS with a Diffie-Hellman key exchange for instance), might lead to an encrypted session that provides perfect forward secrecy. For the other schemes, the leak of the Registration_ID or PSK would enable attackers to decrypt the signal in harvest now, decrypt later attacks. The encrypted data encryption key contained in the PLOAM messages could be decrypted, and then the payloads of the XGEM frames.
  
  Key Derivation
  
  MSK \def\pelican{\textrm{pelican}^2} MSK and its derived keys have three purposes: encrypting the data encryption key (using the MSK \def\pelican{\textrm{pelican}^2} MSK for GPON or the Key Encryption Key (KEK \def\pelican{\textrm{pelican}^2} KEK) otherwise), authenticating PLOAM messages and authenticating OMCI messages (XG-PON and above only).
  
  Key derivation decision diagram
  
  Note that the typos and wordplays in the strings match the actual values used by the specifications, as specific string lengths were required.
  XG(S)-PON and NG-PON2 derivations
  
  SK=AES-128-CMAC(MSK,(SN&smidPON-TAG&smid"SessionK")) \def\pelican{\textrm{pelican}^2} SK = \text{AES-128-CMAC}(MSK, (\text{SN}|\text{PON-TAG}|\text{"SessionK"})) OMCI_IK=AES-128-CMAC(SK,"OMCIIntegrityKey") \def\pelican{\textrm{pelican}^2} OMCI\_IK = \text{AES-128-CMAC}(SK, \text{"OMCIIntegrityKey"}) PLOAM_IK=AES-128-CMAC(SK,"PLOAMIntegrtyKey") \def\pelican{\textrm{pelican}^2} PLOAM\_IK = \text{AES-128-CMAC}(SK, \text{"PLOAMIntegrtyKey"}) KEK=AES-128-CMAC(SK,"KeyEncryptionKey") \def\pelican{\textrm{pelican}^2} KEK = \text{AES-128-CMAC}(SK, \text{"KeyEncryptionKey"})
  
  50G-PON derivations
  
  Let:
  
  K \def\pelican{\textrm{pelican}^2} K be the key used in the BC-ECMAC definition.
  
  M \def\pelican{\textrm{pelican}^2} M be the input message used in the BC-ECMAC definition.
  
  Tlen \def\pelican{\textrm{pelican}^2} Tlen be the requested MAC output length in bits.
  
  BC \def\pelican{\textrm{pelican}^2} BC be the chosen Block Cipher.
  
  MlessLastBlock \def\pelican{\textrm{pelican}^2} M_{\text{lessLastBlock}} be M \def\pelican{\textrm{pelican}^2} M with its final 16 octets removed.
  
  SK=BC-ECMAC(MSK,(SN&smidPON-TAG&smidPON-TAG&smidSN),Tlen) \def\pelican{\textrm{pelican}^2} SK = \text{BC-ECMAC}(MSK, (SN|\text{PON-TAG}|\text{PON-TAG}|SN), Tlen) OMCI_IK=BC-ECMAC(SK, "OMCIIntegrityKeyMakeOMCImoreSafe",Tlen) \def\pelican{\textrm{pelican}^2} OMCI\IK = \text{BC-ECMAC}(SK, \text{ "OMCIIntegrityKeyMakeOMCImoreSafe"}, Tlen) PLOAM_IK=AES-128-CMAC(SK16 least significant bytes,"PLOAMIntegrtyKey") \def\pelican{\textrm{pelican}^2} PLOAM\_IK = \text{AES-128-CMAC}(SK\text{16 least significant bytes}, \text{"PLOAMIntegrtyKey"}) KEK=BC-ECMAC(SK,"KeyEncryptionKeyMakeKEKMoreSafey",Tlen) \def\pelican{\textrm{pelican}^2} KEK = \text{BC-ECMAC}(SK, \text{"KeyEncryptionKeyMakeKEKMoreSafey"}, Tlen) where BC-ECMAC&af(K,M,Tlen)={BC-CMAC&af(K,M,Tlen),Tlen≤128BC-CMAC&af(K,MlessLastBlock,128)&smidBC-CMAC&af(K,M,128),Tlen=256 \def\pelican{\textrm{pelican}^2} \operatorname{BC\text{-}ECMAC}(K, M, Tlen) = \begin{cases} \operatorname{BC-CMAC}(K, M, Tlen), & Tlen \leq 128 \\[4pt] \operatorname{BC-CMAC}\left(K, M_{\text{lessLastBlock}}, 128\right) | \operatorname{BC-CMAC}(K, M, 128), & Tlen = 256 \end{cases}
  For GPON, the data encryption key is only sent encrypted when the OMCI authentication is used; otherwise it is sent in clear form. The key is always sent encrypted in XG(S)-PON, NG-PON2 and 50G-PON, using the KEK \def\pelican{\textrm{pelican}^2} KEK key derived from the MSK.
  
  The other two keys derived from the MSK in XG(S)-PON, NG-PON2 and 50G-PON are used for the authentication of OMCI and PLOAM messages, so only OMCI and PLOAM have authenticity checks, not the main payload. GPON does not have such a mechanism.
  
  Authentication of PLOAM and OMCI messages
  
  Only XG(S)-PON, NG-PON2 and 50G-PON authenticate the PLOAM and OMCI messages; GPON does not. Authentication ensures the messages have been sent by the right peer and that they have not been tampered with.
  
  The PLOAM and OMCI Message Integrity Check (MIC) values are derived the following way:
  
  PLOAM and OMCI MIC calculation
  
  PLOAM-MIC=AES-128-CMAC(PLOAM_IK,(Cdir&smidPLOAM_CONTENT),64) \def\pelican{\textrm{pelican}^2} \text{PLOAM-MIC} = \text{AES-128-CMAC} (\text{PLOAM\IK}, (C{dir} | \text{PLOAM\_CONTENT}), 64)
  
  OMCI-MIC=BC-CMAC(OMCI_IK,(Cdir&smidOMCI_CONTENT),32) \def\pelican{\textrm{pelican}^2} \text{OMCI-MIC} = \text{BC-CMAC} (\text{OMCI\IK}, (C{dir} | \text{OMCI\CONTENT}), 32)
  where Cdir=0x01 \def\pelican{\textrm{pelican}^2} C{dir} = 0x01 for downstream and Cdir=0x02 \def\pelican{\textrm{pelican}^2} C_{dir} = 0x02 for upstream.
  
  and
  
  BC-CMAC \def\pelican{\textrm{pelican}^2} \text{BC-CMAC} is AES-128-CMAC \def\pelican{\textrm{pelican}^2} \text{AES-128-CMAC} for XG(S)-PON and NG- PON2. For 50G-PON, the chosen block cipher used across data encryption, key derivation and message integrity checks is used for OMCI. This allows 50G-PON to use stronger keys (256-bit). PLOAM, however, always uses AES-128-CMAC \def\pelican{\textrm{pelican}^2} \text{AES-128-CMAC}.
  
  PLOAM and OMCI authentication is always enabled; however, before any MSK has been derived a default key is used for PLOAM: 0x5516 \def\pelican{\textrm{pelican}^2} 0x55_{16}. The default key is always used for downstream broadcast PLOAM messages, as well as some unicast PLOAM messages such as the Serial_Number_ONU , Deactivate_ONU-ID , Request_Registration and Registration PLOAM messages. After that, the keys derived from the MSK established from the Registration_ID are used, and finally the keys derived from any new MSK established from one of the authentication mechanisms.
  
  Generating the data encryption keys
  
  There are two types of data encryption keys: unicast and multicast (broadcast). In the previous sections, we only mentioned which keys are used to encrypt the unicast data encryption key; not how it is generated.
  
  The unicast data encryption key used in the GPON, XG(S)-PON and NG-PON2 specifications is generated by each ONU, not the OLT.
  
  GPON, XG-PON and NG-PON2 data encryption key generation
  
  EncryptionKey=ONU-generated random generated value of size 128 bits \def\pelican{\textrm{pelican}^2} EncryptionKey = \text{ONU-generated random generated value of size 128 bits}
  
  A secure random number generator must be used.
  
  Moreover, if the key is not generated properly, all the authentication and key encryption will not matter as the attacker could bruteforce the data encryption key. Thus, according to the XG(S)-PON and NG-PON2 specifications, "the ONU generates a new encryption key using a random number generator suitable for cryptographic purposes"14. The GPON specification has a similar mention "The ONU should generate a cryptographically unpredictable key."4.
  
  As for 50G-PON, the unicast data encryption key is now derived from both an OLT and an ONU random number, instead of being taken directly from the random number generator output:
  50G-PON data encryption key generation
  
  Let:
  
  KEK \def\pelican{\textrm{pelican}^2} \text{KEK} be the Key Encryption Key derived from MSK \def\pelican{\textrm{pelican}^2} MSK.
  
  BC \def\pelican{\textrm{pelican}^2} \text{BC} be the chosen Block Cipher.
  
  Tlen \def\pelican{\textrm{pelican}^2} \text{Tlen} be the BC \def\pelican{\textrm{pelican}^2} \text{BC} key size.
  
  KeyControl_RandomX \def\pelican{\textrm{pelican}^2} \text{KeyControl\_RandomX} and KeyControl_RandomX \def\pelican{\textrm{pelican}^2} \text{KeyControl\_RandomX} be values sent to the ONU through PLOAM by the OLT.
  
  BC-ECMAC \def\pelican{\textrm{pelican}^2} \text{BC-ECMAC} as previously defined.
  
  BC-ECB \def\pelican{\textrm{pelican}^2} \text{BC-ECB} be BC \def\pelican{\textrm{pelican}^2} \text{BC} with the ECB cipher mode.
  
  EncryptionKey=BC-ECMAC(KEK,ONUKeyContrib&smidOLTKeyContrib,Tlen) \def\pelican{\textrm{pelican}^2} EncryptionKey = \text{BC-ECMAC}(KEK, \text{ONUKeyContrib}|\text{OLTKeyContrib}, Tlen)
  
  where
  
  OLTKeyContrib={BC-ECB&af(KEK,KeyControl_RandomX),Tlen=128BC- ECB&af(KEK,KeyControl_RandomX|KeyControl_RandomY),Tlen=256 \def\pelican{\textrm{pelican}^2} \text{OLTKeyContrib} = \begin{cases} \operatorname{BC-ECB}(KEK, \text{KeyControl\_RandomX}), & Tlen=128 \\[4pt] \operatorname{BC-ECB}(KEK, \text{KeyControl\_RandomX|KeyControl\_RandomY}), & Tlen=256 \end{cases}
  
  and
  
  ONUKeyContrib=ONU-generated random generated value of size Tlen \def\pelican{\textrm{pelican}^2} \text{ONUKeyContrib} = \text{ONU-generated random generated value of size Tlen}
  A secure random number generator must be used.
  However, the key is still generated on the ONU side, sent encrypted to the OLT and used as-is. Thus, it seems that the ONU can still hardcode a key or ignore the OLT's contribution, and is responsible for the key strength more generally. But the ONU can now use the OLT entropy pool to increase the data encryption key strength.
  
  Finally, for XG-PON and above, the data encryption key is sent encrypted to the OLT, using the chosen block cipher in ECB mode and KEK \def\pelican{\textrm{pelican}^2} KEK as key. For GPON, MSK \def\pelican{\textrm{pelican}^2} MSK is used instead of KEK \def\pelican{\textrm{pelican}^2} KEK, and encryption of the data encryption key not mandatory.
  
  Encryption of the data encryption key
  
  For GPON Encrypted EncryptionKey=AES-128-ECB&af(MSK,Encryption Key), \def\pelican{\textrm{pelican}^2} \text{Encrypted EncryptionKey} = \operatorname{AES-128-ECB}(MSK, \text{Encryption Key}),
  
  For XG-PON and above Encrypted EncryptionKey=BC-ECB&af(KEK,Encryption Key), \def\pelican{\textrm{pelican}^2} \text{Encrypted EncryptionKey} = \operatorname{BC-ECB}(KEK, \text{Encryption Key}),
  where BC=AES−128 \def\pelican{\textrm{pelican}^2} BC = AES-128 for XG(S)-PON and NG-PON2.
  
  XG(S)-PON, NG-PON2 and 50G-PON also allow the use of a multicast data encryption key which is generated on the OLT and allows a frame to be encrypted once so that it can be decrypted by multiple ONUs.
  
  Enabling encryption
  
  Encryption is mostly disabled by default for all PON versions.
  
  For GPON, the encryption of a GEM port is activated through PLOAM, and only the downstream frames are encrypted. For XG-PON and above, the default XGEM port which is used for OMCI is always set for bidirectional unicast encryption, other XGEM ports must be provisioned (unicast/multicast, direction of the encryption, etc). However, the encryption of the frame is still enabled by the Key_index field in the frame header, although the XG-PON specification does mention that it must be done "within the explicitly configured or pre-defined capabilities of the associated XGEM port".
  
  Enabling encryption decision diagram
  
  For the encryption of the OMCI messages (on the OMCC channel), no OMCI Management Entity needs to be configured. For XG-PON and above, ITU-T G.98815 mentions that "If the GEM frame itself contains an encryption key index, it is understood to refer to the unicast key and to require encryption both up- and downstream." and the XG(S)-PON and above specifications say "Whenever the default XGEM port traffic is encrypted in the downstream direction, the ONU is expected to encrypt the default XGEM port traffic upstream". One interpretation of that last quote could imply that an unencrypted frame can be sent to the default (OMCI) XGEM port, which slightly contradicts the ITU-T G.988 specification.
  
  Implementers should make sure that the Key_index value of a specific frame matches the configuration of the XGEM port.
  
  PLOAM messages and OMCI Management Entities relevant to security features
  
  There are a few PLOAM messages and OMCI Management Entities related to security features that are scattered in the specifications. Annex B: PLOAM and OMCI security-related messages can be used as a reference and might be useful for the next section.
  
  Encrypted communications
  
  Finally! We've identified the ONU, passed the authentication process, established an MSK , derived the keys, generated a random data encryption key and sent it encrypted to the OLT, we've enabled the encryption on the (X)GEM port, set the right fields in the (X)GEM header, authenticated the OMCI and PLOAM messages (unless GPON), and at last we can send our encrypted message!
  
  Block cipher and CTR mode
  
  First of all, only the payload of the X(GEM) frame is encrypted, not the X(GEM) header.
  
  The default encryption method is AES-128-CTR (AES-128 with the counter mode of operation specified in NIST SP 800-38A22) and it must be supported by both the ONU and the OLT. In addition to AES-128, 50G-PON (ITU-T G.9804.217) must also support AES-256. However, for 50G-PON, the OMCI "ONU2-G" Management Entity can advertise and enable support for other block ciphers: Camellia-128, Camellia-256 and SM4-128.
  
  While technically, the NIST SP 800-38A22 "assumes that a FIPS-approved symmetric key block cipher algorithm has been chosen as the underlying algorithm", and Camellia and SM4 are not NIST- approved, the same counter mode is used for all block ciphers.
  
  Even though CTR is a strong encryption mode, it does not provide authentication, which means an attacker can blindly modify the encrypted payload. Other protocols such as TLS 1.3 use AEAD (Authenticated encryption with additional data) modes to provide both encryption and authentication of the main payload, as well as authentication of additional data that must stay visible (a header for instance).
  
  The Counter
  
  The counter is reset at the start of each (X)GEM frame, and its initial value is called Initial Counter Block in XG-PON and later but this designation works for GPON as well. It is then increased by one after each 16-byte block inside the (X)GEM frame.
  
  The Initial Counter Block is a function of the SFC which is sent by the OLT and the Intraframe counter (IFC). The IFC is reset to 0 at the start of each FS frame, increased every 4 bytes for GPON and every 16 bytes for XG-PON and later. The IFC value used in the Initial Counter Block calculation is the IFC value at the first byte of the GEM header for GPON, and at the position of the first four bytes for XG-PON and later (XGEM frames are aligned on a 4-byte boundary).
  
  The figures below represent the SFC , IFC and how (X)GEM frames are encrypted for downstream GPON and XG-PON (and above).
  
  Encryption of a downstream (GPON) GEM frame
  
  Encryption of a downstream XGEM frame
  Duplicated counter blocks
  
  The XG-PON specification and above mention two SFC values which lead to duplicated counter blocks in both directions:
  
  For XG(S)-PON and NG-PON2: SFC(49..0)=0b1(0)49 \def\pelican{\textrm{pelican}^2} SFC(49..0)=0b1(0){49} and SFC(49..0)=0b0(1)49 \def\pelican{\textrm{pelican}^2} SFC(49..0)=0b0(1){49}. According to the specifications, the duplicated counter blocks appear for 250μs once every 4000 years. SFC(49..0) \def\pelican{\textrm{pelican}^2} SFC(49..0) is used, as one of the 51 bits of SFC is dropped before the counter calculation.
  
  For HSP/50G-PON: SFC(47..0)=0b1(0)47 \def\pelican{\textrm{pelican}^2} SFC(47..0)=0b1(0){47} and SFC(47..0)=0b0(1)47 \def\pelican{\textrm{pelican}^2} SFC(47..0)=0b0(1){47}. According to the specification, the duplicated counter blocks appear for 100μs once every 1000 years. SFC(47..0) \def\pelican{\textrm{pelican}^2} SFC(47..0) is used, as three of the 51 bits of SFC are dropped before the counter calculation.
  
  where SFC(x..y) \def\pelican{\textrm{pelican}^2} SFC(x..y) represents SFC \def\pelican{\textrm{pelican}^2} SFC's bits x to y (included) in that order.
  
  To mitigate this issue, the specifications recommend initialising SFC to a small value.
  As for the upstream payloads, GPON does not encrypt them. For XG-PON and above, upstream frames can be encrypted, when they are the operation is very similar to the encryption of downstream frames.
  
  The main difference is how IFC is calculated: instead of starting at 0 \def\pelican{\textrm{pelican}^2} 0, IFC starts with a value derived from the StartTime at which the upstream burst is sent. This way, IFC is unique for each Alloc-ID.
  
  Reduced data encryption strength: why?
  
  All the ITU-T PON specifications discussed specify the use of data encryption keys with "reduced effective length".
  
  Instead of generating a 128-bit encryption key, an ONU may generate a key of size Leff \def\pelican{\textrm{pelican}^2} L_{eff} bits where Leff \def\pelican{\textrm{pelican}^2} L_{eff} is a multiple of 8, filling the remaining most significant bytes with 0x55 \def\pelican{\textrm{pelican}^2} 0x55.
  
  Leff \def\pelican{\textrm{pelican}^2} L_{eff} can be reported through the OMCI "Enhanced security control" Management Entity and the "Effective key length" attribute, but it is optional.
  
  While this provision was probably in place to support older devices, it is odd that it is still present in newer specifications that require more capable devices.
  
  Bringing it all together: ONU initialisation and key switching
  
  While we have all the bricks to authenticate and encrypt secure channels between ONUs and OLTs, timing is important: some authentication methods are not available right away, keys are renewed regularly (key switching) or must transition from one authentication method to another, etc.
  
  The diagram below presents the key events of an XG-PON ONU from power-up to the establishment of a secure data channel, highlighting the transitions between authentication schemes. Note that this is a "happy path" scenario; it is designed to demonstrate the integration of the security mechanisms discussed in this post rather than provide an exhaustive state-machine analysis of the full specification.
  
  On the left of the diagram are represented the approximate ONU and key management states that are used in state-machines in the specification; not all events are displayed and some are simplified.
  
  XG-PON timeline for power-up to secure channel
  
  The data encryption key should be regularly regenerated by the ONU on the OLT's request; however, the renewal frequency is at the OLT's discretion.
  
  During key renewal, all PON specifications implement measures to ensure only valid keys are used and the link is not left broken. For GPON, the OLT simply sends a superframe counter value to the ONU, at which the new key will be used. For XG-PON and above, the process is more complex and involves timers and state machines. While the XG-PON and later specifications mention two ONU timers (the "ONU key exchange waiting timer" and "Key Ack waiting timer"), the ITU-T Supplement 8120 deprecates them "the ONT-side timers are deprecated", leaving timeout management to the OLT.
  
  Conclusion
  
  ITU-T PON specifications implement link-level encryption and authentication between OLTs and ONUs to protect against eavesdropping, data theft, and impersonation. However, there are many choices to make and steps to follow, and the specifications do not always have a "secure by default" approach.
  
  GPON, as the oldest PON specification in this blog post, offers the most limited security: downstream-only encryption and optional OMCI-based authentication. Without OMCI authentication, unicast data encryption keys are transmitted unencrypted to the OLT.
  
  XG-PON and newer PON specifications (XGS-PON, NG-PON2, 50G-PON) mandate authentication and support bidirectional encryption. However, the Registration ID-based scheme will use a default null string if not provisioned: while the resulting secure channel will be authenticated and encrypted, it will be based on a known secret, which defeats the purpose of the secure channel. Only the IEEE 801.2X-based scheme with the right EAP mode (such as EAP-TLS with a Diffie-Hellman key exchange) can support Perfect Forward Secrecy (PFS), preventing "harvest now, decrypt later" attacks.
  
  For all PON versions, encryption is usually disabled by default. Only the OMCI XGEM port is always encrypted in both directions for XG-PON and above.
  
  Then, a block cipher (usually AES-128) is used in CTR mode for the actual encryption of the (X)GEM payloads. The CTR mode does not provide authentication of the payload, which means an attacker can blindly modify the ciphertext without being detected. AEAD modes, which are the only modes supported by TLS 1.3 for instance, provide both encryption and authentication of the payload simultaneously.
  
  A somewhat new evolution in the PON specifications is the support of 256-bit block ciphers by the Higher Speed PON (HSP)/50G-PON specifications. 50G-PON now mandates the support of 256-bit keys, and generalises the use of ciphers of this key size. While we do not make any conclusions on the specifications' resilience against quantum cryptography, 256-bit AES keys are recommended by multiple agencies' post-quantum cryptography notes26 27 as a measure against Grover's algorithm. ITU-T Supplement 8120 recommends using HMAC-SHA-256 in the OMCI-based authentication scheme for quantum-resistance.
  
  50G-PON also changes how the unicast data encryption key is generated by including an OLT-generated value. However, the key is still generated on the ONU's side and sent to the OLT, unlike a Diffie-Hellman key exchange for instance, where the shared secret is at least guaranteed to include each sides' secret.
  
  Moreover, 50G-PON still includes a section relative to "reduced data encryption strength", which has carried on across PON specifications since GPON. It is unclear why such a provision is still necessary when 256-bit keys have been introduced.
  
  Finally, while we did go through a lot of PON security threats and features, there are other concerns that we did not discuss. The ITU-T specifications and supplements also mention "rogue ONUs", ONUs that do not behave according to the specification, and how to protect against them. Cloned ONUs, attacks against OMCI Management Entities, are other subjects we did not tackle.
  
  Acknowledgments
  
  I would like to thank my colleagues Angele Bossuat and Celian Glenaz for their review, as well as all other reviewers of this blog post!
  
  Further reading
  References
  1. R. Rousseau, "Avec le 50G-PON, Orange propose une experience inedite en France et demontre la prouesse de la fibre du futur," Newsroom Groupe Orange. Available: https://newsroom.orange.com/?p=60059. &larrhk
  2. ITU-T G.984.1 (03/2008) - Gigabit-capable passive optical networks (GPON): General characteristics &larrhk
  3. ITU-T G.984.2 (08/2019) - Gigabit-capable Passive Optical Networks (G-PON): Physical Media Dependent (PMD) layer specification &larrhk
  4. ITU-T G.984.3 (2014) Amd. 2 (11/2025) - Gigabit-capable passive optical networks (G-PON): Transmission convergence layer specification &larrhk &larrhk &larrhk
  5. ITU-T G.984.4 (02/2008) - Gigabit-capable passive optical networks (G-PON): ONT management and control interface specification &larrhk
  6. ITU-T G.987 (06/2012) - 10-Gigabit-capable passive optical network (XG-PON) systems: Definitions, abbreviations and acronyms &larrhk
  7. ITU-T G.987.1 (2016) Cor. 1 (03/2020) - 10-Gigabit-capable passive optical networks (XG-PON): General requirements &larrhk
  8. ITU-T G.987.2 (2023) Amd. 1 (06/2023) - 10-Gigabit-capable passive optical networks (XG-PON): Physical media dependent (PMD) layer specification &larrhk
  9. ITU-T G.987.3 (05/2025) - 10-Gigabit-capable passive optical networks (XG-PON): Transmission convergence (TC) layer specification &larrhk &larrhk &larrhk &larrhk &larrhk &larrhk &larrhk
  10. ITU-T G.9807.1 (2023) Amd. 1 (05/2025) - 10-Gigabit-capable symmetric passive optical network (XGS-PON) &larrhk &larrhk
  11. ITU-T G.989 (10/2015) - 40-Gigabit-capable passive optical networks (NG-PON2): Definitions, abbreviations and acronyms &larrhk
  12. ITU-T G.989.1 (03/2013) - 40-Gigabit-capable passive optical networks (NG-PON2): General requirements &larrhk
  13. ITU-T G.989.2 (2019) Amd. 1 (10/2020) - 40-Gigabit-capable passive optical networks 2 (NG-PON2): Physical media dependent (PMD) layer specification &larrhk
  14. ITU-T G.989.3 (2021) Amd. 2 (05/2025) - 40-Gigabit-capable passive optical networks (NG-PON2): Transmission convergence layer specification &larrhk &larrhk &larrhk &larrhk
  15. ITU-T G.988 (2022) Amd. 2 (05/2025) - ONU management and control interface (OMCI) specification &larrhk &larrhk &larrhk &larrhk
  16. ITU-T G.9804.1 (2019) Amd. 3 (05/2025): Higher speed passive optical networks - Requirements &larrhk
  17. ITU-T G.9804.2 (2021) Amd. 3 (11/2025): Higher speed passive optical networks - Common transmission convergence layer specification &larrhk &larrhk &larrhk &larrhk &larrhk
  18. ITU-T G.9804.3 (2021) Amd. 3 (02/2026): 50-Gigabit-capable passive optical networks (50G-PON): Physical media dependent (PMD) layer specification &larrhk
  19. ITU-T G.9805 (2022) Amd. 2 (11/2025) : Coexistence of passive optical network systems &larrhk
  20. G Suppl. 81 (ex G Suppl.PONsec) - Practical aspects of PON security - Revision 1 &larrhk &larrhk &larrhk
  21. "GPON - OMCI MIB [O3 Labs]." Available: https://www.tripleoxygen.net/wiki/misc/gpon/omci-mib#privados &larrhk
  22. M. J. Dworkin, "Recommendation for block cipher modes of operation : methods and techniques," National Institute of Standards and Technology, Gaithersburg, MD, NIST SP 800-38a, 2001. doi: 10.6028/NIST.SP.800-38a. &larrhk &larrhk
  23. J. Vollbrecht, J. D. Carlson, L. Blunk, B. D. Aboba, and H. Levkowetz, "Extensible Authentication Protocol (EAP)," Internet Engineering Task Force, Request for Comments RFC 3748, Jun. 2004. doi: 10.17487/RFC3748. &larrhk &larrhk
  24. C. Clancy and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method," Internet Engineering Task Force, Request for Comments RFC 5433, Feb. 2009. doi: 10.17487/RFC5433. &larrhk
  25. D. Simon, R. Hurst, and B. D. Aboba, "The EAP-TLS Authentication Protocol," Internet Engineering Task Force, Request for Comments RFC 5216, Mar. 2008. doi: 10.17487/RFC5216. &larrhk
  26. "ANSSI views on the Post-Quantum Cryptography transition". Available: https://messervices.cyber.gouv.fr/guides/en-anssi-views-post-quantum-cryptography-transition &larrhk
  27. "Post-Quantum Cryptography: Current state and quantum mitigation | ENISA.". Available: https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation &larrhk
3. 🔗 exe.dev Mayfly Chat: Transient Chat for Agents rss
  
  Earlier this week I caught myself copy/pasting code between two agents.
  
  I don’t want to be a meat proxy, but it really was going to be best if they just…talked to each other. And yet it was weirdly hard to arrange that.
  
  So I summoned Mayfly Chat.
  
  There’s not much to it. It provides transient chat channels for agents. You click “New Channel” and then give the URL to your agents, and then they can chat there. You can watch or chime in if you want.
  
  Use Cases
  
  The instant I had my first prototype up I suddenly had a dozen use cases.
  
  For example, on one of my systems, I had an agent rearranging some dotfiles and doing some configuration, and I wanted the same thing to be replicated on another of my computers, which had a somewhat different base configuration. Instead of having to figure out how to systematize it, which was really not worth the time, I started a new agent on the second machine and asked the first agent to guide it on what the new configuration should look like. Communicating over Mayfly Chat, the two agents worked together to adapt the setup to the shape of the second machine in a way that would have been pretty tedious to do through scripting.
  
  Later, I found that some code that I had developed on one machine needed specialized access to a service conveniently available from a VM. No problem. Spin up a second agent on the VM, get them both in a chat, give them both their brief, and let them work it out together.
  
  It's like having a subagent, only the subagent runs anywhere you like.
  
  Mayfly Chat supports having a large number of participants. Farming out a task to a little swarm? Ensure they all have the channel URL up front, and watch them sort it out together.
  
  Yet another use case: I started an agent on a little server in my house but had to step away from my LAN. I wanted to keep communicating with it from my phone, so I set up a channel and used that.
  
  Yes, most of these use cases would be obviated by better planning. Sounds nice. But also…hahahahahahaha.
  
  Oh, and of course, agents can create Mayfly Chat channels too. What could go wrong.
  
  Security
  
  The hardest design aspect was the security and privacy model. My initial prototype sent everything in cleartext with simple curl commands.
  
  It was easy to use and easy to explain, and it just worked. And if you completely control all access to the server, that's fine. But I wanted to be able to stand this up as a public service for folks who wanted to kick the tires or just plain didn't want to run their own.
  
  I didn't want anybody else's readable data anywhere near my VM, which meant end-to-end encryption was a hard requirement.
  
  Of course, end-to-end encryption requires that the client actually do some real work, not just send a curl command. And I wanted using Mayfly Chat to involve no setup for the human and no thick client libraries. The whole point was to be lightweight.
  
  The solution: Hand the agents a small script that they could use to do the end-to-end encryption. This should terrify you. Wait, you say. Your server is going to solve its security problem by handing out code to my agents? Yes. Yes it is.
  
  There is already a variant of this problem with any browser-based end-to-end encryption. The server serves you the JavaScript that you feed your data into, and the server can just send you different JavaScript. Our world fundamentally runs on trust, and anyone who says otherwise is trying to sell you cryptocurrencies.
  
  (Remember: end-to-end encryption here is solving my problem of not wanting to have your data. To solve your problem, namely having to trust the server, you can and should run your own. It is open source! I made it intentionally easy to deploy. You might even choose to deploy it on exe.dev. But failing that, you may also decide to just trust me.)
  
  The alternative to these scripts was to describe the protocol in detail and make every single agent re-implement their own client. For something that is supposed to be speedy and disposable, that was going to be too slow and token- hungry.
  
  So I selected an end-to-end encryption scheme that was as small and lightweight as possible, so that the actual scripts are extremely auditable, including by the agents grabbing them. Will the agents actually audit it? I dunno, probably not. But in principle they should be able to readily spin off a subagent, glance at a very moderate amount of mundane code, and convince themselves readily that it is not malicious and does exactly what it says on the tin.
  
  This requirement precluded fancier forms of encryption like, say, the Signal protocol. I'm still not super happy about it, but between the Scylla of clear text and the Charybdis of client support, I will take the client support. I had hoped that there were existing widely distributed unix tools that could be chained together to accomplish what I wanted, but I couldn't find any. (If you know of some, please let me know, and I will happily retrofit them in!)
  
  Another tricky question was permissions boundaries. For example, if an agent joins the conversation late, should it be able to see the history of all the messages to date or only the new ones? I eventually realized that it didn’t matter. Anyone who joins the conversation late can simply ask one of the agents to catch them up on everything that happened so far, and that agent will happily comply.
  
  By far, the best thing to do in this scenario is to have a very simple, very honest mental model, which is: once you have the URL, you have root. Every client is equally privileged. Every client can read everything. It can post; it can lie about its identity; it can delete the thread. Anything else is theater, and this model is easy to reason about.
  
  The last sticky point was metadata. It’s always metadata. And I basically punted. The server has metadata. And more than that, I made one conscious decision to store and forward client IP addresses. The server is in a unique position to have unspoofable knowledge of the IP address, unlike the data. By forwarding it along, if an agent suddenly has a different IP address, there is at least a little chance that one of the other agents might notice. And if you notice, you can at least assess, is that IP address a plausible one? On balance, I felt that the value to the user of the service warranted having the IP address stored in the clear alongside the other metadata.
  
  I'm sure that other people would make different choices about security and privacy than I would. That's fine. Code is cheap now.
  
  I have shared the idea with you. Go forth and make your own transient chat that matches your exact needs. Fork Mayfly Chat if you feel like, or start from scratch. And if you just want to use the hosted version https://mayfly.chat/, it's at your disposal.
4. 🔗 anthropics/claude-code v2.1.273 release
  What's changed
  - Added x-claude-code-request-class, x-claude-code-agent-type, x-claude-code-prev-tool-durations, x-claude-code-compaction and x-claude-code-context-compacted request headers for LLM gateways; opt in with CLAUDE_CODE_GATEWAY_HINT_HEADERS=1
  - Added a notification when an MCP server disconnects mid-session and automatic reconnection gives up, pointing at /mcp
  - Added forking a session started with claude --remote-control or /remote-control from the Claude app; the fork runs as a background session on your computer
  - Fixed Bash commands the permission checker cannot fully analyze skipping the prompt under permissions.blockReadsOutsideWorkingDirectories, and a subshell hiding a dangerous rm in bypass mode
  - Fixed skills synced from claude.ai staying available after your organization turns Skills off; they now move to the recoverable trash
  - Fixed allowManagedMcpServersOnly, deniedMcpServers and disableClaudeAiConnectors set via MDM or managed-settings.json being ignored when server-managed settings are also present
  - Fixed 401/403 errors on Bedrock, Vertex and Foundry, and Claude apps gateway 403s, telling you to run /login; the message now names the credential to refresh or points to your gateway administrator
  - Fixed /login, /upgrade, and /extra-usage discarding earlier thinking from the conversation, which forced a full prompt-cache rewrite on the next request
  - Fixed auto mode stopping for approval when the Artifact tool uploads a file you attached to the chat in a cloud or Remote Control session
  - Fixed a long-running session recreating a stub .git/info/exclude after the repository's .git directory was removed or moved away
  - Fixed the main prompt dropping a ! typed at the start while already in shell mode, so negated commands like ! grep … can be typed
  - Fixed Read on macOS refusing a dragged-in screenshot, or any file the system reports under a second path, with "symlink resolution changed after permission was checked"
  - Fixed permissions.blockReadsOutsideWorkingDirectories: a memory directory chosen by a repository's settings is no longer loaded into the prompt, recalled, indexed, or used by memory extraction
  - Fixed sub-agents and background agents being reported as failed, with their result never delivered, when the final streamed reply omitted token usage or carried no model id
  - Fixed the context meter and auto-compact counting advisor-tool turns at roughly twice their real context size, which made auto-compact fire at about half the real window
  - Fixed /tui refusing to restart because of an agent-team teammate that had already finished its work and was no longer shown in the agents panel
  - Fixed saved scheduled tasks running in the wrong session after .claude/scheduled_tasks.json was copied into another folder, such as a new worktree
  - Fixed SDK and --output-format stream-json output dropping a subagent's remaining messages and final report after it is moved to the background mid-run (e.g. by CLAUDE_AUTO_BACKGROUND_TASKS)
  - Fixed /install-github-app reporting a SAML single sign-on block as "admin permissions required"
  - Fixed Remote Control clients attached to a Claude Desktop, VS Code or JetBrains session being refused when they ask for the session's context window usage
  - Fixed the spinner showing a doubled ellipsis ("……") on compaction status lines such as "Running PreCompact hooks…"
  - Fixed a false-positive spinner tip suggesting the frontend-design plugin after reading or publishing Artifacts
  - Reverted a 2.1.268 change that checked Read and Edit deny rules on Bash lines the permission checker can't analyze (eval, env -C); commands like time -p make build prompt again instead of being denied
  - Improved responsiveness in long sessions: hook progress and sub-agent activity no longer re-process the whole conversation on every update
  - Improved the Artifact tool's error when a publish includes a file type artifacts don't serve: Claude is told which types are served and what to do instead, and the terminal shows one plain line
  - Improved the Artifact tool's page read to state the capabilities and database rules the artifact service holds for the page, for anyone who can publish to it
  - Improved artifact database writes: an update can now remove a single field instead of rewriting the whole document
  - Improved artifact publishing: a publish whose connection drops after reaching claude.ai is now re-sent safely instead of failing or creating a duplicate version
  - Improved the cloud-session GitHub error for an IP allow list, a suspended app installation or SAML single sign-on to show the cause instead of a generic install hint
  - Improved /autofix-pr: when gh pr view fails it now shows gh's own error (sign-in, SAML, rate limit) instead of a generic exit-code line
  - Improved /autofix-pr to say why GitHub webhook delivery couldn't be set up for the PR (for example, no linked GitHub account) instead of a generic warning
  - Improved /web-setup errors: a refused GitHub token now lists the likely reasons and the fix, and a connection failure names a configured proxy or TLS certificate problem
  - Improved the in-session SSL certificate and proxy connection errors to name the error code and what to fix, such as NODE_EXTRA_CA_CERTS for an untrusted corporate CA
  - Improved the error when a cloud session can't be created because your Claude login expired or was revoked: it now tells you to run /login
  - Improved the error shown when an MCP server's sign-in expires mid-session to say how to re-authenticate (/mcp)
  - Changed auto mode on Bedrock, Vertex and Foundry to use the local classifier by default for now; set CLAUDE_CODE_AUTO_MODE_SERVER=1 to use the platform's server-side classifier
  - Changed OTEL_LOG_TOOL_DETAILS=1 to also include real agent, skill, plugin and MCP server names on cost and token metrics
  - Changed sign-in with a Claude account to also request access to your claude.ai plugins
  - Changed /bug and /feedback reports to include only model-behavior params (model, system prompt, tools) from the last API request, omitting request metadata and CLAUDE_CODE_EXTRA_BODY fields
  - [VSCode] Fixed "Report a problem" still appearing, and /bug / /feedback opening a report form, for organizations that have product feedback disabled
  - [VSCode] Fixed a red "Claude Code process exited with code 4294967295" banner appearing after completed turns on Windows
  - Windows: Improved the network-path permission check for UNC paths when a mapped network drive was added with --add-dir
  - [Claude Code on the web] Fixed routines losing access to an organization connector, and still calling the old one, after an admin removed and re-added that connector
  - [Claude Code on the web] Fixed creating a self-hosted environment from organization settings occasionally failing with a server error and leaving a half-created environment behind
  - [Claude Code on the web] Changed the admin "Share cloud sessions" setting to live under Data and privacy instead of the Claude Code page, where Data and privacy admins can also manage it
  - [Claude Code on the web] Added a "Discard unsaved changes?" confirmation before the New routine page or the Edit routine dialog throws away a routine name, prompt or edit you typed
  - [Claude Code on the web] Removed the full-page desktop-app download screen that new users without a cloud environment saw on Mac and Windows; they now go straight to setup
  - [Claude Code on the web] Improved the routine detail page: menu and rename in the breadcrumb, the on/off switch and Run now at the top, and run history beside the routine's settings
  - [Claude Tag] Fixed Claude going silent minutes after reinstalling the app when an Enterprise Grid was disconnected but one of its workspaces stayed connected
  - [Claude Tag] Fixed scheduled tasks set up in an organization-shared private Slack channel silently never posting; they now keep running in the thread they were created in
  - [Claude Tag] Fixed replying in an older Slack thread while Claude is mid-task sometimes restarting it from scratch and losing work it had not pushed yet
  - [Claude Tag] Fixed Claude occasionally dropping a message with an incorrect "couldn't find a Claude Code environment" notice right after your account token refreshed
  - [Claude Tag] Fixed AWS connections refusing region-less endpoints such as Budgets, Savings Plans, WAF Classic and Import/Export; Global Accelerator requests now sign correctly
  - [Claude Tag] Improved AWS connection failures: when a request can't be signed, such as a hostname with no region, Claude is told why and how to fix it instead of a bare error
  - [Claude Tag] Fixed OAuth client-credentials and JWT-bearer connections failing with providers that return a lowercase token type; requests now send the standard Bearer scheme
  - [Claude Tag] Fixed adding a channel manager being refused on Enterprise Grid shared channels, on channels where Claude hasn't been used yet, and on legacy private channels
  - [Claude Tag] Changed Claude to start watching related public channels on its own, such as an incident channel a conversation depends on, instead of only when asked
  - [Claude Tag] Fixed the admin Memory page not listing Slack channels Claude set up on its own even when they had saved memory; admins can now open, edit and delete that memory
  - [Code Review] Fixed merging the base branch into a PR whose earlier review listed "Additional findings" triggering a full re-review; these pushes now get the lighter follow-up review
  - [Code Review] Fixed a whole REVIEW.md being ignored because of an @-mention, a code span wrapped across lines, or a backticked HTML tag; only lines linking to changed files are withheld
  - [Code Review] Improved suggested fixes to say what the fix must keep working when other code depends on the behavior being changed
  - [Code Review] Improved review comments that point to a second affected location to state that location's issue in a full sentence instead of a cut-off stub
  - [Code Review] Fixed /ultrareview --post so a retry after a GitHub error posts the findings comment exactly once instead of never or twice; the comment now names the reviewed commit
  - [Code Review] Fixed empty or content-identical pushes being re-reviewed on GitHub repositories whose owner or name contains a capital letter; these pushes are now skipped
5. 🔗 Locklin on science Developing immunity to propaganda rss
  
  Propaganda is one of those things which has obviously improved in its execution over time. In part this is due to higher levels of education among the populace. Educated people are used to stuffing facts in their brains, and continue the habit after the formal education has ended. This is what propaganda is: stuffing unverified […]
6. 🔗 crmne/spotifast Spotifast 0.8.0 release
  0.8.0 introduces custom themes and automatic Omarchy theme updates. It is also the first release under the new name, Spotifast , at spotifast.rocks. Your existing native-package settings and sign-ins carry over. Flatpak users switch to the new application ID as described below.
  
  screenrecording-2026-09-15_11-13-29.mp4 screenrecording-2026-09-15_11-32-22.mp4
  
  New
  - Flatpak installs as Spotifast. The bundle now uses rocks.spotifast.Spotifast. Install it separately from the old ID, copy settings and history if wanted, and sign in again. The repackaged bundle contains the original 0.8.0 executable. Switching instructions. By @crmne.
  - Make the app match your desktop. Choose Light, Dark, Follow system, or a local JSON palette. On Omarchy, packaged installs set up the theme hook at first launch and follow theme changes automatically. Open the themes folder from Settings to add your own palettes. Themes change colors while preserving the familiar layout and fonts. By @jdubba1 and @crmne. (#392)
  - Install updates from inside the app. Download an update, then choose when to restart and install it. A failed installation restores the previous copy. By @coah80 and @crmne. (#383, #79)
  - macOS downloads are signed and notarized by Apple. Both Apple Silicon and Intel are included in the same download. By @crmne.
  - Middle-click to autoscroll on Windows. Move the pointer to scroll the current list; click or press Escape to stop. No setting is needed. By @zHeuzy2 and @crmne. (#112, #96)
  - Refresh a playlist from its three-dot menu. Reload its details and songs without leaving the page. By @AQS-DS and @crmne. (#397)
  - Find settings by typing their names. Settings search matches the visible controls. By @KartikeyaKotkar and @crmne. (#372)
  - Double-click a Library item to play it. Play an album or playlist straight from the sidebar. By @skorokithakis. (#391)
  - Drag all your selected songs together. Copy a selection into a playlist, drop into the open playlist, and scroll near list edges while dragging. By @sanketttt26 and @crmne. (#290)
  - Keep the Library in your preferred order. Sort choices persist, and Liked Songs can move with other Library items. By @crmne.
  - Control playback from the Windows taskbar preview. Play, pause and skip without bringing the window forward. By @Shipi1.
  - Search can use your personal Spotify app. The sign-in flow explains when a personal app is useful for Premium listeners. By @joshkat and @crmne. (#388)
  - Choose which recommendation shelves appear on Home. JSON settings can hide Made for you and Recommended for you independently. By @jdubba1 and @crmne. (#393, #134)
  Fixed
  - Shared-app playlists load through the playback session , with account-specific caches and complete song ordering. By @chagel and @crmne. (#271)
  - Playlist Play starts at the first available song with shuffle off. Sorted and filtered views keep their visible order, and the requested song appears immediately. By @crmne.
  - Repeated songs stay in the queue when adding a selection. Each selected occurrence is preserved. By @kevin9327. (#444)
  - Recent plays keep the right songs and ordering. Repeated short-song listens remain separate, each row starts its own song, and loading older history leaves newer Library plays at the top. By @kevin9327 and @crmne. (#421, #422, #445)
  - Long playlists and albums keep a full-length scrollbar. Jump to distant songs, with placeholders and Retry when a page cannot load. By @alexng353 and @crmne. (#384)
  - Queue and Lyrics retain their full height beside the toolbar. Search and update controls fit the available page width. By @luiscuellar31 and @crmne. (#386, #378)
  - Keyboard shortcuts respect text editing and modifiers. Arrow keys move the caret in focused fields, Queue shortcuts no longer quit the app, and the playing-album shortcut opens the album. By @kevin9327 and @crmne. (#415, #416)
  - Mixed-script and right-to-left titles fit more reliably. Fallback fonts align with Inter, long RTL titles end within their text area, and Yi artist names can use installed fonts. By @kveld9, @kevin9327 and @crmne. (#345, #340, #439)
  - Maximized windows restore correctly , and Windows checks mini-player positions against available monitors. By @luiscuellar31 and @crmne. (#396, #351)
  - Flatpak keeps settings and sign-ins after fully quitting. By @GusMartins499. (#370)
  - Spotify grants use the native credential store , with sign-in attempts isolated from older callbacks. By @crmne.
  - Playback tries other addresses when a connection stalls. Connection attempts have bounded timeouts. By @crmne. (#413)
  - Large playlist cache writes use less temporary memory , and bounded page caches preserve pending edits. By @Cleboost and @crmne. (#328, #320)
  - EPs are shown separately from singles , submenu icons align consistently, and malformed album dates or nested unpacked skins are handled correctly. By @luiscuellar31, @kveld9, @kevin9327 and @crmne. (#356, #295, #341, #337)
  - Linux packages declare the GUI libraries they need. DEB and RPM installation is checked on both architectures; Gentoo instructions are also available. By @aljazceru, @NikoMalik and @crmne. (#399, #389)
  Thanks
  
  @jdubba1, @coah80, @zHeuzy2, @AQS-DS, @KartikeyaKotkar, @skorokithakis, @sanketttt26, @Shipi1, @joshkat, @chagel, @kevin9327, @alexng353, @luiscuellar31, @kveld9, @GusMartins499, @Cleboost, @aljazceru, @NikoMalik, and everyone who reported and helped test these changes, including @juanre7.
  
  Full changelog : v0.7.1...v0.8.0
7. 🔗 HexRaysSA/plugin-repository commits sync repo: +4 releases, -2 releases rss
```
sync repo: +4 releases, -2 releases

## New releases
- [IDAssist](https://github.com/symgraph/idassist): 2.4.0
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.11.1
- [ida-settings-editor](https://github.com/williballenthin/ida-settings): 1.2.4
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.14.0

## Changes
- [IDAssist](https://github.com/symgraph/idassist):
  - removed version(s): 1.3.0
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - removed version(s): 0.3.2
```
8. 🔗 smol-machines/smolvm smolvm v1.16.1 release
  What's Changed
  - Speed up pack compression with bounded zstd workers by @BinSquare in #1243
  - Fix checkpoint restore port collisions and startup diagnostics by @BinSquare in #1248
  - Reuse cached image layers for offline exports by @BinSquare in #1244
  - Allow retrying machines after failed image pulls by @BinSquare in #1250
  - Fix exports from stopped branches by @BinSquare in #1251
  - Size the pack extraction cache from the disk instead of a fixed 5 GiB by @BinSquare in #1249
  - Bundle sparse branchable memory promotion by @BinSquare in #1252
  - cuda: expose VMM allocation APIs to PyTorch by @BinSquare in #1256
  - Stream checkpoint artifacts without redundant file passes by @BinSquare in #1253
  - Avoid redundant checkpoint RAM copies on Linux by @BinSquare in #1257
  - Keep packed image extraction out of metadata queries by @BinSquare in #1261
  - Quiesce guest storage before graceful shutdown by @BinSquare in #1260
  - Map shared image layers into export helpers by @BinSquare in #1258
  - Restore prepared checkpoints safely from the node cache by @BinSquare in #1259
  - Expose workload image in machine responses by @BinSquare in #1262
  - Clean up cancelled checkpoint captures by @BinSquare in #1263
  - Update rustls to address RustSec advisory by @BinSquare in #1268
  - Keep machines responsive and recoverable while checkpoints save by @BinSquare in #1269
  - Fix failures when restoring the same checkpoint concurrently by @BinSquare in #1272
  - Keep checkpoint restores isolated under private service permissions by @BinSquare in #1276
  - Avoid connection delays after restoring a machine by @BinSquare in #1273
  - Accept published-port connections without polling delays by @BinSquare in #1274
  - Complete partial writes when copying checkpoint disks by @BinSquare in #1277
  - Share immutable checkpoint disks between restored machines by @BinSquare in #1278
  - Prepare SmolVM v1.16.1 for release by @BinSquare in #1280
  Full Changelog : v1.16.0...v1.16.1
9. 🔗 r/LocalLLaMA Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF rss
  
  | it be like that submitted by /u/Every-Walrus
  [link] [comments]
  ---|---
10. 🔗 r/LocalLLaMA CrofAI "cheapest inference provider in the world" gets exposed as an OpenRouter wrapper, routing requests to smaller, cheaper models at up to 20x markup. CrofAI responds to Wire Fraud allegations by denying everything, then backtracking, then 3 hours later wiping their entire online presence rss
  Disclaimer: no AI was used whatsoever to write this post
  
  Cautionary tale about chasing cheap tokens.
  
  exposé: https://kendell.dev/blog/crofaifalse/
  
  reaction by nahcrof, announcing the shutdown of the service: https://x.com/nahcrof/status/2099552389434900643 - now deleted, archive picture: https://i.imgur.com/teOQngH.png
  
  NahCrofAI (crof.ai, nahcrof.com) was an inference provider which had all the latest models at the cheapest price, often significantly below the lowest alternative on OpenRouter. The owner claimed that they are running custom inference engines that allows them to offer tokens for dirt cheap, and other providers are suffering from "skill issues", that's why they are so expensive.
  
  In reality:
  - "CrofAI is an OpenRouter wrapper that silently routes to cheaper or weaker models than what you request"
  - For example, expensive models like kimi-k3 are sold at $2/$10 in/out, but instead routed to GLM 5.3 Flash via OpenRouter, representing a 13.3x multiple on input, and 20x multiple on output
  - CrofAI's "own model family" greg-2-ultra routes to GLM 5.2, greg-1-mini routes to Qwen 3.5 9B. greg-2-super, greg-1, greg-1-super routes to Kimi K2.7 Code. All of these at a significant markup compared to the actual model being served. CrofAI admits in DMs that his claims of the greg family being made by him is a lie.
  - The person investigating details the 5 different attempts by CrofAI at fixing their models being served via OpenRouter after given a heads-up and a lengthy grace period. In all 5 attempts, the only change CrofAI made was attempts to hide the fingerprints of OpenRouter, while still serving models through them
  - Other inconsistencies don't add up either: CrofAI claims to run Kimi K3 on RTX Pro 6000s rented via Vast. That model requires ~802GiB even at the lobotomy level quantization of Q2_K. The largest RTX PRO 6000 machine on Vast has only 8 of them, totaling 765GiB. He also claimed that for the purposes of "investigating" the "issue" of his API routing to OpenRouter, he will have deepseek-v4-flash-0731 running on his local DGX Spark. A Spark has 128GB memory, and is therefore unable to run that model.
  CrofAI responded to the exposé by announcing the shutting down of their service; after their failure to provide their own inference, they promise to provide one last thing: a refund to those asking.
  
  UPDATE
  
  UPDATE: around 4:30 AM UTC of Sept 15, the owner published a now-deleted blog post (archive image) writing under the fake pretense that it's his "team" authoring it, stating all of CrofAI founder's claims "were written under a lot of stress, and they described the situation as worse it was", and that a new team is taking over, with the service being resumed in 2 weeks.
  
  At the same time, the CrofAI twitter account was also supposedly "taken over" by the team, starting each twitter reply with "Hey, Nathan here", stating the founder is stepping back and a "team" is taking over everything. This fake pretense act only lasted a few hours, and scared either by the public not buying the Nth fake story of the pathological liar that CrofAI is, or by the public's replies reminding him that what he committed is numerous counts of wire fraud, he has now deleted all his online presence: nahcrof.com and crof.ai return 404, Twitter page is deleted, /r/CrofAI sub is now private.
  
  Here is another image of the owner admitting that he was defrauding customers for the entire 2 year operation of his service, then begging the investigator to help him cover his tracks and not expose him
  
  EDIT: Commenters pointed out that NahCrof is 4chan in reverse. The owner's Discord name was "Devious Flimflam". Flimlam is defined as "deception, fraud". Looks like it was a deliberate scam operation from the get-go, and the owner's age was among the many lies.
  
  I cannot stress this enough: if you bought any credits (even if you used them up) you are entitled to a full refund for every transaction as the victim of fraud. Open a chargeback with your bank for every transaction made. If you used their API, assume that everything was logged and is currently being mined for personal information and API keys to sell on the black markets. Rotate your keys, change passwords, get a new debit/credit card.
  
  submitted by /u/SorosAhaverom
  [link] [comments]
11. 🔗 anthropics/claude-code v2.1.272 release
  What's changed
  - Bug fixes and reliability improvements
12. 🔗 Servo Blog Your Donations at Work: One Year of Sponsored Servo Development rss
  Last September, the Servo project announced that long-time maintainer Josh Bowman-Matthews (@jdm) would work part-time on improving the Servo contributor experience, entirely funded by the monthly donations on OpenCollective and GitHub. In his own words, here is a look back over the past year!
  
  First of all, I am enormously grateful to everyone who financially supports Servo, as those donations have enabled me to devote significant time to a project that I care a lot about. Some highlights from that funded work that I’m proud of:
  - I nominated 8 newmaintainers
  - I reviewed 1150 pull requests
  - I filed 114 issues targeted at newer contributors (92% of them have been fixed)
  - I wrote new documentation about borrow hazards, experimental features, the AI policy, finding things to do, and fixing stable and intermittent test failures
  On top of that, I spent time diagnosing unexpected failures in others’ PRs and fixed numerous intermittent test failures that made merging PRs more difficult for everyone.
  
  A few pieces of work from this period that stand out to me:
  - supporting a large scale rewrite of Servo’s JS engine integration to address intermittent panics related to garbage collection—I reviewed lots of pull requests, but also filed many issues that enabled the work addressing the panics to be spread across many other contributors
  - getting tagged in to help understand test failures, uncovering our broken window.open behaviour, and eventually making a lot of flaky tests more stable
  - supporting another contributor’s grant proposal to work on Servo that was approved!
  This role I’ve carved out means a lot to me—I’ve found a healthy balance that allows me to spend time with my family as well as make meaningful contributions to Servo, and I get to spend a lot of time looking for ways to make the project more accessible for others. A big thank you to everybody supporting the project and my work; each individual monthly donation makes a big difference! I’m excited to see what’s possible in the coming year.

generated: September 18, 2026 at 22:55:07