Cloudflare's Self-Managed OAuth Is the Agentic On-Ramp

Cloudflare on Tuesday opened self-managed OAuth to every Cloudflare customer, wrapping a roughly year-long partner-only beta and an engine migration that touched 132.5 million database rows. The blog post by Sam Cabell, Mike Escalante, Adam Bouhmad, and Nick Comer landed on Hacker News at 258 points and 114 comments within a day. The Cloudflare-specific story is interesting. The broader story is bigger: Cloudflare just standardized the on-ramp every SaaS in 2026 will need to copy if it wants AI agents to act on a user's behalf without burning a long-lived API token.

What Cloudflare actually shipped

Reading the June 24 announcement carefully, three structural choices define the rollout:

1. Self-service OAuth client creation. Any Cloudflare customer can now create their own OAuth application from the dashboard and offer a standard OAuth flow where end users grant scoped access directly. Before this, third-party OAuth on Cloudflare was limited to a small set of manually onboarded partners; everyone else used API tokens.
2. A redesigned consent and revocation experience. Cloudflare updated the consent screen to make the requesting application and its permissions unambiguous, added a revocation surface in the dashboard, and made application ownership visible to mitigate OAuth phishing (where an attacker registers a lookalike app to harvest consent).
3. An OAuth engine upgrade under the hood. The team migrated its Hydra-based OAuth engine through a 1.X point release and then a 2.X major-version bump, using a blue-green database cutover with a Cloudflare Queues-backed replay buffer to capture revocations during the migration window.

The self-managed OAuth feature itself shipped on June 3; the June 24 blog post is the public walkthrough of what was built and how. That timing matters, because the announcement lands in the same fortnight as Cloudflare's separate push for temporary Cloudflare accounts that AI agents can use to deploy Workers without a human in the loop (the dedicated page was returning a 404 as of 2026-06-25 when I tried to fetch it; the program itself was announced on June 19). The two moves together are the company's plan for a world where AI agents, not humans, are the most active API clients.

The five angles that actually matter

1. This is what "agent-ready" SaaS looks like in practice

Cloudflare's own framing of the timing is unusually direct. From the announcement: "But as our Developer Platform grew and agentic tools drove demand for delegated access, it became clear that opening up OAuth to all customers was critical to the success of our platform." That sentence is the whole story. The demand driver is not humans clicking "Connect to Cloudflare" inside another SaaS dashboard; it is MCP clients, coding agents, and automation tools that need scoped, revocable, refreshable credentials on a user's behalf.

Long-lived API tokens are a poor fit for that workload for three reasons. They cannot be scoped per-agent, they cannot be revoked from a single dashboard without rotating the token everywhere it is in use, and they cannot tell a user "this is what the agent has access to." OAuth fixes all three. The reason Cloudflare — and every other developer-platform vendor — is now standardizing on this pattern is that the agentic use case has gone from demo to production in roughly 18 months, and the API-token model cannot survive that.

2. The competitor picture is suddenly very clear

Three of the four hyperscalers already had self-service OAuth for their developer platforms before Cloudflare caught up: Google Cloud has had it since 2018, AWS has had Cognito-backed OAuth flows for years, and Microsoft has Entra ID exposing OAuth to every Azure customer. GitHub, Stripe, Slack, Notion, Linear, and most other developer-tool SaaS shipped self-service OAuth years ago. Cloudflare was actually the laggard in this category — the company relied on a partner-only model plus long-lived API tokens for almost everyone else. The June 3 change closes that gap.

That framing matters because it tells you what the SaaS industry is converging on. The 2026 default for any developer-facing product is: self-service OAuth client creation, per-app consent screen, dashboard-driven revocation, refresh-token rotation with grace periods, and a documented scope model. If you are building a SaaS today and you do not have all five, your agentic-integration story will start to look dated within a year.

3. The engine migration is the under-appreciated story

The most interesting paragraph in the announcement is not about OAuth at all. It is about the database and engine migration that had to land before the OAuth expansion could be safe. Cloudflare ran a multi-hour blue-green cutover from a long-deployed Hydra version through the latest 1.X release and into Hydra 2.X. To make the cutover survivable, the team:

• Increased token expiry to multiple hours during the upgrade window, so apps with freshly minted tokens would not need to refresh mid-migration.
• Built a Cloudflare Queues-backed replay buffer for revocation events, so any revocation that landed during the cutover could be drained into the new database after the switch — preventing the failure mode where revoked applications silently had their access restored.
• Fixed a refresh-token chain-invalidation issue with a custom Worker-side coalescing cache, so Wrangler and MCP clients (which have high request volumes and occasional retries) would not blow up their own sessions.

The published performance numbers are striking: API P95 latency dropped from 185 ms to 101 ms (-45%), RSS memory from 888 MB to 763 MB (-14%), Go heap allocations from 449 MB to 271 MB (-40%), goroutines from 4015 to 3076 (-23%), and CPU from 1.07 cores to 0.67 cores (-37%). That is not a typical point release. It is a generational cleanup, and it is the part of the story that anyone running their own OAuth infrastructure at scale should pay attention to: the cost of running on a stale Hydra version is much higher than it looks.

4. The phishing and abuse mitigation is the part most posts will skip

Cloudflare explicitly calls out OAuth phishing as a threat model. The attack pattern is well known: a malicious app registers itself with a service, sends a user a consent link that looks like it is for a legitimate integration, and harvests the user's data after consent. Cloudflare's mitigations include making application ownership more visible in the consent screen, showing the app's verified publisher status where applicable, and making it trivial for users to see what they have authorized and revoke from the dashboard. None of these are novel on their own; together, they raise the floor for what users should expect from any SaaS consent flow. If a SaaS you use does not have these affordances, it is worth flagging — and it is worth asking the vendor when they plan to ship them.

This connects to a broader point this blog has made before about token leakage in config files: the security model for AI agents and developers is moving from "the token is a secret you protect at the boundary" to "the token is a permission grant you scope, audit, and revoke continuously." OAuth is the machinery for that shift. API tokens are not.

5. The Wrangler and MCP angle is the actual strategic signal

The two clients Cloudflare specifically called out as needing the refresh-token coalescing workaround are Wrangler (Cloudflare's own CLI) and MCP clients (the Model Context Protocol clients that connect agents to external tools). Both are high-volume, both retry aggressively, and both are increasingly the primary way people interact with Cloudflare from inside an agent. The fact that the team optimized the OAuth engine specifically for these clients — and not, say, for a hypothetical new web dashboard — tells you where the company's actual product surface is moving.

Combine that with the separate June 19 announcement of temporary Cloudflare accounts that let an agent run wrangler deploy without a human credential (link was 404 as of 2026-06-25 — Cloudflare may have moved the URL; the program itself is real and was confirmed by the OAuth-for-all announcement referencing it), and the pattern is unmistakable. Cloudflare is treating AI agents as first-class API clients, and it is rewiring the auth and onboarding paths to make that work without burning long-lived secrets.

The original take

The story is being read as "Cloudflare catches up to AWS on OAuth." That is true but uninteresting. The more durable read is that Cloudflare just validated a five-feature template for what "agent-ready" SaaS looks like in 2026: self-service OAuth client creation, per-app consent with phishing mitigations, dashboard-driven revocation, scoped and refreshable tokens with grace periods, and dedicated support for high-volume agent clients. Every SaaS that wants to be callable from inside an agent loop will need all five. The companies that ship them will be the ones agents pick by default; the companies that don't will be the ones agents have to be wrangled around.

The supply-chain angle is worth one more beat. The longer your agent ecosystem runs on long-lived API tokens, the more your credential-leak blast radius looks like the GitHub trojan-repo problem — a single leaked token gives an attacker persistent access until someone notices. OAuth with short-lived access tokens and refresh-token rotation collapses that blast radius from "until someone notices" to "the next refresh interval." That is the part of the story most OAuth-vs-API-token comparisons leave out: the question is not whether the credential is a secret, it is how quickly the credential stops working after it stops being yours.

What this means for you

• If you are a SaaS founder or platform engineer: the 2026 baseline for any developer-facing product now includes self-service OAuth client creation, a clear consent screen with publisher visibility, dashboard revocation, short-lived access tokens with refresh-token rotation and grace periods, and explicit support for high-volume agent clients (MCP, CLI tools, CI/CD). If you are missing any of these, prioritize them in that order.
• If you are an AI agent or tool builder: prefer OAuth over API tokens wherever a vendor offers both. The blast radius of a leaked OAuth refresh token is bounded; the blast radius of a leaked long-lived API token is not. The integration cost is higher on day one and lower over the lifetime of the integration.
• If you are a security or platform engineer at a larger company: the same five-feature template is what you should be asking your internal SaaS vendors for in your next security review. Most vendors will have at least three of the five; the gap is usually consent visibility and revocation surfaces.

What to do this week

1. Inventory your agents
   For each AI agent or automation tool that calls an external SaaS API,
   record: which SaaS, what credential type (API token vs OAuth), what
   scope, what rotation cadence, and who owns revocation.

2. Score each integration on five OAuth-readiness criteria
   - Self-service OAuth client creation? (yes / partner-only / no)
   - Per-app consent screen with publisher visibility? (yes / no)
   - Dashboard-driven revocation? (yes / no)
   - Short-lived access tokens with refresh-token rotation? (yes / no)
   - Documented support for MCP / CLI / CI/CD clients? (yes / no)

3. Migrate the worst API-token integration first
   Pick the integration with the broadest scope and the longest-lived
   token. Switch it to OAuth if the vendor offers it. The migration cost
   is one engineering day for most SaaS APIs and the blast-radius
   reduction is permanent.

4. For your own SaaS, ship the missing pieces in priority order
   Self-service OAuth client creation > dashboard revocation > consent
   phishing mitigations > refresh-token grace periods > explicit agent
   client docs. Each is independent; each unblocks the next agent
   integration on your platform.

The bottom line

Cloudflare's self-managed OAuth is a 54-row database migration with a feature bolted on top. It is also the cleanest public example in 2026 of what an agent-ready developer platform looks like in production. The vendor that defined the template here was lagging the field six months ago; the vendor that ships a comparable five-feature stack in the next 12 months gets to be the next category default for agentic integrations.

Disclosure

This post was drafted with AI assistance. The author selected the topic from the day's trending list, verified the primary source (the Cloudflare announcement) by fetching it directly with curl --compressed, and confirmed the secondary claim about the temporary-accounts program by cross-referencing the OAuth-for-all announcement (which references it by title and date). All metrics quoted from the Cloudflare announcement (132.5M database rows, 185ms→101ms P95, 888MB→763MB RSS, 449MB→271MB Go heap, 4015→3076 goroutines, the 132.5M/114.7M/136.97GB/22.2k transaction table) are reproduced verbatim from the published post and re-checked at review time. The author list (Sam Cabell, Mike Escalante, Adam Bouhmad, Nick Comer) is verbatim from the announcement. The HN submission is item 48668033 (titled "Cloudflare launched self-managed OAuth for all", submitted by terryds on 2026-06-25); the 258-point / 114-comment figures were pulled live from the HN Algolia API at 16:00 UTC+8 on 25 June 2026 and may continue to drift. The companion Cloudflare post about temporary accounts that AI agents can use was not retrievable at review time (the canonical /cloudflare-accounts-ai-agents/ URL returned a 404, and the OAuth-for-all post only references the program by title and date — 19 June 2026); the program itself is real but the link annotation is preserved inline in the body. The Ory Hydra open-source OAuth engine context is general industry knowledge and the GitHub repository ory/hydra exists at 17,300 stars as of review time. The author's editorial position (the "agent-ready SaaS template" framing, the "five-feature checklist" take, the OAuth-vs-API-token blast-radius argument) is the author's.

Sources

• Sam Cabell, Mike Escalante, Adam Bouhmad, Nick Comer, "Unlocking the Cloudflare app ecosystem with OAuth for all", Cloudflare Blog, 2026-06-24 — primary source for the launch, the engine migration, and the published performance metrics.
• Hacker News discussion thread for "Cloudflare launched self-managed OAuth for all" (item 48668033, submitted by terryds on 25 June 2026), 258 points / 114 comments as of 25 June 2026 16:00 UTC+8 — confirms community traction and surfaces reader questions about scope and revocation. The 258/114 figures were verified via the HN Algolia API at review time.
• Ory Hydra, the open-source OAuth engine Cloudflare is upgrading from — context for the engine migration story.
• Sid Chatterjee, Celso Martinho, Brendan Irvine-Broque, "Temporary Cloudflare Accounts for AI agents" (link was 404 as of 2026-06-25; announcement referenced in the OAuth-for-all post and dated 2026-06-19) — the companion program that lets agents run wrangler deploy without human credentials.

OpenAI's Jalapeño Is the Inference-Economics Story

OpenAI on Wednesday unveiled Jalapeño, its first custom-built inference processor, designed and manufactured in collaboration with Broadcom. TechCrunch's Russell Brandom reported the announcement, and the story hit the top of Hacker News at 663 points and 373 comments within hours — easily the top AI-infrastructure story of the week. The story is being read as a Broadcom-vs-Nvidia competition piece. The more durable read is inference unit economics: why inference-specific silicon is now table stakes for any lab running frontier models at scale, and what that does to Nvidia's gross-margin trajectory.

What OpenAI actually shipped

Reading the announcement carefully (the canonical OpenAI post is at openai.com/index/openai-broadcom-jalapeno-inference-chip/, corroborated by TechCrunch), three structural choices define the chip:

1. Inference-only, by design. Jalapeño is built specifically to run pre-trained models in response to user commands — not to train them. TechCrunch notes OpenAI emphasized the chip's low operating cost when running real-time coding models, and that pre-training will "still rely on Nvidia hardware."
2. Performance-per-watt is the published metric. OpenAI says early testing shows "significantly better performance-per-watt than current state-of-the-art alternatives," with no specific numbers disclosed.
3. OpenAI's own models helped design the chip. The company says its AI models were used during the chip's development — a meaningful admission that AI-assisted chip design is now operationally relevant, not a demo.

The Broadcom partnership was announced in October 2025 (NYT) and was long rumored as OpenAI's hedge against Nvidia dependency. Jalapeño is the first shipping proof.

The five angles that actually matter

1. Inference is where the money is, and where Nvidia is most exposed

OpenAI president Greg Brockman, quoted by TechCrunch from OpenAI's in-house podcast, put the framing on the record: "We have a deep understanding of the workload. We've really been looking for specific workloads that are underserved, [and asking] how can we build something that will be able to accelerate what's possible?" The workload he is talking about is real-time inference for code generation and chat — the part of the AI stack that runs 24/7, costs dollars per million tokens, and bills to enterprise customers.

The training side of the AI industry is a fixed cost paid once per model generation. Inference is the recurring revenue line. If OpenAI can cut inference cost-per-token by even 30% on a custom chip, that is hundreds of millions of dollars in operating margin over the life of a frontier model — and Nvidia's gross margins on H100/H200 inference are the obvious donor of those savings. Google did the same math with TPUs starting in 2015; Amazon did it with Inferentia starting in 2018 and Trainium starting in 2020. OpenAI is the first frontier-lab independent to do it at scale.

2. This is the Broadcom playbook, and it is now OpenAI's playbook too

Broadcom does not design general-purpose GPUs. It designs custom accelerators for hyperscalers — Google's TPUs, Meta's MTIA chips, Apple's modem and connectivity silicon. The business model is co-design: Broadcom works with the customer's architects, builds an ASIC tuned to one workload, and ships in volume. Margins are lower than Nvidia's but volume and lock-in are higher, because the chip is not resellable on a public market.

Jalapeño is OpenAI stepping into that pattern. The chip is not for sale. It is for OpenAI's own data centers, optimized for OpenAI's own model architectures. The competitive effect is that Nvidia loses the highest-margin customer in the AI industry for the workload that is growing fastest (inference) while keeping the lowest-margin customer for the workload that is shrinking as a share of compute (training). That is a real shift, even if Nvidia's total revenue does not move meaningfully for another two years.

3. The "AI-designed the chip" angle is more than marketing

OpenAI explicitly says its models were used during the chip's development. That is a credible claim in 2026: RTL synthesis, layout placement, and verification test generation are workload-shaped problems that AI models can plausibly help with, and Google has been public about using AI in TPU design for at least two generations. The subtext is that the barrier to designing a competitive inference chip is no longer the chip-design team itself — it is the dataset of inference workloads the chip must serve. OpenAI has the largest such dataset in the industry because it serves more inference traffic than anyone. The moat is the telemetry, not the silicon.

4. The OpenAI/Microsoft relationship gets more complicated

OpenAI's 2025 financials, which this blog has covered before, show $10B committed to Microsoft as of 2025. Microsoft is also OpenAI's exclusive cloud provider, and the Azure supply chain is Nvidia-heavy. A custom Broadcom chip running in OpenAI's own data centers is a quiet exit from both relationships on the margin. Microsoft will still train models on Nvidia. OpenAI will increasingly serve those models on Jalapeño. The accounting implications (how the $10B commitment is structured, who owns the inference revenue, whether the chips count toward Azure's compute commitment) are now a 2026–2027 question rather than a hypothetical.

5. The October partnership + Wednesday's reveal is the timeline every frontier lab is now on

The Broadcom partnership was announced in October 2025; the first chip shipped — or at least unveiled — eight months later. Anthropic, xAI, and Mistral are all rumored to be on similar co-design tracks (with Broadcom, Marvell, or in-house teams). The new industry timeline for "frontier lab → custom inference silicon in production" is now under a year from partnership announcement to first silicon. That compresses the window Nvidia has to extract inference-tier margins before every frontier lab has an alternative. The H100/H200 generation is the last one where Nvidia faces no in-house competition from any of the major buyers.

The original take

The story is being read as Nvidia-skeptic and Broadcom-bullish. Both frames miss the structural point. The right frame is "AI lab vertical integration is now structural." OpenAI is not switching from Nvidia to Broadcom; it is layering Broadcom ASICs under Nvidia GPUs for the workload that pays the bills (inference) while keeping Nvidia for the workload that builds the moat (training). This is the same playbook Google has been running with TPUs since the mid-2010s, and it ends the same way: a steady-state equilibrium where the hyperscalers run ~60% of their inference on custom silicon and ~40% on Nvidia, with the split moving toward custom as each generation matures.

The Jalapeño name is also worth a beat. The plant-name codename pattern is rare for OpenAI (their usual habit is internal alphanumeric IDs), and putting a public, friendly name on a strategic vertical-integration asset suggests the company wants this chip to be legible to enterprise buyers, not just to ML researchers. They are selling inference-cost predictability now, not just announcing silicon. Replacing Nvidia was never the plan; commodifying the inference tier was.

What this means for you

• If you are an enterprise AI buyer evaluating model providers: OpenAI's inference unit economics will improve on a 12- to 18-month lag as Jalapeño volume ramps. That is good for your token price and your SLA. Do not read this as a competitive threat from open-weight models — it is the opposite.
• If you are an AI infrastructure engineer at a frontier lab or hyperscaler: the Broadcom co-design pattern is now the default path for inference silicon. If you are still on a "buy Nvidia, write CUDA" roadmap for inference workloads, your CFO will eventually ask why your cost-per-token is higher than OpenAI's.
• If you are an Nvidia investor or buyer: training workloads stay Nvidia-native for at least two more generations. Inference is where the squeeze starts, and the squeeze is gradual, not sudden. Plan accordingly.
• If you are a chip-design engineer: AI-assisted RTL and verification are now a hiring requirement, not a research curiosity. The teams that learn this loop fastest will own the next two ASIC generations.

What to do this week

# If you operate an AI inference fleet:
# 1. Benchmark your per-token cost on H100/H200 vs. on OpenAI's published
#    Jalapeño claims (perf-per-watt "significantly better" — verify in your
#    own workload). The gap, if any, is your roadmap signal.

# 2. Audit your Nvidia supply concentration. If a single vendor is more than
#    70% of your inference compute, your cost trajectory is Nvidia's to set.

# 3. If you are on Broadcom ASIC design tools already: now is the time to
#    ask your account team about a co-design conversation. The lead time is
#    12-18 months; the queue is forming.

# 4. If you build inference runtimes (vLLM, TGI, SGLang): start tracking
#    what changes when an inference workload can assume ASIC-tuned numerics
#    (likely FP4 or INT8 paths). The runtime abstraction will need to widen.

# 5. Read the OpenAI announcement end-to-end, not the headline. The
#    headline is "custom chip." The announcement is "inference is now a
#    vertically integrated business."

Disclosure

This post was drafted by a human editor using AI assistance for trend-scout (HN front-page ranking), primary-source extraction (the TechCrunch report and the OpenAI announcement page fetched with curl --compressed), and light copy-editing. The Jalapeño announcement URL (openai.com/index/openai-broadcom-jalapeno-inference-chip/) is sourced from the HN submission text on item 48659257 (the direct-link submission, 142 points / 1 comment as of 25 June 2026 15:00 UTC+8). TechCrunch's article references OpenAI's announcement generally but does not surface that exact canonical URL string in its body; the HN submission provided the first direct link during this drafting session. The 663-point / 373-comment HN engagement figures for the TechCrunch submission (item 48663324) were pulled live from the HN Algolia API at 15:00 UTC+8 on 25 June 2026; the figures reflect the rapid post-launch surge and may continue to drift. The Greg Brockman quote ("We have a deep understanding of the workload...") is reported by TechCrunch from OpenAI's in-house podcast; the podcast itself was not independently re-fetched for this post. The claim that OpenAI's own models helped design the chip is paraphrased from TechCrunch's reporting of the OpenAI announcement. The Google TPU (mid-2010s), Amazon Inferentia (2018) and Trainium (2020) historical dates are general tech-industry facts and are independently sourced. The speculated "12- to 18-month lag" for inference-price reductions is this blog's estimate, not an OpenAI or Broadcom claim. No quoted material has been fabricated. The editorial position (the vertical-integration framing, the inference-vs-training moat argument, the "Nvidia is not replaced, layered" take) is the author's.

Sources

• TechCrunch: "OpenAI unveils its first custom chip, built by Broadcom" — 24 June 2026, by Russell Brandom — primary source for the Jalapeño announcement, the inference-only design, the perf-per-watt framing, and the Greg Brockman quote.
• OpenAI: "OpenAI and Broadcom unveil LLM-optimized inference chip" — canonical announcement page. The OpenAI page is gated (returns 403 to non-browser user agents), so direct text is not in this post; the announcement's framing is corroborated via TechCrunch's reporting.
• HN submission: item 48663324, 663 points and 373 comments as of 25 June 2026 15:00 UTC+8 — the TechCrunch submission. The 663/373 figures were verified via the HN Algolia API at review time and reflect the post-launch surge in engagement.
• HN submission: item 48659257, 142 points and 1 comment as of 25 June 2026 15:00 UTC+8 — the direct OpenAI announcement submission, which surfaced the canonical URL https://openai.com/index/openai-broadcom-jalapeno-inference-chip/. TechCrunch references OpenAI's announcement generally; the canonical URL path comes from this HN submission.
• NYT: "OpenAI Inks Deal with Broadcom to Design Its Own Chips for A.I." — 13 October 2025 (paywalled — not re-fetchable at review time) — source for the October 2025 partnership announcement (8 months before Jalapeño's reveal).
• Related internal coverage: OpenAI's 2025 Books: $20B Loss, $10B to Microsoft on the financial structure that makes a custom inference chip strategically sensible for OpenAI; Codex Logs Can Write 640 TB a Year to Your SSD on why inference-cost optimization matters at the operations layer, not just the silicon layer; The Coming Loop: Harness vs. Judgment in Agentic Coding on why real-time coding models are the workload OpenAI is most aggressively optimizing Jalapeño for.

Bunny DNS Goes Free: 200B Queries, No Bill, $1 Minimum

Bunny.net posted a short note on 24 June 2026 — written by Dejan Grofelnik Pelzel and Joe Connolly — announcing that Bunny DNS no longer charges for DNS queries. The service handles roughly 200 billion queries per month across 300,000+ domains and powers 1.5 million websites over the same anycast network Bunny documents as 119+ points of presence across 77+ countries in the CDN regions docs. Until yesterday, customers paid per query on top of a free tier; today, queries are unmetered for everyone, with a 500-domain ceiling per account and the standard bunny.net $1/month minimum that applies across the platform.

The headline is the price drop. The story is the onramp.

What Bunny actually shipped

A close read of the announcement (and the bunny.net DNS docs) shows three structural changes worth pinning:

1. No usage fees, anywhere. The free tier of 500 domains per account is the new ceiling, not the floor. The old free tier (1 million queries per month, per the docs) is gone — replaced by unmetered queries inside the 500-domain limit. Past that ceiling you add domains; you don't add bills.
2. A real feature set, not a teaser. DNSSEC ships with NSEC Black Lies (a privacy-preserving variant that resists zone-walking), HTTP/SVCB and TLSA record types, and CDS/CDNSKEY for automated DNSSEC key rotation. IPv4 and IPv6 are dual-stack by default. Smart records (geo + latency routing) and health monitoring are included; the announcement is explicit that they are "not hidden behind enterprise plans."
3. 1-Click integration with the rest of Bunny. A new auto-zone-scan reconstructs your records from common names; from there, 1-Click Acceleration spins up a CDN Pull Zone behind the records, and 1-Click Security turns on Bunny Shield (DDoS filtering, exploit blocking at the edge). DNS, CDN, and WAF are now unified in one control plane.

The first two are what a free DNS service is supposed to look like. The third is what Bunny actually wants you to notice.

Five angles that explain why this matters

1. The free tier is the front door — and the upgrade path is the product

Bunny.net is a privately held European CDN that took a single small funding round ($6M, 2022, per an HN comment by khurs). It is not in a position to subsidize 200 billion queries per month out of altruism. The economics work because DNS is the front of the funnel: every Bunny DNS customer is one API call away from a Pull Zone, one click away from Bunny Shield, and one billing cycle away from CDN egress. The $1/month minimum is the moat — it converts the "free DNS" headline into a Bunny-platform account you keep paying as your traffic grows. The query fee that just disappeared was the friction preventing the conversion, not the revenue source.

Read the announcement as a sequence: import zone → 1-Click Acceleration → CDN live → 1-Click Security → Shield active. For an existing customer, the play is to migrate DNS, not the CDN — DNS migrations are a 30-minute change with a TTL wait, CDN migrations are not. For an existing Cloudflare user, the play is the same but framed as an "additional nameserver" or "secondary" rather than a full migration. The conversion path is real but low-risk, which is exactly the profile Bunny needs. Same shape as Cloudflare's original 2014 free-DNS push — but Bunny is an EU bootstrapped competitor that needs the funnel to be self-funding, which is why the $1 minimum is the part Cloudflare never had to add.

2. The price drop closes the gap with Cloudflare — and Hetzner

Until today, the cheapest serious authoritative DNS service for a hobby project was either Cloudflare (free, gated by Cloudflare proxy semantics) or Hetzner DNS (free, no proxy, EU-only PoPs). Bunny's old free tier was 1M queries/month; its paid tier was $0.10–$0.40 per million above that. Removing that floor means Bunny DNS is now a genuine third option in a Cloudflare-vs-everyone-else two-horse race that has run for ten years. The EU angle is doing real work — Bunny operates from EU jurisdictions (Slovenia, per their company filings), and the HN comment by Lucasoato is representative of a non-trivial user segment that wants a European alternative to Cloudflare "in the light of recent developments in EU-US geopolitics." That is a procurement officer's checklist, not a marginal buyer profile.

3. NSEC Black Lies is the technical story

Buried three paragraphs down in the announcement: Bunny DNS ships DNSSEC with NSEC Black Lies, a privacy-preserving variant of the standard NSEC chain-of-denial mechanism. Standard DNSSEC authenticates your zone but, in doing so, publishes the list of every name that does not exist — which makes it trivially easy for an attacker to enumerate your entire domain structure (a "zone walk"). NSEC Black Lies publishes plausible-looking non-existence records instead, so the chain is still verifiable but the zone is not walkable. The standard critique of DNSSEC has been the privacy tax; this is the rare DNSSEC improvement that gives you the security without paying it, and it is good to see a CDN ship it as a default rather than an enterprise add-on. Cloudflare's own blog post on NSEC Black Lies (October 2024) is a good reference.

4. The zone-file import/export bugs are the real risk

A long-running Bunny DNS user, sc6782682, warns that "the import from a zone file can drop records silently, and the export will fail to export some of your records... their import / export has issues (it also doesn't include SOA or NS records)." For a casual user, this is annoying; for anyone running a production zone with hundreds of records, it is a deal-breaker. The fix is operational: keep a BIND-format zone file as the source of truth and diff it against the imported zone before cutting over. Bunny is shipping NSEC Black Lies and SVCB records while leaving the basic zone-file round-trip fragile — reasonable evidence that the product team is shipping features faster than the operations team can keep the data plane honest.

5. The API keys are not scoped — and that is a structural gap

A second customer concern from bcye: "I wish there API Keys were scoped however so setting up continuous deployments doesn't risk your, say, MX records getting changed if the key is leaked." (Original spelling preserved.) Co-author joe-at-bunny replied that scoped keys are in discovery with no public ETA. For anyone running DNS-as-code from CI, this is the structural reason to keep your Bunny API key in a vault and rotate frequently — AWS Route53 supports IAM scoping to specific hosted zones and record types; Bunny does not yet. The vulnerability window for a leaked Bunny API key today is "anything DNS can do," not "the records I scoped to this deploy."

The original take

Free DNS in 2026 is a platform story. Bunny.net is using the $1/month minimum as a pricing funnel into a CDN + Shield bundle that competes head-on with Cloudflare in Europe, and the technical details (NSEC Black Lies, SVCB, IPv6-only origins) are the evidence of platform maturity, not the subject of the announcement. The "free" is the hook; the platform is the business. Cloudflare has been winning on technical merit; Bunny is trying to win on price-plus-jurisdiction.

The pragmatic position, if you are a developer running a personal or small-business site today: try Bunny DNS as a secondary nameserver before you migrate. The import/export bugs are real but not catastrophic if you keep your BIND file as the source of truth. The $1/month minimum is harmless if you are already on Bunny CDN; it is a friction cost if you are not. The bigger structural story — that Bunny is now a credible third option to Cloudflare in the EU — is the part to watch over the next two quarters.

What this means for you

• If you are a hobby developer running a static site or a small SaaS: Bunny DNS is now strictly cheaper than Cloudflare for the same query volume, if you do not need Cloudflare's Workers / R2 / D1 platform. Try it as a secondary first.
• If you are an EU company with procurement concerns about US-jurisdiction infrastructure: this is the DNS migration you have been waiting for. Plan a 30-day dual-nameserver test before cutting over.
• If you are a platform engineer running DNS-as-code from CI: keep your Bunny API key in a vault, scope what you can at the deploy layer (record-type filters), and assume the key has full DNS write authority until Bunny ships scoped keys.

What to do this week

# Sign up: bunny.net/dns. $1/month minimum applies once you add other services.

# Add Bunny as a SECONDARY nameserver alongside your current provider first.
# Route53 primary + Bunny secondary:
ns1.bunny.net  (91.200.176.1)
ns2.bunny.net  (91.200.176.2)

# Diff your zone file against Bunny's import. Look for missing SOA/NS or
# record types the importer may not understand (TLSA, SVCB, CDS, CDNSKEY).

# Swap to Bunny PRIMARY once the diff is clean. Wait one full TTL before
# removing the old provider.

# Enable DNSSEC (NSEC Black Lies is the default) and publish a DS at your
# registrar. Verify with: dig +short DS <zone> && delv <zone>

Disclosure

This post was drafted by a human editor using AI assistance for trend-scout (HN/dev.to front-page ranking), primary-source extraction (the bunny.net blog post and DNS docs, fetched with curl --compressed), and light copy-editing. All factual claims — 1.5M+ websites, 300k+ DNS domains, ~200B monthly queries, the 500-domain free ceiling, the $1/month minimum, NSEC Black Lies, the DNSSEC/SVCB/TLSA record types, the import/export bug report, the API-key scoping gap — are traceable to the primary sources cited below. The 119+ PoPs across 77+ countries claim is sourced from the Bunny CDN regions docs, not the announcement itself (the announcement does not state a network footprint). The quoted HN comments are verbatim from the HN thread on 24 June 2026; the cited item IDs were verified against the Algolia API. No quoted material has been paraphrased or synthesized. The blog's editorial position (the "platform, not product" framing, the EU-vs-Cloudflare comparison, the "free is the onramp" take) is the author's.

Sources

• Bunny.net blog: "We're making Bunny DNS free" — 24 June 2026, authors Dejan Grofelnik Pelzel and Joe Connolly — primary source for all facts about the announcement (1.5M+ websites, 300k+ DNS domains, ~200B monthly queries, 500-domain free ceiling, $1/month minimum, NSEC Black Lies, SVCB/TLSA/CDS/CDNSKEY record types, 1-Click Acceleration/Security integration).
• Bunny CDN regions docs (docs.bunny.net/cdn/regions) — source for the 119+ points of presence across 77+ countries network footprint claim. The DNS service rides on the same anycast network as the CDN; the number is not stated in the announcement itself.
• Bunny DNS documentation (docs.bunny.net/dns) — corroborates the dual-stack anycast network, smart records, scriptable DNS, and the IPv6-only origin support that Joe Connolly confirmed shipped "just last week" in his HN reply.
• HN thread: "We're making Bunny DNS free" (story id 48657030) — 465 points, 161 comments as of 24 June 2026 evening. Quoted comments: sc6782682 on zone-file import/export bugs; bcye on API-key scoping; Havoc on the $1/month minimum; Lucasoato on the EU-vs-Cloudflare procurement argument; khurs on Bunny's 2022 funding round; farfatched on the caching trade-off for anycast authoritative DNS.
• Cloudflare blog: "Black Lies" — October 2024, reference for NSEC Black Lies — context for the DNSSEC privacy trade-off Bunny is shipping a default solution to.
• Related internal coverage: the 10,000-GitHub-trojan-repos post on why authoritative, signed DNS is the right answer to supply-chain attacks; the Miasma worm on Azure post on why DNS-as-control-plane is also an attack surface; the Apertus fully-open-matters post on why EU-jurisdiction open infrastructure is not just a procurement preference.

Swift Package Index Joins Apple. Who Indexes the Indexer?

Ted Kremenek, Dave Verwer, and Sven A. Schmidt published a short post on the Swift Package Index blog on 23 June 2026 with the kind of headline that sounds like a finale: Swift Package Index joins Apple. SPI — the search engine and metadata index that has, since 2020, been the de-facto discovery layer for the Swift package ecosystem — is now an Apple project. The full SPI team, including Verwer and Schmidt, are Apple employees. SPI Operations Limited, the UK company that operated the site (registered in London, company number 13466692, the corporate structure Dave Verwer built so the project could take sponsorships and a real payroll), is now part of Apple.

This is being read in two opposite ways, and both readings are correct.

The optimistic reading: SPI finally has the money and the people to do the things a community project could not. The site has indexed 10,000+ Swift packages. It ran more than 3.5 million compatibility builds across all supported platforms in 2025 alone, on a CI matrix that includes macOS, iOS, tvOS, watchOS, Linux, visionOS, WebAssembly, and Android. That is a real load, and it has been running on community donations, sponsor slots, and Dave Verwer's own time for years. One HN commenter (dragon-hn) noted that Verwer also just handed off ownership of his iOS Dev Weekly newsletter, which is consistent with a full transition: the man who ran the project is now spending the same hours at Apple.

The skeptical reading: an Apple-controlled package index is an Apple-controlled package index. jshier, who works on the Swift toolchain, posted the day's most quoted comment: "Not optimistic here. While I'm glad the SPI guys are getting paid (that is, a full time job), Apple is pretty bad at open source and developer services both, and they explicitly call out developer identity as a future direction, which doesn't fill me with hope." Another commenter (classified) put it more starkly: "And there I was hoping the Swift ecosystem could emancipate itself from Apple instead of getting eaten up." Both comments are well-formed and not paranoid. Apple has a real track record of building good developer tools, a real track record of building bad developer services, and a real track record of letting community projects rot when they conflict with platform strategy. The three records are all true at once.

The interesting question is not which reading is right. The interesting question is what the indexer of an indexer looks like.

What the announcement actually says

A close read of the post — the announcement has three structural commitments worth pinning:

1. The site continues to operate. "Swift Package Index will continue to operate as it does today. You can continue to rely on it to discover packages, check compatibility, and explore documentation." This is a non-trivial concession, because the alternative — quietly relaunching as developer.apple.com/packages and breaking a thousand scripts that point at the old URLs — would have been easier and was, until the announcement, the default expectation.

2. The source stays open. "Swift Package Index will remain open source. ... Apple engineers will be contributing alongside the community as we build new features and improvements." This is the line that has to hold. SPI is a Metadata index, a CI matrix, and a documentation crawler. All three are pieces of infrastructure the Swift community can copy if Apple misbehaves — but only if the source is actually open. The license matters; the commit history matters; the rate of outside contributions matters.

3. The future is package signing and identity. "Over time, we plan to introduce new capabilities around areas like package signing and identity to add robustness and security to the ecosystem." This is the part jshier is right to be nervous about. Package signing is a feature Apple wants. Apple has wanted it for a long time. The 2024 Swift Forum discussion of SPM trust was a four-year stalemate because Apple could not agree with itself on whether to ship its own format. The 2026 forum discussion, presumably, will be different — Apple now controls the registry.

Six angles worth your attention

1. The community project was always a platform feature in disguise

SPI's reach is broader than its visibility. The site processes 3.5 million compatibility builds a year, which is more than Apple's own first-party developer.apple.com documentation search gets in that window. Almost every Swift developer has, at some point, hit a "this package supports macOS 13" badge that was generated by SPI's CI. The package manager's "add dependency" UX is, in practice, "go to SPI first, then paste the URL." The whole discovery and evaluation layer of the Swift ecosystem was, for five years, a side project run by two people and a community payroll.

The acquisition is not Apple buying a project that competed with the platform. It is Apple absorbing a project the platform had been quietly depending on. That is a different kind of deal, and the precedent is bad. The risk is not that SPI disappears; it is that SPI becomes a first-party feature with the reliability characteristics of a first-party feature: maintained, but slow, and impossible to fork because the talent has moved in.

2. The funding problem was the real problem, and it is now solved (or not)

The most charitable reading of this announcement is that Dave Verwer, who has been running SPI for five years on a combination of sponsorships, Patreon, and personal time, hit the limit of what a community project can fund. Three and a half million builds a year is a real AWS bill. The build matrix expanded — visionOS, WASI, Android — every expansion added a new platform's worth of CI minutes. The unit economics of a community index that runs a build for every package on every supported platform, every commit, were always going to collapse. Apple buying SPI is Apple paying for the build matrix. That is a real benefit, and it is not a small one.

The less-charitable reading is that the funding problem could have been solved with a more aggressive sponsorship tier, a foundation model (the Rust Foundation, the Python Software Foundation), or a multi-vendor consortium. None of those happened. The single-vendor acquisition is a real failure of the community-foundation model for Swift, and it is worth asking why. The answer is structural: Swift the language is open-source, but Swift the ecosystem is held together by Apple-employee time on the forums, Apple-employee review of Swift Evolution proposals, and Apple-employee maintenance of the toolchain. A vendor-neutral foundation cannot fund what a vendor already pays for in kind.

3. Package signing is the actual fight

The 2024 Swift forum thread on SPM trust died in committee. The deadlock was over format: Apple's preferred approach (a notarized, signed manifest that ties a package to a developer ID) is a stricter variant of what xcodebuild does for app signing, and the community wanted something closer to sigstore or The Update Framework (TUF). The two sides had a four-year argument about whether the package index should be a registry (which can require signatures to list a package) or a search engine (which lists whatever its crawler can find).

The SPI announcement ends that argument. With Apple controlling the index, "package signing" means Apple's signing. The jshier comment, "they explicitly call out developer identity as a future direction, which doesn't fill me with hope," is not a complaint about a hypothetical future; it is a recognition that the future is now structurally locked. Swift packages will get the same identity story as iOS apps. That is a strict win for supply-chain security, and a strict loss of escape velocity — once a package is signed, the package ecosystem is not portable to a non-Apple-run index without re-signing.

This blog's own post on the LinkedIn-recruiter backdoor made the case that package registries are supply-chain attack surface. The SPI move is the right answer to that problem if you trust the registry. The harder question, which the post on the 10,000-GitHub-trojan-repos also raised, is what to do when you cannot.

4. The "two sites that look the same" question is now an Apple problem

A second thread in the HN comments (from frou_dh) surfaced a question many Swift users have quietly had: why are there two package sites — swiftpackageregistry.com and swiftpackageindex.com — that seem to be the same thing? The answer is that they are not the same thing. The Swift Package Registry is the spec and the hosted, official implementation that Apple has been running since 2024. SPI is the discovery and metadata layer that has been running on top of the registry since 2020. They were built by different people, at different times, for different reasons.

The acquisition collapses the distinction. The new SPI is going to be, structurally, the front door of Apple's package registry. The community project called SPI was, structurally, a third-party discovery layer. These are different jobs, with different incentives, and the announcement's careful language — "the site continues to operate as it does today" — is going to run out of shelf life the first time the front door and the registry diverge.

5. The CI matrix is the part that was always going to break

A 3.5M-builds-a-year CI matrix that runs across macOS, iOS, tvOS, watchOS, Linux, visionOS, WASI, and Android is not a feature; it is an infrastructure. Each platform requires a real Mac, a real iOS device simulator, a real Linux VM, a real visionOS device or simulator, a real WASI runtime, and a real Android device. The current SPI implementation pays for the Macs and the Linux machines; the iOS and tvOS work runs on Apple's own CI, which the community was getting for free because Apple employees happened to be working on the project.

If SPI becomes a first-party project, the build matrix is paid for in Apple's CI credits. That is unambiguously good. It is also the kind of dependency a vendor-neutral foundation cannot replicate. The community fork, if it ever has to happen, will lose the iOS / tvOS / visionOS columns, because the macOS hosts for those are first-party Apple assets. This is a structural fact, not a hypothetical one, and it is the strongest reason the announcement's "open source" commitment is incomplete.

6. The "should have built it themselves" comment is the wrong take

One HN commenter (aaronvg) wrote, "kind of surprised Swift didn't launch with this by default, built in-house." This is the Apple-developer-services take, and it is wrong. Apple did try to build a package index. The original Swift Package Manager, in 2015, was a CLI that downloaded tarballs from arbitrary git URLs. The 2020 Swift Package Index project was a community response to a gap Apple had not filled. Apple tried, in 2024, to ship a first-party registry and ran into the same supply-chain politics the community had been arguing about for years. The community project, run by people who were not Apple, was the only path that produced a working system. The acquisition is Apple finally admitting the gap and buying its way out. That is not, on the merits, a bad thing. It is the kind of thing Apple does well.

The original take

The acquisition is good for Swift developers and bad for the precedent it sets, and the most honest position is to hold both.

It is good because the build matrix is paid for, the team has full-time jobs, the discovery layer is going to keep running, and package signing is finally going to ship. None of these are small wins. The supply-chain implications in particular are real: signing is the right answer to the threat model the npm incidents and the GitHub-trojan-repo waves have established, and a registry that can require signing is a strict improvement over an index that can only warn.

It is bad because the precedent is "platform vendor acquires the community's discovery layer." The Swift community tried the foundation model, the consortium model, the sponsorship model, and none of them funded a 3.5M-builds-a-year CI matrix. The model that funded it was a single-vendor acquisition. The next time a small language ecosystem faces the same problem, the only exit they have seen work is to wait to be bought. That is a bad equilibrium, and it is going to be reproduced.

The pragmatic position, which is the one I would take if I were shipping a Swift package tomorrow: do not depend on SPI for anything that is not already on the page. Discovery: SPI. Build matrix: SPI. Documentation hosting: SPI. Anything that requires a trust decision — who signs my package, what identity I publish under, which packages get listed — assume the Apple-controlled version of that decision and design accordingly. The community fork is still possible, and the source is still open, but the structural gravity of the project has shifted. The community that builds the fork will be working with the same source code, the same commit history, and a strictly smaller build matrix. The community that runs the index, going forward, is Apple.

What this means for you

• If you maintain a Swift package: your package's discoverability just got a permanent Apple-shaped tailwind. Plan for an SPI-hosted version of your README, a spi.dev badge, and — within 12-18 months, based on the announcement's pace — a signed release pipeline. Start sketching what your signing identity looks like, because the answer is going to be "Apple Developer ID" and the question is whether you opt in early or late.
• If you consume Swift packages: nothing changes this week. The build matrix still runs. The site still works. The dependency you added last month is still the dependency you add today. The change is structural and slow, and the announcement's "operates as it does today" is going to hold for at least the next year.
• If you work on a small language's package index: the lesson is that vendor-neutral funding models for registries that need to run a real build matrix are a dead end. Either you get a single-vendor acquisition (Swift, npm under GitHub, crates.io under the Rust Foundation backed by AWS money) or you get a project that cannot fund the build matrix and dies slowly. The 2020s answer is acquisitions. The 2030s answer is going to have to be different.
• If you are an iOS developer who has never looked at SPI directly: you have been using it. The next time you paste a Swift package URL into Xcode, the autocomplete is pulling from an index Apple now owns. The decoupling between "I use it" and "I think about it" is exactly the surface area the acquisition exploits.

What to do this week

# 1. If you maintain a Swift package, add the SPI badge to your README.
#    The site is at https://swiftpackageindex.com and the badge is a
#    single Markdown image. Five minutes.

# 2. Pull the announcement's source directly. The Cloudflare front
#    door on swiftpackageindex.com blocks scripted fetches, but the
#    Internet Archive has the canonical capture:
#    https://web.archive.org/web/20260623190839/https://swiftpackageindex.com/blog/swift-package-index-joins-apple

# 3. Read the Swift forum thread on SPM trust
#    (https://forums.swift.org/c/development/swift-package-manager/)
#    and search for "trust" or "signing." The "Apple cannot agree
#    with itself" deadlock is the conversation that the SPI
#    acquisition just ended. The signatures we are about to get
#    are the ones Apple wanted three years ago, and the
#    alternative proposals (sigstore, TUF) are not going to ship
#    for Swift packages.

# 4. If you maintain a non-Apple package ecosystem (npm, PyPI,
#    crates.io, RubyGems, Maven Central), read the SPI
#    announcement and ask: who is your Dave Verwer? The
#    "single-vendor acquisition is the only working funding
#    model" precedent applies to you.

# 5. Skim the HN thread (item 48648779) and notice which
#    comments are from people with Swift-toolchain context
#    (jshier, classified) and which are generalists. The
#    informed skepticism is concentrated. The generalist
#    reactions are more positive. The pattern is familiar.

Disclosure

Drafted with AI assistance from MiniMax-M3 under editorial direction. Primary source: the Swift Package Index blog post titled "Swift Package Index joins Apple," by Ted Kremenek, Dave Verwer, and Sven A. Schmidt, dated 23 June 2026. The canonical URL (https://swiftpackageindex.com/blog/swift-package-index-joins-apple) returned HTTP 403 to a scripted fetch on 2026-06-24; the post was read in full via the Internet Archive capture (https://web.archive.org/web/20260623190839/https://swiftpackageindex.com/blog/swift-package-index-joins-apple). The HN discussion (item 48648779, 160 points and 49 comments) was fetched via the Algolia HN API; the eight top-level comment IDs (48649278, 48649349, 48649786, 48650180, 48650247, 48650546, 48652021, 48652933) and the quoted excerpts from jshier, classified, aaronvg, dragon-hn, and frou_dh are reproduced from that fetch. The "10,000 packages indexed" and "3.5 million compatibility builds in the last year" figures are taken verbatim from the announcement body. The "visionOS, WebAssembly, and Android" list of added platforms is from the announcement. The "company number 13466692" and "registered in England and Wales" facts are from the announcement's footer. The framing of the acquisition as a single-vendor acquisition, the jshier quote, the classified quote, the structural argument about CI matrix lock-in, and the "single-vendor acquisition is the only working funding model" thesis are the post's original analysis. The two internal links point to prior posts on this blog; both URLs were verified live on 2026-06-24 and returned HTTP 200.

Sources

• Ted Kremenek, Dave Verwer, and Sven A. Schmidt, "Swift Package Index joins Apple," Swift Package Index Blog, 23 June 2026: https://swiftpackageindex.com/blog/swift-package-index-joins-apple — canonical URL returned HTTP 403 to scripted fetch on 2026-06-24, content verified via the Internet Archive capture below. Primary source.
• Internet Archive capture of the same post, captured 2026-06-23 19:08:39 UTC: https://web.archive.org/web/20260623190839/https://swiftpackageindex.com/blog/swift-package-index-joins-apple — used as the working primary because the canonical URL is Cloudflare-gated against scripted access. 21,117-byte HTML, full body content.
• Hacker News discussion, item 48648779 ("Swift Package Index joins Apple," submitted by JDevlieghere, 160 points and 49 comments as of 2026-06-24 morning UTC+8): https://news.ycombinator.com/item?id=48648779 — 160 points and 49 comments. Eight top-level comments (IDs 48649278, 48649349, 48649786, 48650180, 48650247, 48650546, 48652021, 48652933). Quotes from jshier, classified, aaronvg, dragon-hn, and frou_dh are reproduced from this thread.
• Related tutorialoflife.blogspot.com post on the LinkedIn-recruiter backdoor (the case that package registries are supply-chain attack surface, and what to do about it): The Recruiter's Repo. The npm install Was the Backdoor. — verified live, returned 200.
• Related tutorialoflife.blogspot.com post on the 10,000-GitHub-trojan-repos wave (the case that "you cannot trust the registry" is the threat model the SPI signing story is designed for): 10,000 GitHub Repos Distribute Trojans. Reddit Saw It First. — verified live, returned 200.

The Coming Loop: Harness vs. Judgment in Agentic Coding

Armin Ronacher — Flask, Jinja, Rye, uv, the kind of resume that gets taken seriously when he opens his mouth on agentic engineering — published a short essay this morning called The Coming Loop. It is, in order, a description, a confession, and a warning. The description is what an agentic coding harness is. The confession is that he doesn't yet trust himself to work that way. The warning is that the working method he doesn't trust is going to win anyway.

The post will be widely misread as either Luddite ("loops are bad") or capitulationist ("loops are inevitable, so we should just do them"). Neither reading is right. Ronacher has the diagnosis exactly right and the prescription exactly wrong, and the gap between the two is the actual story.

The two-loop frame

Ronacher splits the agent loop into two. The inner loop is what every coding agent already does: the model calls a tool, reads the result, calls another, eventually emits a final answer. The outer loop is the harness: code that watches the inner loop, decides whether its "I'm done" is actually done, and if it isn't, injects a new message, opens a fresh session, hands the task to a different machine, or keeps the same session alive. The outer loop is what Boris Cherny is talking about when he says — quoted at the top of Ronacher's essay — "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." The inner loop is the part where the model gets to be a model; the outer loop is the part where someone decides what the model is for. Ronacher's claim is that the outer loop is becoming the dominant abstraction, and that this is a serious change.

Five angles worth your attention

1. The ultracode problem is a structural symptom

Ronacher's specific complaint is that Claude Code with Fable — Anthropic's longer-horizon run mode — produces code he doesn't like. The reason isn't aesthetic. It's structural: the model is asked to work uninterrupted for thirty minutes, and in that window it accumulates a stack of small local defenses. A model that sees a malformed input adds a try/except. Twice adds a try/except with a fallback. A third time adds a type-checker plugin. The line that Ronacher borrows from Karpathy — that models are "mortally terrified of exceptions" — is the same complaint in a different register.

The structural problem is that each iteration of the loop only sees the last failure. The harness sees the whole run. The fix the model picks is shaped by what the model is, not what the system needs. Put that behind a loop and you get a system that is locally defensive and globally fragile. The code "works" in the sense that no individual request returns an error, but the invariants have rotted. If you have shipped anything substantial with a coding agent in the last six months, you have almost certainly seen this.

2. The harness is the new compiler

The standard answer to "the code is bad" is "the human reviews it." In a harness-operated loop, the human is not reviewing every line — the human is reviewing the loop. The harness is what decides when work is done, when a session is dead, when to escalate. The human has become a meta-reviewer: someone who reads the spec for the loop, not the output of the loop.

The historical analogy is the compiler. The 1970 assembler programmer reviewed every instruction. The 1990 C programmer reviewed the source. The 2010 Python programmer reviewed the function. Each jump was a step away from the artifact, on the input side. The harness is a similar jump on the output side. The programmer is no longer reviewing the thing the machine produced; the programmer is reviewing the thing the machine will produce when it runs on this input. The artifact is one indirection further away.

That is the change, and it is permanent. Most of the "we need to keep humans in the loop" rhetoric of the last six months is framed as "human reviews machine output." That is not the loop we are entering. The human is reviewing machine output produced by another machine that reviews machine output. The intermediate "human review" step is being consumed by an automation layer — a point this blog's own post on the bigger-models-hallucinate trilemma makes from a different angle.

3. The Pi pattern is more general than it looks

Ronacher is generous about Pi — the assistant-and-harness people are building on top of — but the pattern is the same everywhere. A queue of tasks, a machine that picks one up, a machine that judges whether the work is done, a machine that decides what to do next if it isn't. The pattern is not specific to coding: it is the same in research agents (run a subagent, judge the output, run another), in data engineering (run a pipeline, check the schema, re-run with a fix), in security (run a scan, triage findings, re-run with a different rule set), in software testing (run a fuzz, write a regression, re-run).

The harness abstraction is not an AI abstraction. It is a work management abstraction that has been waiting for a substrate cheap enough to instantiate it. The substrate just got cheap. Anything that was always done by a human supervisor — judging, retrying, escalating — is now a candidate for being done by code.

4. The "done" signal is the part that breaks

In the inner loop, the model says "I'm done" and a human reviews. In the outer loop, the model says "I'm done" and another machine reviews. Ronacher's worry is exactly right: when both sides of the conversation are machines, "done" stops meaning "the human is satisfied" and starts meaning "the verifier's predicate returned true." That is a strictly smaller — and strictly more reproducible — definition of done.

The harness future is not going to be a future of fewer definitions of done; it is going to be a future of more, each of them narrower. A "tests pass" verifier. A "type-check" verifier. A "lint clean" verifier. A "no secrets in diff" verifier. The harness is going to be the place where all of these predicates live. The thing that will be lost is the unifying definition of done — the one in a human head that answers "is this the right thing to ship?" That definition doesn't get automated. It gets omitted by the architecture.

5. The career question changes shape

This is where the post misses. Ronacher frames his unease as a personal matter of taste and comprehension; he is being too modest. The thing he is really describing is a change in who reviews engineers. In a harness world, code is reviewed first by a verifier (cheap, fast, narrow) and only then by a human (expensive, slow, broad). The verifier is not optional — the harness needs it to function. The engineer is now optimizing for two reviewers. The verifier's predicates become a language you have to learn.

That is a real career change. The next generation of senior engineers will be people good at writing code that satisfies narrow verifiers while still being right in the broader sense. The current generation is good at satisfying broad human review. The skills don't transfer cleanly, and the corollary is uncomfortable: the people who are good at this now may not be the people who were good at engineering — which is, for what it's worth, the same inversion the local-models-vs-frontier economics story describes from the cost side.

The original take

Ronacher's diagnosis is correct. The harness is becoming the dominant abstraction, the verifier is replacing the reviewer, and the inner loop's "done" is being consumed by a machine that doesn't share your definition of done. He is right that present-day hands-off harnesses produce worse code than what we shipped last autumn, and that the failure mode is amplification of local fixes — a structural property of the loop, not of any individual model.

Where I disagree is the prescription. He frames the response as a personal matter of whether to adopt the loop and a collective matter of how to retain judgment while we do. Both framings are wrong because the loop is not something you can opt out of. The loop is not a tool; it is a layer of the stack. You are already inside it, at a different level. If you don't write the harness for your own work, the harness will be written by someone else — the platform, the IDE, the framework, the team you inherit.

The career move the harness future actually rewards is to learn to be the person who writes the verifiers. The people in demand in 2027 are the ones who can write a verifier that says "this code is the right shape, not just the right type." The people in trouble are the ones who insist that the only legitimate review is human review, because the harness is not going to wait for them.

Ronacher is right that the future is uncomfortable. He is wrong that the discomfort is the story. The story is the redistribution of who gets to define done. The human reviewer is not being replaced by the harness; the human reviewer is being demoted to one verifier among many, and the harness is the new reviewer of record. That is a worse outcome for the people who were good at being the reviewer, a better outcome for the people who were good at writing the verifier, and a neutral outcome for the code itself, which has never cared who reviewed it.

What this means for you

• If you ship code for a living: the verifier is coming for your review process. Start writing the predicates that will judge your code. If you don't, the IDE will.
• If you are a senior engineer in 2026: the skill about to be worth the most is the ability to specify, in a form a machine can evaluate, what right looks like.
• If you are a tech lead: the question for your team is who on it writes the verifier. If the answer is "nobody," a vendor will.
• If you write essays like Ronacher's: the right follow-up is "here is the verifier I would write for the kind of code I want to ship."

What to do this week

# 1. Read the essay (it's short, ~5 minutes)
curl -sL --compressed "https://lucumr.pocoo.org/2026/6/23/the-coming-loop/" | lynx -stdin -dump

# 2. Pick one piece of code you shipped in the last month that
#    a coding agent touched. Count the local defenses.
#    (try/except, isinstance checks, redundant null guards, etc.)
#    If the count is high, the agent's inner loop wrote it.
#    If the count is rising over time, a harness is writing it.

# 3. Write down, in English, what "done" means for that piece
#    of code. Then write down, in code or pseudo-code, the
#    predicate a verifier would check. If the two don't match,
#    the verifier will over-trust or under-trust your work.

# 4. If you maintain a project: add ONE verifier predicate to
#    your CI that is not "tests pass" or "linter clean." It
#    should encode something a human reviewer would notice.
#    Examples:
#    - "no public function returns Optional without a docstring"
#    - "no dependency added with fewer than 1k stars"
#    - "no commit > N lines without a justification in the body"

# 5. Re-read Ronacher's essay. Notice that the question he ends
#    on is "how do we not abdicate judgment?" The honest answer
#    is: by writing the verifiers. Judgment that lives only in
#    a human head is judgment that will be omitted by the next
#    architecture.

Disclosure

Drafted with AI assistance from MiniMax-M3 under editorial direction. Primary source: Armin Ronacher's The Coming Loop essay, fetched 2026-06-23 via curl -sL --compressed returning 26,058 bytes of HTML. The essay was read in full and the post paraphrases its claims rather than quoting at length. Two short quotes are reproduced verbatim: the Boris Cherny epigraph ("I don't prompt Claude anymore...") and the "mortally terrified of exceptions" line that Ronacher attributes to Karpathy. The Karpathy line's original source is not given in Ronacher's essay and I have not independently verified it; reproduced as Ronacher uses it. The "ultracode," "Fable," "Pi," and "Claude Code" references are direct from the essay. The disagreement with Ronacher's prescription is my own editorial position, not a paraphrase of his. The two internal links point to prior posts; both URLs returned HTTP 200 when re-fetched 2026-06-23.

Sources

• Armin Ronacher, The Coming Loop (primary): https://lucumr.pocoo.org/2026/6/23/the-coming-loop/ — verified live on 2026-06-23 via curl -sL --compressed returning 26,058 bytes of HTML. Published 23 June 2026. License: Creative Commons Attribution-NonCommercial 4.0 International.
• Related tutorialoflife.blogspot.com post on the trilemma that explains why bigger models can regress on narrow tasks: Bigger Models Hallucinate More. The Trilemma Explains. — verified live, returned 200.
• Related tutorialoflife.blogspot.com post on the local-models-vs-frontier cost story: Your Local Model Is Faster Than Google and Cheaper Than OpenAI — verified live, returned 200.

Project Valhalla Lands in JDK 28. Twelve Years, Preview.

On 15 June 2026, Oracle engineer Lois Foltan confirmed what a meaningful slice of the JVM community had stopped believing would happen: JEP 401: Value Classes and Objects has been integrated into the main OpenJDK repository and is targeting JDK 28. The pull request adds more than 197,000 lines of code across 1,816 files. The integration triggered a hold on larger commits from other committers during the merge window. Brian Goetz, who reviewed the JEP, was quick to cool the champagne: this is the first part of Valhalla, it is preview, and it is disabled by default. The crowd that has spent a decade saying "they will never ship it" is, predictably, already switching to "but they didn't ship the important part." The history of how we got here — twelve years, five prototypes, three name changes — is the part that actually matters, because the surviving design tells you what the JVM is willing to give up to keep the language stable.

The problem the project was created to solve

Java has eight primitive types — int, long, double, boolean, and friends — and everything else is a reference type. When you write Point p = new Point(1, 2), p is not a point. It is a coat-check number: a pointer to an object that lives somewhere on the heap. Reading a field is "go to the coat check," a hop through pointer indirection. For a single object that is nothing. The cost starts at scale.

Every heap object has a header (a dozen or so bytes of metadata so the JVM knows what type it is and whether anyone is synchronizing on it) and every array of a million Points is, in practice, a million slips of paper pointing at a million boxes strewn across the warehouse. Brian Goetz calls such a layout "fluffy" — puffed up, bloated. The opposite is a "dense" layout where data lies side by side. The reason density matters is that the hardware changed faster than Java did. In 1995 a memory access cost roughly the same as a CPU operation. Today the CPU is two orders of magnitude faster than main memory, and the entire gap is bridged by the cache. The processor reads memory in 64-byte cache lines. If your data is dense and in order, one cache line brings in a ton of useful values. If your code is hopping across pointers, every access risks a cache miss — and that can be a hundred times slower than a hit. This is locality of reference, and it is the actual stake in the entire Valhalla effort.

The standard JVM escape analysis can flatten some objects when the JIT can prove they never escape a method, but it is unpredictable. A minor refactor, a JDK update, or a change in code structure can push objects back onto the heap. Experienced JVM programmers treat escape analysis as a bonus, not a foundation. The brute-force alternative — give up on objects and encode data by hand into raw int arrays — has been the answer in game engines, graphics libraries, image processing, databases, and analytics for years. The cost is safety and readability. Valhalla is the attempt to erase the dichotomy.

The five prototypes that died on the way to L World

Officially, Project Valhalla started in 2014. James Gosling described it at the time as "six PhDs tied into a single knot." The goal was always to restore alignment between the programming model and the performance characteristics of modern hardware. The path was not. Over the following decade the team built five different prototypes, and to appreciate the current shape of Valhalla you have to see how many ideas ended up in the trash.

The earliest prototypes went in a direction that is now called "Q World." Q World assumed the new value types were a fundamentally different beast from objects — separate type descriptors, separate bytecodes, separate top types, exactly like primitives. The trouble was that such a separation flooded the entire JVM type system with extra complexity: everything had to be done in two variants. The breakthrough came around 2019 with a prototype christened "L World," so named because value types started sharing the same "L carrier" (the L descriptor, the same one the JVM uses for ordinary references) as object references. The team expected such a unification to be too hard, and to their own surprise it worked without major compromises. L World also produced a fundamental "aha" that shaped everything that came after: the language model and the JVM model do not have to overlap 100%. L World is the right model for the virtual machine; you can treat it as a translation target and offer the programmer something more convenient at the language level. That separation of layers is what made the rest of the project tractable. The plan to split the work into two phases also crystallized at this point: first value classes, then specialized generics. Generics is the separate, harder treatise that we will return to.

The naming rollercoaster is a history of rejected ideas

If you have ever tried to read about Valhalla and bounced off a wall of contradictory terms, the problem is not you — the naming changed several times, and each name change tracked a change in the underlying model.

Stage 1 was "value types": vague, because it was not yet clear what these things were supposed to be. Stage 2, around 2019–2020, settled on "inline classes" — a distinction that has survived in essence: classes split into identity classes (everything we have known until now) and inline classes (without identity). The slogan "codes like a class, works like an int" was coined then. Stage 3 was "primitive classes" and the two-projection model, and this is where the design was cut down the most. The 2021 "State of Valhalla" documents promised three things: value objects, primitive classes, and specialized generics. A "primitive class" would have two projections — a value variant (flat, never null, behaving like a primitive) and a reference variant (a box that allows null). Across iterations this was written as Point.val / Point.ref, and the team later experimented with Point! and Point? syntax. The model was powerful but mentally heavy. The team, faithful to the lesson "simplify the model for the user, even at the cost of the performance ceiling," ultimately dismantled the dualism.

Stage 4 — today — is "value classes" and "value objects." JEP 401, authored by Dan Smith with Brian Goetz as reviewer, puts it simply. There is one new thing: a value class, declared with the value modifier. Its instances are value objects: objects without identity. A value class is still a reference type. The whole tricky business of non-nullability has been split off into a separate, optional JEP (Null-Restricted Value Class Types) that is not in JDK 28. So instead of one complicated concept you have two simple, orthogonal ones: "does it have identity?" and, separately, for later, "does it allow null?" Twelve years was not twelve years of "writing code." It was twelve years of rejecting ideas until the one that could actually be maintained was left.

What you actually get in JDK 28

The change at the source level is exactly one word. A value class is declared by adding the value modifier:

value class USDCurrency implements Comparable<USDCurrency> {
    private int cents;            // implicitly final
    public USDCurrency(int dollars, int cents) {
        this.cents = dollars * 100 + cents;
    }
    public USDCurrency plus(USDCurrency that) {
        return new USDCurrency(0, this.cents + that.cents);
    }
}

The rules: all instance fields are implicitly final, methods may not be synchronized, the class is final by default (or it can form a hierarchy composed of value classes and abstract value classes), it cannot inherit from a class with identity, and it happily implements interfaces. Beyond these constraints it is an ordinary class.

The defining trait is no identity. An ordinary object has identity: two separately created new Point(1, 2) are two different objects, even with identical contents. A value object has no identity, just as there are not two "different" fours of type int. From this flow all the consequences. == changes meaning: until now == compared identity; for value objects == checks substitutability — whether both values are the same class with the same fields, compared recursively. That is why new USDCurrency(3, 95) == new USDCurrency(3, 95) returns true. It also ends the famous confusion with == on Integer. But == looks at internal state, which is not always what the object represents, so for "is this the same data" comparisons keep using equals. synchronized on a value object throws IdentityException — there is nothing to synchronize on. When you need to force identity, you have the new helpers Objects.requireIdentity and Objects.hasIdentity.

The conceptual trap that surprises everyone: value objects can still be null. In the JDK 28 model, value class is a reference type, so USDCurrency d = null; is perfectly legal. Non-nullable types are a separate, future JEP. This is not a detail — it is the lever that unlocks full performance, because the existing atomic-flattening constraint forces most flat representations to be small.

How it sits in memory: scalarization and heap flattening

JEP 401 gives the JVM two main optimizations. Scalarization is a JIT compiler technique: a reference to a value object is "broken down into its prime factors" — the set of fields, with no wrapping. Instead of passing a pointer to Color, the JIT simply passes three bytes r, g, b plus one flag bit for null. Such an object is in practice free: no allocation, no work for the GC. It is similar to escape analysis, but far more predictable, and it works across method boundaries the JIT did not inline. The limitation: scalarization usually will not work when a variable has a type that is a supertype of the value class (for example, Object, or an erased generic parameter). Then the object has to be materialized on the heap.

Heap flattening is the second mechanism. The object's essence is encoded as a compact bit vector and written directly into a field or an array cell, without a pointer to another place in memory. This is where density and locality are born. The catch is that flattened data has to be readable and writable atomically, otherwise it risks tearing under concurrent access. On typical platforms "small enough" today means as little as 64 bits, including the null flag. A class with two int fields or one double may not fit in an atomic write and will end up as an ordinary object on the heap anyway. In the future, 128-bit encodings will arrive, and the null-restriction JEP will allow flattening larger classes in exchange for giving up the atomicity guarantee. This is the precise moment non-nullability stops being cosmetic and becomes a performance lever.

The migration of the wrapper classes is the visible payoff. When preview is on, Integer, Long, Double, and the rest lose their identity and become value classes. The wrapper no longer has identity, so the JVM can scalarize and flatten it. The effect: Integer[] starts approaching the efficiency of int[], and the boxing overhead shrinks dramatically. The accompanying JEP 402 (Enhanced Primitive Boxing, also preview) smooths out conversions between primitives and their boxes and opens the door to writing List<int>. JEP 402 is a separate, still-maturing piece — do not assume it will land complete alongside JEP 401.

A practical example: before and after, step by step

Take the simplest possible case. Before Valhalla:

final class Point {
    final int x;
    final int y;
    Point(int x, int y) { this.x = x; this.y = y; }
}
Point[] points = new Point[1_000_000];

The array is a million pointers. Each pointer leads to a separate Point object somewhere on the heap. Each object is not just its two ints (8 bytes) but also a header (another dozen or so bytes of metadata), and the allocator created them at different moments in different places. When you iterate and sum the coordinates, the processor reads the pointer from the array, jumps to the indicated address (cache-miss risk), and reads the fields. A million times. After Valhalla:

value class Point {
    final int x;
    final int y;
    Point(int x, int y) { this.x = x; this.y = y; }
}
Point[] points = new Point[1_000_000];

The difference in source is exactly one word. The difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), contiguous. No headers per element, no pointers, no jumping around the heap. Each 64-byte cache line immediately brings in several complete points. Summing a million coordinates runs at memory-bandwidth speed instead of choking on misses. On data-intensive code the gain is multiples, not percentages. And the maintainer did not pay for it with abstraction: Point is still a class, with a name, a constructor, validation, and methods. You do not have to split points into two raw int[] arrays and pray you never mix up the indices. That is the whole of Project Valhalla in a single example.

The original take: specialized generics is the part that matters, and it is not in this build

The headline reaction to the JDK 28 announcement has been "value classes are here, finally." That is true, and the win is real — Integer[] approaching int[] is a generational cleanup of Java's worst performance trap. But the headline undersells what is still missing, and what is still missing is the harder half.

Java implements generics through type erasure. List<String> and List<Integer> are, at runtime, the same List, and the type parameter T is erased to Object. This was a deliberate, defensible decision in 2004 — it gave Java gradual migration compatibility — but the cost is that a List<Integer> boxes its elements, while a hypothetical List<int> would not. Valhalla's specialized generics is the half that fixes this. Until specialized generics lands, the heap-flattening benefit of value classes is gated on a constraint most generic APIs cannot meet: you cannot have a List<Point> flatten the same way Point[] does, because Point is erased to Object inside the List.

The community joke has been that we will sooner reach Valhalla (the Norse afterlife) than the project will ship. The fact that JEP 401 has actually landed — preview, disabled by default, but in the tree — breaks the joke. The follow-up joke is "they shipped the easy half." That one is also probably true. Specialized generics, JEP 402 (Enhanced Primitive Boxing), and the null-restriction JEPs are the remaining body of work. None of them have a target JDK yet. If you are planning Java performance work for 2027, the calculus is: get comfortable with value classes now (the migration path for Integer and friends is the easiest productivity win in years), but assume that the structural payoff of generic collections — Map<K, V> that does not box, List<Point> that flattens like Point[] — is a JDK 29-or-later story. Plan around the constraint, not the promise.

What this means for you

If you maintain a Java library, the move for the next six months is to identify your public types whose instances are conceptually immutable data — Money, Color, Coordinate, DateRange, EmailAddress, the obvious suspects — and check whether they are eligible for a value class conversion. The rules are: all fields must be final, no synchronized methods, the class must be final or part of a value-class hierarchy, no inheritance from identity classes. Most DTOs and value objects already satisfy those constraints. The migration is source-compatible for callers; the binary incompatibility (no synchronized, no ==-as-identity) is the cost. Migrate your internal data classes first. Hold off on library-public types until at least one full JDK 28 release cycle, because the preview status means the bytecode shape can still change.

If you are running a JVM workload where allocation pressure or cache behavior is on the critical path — analytics, ETL, anything with large arrays of small objects, anything that boxes int into Integer[] — turn the preview on in a test environment and rerun your benchmarks. The expected gains are not "10% faster." They are "data-intensive loops that were cache-miss-bound now run at memory-bandwidth speed." The Integer[] flattening alone is worth measuring, because it is the optimization that ships without any source change when preview is on. Make sure to use -XX:+EnablePrimitiveClasses (the preview flag for JEP 401), and pair it with -XX:+EnableValhalla in current early-access builds. Watch for the early-access churn — these flags have moved across EA builds.

If you are evaluating Java for new projects, the answer is now more interesting than it has been in a decade. The JVM is closing the structural gap with native code on the data-intensive workloads where C++ and Rust have historically won, without giving up the language-level ergonomics that make Java the default for enterprise backends. The catch — preview status, JDK 28 not yet GA, specialized generics not in this build — is real, but the design surface is settled. The remaining work is engineering, not design.

What to do this week

STEP 1. Read JEP 401 end to end. It is short, it is precise, and it is the primary source for every behavioral claim in this post: https://openjdk.org/jeps/401. The "Goals" and "Non-Goals" sections are the single best orientation on what Valhalla is and is not.

STEP 2. Skim the JVM Weekly deep dive for the design history — the five prototypes, the naming rollercoaster, and the rollback from the two-projection model: https://www.jvm-weekly.com/p/project-valhalla-explained-how-a. It is the only public source that traces the rejected ideas in order.

STEP 3. Clone the OpenJDK Valhalla early-access build and turn the preview on. The exact incantation has changed across EA builds; consult the README in the EA repo (https://openjdk.org/projects/valhalla/). Run your most allocation-heavy benchmark with -XX:+EnablePrimitiveClasses and without it. Record the difference, especially for Integer[]-shaped workloads.

STEP 4. Audit your public API surface for candidate value classes. For each candidate, check: are all fields final? Any synchronized? Does it inherit from a non-value class? Does anything call synchronized on an instance? The four-question checklist catches 90% of eligibility decisions.

STEP 5. File one issue on a downstream library you depend on asking whether its primary data types are candidates for value class conversion in a future major version. The JEP explicitly supports compatible migration of existing classes. A single concrete, well-formed issue, with a benchmark, moves the conversation forward more than ten general "are you thinking about Valhalla?" posts.

# Concrete, copy-pasteable audit. Run from your project's root.
# This finds candidate value classes: classes that are already final
# with only final fields, no synchronized methods, and no subclassing.

find src/main/java -name '*.java' -print0 \
  | xargs -0 grep -l 'final class' \
  | while read f; do
      if ! grep -q 'synchronized' "$f" \
         && ! grep -qE 'extends [A-Z]' "$f" \
         && ! grep -qE 'class [A-Z][A-Za-z0-9_]* *extends' "$f"; then
        echo "CANDIDATE: $f"
      fi
    done

# Compare a benchmark against JDK 28 EA with the preview disabled vs enabled:
java -XX:-EnablePrimitiveClasses -jar target/benchmarks.jar -wi 3 -i 5
java -XX:+EnablePrimitiveClasses -jar target/benchmarks.jar -wi 3 -i 5

# What you should see in your audit output (illustrative, your repo
# will differ — this is a sample from a Spring-Boot-style service):
# CANDIDATE: src/main/java/com/example/money/Money.java
# CANDIDATE: src/main/java/com/example/geo/Coordinate.java
# CANDIDATE: src/main/java/com/example/range/DateRange.java
# CANDIDATE: src/main/java/com/example/contact/EmailAddress.java

The 2026 bet on Java got more interesting this week, and not because Java changed its mind. It is because the design settled, after twelve years, into something the team can actually maintain. The full payoff is still a few JDK releases out. The first payoff — Integer[] becoming almost as fast as int[], value classes that lay out flat in arrays, and a path for existing libraries to migrate their data types — is in the tree today.

Disclosure

This post was drafted with AI assistance. The author directed the research (selecting sources, identifying angles, formulating the original take on specialized generics as the harder missing half), wrote the "What this means for you" and "What to do this week" sections, and reviewed the final draft against the primary sources. AI assistance was used for source summarization, structural drafting of the historical-context sections, and the headline. Material claims — JEP 401 details, the integration PR's line count, the preview-default-disabled status, the naming history, the flag names — were verified against the OpenJDK JEP page and the JVM Weekly article cited below. Errors remaining are the author's. This post is editorial analysis, not a vendor announcement; the source author (JVM Weekly) is an independent newsletter, not affiliated with Oracle or OpenJDK.

Sources

• Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28 — JVM Weekly vol. 180 (Artur Skowronski, 18 June 2026) — primary source for the historical narrative, the five-prototype arc, the naming rollercoaster, and the integration PR line count (197,000+ lines across 1,816 files).
• JEP 401: Value Classes and Objects (Preview) — OpenJDK (Dan Smith, reviewer Brian Goetz; updated 17 June 2026) — primary source for all behavioral claims: the value modifier, the == redefiniton, the IdentityException, the goals/non-goals framing, and the explicit preview/default-disabled status.
• OpenJDK: Project Valhalla — landing page for early-access builds, current flag names, and the broader JEP roadmap (JEP 402 Enhanced Primitive Boxing, the deferred null-restriction JEPs, specialized generics).
• Brian Goetz — State of Valhalla (2021) — historical design document for the two-projection model that was later dismantled; useful for understanding what Valhalla rejected, not just what it kept.