Azure Pipelines has traditionally used a concurrency-based model for Microsoft-hosted agents. You purchase or receive parallel-job capacity, and that capacity determines how many hosted jobs can run at the same time.

Azure DevOps now also provides GitHub-hosted agents for Azure Pipelines with a different pricing model: pay as you go.

With this model, pipeline execution is charged per minute based on the selected agent size. GitHub-hosted agents provide access to larger machine configurations, including Apple Silicon macOS options and larger Linux and Windows machines. The GitHub-hosted Agents pool is separate from the existing Azure Pipelines pool.

For DevOps teams, the important change is not simply the price calculation. It changes how teams should think about pipeline capacity, machine size, cost control, and workload placement.

What Are Hosted Agents?

A hosted agent is a virtual machine provided by the CI/CD platform to execute a pipeline job.

A simplified Azure Pipelines workflow looks like this:

Code
Developer Push
      |
      v
Azure Pipeline
      |
      v
Hosted Agent
      |
      +-- Checkout
      +-- Restore
      +-- Build
      +-- Test
      +-- Publish

With Microsoft-hosted agents, Azure Pipelines traditionally uses a parallelism-based model.

The newer GitHub-hosted agent model works differently:

Code
Pipeline Job
     |
     v
GitHub-hosted Agent
     |
     v
Pay for Execution Minutes

The agent size determines the per-minute rate.

This allows teams to select more powerful machines when a workload actually needs additional CPU, memory, storage, or Apple Silicon.

What Changed With Pay-as-You-Go?

The main difference is the billing model.

Microsoft-hosted agents:

Code
Capacity
   |
   v
Parallel Jobs
   |
   v
Concurrency-Based Billing

GitHub-hosted agents:

Code
Pipeline Execution
   |
   v
Agent SKU
   |
   v
Minutes Used
   |
   v
Pay-as-You-Go

GitHub-hosted agents do not use the existing parallel-job concurrency model. Jobs using this pool are metered by execution time instead.

There is also no free tier or free minutes for GitHub-hosted agents under the pay-as-you-go model.

Existing Pipelines Do Not Automatically Change

This is an important point for teams worried about unexpected billing.

Enabling GitHub-hosted agent billing does not automatically move existing pipelines to the new pool.

Existing pipelines continue using the Microsoft-hosted Azure Pipelines pool unless their configuration is changed to target the GitHub-hosted Agents pool.

The architecture therefore looks like:

Code
                    Azure DevOps
                         |
             +-----------+-----------+
             |                       |
             v                       v
     Azure Pipelines Pool     GitHub-hosted Agents
             |                       |
             v                       v
     Parallelism Model          PAYG Minutes

This gives organizations the option to migrate individual workloads rather than changing everything at once.

How to Use a GitHub-Hosted Agent

After the GitHub-hosted Agents pool is available, a YAML pipeline can explicitly select it.

For example:

Code
pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64'

steps:
  - checkout: self

  - script: |
      uname -a
      sw_vers

The important part is the combination of:

Code
name: 'GitHub-hosted Agents'

and the required VM image.

Microsoft's current documentation includes Apple Silicon macOS images such as macos-26-arm64 and macos-26-arm64-xl.

Why Larger Agents Matter

Not every pipeline needs a large machine.

A small application might run perfectly well on a standard hosted agent.

A large build can be different.

For example:

SQL
Large Repository
      |
      +-- Restore dependencies
      +-- Compile many projects
      +-- Run tests
      +-- Build containers
      +-- Package artifacts

Such a pipeline may benefit from additional CPU, memory, or disk capacity.

The pay-as-you-go model allows the team to select a larger machine for that workload instead of treating every pipeline as if it needs the same hardware.

The goal should be to match compute capacity to workload requirements.

Pay-As-You-Go Does Not Automatically Mean Cheaper

This is one of the most important considerations.

A per-minute model can be attractive when workloads are short or when a team needs specialized hardware only occasionally.

But a pipeline that runs frequently and consumes a large number of minutes can generate significant usage costs.

Consider two simplified workloads:

Code
Pipeline A
10 minutes × 20 runs
= 200 execution minutes

Pipeline B
45 minutes × 200 runs
= 9,000 execution minutes

The second workload needs much more careful cost analysis.

These numbers are only examples, not pricing estimates.

The actual cost depends on the agent SKU and current pricing.

Cost Depends on Agent Size

The pay-as-you-go model ties the rate to the selected agent SKU.

That means your YAML configuration becomes an important cost decision.

For example:

Code
pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64'

and:

Code
pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64-xl'

represent different compute configurations and therefore different billing characteristics.

Do not select the largest machine simply because it makes builds faster.

First determine whether the performance improvement justifies the additional per-minute cost.

A Simple Cost Model

You can estimate pipeline spending with a simple formula:

Code
Estimated Cost =
Pipeline Minutes × Agent Rate

For multiple workloads:

Code
Total Cost =
(Build Minutes × Build Rate)
+
(Test Minutes × Test Rate)
+
(Release Minutes × Release Rate)

For example:

Code
Build:
1,000 minutes × build rate

Tests:
2,000 minutes × test rate

Total:
3,000 billed minutes across the selected SKUs

The exact rates should come from the current Azure DevOps pricing information rather than being hard-coded into internal documentation.

Monitoring Usage

Cost management becomes especially important when teams move from a capacity-oriented model to usage-based billing.

Azure DevOps provides usage information for the GitHub-hosted Agents pool, and usage can also be monitored through Azure Cost Management. Microsoft's current documentation notes that pool analytics can show minutes by project, image, agent SKU, and pipeline.

A useful monitoring structure is:

SQL
Total Minutes
      |
      +-- Project A
      |     |
      |     +-- Pipeline 1
      |     +-- Pipeline 2
      |
      +-- Project B
            |
            +-- Pipeline 3
            +-- Pipeline 4

This makes it easier to identify expensive workloads.

Finding Expensive Pipelines

Suppose a team notices that its monthly CI usage has increased.

Do not immediately reduce the runner size.

First find out what is consuming the minutes.

Look for:

  • Pipelines with unusually long builds

  • Frequently triggered workflows

  • Large test suites

  • Repeated dependency installation

  • Jobs running on oversized machines

  • Pipelines that run when no artifact is produced

  • Duplicate CI work

For example:

Code
Pipeline
   |
   +-- Restore: 8 min
   +-- Build: 5 min
   +-- Test: 35 min
   +-- Package: 3 min

If tests consume most of the time, changing the build machine may not solve the cost problem.

Optimize the expensive stage first.

Use the Right Agent for the Right Workload

Not every pipeline should use the same agent.

For example:

Code
Documentation
      |
      v
Standard Agent

.NET Build
      |
      v
Standard / Larger Agent

Large Native Build
      |
      v
Larger Agent

Apple Silicon Build
      |
      v
macOS ARM64 Agent

This is one of the strongest benefits of the new model.

Compute selection can become workload-specific.

Apple Silicon Workloads

One notable addition is Apple Silicon support for Azure Pipelines through GitHub-hosted agents.

For example:

Code
pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64'

A larger Apple Silicon configuration is also available:

Code
pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64-xl'

These options are useful for workloads that specifically need native ARM64 execution.

This can matter for Apple-platform development and other workloads where architecture compatibility affects the build environment.

Networking Considerations

There is an important limitation when using GitHub-hosted agents.

These agents do not provide direct private connectivity such as ExpressRoute or VPN access to a corporate network. Network traffic to your servers goes over the public network.

That means a pipeline that requires access to an internal-only resource may not be a good candidate.

For example:

Code
GitHub-hosted Agent
       |
       X
Private Internal Database

If the database is accessible only through a private corporate network, a self-hosted or otherwise appropriately connected agent may be more suitable.

Always evaluate network requirements before migrating a pipeline.

Security Considerations

GitHub-hosted agents run on isolated virtual machines and are reimaged after each job. Each VM is dedicated to a single organization and does not retain data between jobs.

That provides useful isolation, but it does not remove all security concerns.

Your pipeline still handles:

  • Source code

  • Package credentials

  • Deployment credentials

  • Signing certificates

  • Environment variables

  • Cloud authentication

Keep secrets in the appropriate secret-management system and expose them only to the jobs that require them.

Also review what external services the pipeline can access.

Microsoft-Hosted vs GitHub-Hosted vs Self-Hosted

The three approaches solve different problems.

Feature

Microsoft-Hosted

GitHub-Hosted PAYG

Self-Hosted

Billing model

Parallel jobs

Per-minute

Infrastructure cost

Machine sizes

Standard

Standard and larger options

Fully customizable

Maintenance

Microsoft

Microsoft

Your team

Fresh VM per job

Yes

Yes

Depends on setup

Custom software

Install during job

Install during job

Can preinstall

Private corporate network

No direct access

No direct access

Possible

Best for

Standard CI

Specialized or larger workloads

Maximum control

GitHub-hosted agents complement rather than replace the Microsoft-hosted Azure Pipelines pool.

Common Mistakes

Assuming Billing Changes Existing Pipelines

It does not.

Pipelines need to explicitly use the GitHub-hosted Agents pool.

Choosing the Largest Agent for Everything

More CPU and memory can reduce runtime, but you pay based on the selected SKU.

Measure first.

Ignoring Pipeline Duration

A five-minute pipeline and a 60-minute pipeline have very different usage profiles.

Forgetting Repeated Triggers

A pipeline running on every commit, pull request, scheduled trigger, and branch update can accumulate significant minutes.

Ignoring Network Requirements

A GitHub-hosted agent may not be suitable if the pipeline requires private corporate network access.

Treating Cost as the Only Decision

The cheapest agent is not always the best option.

Developer productivity, build time, reliability, and required hardware also matter.

Troubleshooting

GitHub-Hosted Agent Pool Is Missing

After enabling billing, the new pool may take time to become available. Microsoft notes that provisioning can take up to 24 hours.

Pipeline Still Uses the Old Agent

Check the YAML:

Code
pool:
  vmImage: 'ubuntu-latest'

This uses the normal Azure Pipelines pool unless you explicitly configure the GitHub-hosted Agents pool.

For the new model:

Code
pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64'

Jobs Are Queued

During the current rollout, availability and concurrency limits can vary by agent SKU. Check the agent pool and current service documentation if jobs remain queued.

Costs Are Higher Than Expected

Start by checking:

  1. Total minutes.

  2. Agent SKU.

  3. Number of pipeline runs.

  4. Average pipeline duration.

  5. Pipelines using larger machines.

  6. Unnecessary repeated builds.

Then optimize the biggest contributor.

Advantages

Flexible Compute

Teams can choose different machine sizes for different workloads.

Usage-Based Billing

You pay based on pipeline execution minutes instead of purchasing parallel capacity for these agents.

Larger Machines

Workloads that need more CPU, memory, or storage have additional options.

Apple Silicon Support

macOS ARM64 agents provide native Apple Silicon environments for supported workloads.

No Runner Maintenance

The hosted environment is managed by Microsoft rather than by your infrastructure team.

Disadvantages and Trade-Offs

Usage Can Become Expensive

Long-running or frequently triggered pipelines can accumulate significant per-minute charges.

No Free Tier

GitHub-hosted agents under the PAYG model do not provide free minutes.

No Private Network Connectivity

They are not designed for direct private connections into corporate networks.

More Cost Decisions in Pipeline Design

The selected machine size now becomes part of the cost model.

Best Practices

  1. Measure current pipeline duration before migrating.

  2. Use the smallest agent that comfortably meets the workload requirements.

  3. Reserve larger agents for workloads that actually benefit from them.

  4. Monitor usage by project, pipeline, and agent SKU.

  5. Use Azure Cost Management for broader cost visibility.

  6. Review frequent triggers and duplicate CI work.

  7. Keep private-network workloads on an appropriate agent type.

  8. Do not assume enabling PAYG changes existing pipelines.

  9. Test the new pool with one or two representative pipelines first.

  10. Set budgets and alerts where appropriate.

  11. Review build optimization before simply increasing machine size.

  12. Document which workloads require specialized agent SKUs.

Final Thoughts

Pay-as-you-go hosted agents change the economics of Azure Pipelines.

Instead of treating compute capacity primarily as a parallel-job decision, teams can choose a specific agent configuration and pay for the pipeline execution time consumed by that workload.

That can be useful when a project needs larger machines, Apple Silicon, or other specialized compute only for certain pipelines. At the same time, usage-based billing makes pipeline duration and trigger frequency more important cost factors.

The right approach is not to move every pipeline to the largest available machine.

Start by measuring. Identify the workloads that need additional compute, choose the smallest suitable agent, and monitor actual usage. For pipelines that require private corporate network access, evaluate self-hosted or other suitable infrastructure instead.

The most important change for DevOps teams is therefore not simply billing. It is the ability to treat CI compute as a workload-specific resource.