7 min read · 12 sources

Every Kubernetes admin has a script that cross-references PVCs against running pods to find the orphaned storage silently burning cloud spend. As of v1.37, that script is obsolete. The PersistentVolumeClaimUnusedSinceTime feature gate is now Beta and enabled by default, and the PVC protection controller stamps an Unused condition on every claim that no running or pending pod references. Terminated pods don’t count as users. You get a timestamp for when the claim went idle, which means you can finally write a one-liner to find every PVC that’s been cold for 30 days and delete it with confidence.

That’s the quiet win of the day. The loud one is Cloudflare finally shipping Python as a first-class Workers citizen, and it’s a bigger deal than the release notes suggest.

The share of engineers who find Prometheus and OpenTelemetry hard to use together dropped from 29% to 10% in two years.

Kubernetes v1.37: The control plane now tracks your orphaned storage

The Unused condition lands on each PersistentVolumeClaim, set by the PVC protection controller based on whether any running or pending pod references it. The timestamp attached to the condition tells you exactly when the claim stopped being used, so cleanup policies can target PVCs idle for specific periods rather than guessing.

For large clusters, this kills a whole category of bespoke tooling. Teams running hundreds of namespaces typically maintain cron jobs or admission webhooks to hunt for claims that are provisioned but never mounted. That’s silent cost - provisioned storage you’re paying for whether or not anything reads it. The new condition makes the data native to the API server, queryable with a standard kubectl get pvc -o jsonpath expression. No new components, no CRDs, just a condition on a resource you already watch.

Python Workers hit GA, and the TypeScript bridge is gone

Source: blog.cloudflare.com ↗

Cloudflare has made Python Workers generally available, and the headline change is that Python is now a first-class language on the Workers runtime. Bindings to Workers AI, R2, D1, Queues, and the rest of the platform work natively. Frameworks like FastAPI, Django, and Flask run without glue code.

The previous model forced Python developers to convert objects to TypeScript at the RPC boundary - a serialization dance that added latency and cognitive overhead to every edge function. That’s gone. If you’ve been holding off on Workers because your logic lives in Python and the interop layer felt fragile, the reason to wait just evaporated. The practical consequence: teams can now port existing Python services to the edge without rewriting them in a second language, which changes the cost-benefit math on edge deployment for a lot of shops.

Prometheus and OpenTelemetry are learning to get along

Source: prometheus.io ↗

The 2026 interoperability survey from the Prometheus project has a number worth sitting with: the share of respondents who find the two hard to use together dropped from 29% in 2024 to 10% now. Ease-of-use ratings climbed from 3.1 to 3.6. The sample is small - 186 respondents, 81 qualified - but the direction is unambiguous.

The instrumentation split is telling. For infrastructure, Prometheus exporters (72%) and OTel receivers (57%) lead. For application code, OTel SDKs dominate at 65%. Nearly half of respondents run both stacks concurrently. The practical takeaway: the ecosystems have settled into a division of labor rather than a fight. Prometheus owns the infrastructure scrape path; OpenTelemetry owns the application instrumentation path. The interop work is paying off, and the “very difficult” crowd has effectively vanished.

Cutting CI time 64%: the boring hardware upgrade wins again

Source: platformengineering.org ↗

A platform engineering team cut its Merge Train pipeline from ~60 minutes to 22 minutes - a 64% reduction - while growing the test suite by 90% and pushing CI health from ~82% to over 90%. The biggest lever wasn’t clever caching or test parallelization. It was migrating compute from a C5 fleet to newer-generation hardware. AMD initially looked best, but the team landed on Intel after benchmarking.

The methodology matters as much as the result. The team changed one variable at a time to track impact, which is how they isolated the hardware win from the test-splitting changes. Monthly infrastructure costs rose only ~10% despite the faster fleet and larger suite - a trade most teams would take without hesitation. The estimated payout: over 1,300 engineer hours recovered that were previously lost to delays and retries.

What Sun got wrong: operational boredom

Source: bcantrill.dtrace.org ↗

Bryan Cantrill’s post-mortem on Sun Microsystems distills the company’s failure to a boredom with the mechanics of running a business. The anecdote that lands it: in 2005, a startup running OpenSolaris wanted to buy Sun hardware and couldn’t get Sun to respond. Dell’s local account executive called back the next morning and closed the deal in under two weeks.

The lesson for anyone running infrastructure today is uncomfortable. Technical superiority evaporates fast when sales, support, and responsiveness are an afterthought. Sun paired great technology with operational disinterest and lost the business to a more responsive competitor selling inferior hardware. It’s a reminder that the boring parts - the account exec who calls back, the ticket that gets answered - are the moat.

Markdown in /src: the source of truth for agent-generated code

Source: htmx.org ↗

Carson Gross argues in Markdown in /src that Markdown is becoming source code, not documentation. Agentic coding workflows increasingly define application logic in prompt sessions, and those sessions are ephemeral. When the session ends, the generated code becomes the only ground truth - and that’s a flawed model.

The fix: persist the Markdown that defines intent into /src, checked in alongside the code. That makes it diffable, reviewable, and available to both humans and agents. Tests can be derived from it to verify the implementation matches the intent. The argument is really about reproducibility - compilers retain source code, so LLM workflows should too. If you’re building on agent-generated code, the question isn’t whether to adopt this; it’s whether you want your prompt history to be the only record of why the code exists.

Ax: Google's orchestrator for billions of agents on Kubernetes

Source: github.com ↗

Google’s Ax is a declarative orchestrator for running autonomous agent workloads at massive scale on Kubernetes. It uses Agent Substrate for sandboxed execution and exposes four primitives - Task, Workspace, Gateway, and Model - as ax.io/v1alpha1 manifests. Commands like ax apply, ax watch, ax ssh, and ax suspend/resume manage the lifecycle.

The design goals are isolation, network fencing, and cost control - the three things that go wrong when you let agents run loose. It’s pre-stable with major breaking changes expected, and it requires a Kubernetes cluster, ko, and a container registry to deploy. Not for production yet, but the declarative manifest approach is the right shape for managing fleets of autonomous workloads.

Treg: OpenRouter for agent tools

Source: github.com ↗

Treg is an open-source proxy positioning itself as “OpenRouter, but for agent tools.” It catalogs 3,000+ endpoints across 60+ providers - SEO, social, enrichment, scraping - priced per call from a cent, with no provider signup. Credentials are injected server-side, so callers never hold keys. It supports both Treg’s own keys and team-registered tools (APIs, OAuth, CLIs, SKILL.md).

The pitch is straightforward: instead of maintaining monthly subscriptions to Semrush or Moz, pay per call through a shared pool. New verified accounts get $1.00 free. Hosted at treg.to or self-hostable. For agent builders, this removes the credential-management headache that usually comes with wiring up tool calls.

Microsoft open-sources TauGrid for GPU workloads

Source: infoq.com ↗

Microsoft open-sourced TauGrid, a cloud-native platform for managing, scheduling, and monitoring AI workloads on GPU-enabled Kubernetes clusters. It unifies Kueue (queuing), KubeRay (orchestration), GPU-node health monitoring, and observability into a single Helm install. Workloads are defined via a tau.yaml config and submitted with tau run. It supports checkpoint-based resumption on failure, and the roadmap includes multi-tenant workspaces, RBAC, and PyTorch DDP/FSDP support.

The value is consolidation. Teams running GPU workloads typically stitch together Kueue for queueing, KubeRay for Ray clusters, and custom health checks for flaky GPUs. TauGrid wraps that into one install. Still early, but the unified approach is a direct answer to the operational sprawl of AI infrastructure.

The tail: Forrester, TanStack, and the wisdom question

Source: cloud.google.com ↗

Google was named a Leader in the Forrester Wave for External Threat Intelligence, scoring 5.0 across nine criteria. The report notes Google is the only vendor that’s also a frontier AI model developer, enabling agents that actively evolve rather than summarize.

TanStack Charts hit Alpha as a framework-agnostic grammar of graphics for TypeScript, pulling ~160,000 weekly downloads. It was “almost all” produced with AI coding agents under supervision. A commercial competitor notes it’s better suited for simpler charts than heavy real-time workloads.

Finally, AI Has No Wisdom and Neither Will You makes the case that code maintainability lacks immediate measurements, so AI trained on beginner rulebooks can’t learn what makes code maintainable - that takes months or years to observe. The warning: developers who stop reading and writing code will produce vibe-coded projects that devolve over time.