Today, we’re announcing the general availability of GitHub-hosted agents and pay-as-you-go pricing in Azure Pipelines.

GitHub-hosted agents give teams access to more compute options for their pipelines, including native Apple silicon and larger Linux and Windows machines. Instead of purchasing parallel-job capacity in advance, you pay only for the pipeline execution time you use, based on the selected agent SKU.

This release includes:

• General availability of GitHub-hosted agents and pay-as-you-go pricing
• General availability of macOS agent SKUs
• Public preview of Linux and Windows agent SKUs

Choose the right compute for each pipeline

The GitHub-hosted Agents pool complements the existing Microsoft-hosted Azure Pipelines pool. It runs on the same infrastructure as GitHub Actions and provides additional hardware configurations, including larger machines with more CPU, memory, and storage.

Each job runs on a fresh, isolated virtual machine. The virtual machine hosts a single agent and is reimaged after the job finishes.

The available SKU families are:

Availability in this table applies to the agent SKU families. For current image labels and the software installed on each image, see the GitHub-hosted agents documentation.

Important The ubuntu-26.04-8-core, ubuntu-26.04-16-core, windows-2025-8-core, and windows-2025-16-core images are still rolling out and aren’t available to every Azure DevOps organization yet. They will become available to more organizations over the next few weeks. The Ubuntu 24.04 and Windows Server 2025 with Visual Studio 2026 images are available to all organizations that have GitHub-hosted agents enabled.

GitHub-hosted agents run in the same regions as Microsoft-hosted agents.

Pay only for the minutes you use

GitHub-hosted agents use pay-as-you-go billing. You’re charged per minute of pipeline execution time, with the per-minute rate determined by the agent SKU.

This model is separate from the parallel-job billing used by Microsoft-hosted agents in the Azure Pipelines pool:

• You don’t need to purchase parallel-job capacity for jobs that run in the GitHub-hosted Agents pool
• GitHub-hosted agent jobs don’t consume your existing parallel jobs
• There is no free tier or allocation of free minutes for GitHub-hosted agents
• Existing pipelines continue to use their current pool unless you explicitly update them

For current rates, see Azure DevOps pricing.

Enable GitHub-hosted agents

To get started, you need permission to configure your organization’s billing settings.

1. In your Azure DevOps organization, go to Organization settings > Billing
2. Set Enable GitHub-hosted agents to On
3. Select Save

Azure DevOps provisions a new GitHub-hosted Agents pool for your organization. Provisioning can take up to 24 hours.

Enabling the pool doesn’t change existing pipelines or start any jobs. Charges begin only when a pipeline runs on a GitHub-hosted agent.

Use a GitHub-hosted agent in a pipeline

Set the pool name to GitHub-hosted Agents and select the VM image label that matches the operating system and SKU you want.

The following example uses a standard macOS agent:

pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'xcode-27-xlarge'

steps:
- bash: |
    echo "Hello from Apple silicon"
    uname -a
    sw_vers
    hostinfo | grep memory

The next example uses an 8-core Linux agent:

pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'ubuntu-24.04-8-core'

steps:
- bash: |
    echo "Hello from Linux"
    echo "Logical processors: $(nproc)"
    free -h

And this example uses a 16-core Windows agent:

pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'windows-2025-vs2026-16-core'

steps:
- pwsh: |
    Write-Host "Hello from Windows"
    Write-Host "Logical processors: $([Environment]::ProcessorCount)"
    Get-ComputerInfo | Select-Object WindowsProductName

For the complete and current list of image labels, see GitHub-hosted agent images.

Monitor usage and costs

You can monitor usage from the Analytics tab of the GitHub-hosted Agents pool. The analytics view shows consumed minutes and lets you filter by agent SKU, project, and pipeline.

Pay-as-you-go usage is also available in Azure Cost Management. You can filter costs by Azure DevOps organization and project, and use Azure Cost Management budgets and alerts to help track spending as more teams adopt the new agents.

Get started

GitHub-hosted agents make it easier to match pipeline compute to your workload. Use native Apple silicon for Apple development, choose larger Linux or Windows machines for compute-intensive builds, and pay only for the execution time you consume.

Enable GitHub-hosted agents in your organization’s billing settings, update a pipeline to use the new pool, and monitor usage as you scale.

To learn more, see:

• GitHub-hosted agents for Azure Pipelines
• Azure DevOps pricing
• Apple silicon and Xcode 27 images available in pay-as-you-go preview

The post GitHub-hosted agents with Pay-as-you-Go pricing are now generally available in Azure Pipelines appeared first on Azure DevOps Blog.

The post From reuse to recycling: How Microsoft manages old datacenter hardware appeared first on Source.

2026-10-01

• Add copilot sandbox ca commands to check, create, trust, rotate, and remove proxy CA trust, including unattended Windows setup; /sandbox ca install becomes create and trust
• Session timelines now clear busy status after interrupted turns finish.
• Sandboxed commands run on Windows versions without filesystem enumeration support, with a warning that PowerShell's current location may be wrong
• Footer text selection stays on the same visible line when the footer grows or shrinks.
• Offer sandbox network bypass for Node/npm EACCES socket denials on Windows
• CLI shutdown flushes pending telemetry before exit, with a bounded delay when telemetry is still initializing.
• Complete, statically analyzable read-only shell pipelines can now enter execution-evidence review, while incomplete or unbound pipelines require explicit approval.

The following article originally appeared on Robert Englander’s blog site and is being reposted here with the author’s permission.

The software industry has become deeply focused on autonomous AI systems. Agents that can replace workers. Agents that can write software. Agents that can operate applications on our behalf. Entire startups are now built around the assumption that the natural end state of AI is autonomy.

Some of this work is genuinely useful. AI-assisted coding can improve productivity. Generative systems are already helping people draft documents, summarize information, and accelerate certain kinds of repetitive work. There are clearly domains where more automation makes sense.

Still, I increasingly suspect the industry may be underestimating another opportunity that feels both more practical and potentially more transformative over the long term: natural language interfaces sitting on top of deterministic software systems.

Much of the current AI narrative assumes the model itself should become the authoritative actor. The AI writes the code. The AI performs the workflow. The AI executes the task. The AI makes the decision. The conversation around “agents” often assumes the system itself should gradually absorb more and more of that responsibility until people become optional.

The problem is that large language models are probabilistic systems. They’re incredibly capable. But they’re still statistical machines. They hallucinate, improvise, approximate. In many contexts, that’s perfectly acceptable.

Brainstorming, summarization, drafting, translation, and exploratory work all tolerate a degree of uncertainty. Deterministic systems generally don’t.

Financial systems have to calculate correctly. Scheduling systems have to preserve consistency. Medical systems have to maintain integrity. Accounting systems have to reconcile accurately. Reliability is still the foundation upon which useful software is built.

That’s one reason I think the most important role for LLMs may not be replacing deterministic systems, but reducing the friction between people and those systems.

Historically, software interfaces forced people to adapt to machine discipline. We learned command syntax. We navigated menus and workflows. We memorized procedures. We filled out forms in exactly the way the application expected. Even graphical interfaces, which were a huge leap forward, still largely required users to think in terms of the structure of the software itself. Natural language interfaces potentially invert that relationship.

Instead of forcing users closer to the system, the system moves closer to human expression. That may sound subtle, but I think it represents a significant shift in how software can be experienced. A user no longer needs to think primarily in terms of application structure or workflow design. The interaction begins to center more naturally around intent.

“Show me how delaying Social Security by two years impacts long-term spending.”

“Transfer $500 from checking into savings next Friday.”

“Why did my tax liability increase this year?”

“Find the contracts signed after January that contain auto-renewal

language.”

None of these requests eliminates the need for deterministic systems underneath. In fact, they depend on them. The natural language layer simply acts as an interpreter between human expression and authoritative execution.

That architecture feels considerably more durable to me than the idea that probabilistic systems should become the primary authority layer themselves.

One interesting thing about the current AI wave is that language models are often strongest in areas involving interpretation. They’re remarkably good at extracting meaning from ambiguous human communication, maintaining conversational context, translating between representations, and helping users express intent more naturally. Those are fundamentally interaction problems.

Meanwhile, the areas where language models remain weakest are usually the areas requiring guarantees, consistency, accountability, and deterministic correctness. Those are system-of-record problems. The current industry conversation often blurs the distinction between the two.

I don’t think conversational interfaces reduce the importance of deterministic software. If anything, they increase it. Once users begin interacting through natural language, the validation layer underneath becomes even more critical. Systems have to safely interpret intent, validate operations, preserve constraints, and maintain correctness even when the incoming requests are conversational and ambiguous.

The conversational layer improves accessibility. The deterministic layer preserves trust.

Both matter.

Every major era of computing has involved some kind of interface transition. Mainframes required specialized operators. Personal computers brought graphical interfaces that made computing accessible to nonspecialists. The web normalized hyperlinks, search, and forms. Mobile computing shifted interaction toward touch and gestures. Natural language may become the next major abstraction layer.

Not because computers suddenly became human-like, but because we finally built systems capable of translating between human communication and machine discipline at scale.

I also think this changes how we should think about software’s future. The current AI environment sometimes frames autonomy as the inevitable destination. If an AI can partially perform a task today, many assume the long-term outcome is full replacement of the person performing that task.

I’m not convinced that’s where the most durable value lies.

In many domains, the real friction isn’t execution. It’s interface complexity. People struggle less with the underlying capabilities of software than with the difficulty of expressing what they actually want the software to do.

Enterprise systems are notoriously difficult to navigate. Financial systems expose overwhelming complexity. Creative tools bury users under layers of workflow and terminology. Even relatively simple applications often require substantial onboarding before users become comfortable with them.

Natural language interfaces potentially change that equation in a meaningful way. They allow software to meet users closer to where they already are: ordinary human communication.

That doesn’t mean conversational systems should become undisciplined systems. In fact, I think the opposite is true. As interfaces become more conversational, the underlying architecture has to become even more rigorous about validation and execution semantics. The ambiguity doesn’t disappear. It moves.

Historically, much of the burden of precision sat on the user. The user had to learn the syntax, understand the workflow, and conform to the application’s structure.

Conversational systems shift more of that burden into the interpretation and validation layers of the software itself. That’s not a trivial engineering problem. It requires clarification, normalization, policy enforcement, validation, and authoritative execution underneath the conversational layer. It also requires accepting that probabilistic interpretation and deterministic execution aren’t competing ideas. They’re complementary ones.

This is one reason I increasingly think the future of software may become conversational without necessarily becoming autonomous. The two ideas are related. But they’re not the same thing.

There’s enormous value in reducing the natural friction between human expression and machine discipline. Large language models may ultimately prove most transformative not when they replace deterministic systems, but when they help people interact with those systems more naturally.

For decades, people have adapted to computers. It now seems possible that software may finally start adapting to people instead.