Dev Breakfast · 2026-08-23

Good morning. Today's must-read is Rust Glancer—a Rust LSP one developer built in 4 months that uses two orders of magnitude less memory than rust-analyzer, endorsed by rust-analyzer's own author; also, Claude Code is reportedly running a quiet A/B test that lowers effort levels, and daily users should check whether they're in it.

A Rust LSP using two orders of magnitude less memory: Glancer makes 8GB machines viable again

A developer spent 4 months building Rust Glancer, an alternative to rust-analyzer that targets under 100MB of language-server memory, and it earned 392 points on HN. The weightiest endorsement comes from matklad, the author of rust-analyzer himself—he wrote a commentary post calling the project "incredibly cool", backed the "two orders of magnitude less RAM" claim, and admitted that rowan, the syntax-tree representation he chose for rust-analyzer, wasn't worth it: it optimized for the 1% incremental-editing case while sacrificing the 99% case of "thousands of dependencies that only need shallow analysis."

Glancer's core trade-off is giving up incremental computation for a "frozen analysis result invalidated on save"—analysis results can be offloaded to the filesystem and loaded into memory only when needed, with a nice side effect: restarting your editor doesn't require re-indexing. The author tested it on an 8GB 2020 MacBook Pro M1: full indexing in 9 seconds, actually faster than rust-analyzer on the same machine (14 seconds), with RAM staying under 100MB throughout.

Note that it's not a complete LSP yet: there are feature gaps and known bugs. But the daily operations—goto definition, hover, completions, inlay hints—already work, and the VS Code extension is installable today. Don't uninstall rust-analyzer yet, but keep an eye on this one.

💡 Chef's take: If you write Rust on an 8GB machine, install the extension today and try it; if memory isn't your problem, file away the "frozen analysis + on-demand loading" idea—it applies to any memory-hungry indexing tool.

Sources:

• Hello, world! (Rust Glancer project blog, 2026-08-19)
• matklad's commentary (2026-08-21)
• HN discussion (392 points)

OpenTelemetry is said to be struggling, with someone making a table detailing issues

A blog titled 'OTel isn’t going well, and I made a spreadsheet about it' sparked heated discussion on Hacker News (212 points, 108 comments). Author Mat Duggan didn't just complain empty-handed; he used a table to list item by item the specific shortcomings of OpenTelemetry in terms of specification evolution, SDK maturity, vendor support, etc. For teams in the process of selecting or already deeply integrated with OTel, this isn't just a 'know about it' news—it reminds you to examine whether your instrumentation solution is tied to an unstable intermediate state and whether you've left room for switching. Don't rush to overturn your existing architecture, but it's worth taking the time to read the original article and do a health check against your own usage scenarios.

💡 Chef's take: Dig out your project's OTel configuration, see which experimental APIs you're using, and mark a replacement plan for them.

Sources:

• OTel isn’t going well

MCP publishes a new roadmap: five priority areas set the protocol's course

The Model Context Protocol blog published an updated roadmap (The New MCP Roadmap) on August 22, developed by the Core Maintainers together with community Working Groups, covering the next specification release and the months beyond. It names five priority areas: agentic messaging primitives (server-initiated events via webhooks and channels so clients stop polling; maturing the Tasks extension SEP-2663 into the spec), HTTP-native transport unification and hardening (building on the 2026-07-28 release, so a remote MCP server deploys like any other HTTP workload), agent identity and enterprise-ready security (finalizing DPoP and identity delegation via Workload Identity Federation, replacing pasted API keys and long-lived tokens), improved primitives (one clear contract for tools/call results, plus progressive discovery so a hundred-tool server doesn't dump its whole catalog into context), and improved SDK developer experience. For anyone building MCP servers/clients, the cards are on the table: SEPs inside these five areas get expedited review, and the tool-result contract and auth are the parts most likely to change—don't weld your project to today's interface shapes.

💡 Chef's take: Count how many tools your MCP server exposes—past a few dozen, keep an eye on the progressive discovery work; it's there to save you tokens.

Sources:

• The New MCP Roadmap (official blog, 2026-08-22)

Codex trends again; and a correction on yesterday's Bedrock billing story

OpenAI's terminal coding agent Codex (open-sourced April 2025, 113k stars, latest release still an alpha) hit GitHub Trending again these past few days. A good occasion to correct yesterday's item claiming "10x billing on Bedrock, confirmed as a bug by OpenAI": what issue #37674 actually says is that Codex on Bedrock cannot opt into GPT-5.6 Sol's explicit prompt caching, causing agentic workloads to generate large volumes of cache-write tokens and materially higher cost. It's labeled an enhancement (a missing feature), not erroneous billing, and was closed on August 21. So there's no refund to wait for—those were real charges, rooted in missing cache controls. If you run Codex through Bedrock, what deserves your attention isn't billing anomalies but the share of cache-write tokens in your usage breakdown.

💡 Chef's take: Yesterday we relayed an enhancement as a "confirmed billing bug"; today we correct it against the issue itself. The lesson: an issue's label and title are always more trustworthy than the hot post that links to it.

Sources:

• openai/codex GitHub repository
• Issue #37674: Bedrock lacks explicit cache controls, producing high cache-write spend

Claude Code reportedly A/B testing: "high" effort executes as the old "low"

A user's analysis on X made it to the HN front page (157 points, 149 comments): starting with Claude Code 2.1.236+, Anthropic is reportedly enrolling some Fable 5 sessions server-side into an experiment that shrinks the effort scale—the "high" effort you set actually executes as the old scale's "low" (10/100); older versions and Opus 5 are unaffected, and the changelog says nothing. Effort level determines how much reasoning depth the model invests; shrinking it means faster and cheaper, but complex tasks become more prone to errors and shortcuts. The poster spent a whole afternoon convinced their own code was broken before realizing they were in the test group. Since it's an A/B test, not everyone is affected—but if "high" has recently felt like "low" to you, it may not be your imagination. Note this is a user-side observation; no official response yet.

💡 Chef's take: Explicitly raising effort won't help—the experiment changes the scale itself. If you suspect you're affected, check whether you're on 2.1.236+, then run the same task on an older version or Opus 5 as a control.

Sources:

• @argofowl's original post (2026-08-22)
• HN discussion (157 points)

macOS 27 deprecates hdiutil, image toolchain needs overhaul

Apple has officially marked hdiutil as deprecated in the macOS 27 Golden Gate beta, putting this command-line tool that has accompanied macOS for over twenty years on a countdown. hdiutil has long handled low-level operations such as disk image creation, mounting, signing, and conversion, and many CI scripts, installer creation workflows, and backup tools rely on it. The official replacement per the man page is the diskutil image subcommands (attach/create/resize/info all have counterparts), though not every option has an equivalent—for example -puppetstrings, the machine-parsable progress output, is gone. Deprecation means removal in a future release, so automation depending on hdiutil should be assessed for migration early, rather than discovering all image operations failing after a system update.

💡 Chef's take: Spend ten minutes today grepping your CI configuration and shell scripts, list where hdiutil appears, and assess migration costs.

Sources:

• hdiutil is deprecated in macOS 27 Golden Gate (2026-08-14)

sub2api: packages Claude/Gemini subscriptions into one API

sub2api, recently trending on GitHub (open-sourced in late 2025, 38k stars), focuses on converting subscription accounts of Claude, OpenAI, Gemini, and Grok into unified API interfaces, and also supports cost-sharing through pooling. In simple terms, if you have subscriptions but don't want to pay per-API usage fees, or if several people share an account, it helps convert subscription quotas into standard interfaces for existing tools to call directly. For coders, the temptation to save money is significant, but you need to be cautious: such relay services usually involve account sharing, with risks of violating platform terms, and stability and rate limits are in others' hands. If you're to use it in production environments, first test with small traffic, and don't stake core business on it.

💡 Chef's take: If you want to save money, you can start one locally for personal use, but don't use it as the API foundation for commercial projects; you'll bear the risk of account suspension and supply disruption.

Sources:

• GitHub Trending - Wei-Shaw/sub2api

---

Try installing Glancer today to feel what a 100MB Rust LSP is like, or go check your Claude Code version number. See you tomorrow morning.

This issue selected 7 items from a total of 42 pieces of information over the past 24 hours from X / Hacker News / GitHub Trending. Content is assisted by LLM, each with original source links; for important decisions, please cross-verify.