Dependabot is one of those tools that I really appreciate, right up until I open a repository and see a pile of pull requests waiting for me. And this is particularly noticeable when working on a monorepo, such as the Aspire Community Toolkit.
Individually, each PR is pretty simple: a dependency moves from one version to another, the lockfile changes, CI runs, and if all is well you merge it. The problem is that they don’t arrive individually. They arrive as a queue, and that queue has relationships that GitHub’s PR list doesn’t really make obvious. Which PRs fix security alerts? Which ones touch the same lockfile and will conflict with each other once I merge the first one? Are there alerts with no PR fixing them at all?
I found myself doing that analysis in my head (or across a bunch of browser tabs) whenever I sat down to tidy up dependencies. So I built a canvas for the Copilot app to help: the Dependabot Triage Canvas.
Looking at the queue differently
Canvases are apps that you host in a session within the Copilot app that let you work with something other than chat - a kanban board, an external system dashboard, or in this case, a purpose-built view of your Dependabot PRs.
Rather than listing PRs in the order they were opened, the canvas groups them. By default the grouping is by dependency, but you can also group by directory, ecosystem or status. Each PR shows the dependency update (including whether it’s a patch, minor or major version bump), the state of its checks (is CI passing), whether it’s mergeable, and its review state.
To make this concrete, I opened the canvas against this blog’s repository while writing this post. It found 7 open Dependabot PRs, all in the npm ecosystem, and 6 of them are linked to security alerts. They include a mixture of updates:
brace-expansion 1.1.11 → 1.1.21 (patch)
js-yaml 4.3.1 → 4.3.2 (patch)
sharp 0.35.3 → 0.35.4 (patch)
browserslist 4.21.1 → 4.28.9 (minor)
@babel/core 7.18.6 → 7.29.7 (minor)
A PR with several major @graphql-codegen updates
It also told me something less pleasant: all 7 PRs have failing checks. Clearly this repository needs a bit of attention! 😅 (The failing checks are to do with deploying PR branches to Azure Static Web Apps, which has been broken for a while, so no biggy 😜)
That’s the sort of thing I wanted the canvas to surface quickly. I don’t need to open each PR to discover that there’s a broader problem worth investigating before I start merging.
Connecting PRs and alerts
The thing that pushed me to build this was the disconnect between Dependabot pull requests and Dependabot security alerts.
The canvas loads open security alerts and matches them against the open PRs. When a PR fixes one or more alerts, you can see that relationship from the PR itself. The alerts view also highlights the alerts that don’t have an open PR addressing them.
For this repository, there are 62 open alerts and 53 of them are not addressed by an open Dependabot PR. Many of those are in the /api project’s package-lock.json, including alerts for packages such as undici, ws, form-data and lodash.
That’s a very different picture to “there are 7 PRs to review”. The PR queue is only part of the work; there’s also a bunch of security work that needs a different approach, such as updating a parent dependency or retiring an old part of the project.
Spotting overlaps
Another thing that the canvas looks for is overlap between PRs.
This is something that we hit a lot in the Community Toolkit. Since it’s a monorepo design, we have a lot of package.json files spread across a lot of folders. If a security alert comes out for one of the packages, we could end up with 50+ PRs updating the same package simultaneously. The canvas helps identify these overlaps, and allows us to combine them into one single PR. Doing this means that we have less merges happening, and fewer CI jobs that need to run when the merge happens to the main branch.
Taking action without giving up control
The canvas isn’t only a read-only dashboard. It supports a number of actions that I’d otherwise perform on GitHub:
Approve a PR
Approve and merge a PR, optionally with auto-merge
Close a PR
Post supported @dependabot commands like rebase, recreate and ignore
These can be done one at a time or in bulk. But I was very deliberate about where the guardrails sit.
Approving, merging, closing and commenting only happen after I confirm the action in the canvas. The agent-facing actions can read, filter and select PRs, and they can record results like review verdicts, but they can’t mutate the PRs. Merges also use --match-head-commit, so if a PR has changed since I looked at it, it won’t be merged.
In other words, Copilot can help me understand the queue and get the right PRs selected, but I’m still the one pulling the trigger.
Bringing agents into the workflow
Because the canvas is running inside the Copilot app, it can also hand work off to agents.
Review with agent sends one or more PRs to an agent for review. The agent records a verdict - safe, caution or blocked - along with a summary, and that verdict appears back in the canvas. If the PR’s head changes later, the review is marked as stale so I’m not relying on an old assessment. This can be particularly helpful if there’s a failing CI job, as the agent can help dig through the CI logs to see if the failure is transient or related to the dependency that is being bumped.
The other workflow is what I mentioned above, Combine into one PR. I can select a set of Dependabot PRs and ask an agent to fold them together. The agent works in a separate git worktree, so my checkout isn’t disturbed. It cherry-picks the PRs, regenerates conflicting lockfiles, pushes a new branch and opens a combined PR that lists what it supersedes.
Reviews and combines run in background agents by default, so multiple tasks can be in progress while my main session stays available. The Agents tab shows what’s running, which PRs each agent is working on, and its latest response.
This is where a canvas becomes more interesting than a dashboard. It gives the agent structured context - the PRs, their diffs, the related alerts, and the overlaps - and gives me a structured way to see what the agent did.
Trying it out
The canvas is available as a plugin in the Copilot app:
Open Customise in the Copilot app and navigate to plugins.
Search for “Dependabot Triage Canvas” under Awesome Copilot and enable it.
Ask Copilot to “open the Dependabot triage canvas”.
By default it’ll use the current repository, but you can target a different one by passing { "repo": "owner/name" } when opening the canvas.
You’ll need the GitHub CLI installed and authenticated, as all of the GitHub calls go through gh. Read access is enough for triage, but you’ll need write access to approve, merge, close or comment, and security alert access to see the Dependabot alerts.
Wrapping up
The biggest change for me isn’t any individual button in the canvas. It’s that I can see the shape of the Dependabot work before I start doing it.
Opening it on my blog repo immediately showed me three things: every Dependabot PR is failing checks, most of the open security alerts don’t have a PR, and most of the PRs are going to collide in the same lockfile. That’s a much better starting point than working through PRs one by one.
If you’re dealing with Dependabot queues of your own, give it a try and let me know what you think. The source is on GitHub, and I’d love to hear what other triage workflows would be useful.
AI is making us more productive than ever. But are we becoming better thinkers, or simply getting better at finding answers?
We are living in an extraordinary time. For the first time, we have technology that can write code, analyze information, explain complex concepts, solve mathematical problems, and help us make decisions within seconds. Tasks that once required hours of research, experimentation, and problem-solving can now be completed with a few well-written prompts.
As someone who has spent years in software engineering and now works extensively with AI-assisted development, I find this transformation fascinating. I use AI regularly, and I see firsthand how much it can improve productivity. It has fundamentally changed the way I approach certain problems, explore ideas, and build software.
But the more I use these tools, the more I find myself thinking about something that doesn’t get enough attention.
What happens to our ability to think critically when getting an answer becomes easier than understanding the problem?
I am not particularly concerned that AI will suddenly make people incapable of thinking. Human intelligence doesn’t work that way. What concerns me is something more gradual. We may become so accustomed to receiving immediate, polished answers that we stop exercising some of the mental processes that helped us develop our knowledge and judgment in the first place.
And unlike the dramatic doom’s day predictions that we hear about with AI, this change could happen quietly, through everyday habits.
The Thinking That Happens Before the Answer
Let’s think about how we used to approach problem solving before AI.
When I was learning to code, finding a solution often meant reading documentation, going through forums, experimenting with different implementations in trial and error, debugging errors, and spending hours trying to understand why something wasn’t working.
It wasn’t always efficient. There were plenty of frustrating moments, and I am certainly not suggesting that we should return to a world where developers spend half their day searching Stack Overflow.
But something valuable happened during that process.
Exploring a problem and getting to the solution took time. And when we reached the answer, there was an Ah! Ah! moment that used to give us a dopamine hit! That the hours of hard work paid off.
We also developed an understanding of why certain solutions worked and others didn’t. We began recognizing patterns. We learned how to troubleshoot unfamiliar problems because we had experienced the process of investigating them.
More importantly, we developed judgment.
Judgment is difficult to acquire simply by reading an answer. It develops through experience, comparison, mistakes, reflection, and making decisions when the correct approach isn’t immediately obvious.
Today, AI can eliminate much of that process. You describe a problem and receive a solution. If the solution doesn’t work, you paste the error back into the chat and receive another one. The cycle continues until something works.
The task gets completed, often much faster than before. But there is an important distinction between completing a task and developing the ability to complete similar tasks independently.
And I think that distinction is going to matter alot in the years ahead.
Technology has always made certain mental tasks easier.
Calculators reduced the need for manual arithmetic.
GPS changed how we navigate.
Search engines transformed how we find information.
Each of these technologies allowed us to spend less effort on certain activities and redirect our attention elsewhere.
AI is different in one important way. It doesn’t simply retrieve information or perform predefined calculations. It can produce arguments, interpret evidence, generate solutions, recommend decisions, and explain its reasoning.
In other words, it can perform activities that look remarkably similar to the processes we associate with thinking.
This makes it incredibly useful, but it also creates an interesting problem.
When AI provides a clear, convincing explanation, we may feel as though we understand something simply because the explanation makes sense while we are simply reading it.
Understanding an explanation and being able to independently reason through a problem are not necessarily the same thing.
Imagine reading an AI-generated explanation of a complex architectural decision. It discusses scalability, performance, maintainability, and trade-offs. Everything sounds reasonable, so you accept the recommendation and move forward.
But what happens when the situation changes? What happens when an unexpected constraint appears, or the proposed solution fails in production?
Can you evaluate what went wrong? Can you challenge the original assumptions? Can you develop an alternative without relying entirely on another generated response?
These are the questions that reveal whether we have gained understanding or simply borrowed it.
What Research Suggests About AI and Critical Thinking
In a 2025 study titled The Impact of Generative AI on Critical Thinking, researchers from Microsoft Research and Carnegie Mellon University examined how knowledge workers perceived their use of critical thinking while working with generative AI.
The study involved 319 participants who provided 936 examples of AI-assisted work.
One of the findings was that participants who reported greater confidence in AI tended to report less critical-thinking engagement. Conversely, participants with greater confidence in their own abilities tended to report more critical-thinking engagement.
The researchers also observed a shift in the nature of cognitive work. Rather than spending as much effort generating and analyzing information independently, participants increasingly described their roles as verifying, integrating, and overseeing AI-generated output.
This finding deserves a nuanced interpretation. The study examined self-reported experiences and does not establish that AI directly causes a decline in critical-thinking ability. And reviewing, validating, and integrating information are themselves important forms of critical thinking.
Still, the findings raise a question worth considering.
If our role increasingly becomes evaluating AI-generated work, how do we ensure we develop the expertise necessary to evaluate it well?
Someone who has spent years building software systems may recognize subtle architectural problems in generated code. But what about a developer who has always relied on AI to make those architectural decisions?
If that developer has rarely worked through the trade-offs independently, what foundation will they use to challenge AI’s recommendations?
This is particularly important for people who are still developing expertise. Experienced professionals often have years of knowledge and judgment to draw upon. Beginners are still building that foundation.
AI can accelerate their learning, but only if they use it in ways that encourage understanding rather than simply completing assignments or tasks.
Why Critical Thinking Will Matter Even More for Software Engineers
Software engineering is already experiencing this transformation at an extraordinary pace.
The amount of code a developer can produce in a short period has changed significantly.
But aworking implementation doesn’t automatically mean we have a good design. Passing tests doesn’t guarantee that we have considered all the relevant scenarios. An application that performs well during a demonstration may still have security vulnerabilities, accessibility problems, scalability limitations, or long-term maintenance challenges.
Imagine a developer using AI to build an authentication system. The generated code works, the login flow appears functional, and the basic tests pass. From the outside, everything looks complete.
But has the developer considered session expiration, authorization boundaries, credential storage, token handling, account recovery, and potential attack scenarios? Does the implementation follow the organization’s security requirements? Are the assumptions behind the solution appropriate for the system being built?
The quality of the outcome depends on more than the quality of the generated code. It also depends on the developer’s ability to ask the questions that the AI may not have considered.
This is why I often think about how engineering skills are moving upstream. As code generation becomes easier, the ability to define problems, establish constraints, recognize trade-offs, evaluate architectures, and make informed decisions becomes increasingly important.
The engineer who simply accepts generated solutions may become faster at producing code without necessarily becoming better at engineering systems.
The engineer who uses AI to explore approaches, challenge assumptions, validate decisions, and deepen understanding has the opportunity to become both faster and more capable.
We Need to Preserve the Ability to Struggle With Problems
One of the things I worry about most is our growing discomfort with not having an immediate answer.
Remember the dopamine hit we talked about.
The hours of trying to solve the problem, the hardwork, frustrations, highs and lows invovled in the process. And when you finally are done solving the problem, or achieving your task, the crazy dopamine hit! Well we won’t have that anymore.
AI has made it possible to resolve uncertainty almost instantly. When we encounter something unfamiliar, we can ask a question and receive an explanation in seconds.
That is a wonderful capability. But uncertainty also serves a purpose in learning.
When we don’t immediately know the answer, we begin exploring. We form hypotheses, compare possibilities, test ideas, and revise our understanding. That process is often where deeper learning takes place.
I am not suggesting that frustration is inherently valuable or that spending hours on a simple problem is somehow a superior way of working. There is no intellectual virtue in performing unnecessary repetitive work.
But there is a difference between removing unnecessary friction and removing all opportunities for independent reasoning.
When we are learning a new concept, for example, asking AI for hints rather than a complete solution may be more beneficial. When debugging an unfamiliar issue, attempting to understand the root cause before requesting a fix can help build knowledge that becomes useful later.
And when evaluating a significant decision, spending time developing our own initial perspective before consulting AI may help us avoid becoming overly influenced by its first recommendation.
This requires intentional effort because AI offers something incredibly tempting: a way around the discomfort of not knowing.
But sometimes that discomfort is exactly what motivates us to think more deeply.
How I Think We Should Use AI to Strengthen Critical Thinking
The answer isn’t to stop using AI or artificially make every task more difficult. Instead, I believe we need to become more deliberate about the moments when we allow AI to take over and the moments when we remain actively involved.
One habit I find particularly valuable is developing an initial opinion before asking AI for its recommendation. If I am evaluating an architectural decision, I want to understand the problem, identify the major constraints, and consider potential approaches before asking an AI assistant to analyze the options.
This gives me something to compare its response against. I am not approaching the answer as a blank slate, instead I am more likely to notice when its assumptions differ from mine.
Another important habit is asking AI to challenge ideas rather than simply support them.
Instead of asking whether an approach is good, I can ask what might be wrong with it, what assumptions haven’t been validated, and what circumstances would cause it to fail.
That turns AI into something closer to an intellectual sparring partner.
I also think we should develop a stronger habit of distinguishing between facts, assumptions, and recommendations. AI-generated responses often combine all three into a polished narrative, making them appear equally credible.
But a fact supported by evidence is different from an assumption about how something might behave. And both are different from a recommendation based on a particular interpretation of the situation.
Being able to separate these elements is fundamental to good decision-making.
For consequential decisions, independent verification remains essential. We should examine original sources, review documentation, run tests, validate performance claims, and consult relevant expertise when necessary. Asking AI whether its own answer is correct is not a substitute for verification.
Perhaps one of the simplest practices is to occasionally step away from AI and explain what we have learned in our own words.
If AI helped us understand a new technical concept, can we explain it without reopening the conversation? If it recommended an architectural decision, can we articulate the trade-offs and defend the choice? If it generated code, do we understand how it behaves and why it is appropriate?
If the answer is no, we may need to spend more time developing our understanding.
These practices aren’t about proving that we can work without AI. They are about ensuring that AI continues to expand our capabilities rather than becoming a substitute for them.
They may have access to advanced AI coding assistants from their very first programming assignment. They can generate functioning applications before fully understanding the underlying languages, frameworks, or architectural patterns.
That creates an extraordinary educational opportunity. Someone who previously struggled to begin learning software development can now receive personalized explanations, interactive examples, and immediate feedback.
But it also creates a challenge.
If beginners consistently use AI to bypass the reasoning involved in solving problems, they may complete more work while developing less independent expertise than their apparent productivity suggests.
This isn’t an argument against teaching students to use AI. Quite the opposite.
AI literacy should become part of modern education and professional development.
But we need to teach more than prompt engineering.
We need to teach people how to evaluate generated answers, recognize uncertainty, challenge assumptions, and determine when additional evidence is necessary.
We also need learning experiences that require students to demonstrate understanding rather than merely produce a completed artifact.
A student who can generate a working application has accomplished something. A student who can explain its architecture, diagnose its failures, identify security risks, and adapt it to new requirements has demonstrated a different level of mastery.
In an AI-enabled world, that distinction becomes increasingly important.
The Future Belongs to People Who Know What to Question
We often talk about AI as a technology that is changing the skills people need to succeed.
I agree with that, but I don’t think the transformation is simply about learning new tools or becoming better at writing prompts.
The deeper change is in where human value is created.
When information becomes easy to retrieve and content becomes easy to generate, knowing what to do with that information becomes more important.
When code becomes easier to produce, understanding which code should be written and why becomes more valuable.
When recommendations are available instantly, the ability to evaluate their consequences becomes essential.
And when nearly everyone has access to powerful AI systems, the differentiator may not be who can generate the most answers. It may be who can ask the most meaningful questions, identify the weakest assumptions, and make the best decisions.
I don’t believe AI will inevitably weaken human intelligence. I think it gives us a choice about how we use our own intelligence.
For me, the goal has never been to do everything without AI. I want to use the technology to its fullest potential. I want to automate repetitive work, accelerate development, explore ideas faster, and spend more time on problems that deserve human attention.
But I also want to retain the curiosity to question an answer, the confidence to challenge a recommendation, and the ability to reason independently when necessary.
AI can help us ask better questions, develop deeper understanding, and become better thinkers; if we choose to use it that way.
Research reference: Hao-Ping Lee et al., “The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers,” ACM CHI 2025. https://doi.org/10.1145/3706598.3713778
Linux creator and longtime lead maintainer Linus Torvalds turned to Anthropic’s Claude Code to tackle a kernel performance problem that developers have struggled with for more than two years. On Tuesday, he submitted a 10-patch series that delivered a 23-fold throughput improvement in a synthetic benchmark running on his Ryzen Threadripper.
Torvalds had spent 18 months running a broken version of his own fix for the page-cache reference-counting bottleneck, while other developers had encountered problems with their approaches. The new patches eliminate folio reference-count operations from a common buffered-read path, although Torvalds warned that the benchmark gains would be considerably smaller in real-world workloads.
Reviewers have since identified a race condition and raised concerns about memory reclamation. Torvalds has handed further development to Kiryl Shutsemau, a Linux kernel developer who previously worked on the same bottleneck.
Torvalds had spent 18 months running a broken version of his own fix for the page-cache reference-counting bottleneck, while other developers had encountered problems with their approaches.
Page cache contention problem
On Torvalds’ Core i7-8565U laptop, folio reference-count contention accounted for 99.92% of cross-core load HITMs in eight-thread tests, according to Hardware Busters.
The bottleneck was flagged in 2024 by Matthew Wilcox, an Oracle engineer and longtime Linux kernel memory-management developer, after it surfaced in a customer workload.
Claude Code writes the patches
On Sunday, Phoronix’s Michael Larabel spotted an experimental branch named noref-filemap-read-with-llm in Torvalds’ tree, which rarely contains anything outside the main development branch.
The eight-patch series, based on Linux 7.3-rc6, came with a clear account of what Claude Code did. Torvalds said the assistant wrote the implementation, tests, and initial documentation, and reviewed the code under his direction. He ran the benchmarks himself, despite having previously criticized developers for claiming AI writes 99% of their code.
Earlier approaches copied data without holding a folio reference and checked its validity afterward, leaving races involving reclamation and replacement. The subsequent 10-patch rcu-free-v3 series instead uses a new PG_rcu_free flag and RCU-delayed reclamation to protect the folio through the userspace copy, provided it doesn’t fault.
Earlier approaches copied data without holding a folio reference and checked its validity afterward, leaving races involving reclamation and replacement.
Threadripper benchmark results
The original eight-patch branch nearly tripled throughput on Torvalds’ laptop, pushing eight-thread performance from 10 million to as many as 33 million reads per second while cutting kernel cycles per read from roughly 2,950 to 725. The revised series delivered a much larger gain under heavy contention on his 64-thread Threadripper, where throughput jumped from 13.3 million to 304 million reads per second and cycles per read fell from nearly 20,000 to 735.
The original eight-patch branch nearly tripled throughput on Torvalds’ laptop, pushing eight-thread performance from 10 million to as many as 33 million reads per second while cutting kernel cycles per read from roughly 2,950 to 725.
The performance gains came with trade-offs. In the first implementation, delayed reclamation forced an expedited grace period whenever a CPU queued more than 1,024 pages, according to Hardware Busters. Reads into unmapped user pages also triggered an additional fault before falling back to the existing path, pushing a 16-byte single-thread read from about 4,150 to 6,550 cycles. Whether that regression persists in rcu-free-v3 remains unclear.
Maintainers question the reclamation design
Wilcox questioned the new PG_rcu_free flag and proposed using a page type instead, along with reclaiming inactive-list folios after an RCU grace period.
Torvalds rejected both approaches, arguing that the flag must be set while a folio can still be mapped into userspace and that inactive-list reclamation wouldn’t cover truncate and hole-punch operations. Shutsemau subsequently suggested restricting the flag to 64-bit systems, an approach supported by Arm engineer and Linux memory-management maintainer David Hildenbrand.
Shutsemau also identified a race in filemap_read_rcu_batch(), where folio replacement followed by an extension of i_size could expose data that had never been written. Torvalds recommended moving the file-size read earlier and consolidating the folio checks, which Shutsemau incorporated into a revised patch.
You submit a Kubernetes Job and
wait for its Pods to appear. A minute passes. Then another. The Job is still suspended, there are no
application logs, and there may not even be a Pod to inspect.
In a cluster managed by Kueue, this can be completely normal. Kueue
may still be deciding whether the Job can use the requested resources. The useful question is not
only “Why is the Pod pending?” It is first “Has Kueue admitted the Workload?”
The Kueue plugin for Headlamp brings that
investigation into the Headlamp UI. Instead of reconstructing the admission path from several
commands and large YAML objects, you can begin with the Workload, read its condition message, and
follow links through the LocalQueue, ClusterQueue, ResourceFlavor, and Cohort.
This article follows that Headlamp-first path. The command line appears only in a short optional
section for reproducing the example.
The alpha release provides read-only views for Kueue v1beta2 Cohorts, ClusterQueues, LocalQueues,
ResourceFlavors, and Workloads. It does not add its own create, edit, stop, resume, or delete
workflows. Headlamp still provides its standard YAML and resource actions where your permissions
allow them.
First, separate admission from Pod scheduling
Kueue and the Kubernetes scheduler answer different questions.
Kueue admission: Should this Workload start now, considering queue policy, quota, ResourceFlavors,
admission checks, and other waiting Workloads?
Pod scheduling: After the Workload is admitted and the Job resumes, which nodes can run its Pods?
That boundary changes the investigation. If the Workload is not admitted, stay in the Kueue section
of Headlamp. If it is admitted but its Pods are still Pending, move to Headlamp's normal Job and
Pod views and inspect scheduler events.
Kueue admission architecture
The Headlamp-first troubleshooting path
The quickest investigation starts with the Workload, not with a shell.
Tracing a pending Job through Headlamp
Step 1: Open the Workloads view
In Headlamp, open Kueue → Workloads. Select the namespace that contains the Job, then find the
Workload created for it.
Kueue creates a Workload to represent the
resource request and admission state of a Job. In the alpha plugin, owner references are shown as
Kind/name text but are not yet clickable. The Workload name normally contains the Job name, so the
namespace filter and table search are the simplest ways to locate it.
Before opening the detail page, the list already gives you a useful first scan:
LocalQueue
priority and priority class
active state
admitted state
completion state
a readable current status such as Admitted, Finished, or Inadmissible
age
If there is no matching Workload, check three things before going further: the selected namespace,
whether the Job was submitted to a LocalQueue, and whether your Kubernetes account can list
Workloads. The plugin performs permission checks and displays an access message when the current
identity cannot read a resource.
Step 2: Read status, conditions, and events
Open the Workload. Start with its current status and
conditions,
not with the full YAML.
For admission troubleshooting, the most important condition types are QuotaReserved and
Admitted.
Admitted=True means Kueue has admitted the Workload. The Job can resume, so any remaining
Pending Pods belong to the scheduling branch of the investigation.
QuotaReserved=False with a reason such as Pending means Kueue has not reserved quota. The
condition message explains what prevented the reservation.
An Inadmissible status means the Workload currently cannot fit the available queue
configuration. A missing covered resource, unsuitable ResourceFlavor, stopped queue, or admission
check can all lead you here.
For example, a condition message may report that Kueue could not assign a ResourceFlavor because the
ClusterQueue has insufficient CPU quota. That message is the first real answer to “Why is my Job
still pending?” The rest of the Headlamp journey explains the configuration behind it.
Also check the Events section. Conditions describe the current state; events help show what
recently changed or what Kueue attempted.
Step 3: Compare the Workload's request with its assignment
Stay on the Workload detail page and inspect the PodSets and resource requests. The plugin shows the
requested Pod count, CPU, memory, and other resources that Kueue evaluates together.
This matters because a Job with parallelism: 3 and a one-CPU request per Pod asks Kueue for three
CPUs in total. Looking at only one Pod's template would underestimate the Workload.
If quota has already been reserved, the same page also shows the assigned ClusterQueue,
ResourceFlavors, and admitted resource usage. If those admission assignments are absent, the
Workload has not reached that point yet.
In our example, the Workload requests:
three Pods
three CPUs in total
600 MiB of memory in total
The next question is where that request entered Kueue.
Step 4: Follow the linked LocalQueue
Use the LocalQueue link on the Workload
detail page. A LocalQueue is the namespace-level entry point used by the Job. It connects namespaced
Workloads to a cluster-scoped ClusterQueue.
The LocalQueue page shows:
its namespace and connected ClusterQueue
stop policy and current status
pending, reserving, and admitted Workload counts
Kueue conditions and Kubernetes events
related Workloads in the same namespace
This page answers two practical questions: Did the Job enter the queue you expected, and is it the
only Workload waiting there?
If the LocalQueue is inactive or stopped, that may already explain the wait. If it is active, follow
the linked ClusterQueue to inspect the capacity behind it.
Step 5: Inspect ClusterQueue capacity and usage
A ClusterQueue represents the
cluster-level quota and admission policy available to one or more LocalQueues.
On its Headlamp detail page, compare the Workload request with:
covered resources
nominal quota for each ResourceFlavor
current reservations and usage
borrowing and lending limits
pending, reserving, and admitted Workload counts
queueing strategy and stop policy
preemption, fair-sharing, flavor-fungibility, and admission-check settings
Kueue conditions and Kubernetes events
For the example in this article, the ClusterQueue provides a nominal quota of two CPUs and two Pod
slots. The Workload asks for three of each. The condition message and the ClusterQueue page now tell
the same story: the Workload does not fit, so Kueue leaves the Job suspended.
This is an admission-capacity problem. It is not evidence that kube-scheduler failed to find a node.
Step 6: Check ResourceFlavor and Cohort when needed
Quota is not always a single pool. A
ResourceFlavor can represent a class of
compute through node labels, taints, tolerations, or topology settings. Use the ResourceFlavor link
from the ClusterQueue when the condition mentions flavor assignment or when the Workload requires a
particular hardware class, such as GPU nodes.
If the ClusterQueue belongs to a Cohort, follow
that link too. Cohorts let ClusterQueues share unused quota. The Headlamp page shows parent and
child Cohorts, member ClusterQueues, referenced ResourceFlavors, resource groups, borrowing and
lending limits, and fair-sharing information.
These pages help answer a more subtle question: Is the Workload blocked because the queue has no
quota of its own, because it cannot borrow enough, or because no suitable flavor can be assigned?
What we learned without leaving Headlamp
For the sample pending Job, the UI gives us a complete explanation:
The Workload is not admitted.
Its QuotaReserved condition is false and the message points to insufficient quota.
The Workload requests three CPUs and three Pod slots.
Its LocalQueue is active and points to the expected ClusterQueue.
The ClusterQueue provides only two CPUs and two Pod slots.
Kueue therefore keeps the Job suspended until quota becomes available or the queue configuration
changes.
The important part is not that Headlamp invents a new status. It reads the same Kubernetes API
objects as other clients, then places the related resources and human-readable values in one
connected investigation.
If the Workload is admitted, switch views
Suppose the Workload detail page shows Admitted=True, but the application is still not running.
Kueue has completed its part of the decision. Continue in Headlamp's standard Kubernetes views:
Open Workloads → Jobs and inspect the Job state and events.
Open Workloads → Pods and filter by the Job name or namespace.
Select a Pending Pod and read its Events section.
At this stage, look for scheduler concerns such as insufficient node capacity,
node affinity,
taints and tolerations,
topology constraints, persistent-volume binding, or image-pull failures.
This handoff is the most useful troubleshooting rule in the article:
Not admitted: investigate Kueue resources in Headlamp.
Admitted, but Pods are Pending: investigate Job, Pod, node, and scheduler information in
Headlamp.
A repeatable Headlamp checklist
When the next Job does not start, use this short path:
Open Kueue → Workloads and select the correct namespace.
Find the Workload associated with the Job.
Check the readable status, Admitted, and QuotaReserved conditions.
Read the condition message and recent events.
Compare PodSet resource requests with any admission assignments.
Follow the LocalQueue link and confirm its status and ClusterQueue.
Follow the ClusterQueue link and compare quota, reservations, usage, and policy.
Inspect ResourceFlavor or Cohort details when the message points to flavor selection or shared
quota.
If admitted, move to Headlamp's Job and Pod views.
What Headlamp replaces during this investigation
The plugin does not replace kubectl or
kueuectl for scripts, exact object
output, or changes. It replaces the repetitive UI-less navigation needed during an interactive
investigation.
kubectl get localqueue <localqueue-name> -n <namespace> -o yaml
Which ClusterQueue provides quota?
LocalQueue → linked ClusterQueue
kubectl get clusterqueue <clusterqueue-name> -o yaml
Which flavor or shared quota matters?
ClusterQueue → ResourceFlavor or Cohort
kubectl get resourceflavor <flavor-name> -o yaml or kubectl get cohort <cohort-name> -o yaml
What happened after admission?
Workloads → Jobs and Pods → events
kubectl describe job <job-name> -n <namespace> or kubectl describe pod <pod-name> -n <namespace>
For scripts and GitOps workflows, the command line remains the right tool. For a person asking “why
is this waiting?”, the linked Headlamp path is usually faster to read.
To reproduce the specific quota mismatch used in this article, configure a ClusterQueue with two
CPUs and two Pod slots, then submit a three-Pod Job that requests one CPU per Pod. The Job enters
its LocalQueue, Kueue creates a Workload, and the Workload remains pending because the combined
request is larger than the available quota.
Keeping this setup separate from the main walkthrough is intentional: once the resources exist, the
investigation itself should happen in Headlamp.
Current alpha limitations
The 0.1.0-alpha release is an initial read-only view of the Kueue admission path.
The plugin does not add its own create, edit, pause, resume, or delete flows.
Workload owner references are displayed as text and are not currently navigable.
The UI depends on the Kubernetes permissions of the identity used by Headlamp.
Metrics and a visual relationship map are possible follow-up areas rather than features of this
release.
These limits are useful to state clearly: the plugin's current purpose is to make admission state
and resource relationships easier to inspect.
Developed during LFX Mentorship
The plugin was developed during CNCF LFX Mentorship
2026 Term 2 using TypeScript, React, Kubernetes APIs, and Headlamp's plugin system.
Utkarsh Raj implemented the plugin with guidance and review from René Dudfield
(@illume) and Kevin Hannon (@kannon92).
Feedback from the Headlamp and Kueue communities shaped the resource views, status presentation,
navigation, documentation, tests, and first alpha release.
If a pending Workload is still difficult to explain after following the Headlamp path, that is
exactly the kind of feedback that can improve the plugin.
At Microsoft, our vision is to build a Frontier Firm: one where people and technology work together, combining human expertise, context, and judgment with technology that can extend intelligence throughout everyday work. The potential is significant: helping people create, solve complex problems, and make progress on some of society’s most consequential challenges.
But realizing that potential requires frontier infrastructure. The next phase of Super Intelligence needs a unified infrastructure engine that delivers more intelligence with greater efficiency, making AI more available, reliable, and sustainable across science, healthcare, education, and the economy. This is the work of an entire ecosystem, and precisely the vision we have advanced for years through our industry collaboration within the Open Compute Project Foundation.
Designing silicon in the loop with real workloads
As we enter the next phase of Super Intelligence, inference is becoming the dominant workload and that’s where efficiency, latency, and cost really matter. Azure Maia 300, our next generation AI accelerator from our Maia family, advances the inference efficiency frontier. Maia 300 is a complete system designed for the new types of AI workloads emerging today: long-context reasoning, latency-sensitive conversational experiences, and sustained, multi-step agentic tasks. By improving efficiency across the system, we expect Maia 300 to deliver 40% more tokens per watt compared to leading GPU-based systems. And in a full 96-accelerator configuration, it delivers up to seven times the rack-scale token throughput of Maia 200.
Maia reflects our system co-design approach. It is designed alongside Microsoft infrastructure and production workloads, bringing models, application frameworks, kernels, communication libraries, systems software, and custom silicon into one optimization loop. Maia 200 is deploying across the United States, Europe and Australia and delivering up to 1.7x more tokens per watt for built-in AI capabilities in Microsoft Teams, Copilot and Cowork experiences compared with leading GPU infrastructure.
Azure Maia 200 systems in a datacenter
AI is not only about accelerators. Agentic workloads create entirely new demands on CPUs. Every agent interaction generates orchestration, data retrieval, memory management, and service calls that must occur quickly and efficiently. That is why we designed Cobalt 200 as an agent-native CPU. Cobalt 200 delivers more than 50% performance improvement over Cobalt 100 and reduces agent call latency by 33%, while providing 23% higher throughput on agentic workloads.
Azure Cobalt 200 systems in a datacenter
Maia and Cobalt are designed in the loop with our largest enterprise workloads. That gives Microsoft a unique advantage in tuning performance, reliability, and cost to exactly what customers need in production.
We are applying the same principle to storage and security. The Azure Boost Data Processing Unit moves compression, networking transactions, and security functions away from the CPU onto purpose-built silicon, enabling us to deliver four times more performance while using significantly less power.
And Azure Integrated HSM makes security part of the hardware foundation, with our in-house security chip in all new datacenter servers. It brings cryptographic operations closer to the workload while keeping keys protected inside the hardware security boundary—not exposed in application memory.
Working with industry partners, Microsoft developed Multipath Reliable Connection (MRC), rethinking Ethernet for AI. Its multi-plane architecture scales beyond 100,000 GPUs with two network tiers, reducing power, complexity, failure points, and cost. By intelligently distributing traffic across multiple paths and through packet spraying, MRC limits congestion and maintains reliable performance for frontier-scale training.
We are also advancing open scale-up connectivity through Optical Compute Interconnect Multi-Source Agreement (OCI MSA). OCI, the first optical specification for multi-rack scale-up systems, enables high-bandwidth, power-efficient, multi-vendor infrastructure. Moving forward, we will continue to work with the industry to expand participation in OCI MSA.
In parallel, The Ethernet for Scale-Up Networking (ESUN) workstream brings together more than 175 organizations to define requirements for Ethernet-based scale-up networking. The group has released specification version 1.0 and is developing version 1.1 for later this year. Read more about our networking innovations with the open community.
Rethinking power from grid to silicon
AI infrastructure is also forcing a fundamental redesign of power delivery. Through OCP and the Open Systems for AI initiative, Microsoft is helping advance the industry’s transition toward 800 volt direct current (VDC) infrastructure.
Mt. Diablo, Microsoft’s disaggregated high-voltage datacenter (DC) sidecar architecture, separates power conversion from the compute rack so each can scale independently. It includes a modular design supporting approximately 100 kilowatts (kW) to beyond one megawatt (MW), with redundant feeds, telemetry and optional energy storage. Microsoft, together with OCP partners, contributed Mt. Diablo specifications v0.7 and v1.0 to OCP.
Microsoft and its partners are advancing solid-state transformer-based architectures to make power conversion more efficient, responsive, and scalable for next-generation 800 VDC datacenters. Through OCP’s Clean Backup Power initiative, we are developing open requirements for reliable backup systems that reduce reliance on diesel. In parallel, Microsoft collaborated with partners to release a common grid-interface specification to align utilities, operators, and equipment vendors as hyperscale power architectures evolve. Read more about Microsoft’s approach to 800VDC transition and scaling power infrastructure sustainably.
Cooling as a first-class design consideration
Microsoft approaches cooling as a datacenter-wide challenge, driving innovation from DC facility design to rack-level liquid cooling technologies.
Our third-generation Azure Heat Exchanger Unit, Mt. Atlas, nearly doubles cooling capacity compared to the previous generation while maintaining the same operational footprint. We are also contributing public reference architecture through OCP to help accelerate industry adoption.
At the datacenter level, Microsoft is advancing a zonal cooling strategy in its next-generation AI datacenters to handle the growing mix of liquid-cooled accelerators and traditional air-cooled systems. By tailoring cooling to the specific needs of each workload, and introducing multiple independent water loops, each supplying coolant at different temperatures, we aim to increase efficiency and performance while supporting Microsoft’s energy, carbon, and water reduction goals.
Open hardware security innovation
Microsoft believes strong cloud security is built through openness, transparency, and industry collaboration. This principle is reflected in our founding role in the Confidential Computing Consortium, our work to establish Caliptra as an open-source silicon root of trust, and our contributions to the OCP S.A.F.E. security conformance framework. As AI reshapes the cybersecurity landscape and advances in quantum computing introduce new cryptographic risks, protecting the keys and credentials at the foundation of digital trust has never been more important.
To address these challenges, and building on our commitment to security transparency and industry collaboration, Microsoft, Marvell, and Oracle are introducing Tessera Integrated HSM, an open-source initiative for integrated hardware security modules. Tessera Integrated HSM carries forward the workload direct attached HSM architecture introduced by Azure Integrated HSM, open-sourcing its architecture, specifications, protocols, drivers, software, firmware, and silicon to the broader community. Learn more about Tessera Integrated HSM.
Fleet resiliency at scale
As AI infrastructure scales, fleet reliability is essential to protecting customer workloads, capacity, and service quality. Through OCP, Microsoft has published common RAS, debugging, telemetry, and diagnostics specifications, while contributing work on hardware fault management, CPU and GPU management, and fleet memory fault management. We are using years of fleet data and using AI to validate, predict, and drive fleet actions aimed at preventing faults, pinpointing issues, and recovering more autonomously. Learn more about how Microsoft is advancing fleet reliability through industry collaboration.
Advancing sustainability across the infrastructure stack
Scaling AI responsibly means considering the full datacenter lifecycle to help reach our 2030 commitments to be carbon negative, water positive, and zero waste. As a company, we are committed to incorporating sustainability into how we design, build, and operate our datacenters extending to the communities where we build them. Through OCP, Microsoft is collaborating with partners on low-embodied-carbon steel and concrete—with pathways to reduce concrete emissions by more than 50% per cubic yard.
We are advancing waste-heat reuse, and helping develop Cloud Services Product Category Rules for consistent, auditable lifecycle-carbon reporting. Inside our datacenters, closed-loop liquid cooling, intelligent power management, and renewable-energy agreements help reduce resource use, while Circular Centers reuse or recycle more than 90% of servers and components. Beyond the datacenter, we are investing in local skills, partnerships, and infrastructure so the communities hosting this growth can grow with us. Read Microsoft’s 2026 Environmental Sustainability report.
Building the frontier together
Our vision is to help every organization become a Frontier Firm, uniting human expertise with AI in a continuous learning loop that turns knowledge and ingenuity into scalable intelligence. Realizing that vision requires full-stack co-design: silicon, compute, memory, networking, power, cooling, models, and applications working as one secure, reliable, efficient, and sustainable platform while giving customers choice without passing complexity on to them.
Such a future cannot be realized by a single organization. Through OCP, we are advancing open interfaces, sharing lessons from operating infrastructure at global scale, and collaborating across the industry so innovation moves faster, and the ecosystem stops solving the same problems repeatedly. Together, we can transform frontier innovation into infrastructure that makes intelligence accessible and affordable for every organization, in every industry, and across every region of the world.
At OCP Global Summit 2026, we invite the community to build that future with us.
Build for what’s next
Learn more about Microsoft’s systems approach to infrastructure.
1229. This week, we talk with Ethan Sawyer, the College Essay Guy, about AI and college admissions essays. We look at why admissions officers told him “don’t” when it comes to AI, what he calls the “disembodied voice” of AI writing, and why he rewrote the new editions of his books by hand. Then we look at two pieces of classic essay advice he says to skip, how “finish your ribs” became a standout essay, and how a 10-minute timer can get a stuck writer started.
Log in
