DEV Community: Microsoft Azure

Understanding GitHub Billing and management: from licenses to fair AI credit controls

Chris Noring — Wed, 12 Aug 2026 13:40:44 +0000

Buying GitHub Copilot licenses is only the beginning of the governance story. The licenses are purchased centrally, but administrators still need to decide who receives a seat, how usage is attributed to the right part of the business, and what happens when included AI credits run out.

Those decisions happen through several related controls:

Copilot seat assignment determines which people are licensed.
Cost centers group attributable usage around a team or business owner.
AI credit included usage caps create boundaries around included credits associated with a cost center's licenses.
Cost-center budgets govern paid usage after included credits are exhausted.
User-level budgets (ULBs) limit how much an individual can consume.

Why does this separation matter? Without it, an administrator can easily mistake one control for another. An included usage cap does not set an overage policy, and a cost-center budget does not guarantee every person an equal share. Each control answers a different question.

This article follows the complete flow, starting before a cost center exists and ending with different policies for Business and Developers, where we place them each in separate cost centers with distinct included-usage boundaries, paid-usage budgets, and ULBs.

Series

This is part of a series on GitHub Admin and billing controls.

Managing surprise bills
Better together: GitHub Admin UI + Billing API
Understanding GitHub Billing and management: from licenses to fair AI credit controls, we're here

Problem 1: A central purchase does not identify who is licensed

Our story starts with a purchase, but purchasing seats does not yet tell us who can use Copilot. This is the first problem to solve because cost centers, budgets, and AI credit controls all depend on GitHub knowing which named users actually hold eligible licenses.

Suppose an enterprise purchases 400 Copilot seats for a workforce that includes 600 employees. The purchase creates a centrally managed pool of seats. It does not automatically license 400 unspecified people, nor does every developer receive a fraction of a license.

At this point, the enterprise knows how many seats it owns, but it cannot yet connect those seats to people, teams, or cost centers.

Solution: Assign seats to named users

An administrator assigns those seats to specific users, either directly or through the supported administrative assignment process. At that point, GitHub can distinguish between:

A person who belongs to the enterprise but has no Copilot seat.
A person who has been assigned an eligible Copilot seat.
A licensed person whose usage is attributable to a particular cost center.

This distinction matters because cost-center included credits are based on attributable eligible licenses, not raw headcount.

For example, imagine a Developers cost center containing 200 people:

Developers in the cost center	Developers with eligible Copilot seats	Licenses that can contribute to the calculation
200	200	200
200	120	120
200	0	0

The cost center does not receive an included-credit boundary based simply on having 200 members. GitHub looks at the eligible licenses attributable to those members and calculates the included amount from those licenses.

NOTE: The exact included-credit amount is calculated by GitHub according to the applicable licenses and product terms. Administrators do not manually divide the enterprise's included credits by cost-center headcount.

Now the enterprise knows who is licensed. That solves entitlement, but it creates the next question: when those users consume AI credits, which part of the business owns that usage?

Fig 1: A developer cost center

Problem 2: Licensed usage has no business owner

A list of licensed users is not yet a governance model. Finance and administrators still need to connect usage to the team, program, or financial owner responsible for it.

Why does this matter? A single enterprise can contain groups with very different usage patterns. Business Operations may have predictable demand, while Developers may run more intensive AI workflows. Treating both groups as one undifferentiated population makes it difficult to protect included usage or govern overage appropriately.

Solution: Use cost centers to establish ownership

Cost centers provide that attribution boundary around resources such as users, teams, or organizations. They do not purchase licenses or assign Copilot seats. Instead, they connect licensed activity to the part of the business responsible for it.

For this scenario, create two cost centers:

Business, containing the relevant Business users or teams.
Developers, containing the relevant engineering users or teams.

GitHub can then determine which eligible Copilot licenses are attributable to each cost center. Conceptually, the relationship is:

Cost-center included credits= ∑(included credits from eligible licenses attributed to that cost center)

This is accounting attribution, not a second license purchase. The enterprise still owns and manages the seats centrally. The cost center tells GitHub where the associated usage and included-credit entitlement belong for governance purposes.

With that ownership structure in place, GitHub can tell which licenses are attributable to Business and which are attributable to Developers. Ownership is now clear, but both groups can still participate in the same included-credit pool. That creates the next risk.

Fig 2: Developers and Business cost centers

Problem 3: One group can consume another group's included credits

By default, included AI credits can function as a shared enterprise resource. That is convenient, but it can produce an uneven outcome: one group may consume included credits funded by licenses associated with another group.

Imagine Developers has an unusually intensive month. Without a separate boundary, its members may continue drawing from the shared pool, reducing the included credits available to Business. Attribution tells us who owns the usage, but attribution alone does not protect either group's share.

Solution: Enable the included usage cap

The AI credit included usage cap changes that behavior for a cost center. When enabled, GitHub calculates an included-credit boundary from the eligible licenses attributable to that cost center.

For example, enable the checkbox for both Business and Developers. Each cost center can then use the included credits calculated from its attributable licenses without the other cost center consuming beyond its own boundary.

The safest way to describe this is:

The cost center receives a protected included-usage boundary calculated from its attributable eligible licenses.

It is tempting to call those credits "guaranteed to me," but that wording can imply more than the control provides. The boundary belongs to the cost center, not to an individual, and it does not guarantee that every member receives an equal allocation.

The shared-pool problem is now addressed, but the checkbox also exposes the next question: what happens after a cost center exhausts its protected included credits? The cap separates included usage; it does not define the paid-usage policy.

Fig 3: Included usage cap checked on a cost center

Problem 4: The included usage cap does not stop overage

Once a cost center reaches its included-credit boundary, additional eligible usage may become paid usage when paid AI credit usage is enabled. A cost-center budget determines how that overage is monitored or stopped.

Why is a separate budget necessary? The included usage cap says, "Do not continue consuming included credits beyond this cost center's calculated boundary." It does not necessarily say, "Block all subsequent usage." A spending control is required to define that second outcome.

Our two cost centers need different outcomes. Business should stop before overage, while Developers should be allowed to continue so the enterprise can observe real demand.

Solution for Business: Use a $0 hard budget

Business should use its included credits but create no overage. Configure a $0 cost-center budget and enable Stop usage when budget limit is reached.

Together, the controls mean:

Business uses the included credits associated with its attributable licenses.
The included usage cap prevents it from drawing beyond its protected included boundary.
The $0 hard budget allows no paid usage after included credits are exhausted.

The $0 budget does not prevent Business from using included credits. It establishes a zero-dollar allowance specifically for the paid-usage phase.

NOTE: If paid AI credit usage is disabled for the entire enterprise, a $0 cost-center budget may be redundant. It becomes important in this scenario because Developers must retain access to paid usage under the same enterprise account.

!Business cost center with a $0 hard budget](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/fw05ktbkv415rph8jm5u.png)

Fig 4: Business cost center with a $0 hard budget

Solution for Developers: Start with a soft budget

Developers need more flexibility. Configure a funded cost-center budget, such as $20,000, but leave Stop usage when budget limit is reached disabled.

This is a soft budget. It provides a target and supports alerts, but it is not a hard ceiling. Usage can continue beyond $20,000 unless another applicable control stops it.

That behavior is useful while the organization learns the team's real demand. Administrators can monitor spending, review whether the usage produces value, and later decide whether to change the amount or turn on the stop control.

At this point, Business and Developers have distinct overage policies:

Cost center	Included usage	Paid-usage budget	Stop usage	Outcome
Business	Protected boundary enabled	$0	Yes	Use included credits, then stop
Developers	Protected boundary enabled	$20,000	No	Use included credits, then allow monitored paid usage

We have now defined what paid usage means for each cost center. However, the Developers budget controls the group total, not the behavior of each person inside the group. One heavy user could still consume a disproportionate amount, which leads to the next problem.

Fig 5: Developers cost center with a $20,000 soft budget and no stop control

Problem 5: An aggregate budget does not create individual fairness

The $20,000 Developers budget gives administrators visibility into aggregate paid usage, but it does not divide that amount fairly among the people in the cost center. A few heavy users could consume most of the available capacity while everyone else remains far below the group budget.

Why add a ULB when Developers already has a $20,000 budget? The two controls operate at different levels:

The $20,000 cost-center budget monitors the Developers group's aggregate paid usage.
A cost-center ULB gives each person in Developers an individual ceiling.

Solution: Add a cost-center ULB

A user-level budget limits one person's total AI credit consumption during the billing cycle. It follows the user across included and paid usage and acts as a hard stop when the applicable limit is reached.

For example, configure a $200-per-user cost-center ULB for Developers. This prevents a small number of heavy users from consuming a disproportionate amount while other users receive little opportunity to work.

The $200 value is a maximum, not a reservation. It does not set aside $200 for every person, and unused capacity from one user is not a personal entitlement that another user can claim. It simply says that each covered user stops when their individual consumption reaches $200.

This makes the policy more predictable and equitable without requiring administrators to create a separate budget for every member of the cost center. The common baseline solves the fairness problem, but a uniform limit can be too restrictive for specialized roles.

Fig 6: Developers cost center with a $200 per-user ULB

Problem 6: One baseline does not fit every role

A shared baseline will not fit every role. A platform engineer, AI lead, or approved power user may have a legitimate need for more capacity than the Developers baseline permits.

Raising the $200 limit for the entire cost center would solve that person's problem by giving everyone more capacity. That is broader than necessary and weakens the fairness policy we just established.

Solution: Add an individual override

For example, create an individual ULB of $400 for softchris. That individual policy takes precedence over the $200 Developers cost-center ULB.

The precedence is:

Individual ULB
Cost-center ULB
Universal ULB

This lets administrators start with a broad enterprise default, apply a more suitable baseline to a cost center, and reserve individual overrides for documented exceptions.

An individual override should still be reviewed. More capacity is not automatically better governance; it should correspond to an approved role or business outcome. We have now solved each problem at the narrowest appropriate scope.

Fig 7: Individual ULB override for a specific user in the Developers cost center

Resolution: See the complete control model

Now that each control has been introduced separately, we can connect them into one end-to-end model.

Purchase Copilot seats centrally. The enterprise or organization owns the seat pool.
Assign seats to named users. This establishes who holds an eligible Copilot license.
Attribute users, teams, or organizations to cost centers. This connects licensed activity to Business or Developers.
Enable the included usage cap. GitHub calculates a protected included-credit boundary from eligible licenses attributable to each cost center.
Set cost-center budgets. Business receives a $0 hard budget; Developers receives a $20,000 soft budget.
Set a cost-center ULB. Developers users receive a $200 individual ceiling.
Add approved exceptions. softchris receives a $400 individual ULB.

The resulting Budgets and alerts view tells a coherent story:

Type	Scope	Amount	Purpose
Cost center	Business	$0, stop enabled	Prevent paid overage after included usage
Cost center	Developers	$20,000, stop disabled	Observe aggregate paid usage without an immediate hard stop
User • Cost Center	Developers	$200 per user	Apply a fair individual baseline across the cost center
User	`softchris`	$400	Preserve an approved individual exception

These four rows do not show the included usage caps themselves; those are configured on the cost-center details. The rows show the controls that govern paid usage and individual consumption after the attribution model has been established.

Checkpoint: Avoid the most common misunderstandings

The controls become easier to operate when their boundaries are explicit. Keep these distinctions in mind:

Purchasing 400 seats does not automatically license an unspecified 400 people. Seats must be assigned to users.
Putting 200 people in a cost center does not mean 200 licenses contribute to its included-credit calculation. Only attributable users with eligible licenses contribute.
An included usage cap does not assign an equal number of credits to every person.
An included usage cap does not, by itself, define the cost center's paid-usage policy.
A soft cost-center budget is an observation and alerting threshold, not a hard ceiling.
A cost-center ULB is a per-user maximum, not a guaranteed allocation for each person.
An individual ULB overrides a broader cost-center or universal ULB for that user.

The easiest way to remember the model is:

Assign the license. Attribute the usage. Protect included credits. Govern paid usage. Limit the individual.

Outcome: Different teams, appropriate controls

Business and Developers now operate under the same enterprise purchase but follow policies suited to their work.

Business can consume the included credits associated with its attributable licenses and then stops before creating paid usage. Developers can continue into paid usage while administrators observe demand against a soft budget. A cost-center ULB prevents a few users from dominating consumption, while individual overrides preserve approved exceptions.

No single checkbox provides all of that behavior. The result comes from combining license assignment, cost-center attribution, included-credit boundaries, spending budgets, and ULBs in the right order.

That order is the practical governance lesson: protect included usage first, decide how paid usage should behave second, and then add per-user controls where fairness or predictability requires them.

GitHub Admin UI + Billing API: Better together for smarter spend decisions

Chris Noring — Mon, 10 Aug 2026 14:42:20 +0000

As a GitHub administrator, you already have a strong place to start when somebody asks, “Why did our AI spend go up?” In Metered usage, you can see the change, choose the period, and group the data by organization or cost center.

That first investigation often leads to questions that are specific to your company. Finance may want a month-end report based on its own reporting calendar. An engineering leader may want to see whether an increase is spread across a team or concentrated among a few people. Answering those questions once is useful; answering them repeatedly calls for a reusable approach.

Series

This is part of a series on GitHub Admin and billing controls.

Managing surprise bills
Better together: GitHub Admin UI + Billing, we're here
Understanding GitHub Billing and management

Use each surface for what it does best

The GitHub admin UI shows you where to look and gives you the controls to respond. The Billing Usage API helps you answer the recurring questions that are specific to your company. Neither replaces the other.

Together, they give administrators a practical loop: spot the change in Metered usage, understand it through a reusable API-powered view, and act with a targeted budget. That means better cost control without treating every user or team as the problem.

Let’s walk through this better-together approach using a common example: AI spend starts to rise, but the reason is not yet clear.

The question: Spend is up, but what is driving it?

Imagine that finance notices an increase in AI spend before the next close. It could be a sign that more developers are getting value from Copilot. It could also be one workload using far more than expected. At this point, nobody knows, and a broad restriction would be premature.

The GitHub administrator needs to help finance and engineering answer three practical questions:

Which part of the business is driving the increase?
Is the spend concentrated among a few users or broadly distributed?
Which control should change without disrupting everyone else?

The goal is not simply to reduce a number. It is to understand the increase well enough to protect useful work while addressing anything unexpected.

1. Start in the admin UI: Find the increase

The admin UI is the natural place to begin because it lets you explore the data before you decide what kind of report or control you need. Open Billing and licensing > Metered usage and select the relevant reporting period.

This first check matters. It confirms that the increase is real, shows when it happened, and gives you a shared starting point for the conversation with finance and engineering.

Fig 01: Metered usage establishes the increase and the period that needs investigation.

Narrow the increase by organization

An enterprise total tells you that spend changed, but not where to look next. Group the usage by organization to see which part of the enterprise contributed most to the increase.

Fig 02: Organization grouping narrows an enterprise-wide increase to an accountable business area.

Suppose the octodemo organization stands out. You now know where to continue the investigation and which leaders can add context. You do not yet know whether the spend is justified, and that distinction matters. The increase could come from successful Copilot adoption, a migration, a seasonal workload, or an automated process that needs attention.

Connect the increase to a cost center

An organization can contain several teams, programs, and budgets. Grouping by cost center takes the investigation one step closer to the people who understand the work behind the spend.

Fig 03: Cost-center grouping identifies the financial owner of the increase.

In this scenario, octodemo-org-cc has the largest increase. In only a few clicks, the admin UI has taken us from an enterprise-wide signal to the cost center that needs a closer look. For a one-time question, this may be enough.

Now imagine that finance asks for the same analysis every month, with a fixed reporting period and a ranking of spend by user. That is the point where the API adds value. It does not replace the investigation you just completed; it helps you repeat and extend it.

2. Continue with the API: Answer the repeatable question

The Billing Usage API gives you access to the data behind a more tailored report. You can use filters to match the period finance cares about, focus on the cost center you found in the UI, and build a view that can run again tomorrow or next month.

Fig 04: Billing usage endpoints and time filters provide the inputs for a reusable report.

Define the reporting question first

Before writing code, state the question the report needs to answer. In this example, it is:

Which users in the selected cost center account for the most net spend during this reporting period?

That one question keeps the report focused. It also determines the workflow:

List the organization's members to establish the candidate users.
Resolve which members belong to the selected cost center.
Query organization AI credit and premium-request usage for those users and the selected period.
Combine the results into a per-user total.
Rank users and aggregate the result by cost center.

The prototype uses year, month, and optional day filters so the output matches the finance period. It also accepts a cost-center filter. Because the admin UI has already pointed us to octodemo-org-cc, there is no reason to start with every member of the enterprise.

Understand the per-user query pattern

There is one API behavior to understand before building the report. The organization billing endpoints return an aggregate when the user filter is omitted. To create a spend-by-user ranking, the workflow makes a filtered request for each selected user and usage type.

For example, this request asks for Eve's AI credit usage in July 2026:

curl -L \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer $GITHUB_TOKEN" \
    -H "X-GitHub-Api-Version: 2026-03-10" \
    "https://api.github.com/organizations/octodemo/settings/billing/ai_credit/usage?year=2026&month=7&user=eve"

The response contains one or more usage items, with amounts such as grossAmount, discountAmount, and netAmount. The prototype adds the netAmount values to calculate Eve's AI credit total for the period. It then runs the equivalent premium-request query and combines the two totals.

We can now see one user's contribution during the same period we investigated in the UI. Repeating the request for the members of the selected cost center gives us the ranking that finance asked for.

For a production workflow, a few practical details matter:

Limit the candidate list to the cost center under investigation.
Paginate organization membership and cost-center results.
Use bounded concurrency instead of sending every request at once.
Record partial failures rather than silently treating them as zero spend.
Keep an audit record of when the data was pulled and transformed.

For a daily check, the report can use a narrow period and write a timestamped output. At finance close, the same workflow can produce the month-end rollup. The question stays the same; only the reporting window changes.

Reveal concentration that totals can hide

The result is a custom Spend by User view that brings the organization, cost center, reporting period, AI credit usage, premium-request usage, and total net spend into one place.

Fig 05: A company-specific dashboard exposes per-user concentration inside the selected cost center.

In the illustrative data, the octodemo organization has 22 users and $3,651 in total net spend for July 2026. The octodemo-org-cc cost center accounts for $2,700 of that amount. Two users stand out:

User	AI credit net spend	Premium-request net spend	Total net spend
`eve`	$900	$600	$1,500
`adam`	$600	$400	$1,000

Together, Adam and Eve account for $2,500 of the $2,700 attributed to that cost center. That is approximately 93% of its total in this example.

These figures are demonstration data, but they show why the extra view is useful. Instead of reacting to a $2,700 cost-center total, the administrator can talk to the owners of two workloads and understand what the spend supported.

Concentration does not automatically mean waste. Adam and Eve may be doing approved, high-value work. The dashboard tells the business where to ask the next question; the people involved provide the context needed to answer it.

3. Return to the admin UI: Choose the right control

The API has helped us understand the increase, but it does not make the decision for us. Return to Billing and licensing > Budgets and alerts to review the available controls and choose the narrowest one that fits what you learned.

Fig 06: Budget scopes turn the investigation into a targeted governance decision.

Set a cost-center user-level baseline

A cost-center user-level budget applies the same per-user amount to every current and future member of that cost center. This is useful when the group needs a different baseline from the rest of the enterprise.

For example, the administrator might give octodemo-org-cc additional per-user headroom because its work legitimately uses more AI credits. This avoids raising the universal user-level budget for everyone.

A user-level budget counts both included and paid AI credit usage. It is always a hard stop for the individual. It does not reserve part of the shared pool, and it does not replace the cost center's paid-usage budget.

Preserve justified exceptions

If Adam or Eve has an approved role that requires more capacity, an individual user-level budget can replace the cost-center baseline for that person. The exception stays limited to the person who needs it instead of increasing the budget for the whole cost center.

Fig 07: Cost-center baselines and individual overrides preserve useful work without widening access for everyone.

The precedence is straightforward:

An individual user-level budget overrides the cost-center user-level budget.
The cost-center user-level budget overrides the universal user-level budget.

In practice, you can set a universal baseline, add more headroom for a cost center with a clear business need, and use individual overrides for documented exceptions.

Why the UI and API work better together

At this point, the better-together pattern becomes clear:

Metered usage supports interactive discovery.
Billing Usage API supports repeatable, company-specific analysis.
Budgets and alerts supports targeted policy decisions.

Each surface does the job it is best suited to do. The UI makes it easy to explore and manage GitHub. The API lets you repeat a company-specific analysis without rebuilding it by hand. Used together, they give finance, engineering, and administrators the same evidence before a control changes.

Make it part of the operating rhythm

A useful dashboard should lead to a useful conversation. Decide who receives the report, how often they review it, and what happens when a user or cost center stands out.

For example:

Run a daily pull to detect unusual changes early.
Produce a month-end rollup aligned to finance close.
Route cost-center summaries to the relevant business owner.
Review high-consumption users with engineering before changing limits.
Record approved individual overrides and revisit them regularly.

Over time, the conversation can move from “Who spent this?” to “What outcome did this spend support, and does the current policy still fit?”

When the same users repeatedly appear at the top, leaders can inspect the workload, remove waste, validate business value, or approve more capacity. When usage becomes broadly distributed, the cost-center baseline may need adjustment instead. The report makes those patterns visible over time.

The better-together workflow at a glance

The story above introduces each surface when it becomes useful. This table summarizes their roles.

Surface	Primary role	Best used for	Important limitation
Metered usage	Interactive investigation	Finding the affected period, organization, and cost center	Manual exploration is not a reusable company-specific report
Billing Usage API	Programmatic usage retrieval	Scheduled reporting, time-sliced analysis, and per-user views	Per-user attribution requires filtered requests and careful handling of pagination and failures
Custom Spend by User view	Company-specific interpretation	Ranking users and aligning usage to internal ownership	Concentration is evidence to investigate, not proof of waste
Budgets and alerts	Governance controls	Cost-center baselines and individual overrides	A broader budget cannot override a user who has reached their ULB

The practical takeaway is simple: begin with exploration, automate only the question worth repeating, and adjust policy after the data has context. That sequence keeps governance precise while preserving useful AI work.

Learn more

Turning surprise AI bills into accountable growth with GitHub Billing Controls

Chris Noring — Mon, 27 Jul 2026 18:44:11 +0000

This is a story of how you receive a higher bill than expected and how GitHub's Billing Controls help clarity and predictability. Let's begin our story.

Series

This is part of a series on GitHub Admin and billing controls.

Managing surprise bills, you're here
Better together: GitHub Admin UI + Billing API
Understanding GitHub Billing and management

Confusion: The bill is higher than expected

The AI bill is higher than expected. Now what?

Finance wants to understand what is driving the cost. Engineering leaders, on the other hand, want to preserve the productivity gains behind the increased usage. The administrator needs to balance both priorities and put a policy in place that the business can understand.

One question drives the investigation:

Where is the increase coming from, and how do we control it without disrupting valuable work?

To answer it, we first need to follow the spend. Once we know who owns it, we can apply guardrails at the right level.

Investigation: Follow the spend

Setting a limit too early could restrict useful adoption without addressing the main source of cost. So, let's find out what changed and who can act on it.

The investigation begins in the billing administration portal, where usage and budget settings appear in one place.

Fig 01: A unified billing workspace connects usage evidence to budget controls.

Identify the consumption category

First, we identify which product changed. GitHub reports this by SKU, which simply means the billing category for a product or service.

Fig 02: Grouping metered usage by billing category highlights Copilot Enterprise usage.

Grouping usage by billing category shows which product is driving the increase. In this example, the chart points to Copilot Enterprise usage. Leaders can then ask whether that growth comes from valuable adoption, an unusual workload, or demand that has outgrown its budget.

Locate the accountable organization

Once you know which product is driving the cost, find out who owns the usage. An enterprise-wide total can hide a sharp increase in one organization.

Fig 03: Organization-level grouping identifies the business unit accountable for demand.

The organization view points to the leader who can connect that usage to business results, estimate future demand, and decide what to do next.

Connect usage to a cost center

An organization may still be too broad. A cost center is a billing group that connects usage to the team, program, or function responsible for the cost.

Fig 04: Cost-center analysis reveals concentrated usage averaging about $20,000 per month.

Here, one cost center accounts for most of the AI credit usage and averages about $20,000 per month. That gives leaders a practical starting point. A $20,000 alert may suit normal demand, while a growth team, seasonal workload, or strategic migration may need more headroom, or more room to spend before reaching the limit. The right amount depends on expected usage, financial risk, and the value the work creates.

The investigation has now produced an answer: most of the increase comes from one cost center spending about $20,000 per month. The next question is what to do about it.

Resolution: Put guardrails in place

Rather than place one restrictive limit on everyone, the administrator can add guardrails at three levels: across the organization, for the cost center driving the increase, and for individual users who need a different limit.

The Budgets and alerts page is where those decisions become policy.

Fig 05: The Budgets and alerts page provides the New budget action.

Let's start with the broadest guardrail and then make it more specific.

Set a boundary for shared paid usage

An organization budget gives finance a clear limit for usage charges. License costs are separate and do not count toward this amount.

Fig 06: A $200,000 organization budget establishes a configurable boundary for paid usage.

The $200,000 organization budget shown here is an example. The right amount depends on expected usage, available included credits, growth plans, and what would happen if paid usage stopped. This shared budget applies only to additional paid usage after included credits are used. It does not include license costs.

There is one timing detail to keep in mind: if you create the budget partway through a billing cycle, GitHub does not count usage from earlier in that cycle. The first bill can therefore exceed the displayed $200,000 limit.

The Stop usage when budget limit is reached toggle controls what happens next. Leave it off and GitHub sends notifications while usage continues. Turn it on and affected paid usage stops at the limit. GitHub Copilot code completions and next edit suggestions still work because they do not use this paid AI credit allowance. A blocked request also does not automatically switch to a cheaper model.

Create accountable room for a cost center

The organization budget covers shared paid usage across the organization. A cost-center budget gives a specific team an earlier warning.

Fig 07: A $20,000 cost-center threshold monitors current demand without stopping usage.

In this example, the administrator sets a $20,000 alert and leaves the stop toggle off. The owner can review the workload, remove waste, or ask for a higher limit before usage is interrupted.

The same timing rule applies here: if the budget is created partway through the billing cycle, earlier usage is not counted. The first bill can therefore exceed the displayed $20,000 limit.

Fig 08: Threshold alerts route emerging cost risk to owners before month-end.

Alerts give people time to act. Finance can review expected spending, the cost-center owner can explain the increase, and the administrator can adjust the limit or turn on stopping if needed.

Give different users the right limits

Shared budgets do not control how many AI credits one person can use. Per-user budgets do. They count both included and paid credits, and they always stop further AI-credit use when the person's limit is reached.

Set these limits from broad to specific:

Establish a universal per-user baseline, the starting limit for every licensed user.
Add a cost-center exception where a group's expected outcomes justify a different limit.
Add an individual override, a replacement limit for one person, only for a role with a documented need.

Fig 09: A $200 per-user cost-center exception adds targeted headroom without raising the enterprise baseline.

The screenshot shows the second step: a $200 per-user limit for one cost center. Start with the universal baseline, then add an individual override only when someone has a clear need for a different amount. This keeps exceptions easy to review and avoids raising the limit for everyone just to support one specialist.

Explain which user limit takes priority

What happens when several limits cover the same user? Precedence is simply the order GitHub follows to choose the user-level budget that applies.

Fig 10: Policy precedence applies individual overrides before cost-center and universal user limits.

Among user-level budgets, the individual override comes first, followed by the cost-center per-user budget and then the universal baseline. For example, imagine a $100 universal baseline, a $200 cost-center limit, and a $500 individual override. The specialist gets $500, colleagues in that cost center get $200 each, and everyone else gets $100 each.

Shared organization and cost-center limits still apply separately. Whichever relevant limit is reached first blocks further usage. A person may still have money left in an individual budget when the shared limit has already been reached. The reverse can also happen: a person's limit may stop their usage while the shared budget still has room.

Aftermath: Keep the policy working

Setting the limits is only the start. Someone still needs to review what happens next.

Finance can see where paid usage is limited. Business owners can see which costs they own. Engineering leaders can see where exceptions protect important work. Included-pool controls protect shared credits, organization and cost-center budgets limit additional paid usage, and per-user budgets set individual limits.

Assign someone to review alerts, blocked requests, approved exceptions, and business results on a regular schedule. When a team repeatedly reaches its limit, that owner can look for waste, compare usage with results, and recommend a change. Finance and engineering leaders can then approve the change or step in when cost and delivery needs conflict.

With those responsibilities clear, finance can see the cost, business leaders can own it, and administrators can adjust the controls before the next surprise bill arrives.

A quick reference to the controls

The story above introduces each control when it becomes useful. This table collects the technical differences in one place for reference.

Control	What it does	What it counts	What happens at the limit
Organization or cost-center budget	Monitors or limits shared paid usage	Additional paid usage after included credits are used; license costs are excluded	Sends alerts, or stops affected paid usage when stopping is enabled
Included AI credit pool	Protects the credits included with licenses assigned to a cost center	Shared included AI credits calculated by GitHub	Blocks more AI-credit use, or allows paid usage when paid usage is enabled
Per-user budget	Limits one person's total AI-credit use	Included and paid AI credits for that user	Always stops more affected usage

When an included AI credit pool runs out, administrators can block further AI-credit use or allow it to continue as paid usage, as long as paid usage is enabled. Some reductions to the pool take effect in the next billing cycle, so check the timing before relying on a lower limit.

Learn more

Getting started with GitHub Copilot part 2, streamable responses

Chris Noring — Mon, 16 Mar 2026 20:14:28 +0000

I'm sure you've seen many AI apps where you sit tight for 30s or and you wonder if things are stuck? Not a great experience right? Yes, you're right, you deserve better, so how do we fix it?

Type your prompt> Tell me a joke
.
.
.
.
.
.
.
.
Why could I never find the atoms, cause they split..

Series on Copilot SDK

This series is about Copilot SDK and how you can leverage your existing GitHub Copilot license to integrate AI into your apps

Part 1 - install and your first app
Part 2 - streamable response, you're here

Addressing the problem

By streaming the response, the response now arrives in chunks, pieces that you can show as soon as they arrive. How can we do that though and how can GitHub Copilot SDK help out?

Well, there's two things you need to do:

Enable streaming. You need to set streaming to True when you call create_session.
Listen for events that contains a chunk. Specifically, you need to listen to ASSISTANT_MESSAGE_DELTA and print out the chunk.

# 1. Enable streaming
session = await client.create_session({
        "model": "gpt-4.1",
        "on_permission_request": PermissionHandler.approve_all,
        "streaming": True,
    })

print("Starting streamed response:")

# Listen for response chunks
def handle_event(event):
    if event.type == SessionEventType.ASSISTANT_MESSAGE_DELTA:
        // 2. Chunk arrived, print it
        sys.stdout.write(event.data.delta_content)
        sys.stdout.flush()
    if event.type == SessionEventType.SESSION_IDLE:
        print()  # New line when done

Here's what the full application looks like:

import asyncio
import sys
from copilot import CopilotClient, PermissionHandler
from copilot.generated.session_events import SessionEventType

async def main():
    client = CopilotClient()
    await client.start()

    session = await client.create_session({
        "model": "gpt-4.1",
        "on_permission_request": PermissionHandler.approve_all,
        "streaming": True,
    })

    print("Starting streamed response:")

    # Listen for response chunks
    def handle_event(event):
        if event.type == SessionEventType.ASSISTANT_MESSAGE_DELTA:
            sys.stdout.write(event.data.delta_content)
            sys.stdout.flush()
        if event.type == SessionEventType.SESSION_IDLE:
            print()  # New line when done

    session.on(handle_event)

    print("Sending prompt...")
    await session.send_and_wait({"prompt": "Tell me a short joke"})

    await client.stop()

if __name__ == "__main__":
    asyncio.run(main())

That's it folks, now go out and build better experiences for your users.

Get started with GitHub Copilot CLI: A free, hands-on course

Renee Noble — Thu, 05 Mar 2026 04:44:08 +0000

GitHub Copilot has grown well beyond code completions in your editor. It now lives in your terminal, too. GitHub Copilot CLI lets you review code, generate tests, debug issues, and ask questions about your projects without ever leaving the command line.

To help developers get up to speed, we put together a free, open source course: GitHub Copilot CLI for Beginners. It’s 8 chapters, hands-on from the start, and designed so you can go from installation to building real workflows in a few hours. Already have a GitHub account? GitHub Copilot CLI works with GitHub Copilot Free, which is available to all personal GitHub accounts.

In this post, I’ll walk through what the course covers and how to get started.

What GitHub Copilot CLI can do

If you haven’t tried it yet, GitHub Copilot CLI is a conversational AI assistant that runs in your terminal. You point it at files using @ references, and it reads your code and responds with analysis, suggestions, or generated code.

You can use it to:

Review a file and get feedback on code quality
Generate tests based on existing code
Debug issues by pointing it at a file and asking what’s wrong
Explain unfamiliar code or confusing logic
Generate commit messages, refactor functions, and more
Write new app features (front-end, APIs, database interactions, and more)

It remembers context within a conversation, so follow-up questions build on what came before.

What the course covers

The course is structured as 8 progressive chapters. Each one builds on the last, and you work with the same project throughout: a book collection management app. Instead of jumping between isolated snippets, you keep improving one codebase as you go.

Here’s what using GitHub Copilot CLI looks like in practice. Say you want to review a Python file for potential issues. Start up Copilot CLI and ask what you’d like done:

$ copilot
> Review @samples/book-app-project/books.py for potential improvements. Focus on error handling and code quality.

Copilot reads the file, analyzes the code, and gives you specific feedback right in your terminal.

Here are the chapters covered in the course:

Quick Start — Installation and authentication
First Steps — Learn the three interaction modes: interactive, plan, and one-shot (programmatic)
Context and Conversations — Using @ references to point Copilot at files and directories, plus session management with --continue and --resume
Development Workflows — Code review, refactoring, debugging, test generation, and Git integration
Custom Agents — Building specialized AI assistants with .agent.md files (for example, a Python reviewer that always checks for type hints)
Skills — Creating task-specific instructions that auto-trigger based on your prompt
MCP Servers — Connecting Copilot to external services like GitHub repos, file systems, and documentation APIs via the Model Context Protocol
Putting It All Together — Combining agents, skills, and MCP servers into complete development workflows
learning path image

Every command in the course can be copied and run directly. No AI or machine learning background is required.

Who this is for

The course is built for:

Developers using terminal workflows: If you’re already running builds, checking git status, and SSHing into servers from the command line, Copilot CLI fits right into that flow.
Teams looking to standardise AI-assisted practices: Custom agents and skills can be shared across a team through a project’s .github/agents and .github/skills directories.
Students and early-career developers: The course explains AI terminology as it comes up, and every chapter includes assignments with clear success criteria.

You don’t need prior experience with AI tools. If you can run commands in a terminal, you learn and apply the concepts in this course.

How the course teaches

Each chapter follows a consistent pattern: a real-world analogy to ground the concept, then the core technical material, then hands-on exercises. For instance, the three interaction modes are compared to ordering food at a restaurant. Plan mode is more like mapping your route to the restaurant before you start driving. Interactive mode is a back-and-forth conversation with a waiter. And one-shot mode (programmatic mode) is like going through the drive-through.

Later chapters use different comparisons: agents are like hiring specialists, skills work like attachments for a power drill, and MCP servers are compared to browser extensions. The goal is to provide you with a visual and mental model before the technical details land.

The course also focuses on a question that’s harder than it looks: when should I use which tool? Knowing the difference between reaching for an agent, a skill, or an MCP server takes practice, and the final chapter walks through that decision-making in a realistic workflow.

Get started

The course is free and open source. You can clone the repo, or open it in GitHub Codespaces for a fully configured environment. Jump right in, get Copilot CLI running, and see if it fits your workflow.

GitHub Copilot CLI for Beginners

For a quick reference, see the CLI command reference.

Subscribe to GitHub Insider for more developer tips and guides.

Get started with GitHub Copilot SDK, part 1

Chris Noring — Wed, 04 Mar 2026 20:48:00 +0000

Did you know GitHub Copilot now has an SDK and that you can leverage your existing license to build AI integrations into your app? No, well I hope I have you attention now.

Series on Copilot SDK

This series is about Copilot SDK and how you can leverage your existing GitHub Copilot license to integrate AI into your apps

Part 1 - install and your first app, you're here
Part 2 - streamable responses

Install

You need two pieces here to get started:

GitHub Copilot CLI
A supported runtime, which at present means either Node.js, .NET, Python or Go

Then you need to install the SDK for your chosen runtime like so:

pip install github-copilot-sdk

The parts

So what do you need to know to get started? There are three concepts:

Client, you need to create and instance of it. Additionally you need to start and stop it when you're done with it.
Session. The session takes an object where you can set things like model, system prompt and more. Also, the session is what you talk when you want to carry out a request.
Response. The response contains your LLM response.

Below is an example program using these three concepts. As you can see we choose "gpt-4.1" as model but this can be changed. See also how we pass the prompt to the function send_and_wait.

import asyncio
from copilot import CopilotClient

async def main():
    client = CopilotClient()
    await client.start()

    session = await client.create_session({"model": "gpt-4.1"})
    response = await session.send_and_wait({"prompt": "What is 2 + 2?"})

    print(response.data.content)

    await client.stop()

asyncio.run(main())

Ok, now that we know what a simple program looks like, let's make something interesting, an FAQ responder.

Your first app

An FAQ for a web page, is often a pretty boring read. A way to make that more interesting for the end user is if they can instead chat with the FAQ, let's make that happen.

Here's the plan:

Define a static FAQ
Add the FAQ as part of the prompt.
Make a request to to the LLM and print out the response.

Let's build out the code little by little. First, let's define the FAQ information.

-1- FAQ information

# faq.py

faq = {
  "warranty": "Our products come with a 1-year warranty covering manufacturing defects. Please contact our support team for assistance.",
  "return_policy": "We offer a 30-day return policy for unused products in their original packaging. To initiate a return, please visit our returns page and follow the instructions.",     
  "shipping": "We offer free standard shipping on all orders over $50. Expedited shipping options are available at checkout for an additional fee.",
}

Next, let's add the call to the Copilot SDK

-2 Adding the LLM call


import asyncio
from copilot import CopilotClient

def faq_to_string(faq: dict) -> str:
    return "\n".join([f"{key}: {value}" for key, value in faq.items()])

async def main(user_prompt: str = "Tell me about shipping"):
    client = CopilotClient()
    await client.start()

    prompt = f"Here's the FAQ, {faq_to_string(faq)}\n\nUser question: {user_prompt}\nAnswer:"   

    session = await client.create_session({"model": "gpt-4.1"})
    response = await session.send_and_wait({"prompt": prompt})

    print(response.data.content)

    await client.stop()

if __name__ == "__main__":
    print("My first app using the GitHub Copilot SDK!")
    print(f"[LOG] Asking the model about shipping information...")
    asyncio.run(main("Tell me about shipping"))

Note how we concatenate the FAQ data with the user's prompt:

 prompt = f"Here's the FAQ, {faq_to_string(faq)}\n\nUser question: {user_prompt}\nAnswer:"

-3- Let's run it

Now run it:

uv run faq.py

You should see output like so:

My first app using the GitHub Copilot SDK!
[LOG] Asking the model about shipping information...
We offer free standard shipping on all orders over $50. Expedited shipping options are available at checkout for an additional fee.

What's next

Check out the official docs

The JavaScript AI Build-a-thon Season 2 starts March 2!

Julia Muiruri — Wed, 25 Feb 2026 04:09:06 +0000

Most applications used by millions of people every single day are powered by JavaScript/TypeScript. But when it comes to AI, most learning resources and code samples assume you're working in Python and will leave you trying to stitch scattered tutorials together to build AI into your stack.

The JavaScript AI Build-a-thon is a free, hands-on program designed to close that gap. Over the course of four weeks (March 2 - March 31, 2026), you'll move from running AI 100% on-device (Local AI), to designing multi-service, multi-agentic systems, all in JavaScript/ TypeScript and using tools you are already familiar with.
The series will culminate in a hackathon, where you will create, compete and turn what you'll have learnt into working projects you can point to, talk about and extend.

How the program works!

The program is organized around 2 phases: -

Phase I: Learn & Skill Up Schedule (Mar 2 - 13)

Self-paced quests that teach core AI patterns,
Interactive Expert-led sessions on Microsoft Reactor (Livestreams) and Discord (Office hours & QnA)

Day/Time (PT)	Topic	Links to join
Mon 3/2, 8:00 AM PST	Local AI Development with Foundry Local	Livestream Discord Office Hour
Wed 3/4, 8:00 AM PST	End-to-End Model Development on Microsoft Foundry	Livestream Discord Office Hour
Fri 3/6, 9:00 AM PST	Advanced RAG Deep Dive + Guided Project	Livestream Discord Office Hour
Mon 3/9, 8:00 AM PST	Design & Build an Agent E2E with Agent Builder (AITK)	Livestream Discord Office Hour
Wed 3/11, 8:00 AM PST	Build, Scale & Govern AI Agents + Guided project	Livestream Discord Office Hour

The Build-a-thon prioritizes practical learning, so you'll complete 2 guided projects by the end of this phase:-

1. A Local Serverless AI chat with RAG
Concepts covered include: -

RAG Architecture
RAG Ingestion pipeline
Query & Retrieval
Response Generation (LLM Chains)

2. A Burger Ordering AI Agent
Concepts covered include: -

Designing AI Agents
Building MCP Tools (Backend API Design)

Phase II: Global Hack! (Mar 13 - 31)

Product demo series to showcase the latest product features that will accelerate your builder experience
A Global hackathon to apply what you learn into real, working AI solutions

This is where you'll build something that matters using everything learnt in the quests, and beyond, to create an AI-powered project that solves a real problem, delights users, or pushes what's possible.

The hackathon launches on March 13, 2026. Full details on registration, submission, judging criteria, award categories, prizes, and the hack phase schedule will be published when the hack goes live. Stay tuned!

But, here's what we can tell you now:

🏆 6 award categories
💻 Product demo showcases throughout the hack phase to keep you building with the latest tools
👥 Teams of up to 4 or solo. Your call

Start Now (Join the Community)

Join our community to connect with other participants and experts from Microsoft &. GitHub to support your builder journey.

Foundry Discord (#js-ai-build-a-thon channel): Our platform for office hours, live QnA, quick questions, community & expert support
GitHub Discussions: This is where you'll share ideas, ask questions, find teammates
Social: Share your progress online using #JSAIBuildathon

See you soon!

Host Your Node.js MCP Server on Azure Functions in 1 Simple Step

Yohan Lasorsa — Tue, 09 Dec 2025 15:44:53 +0000

Building AI agents with the Model Context Protocol (MCP) is powerful, but when it comes to hosting your MCP server in production, you need a solution that's reliable, scalable, and cost-effective. What if you could deploy your regular Node.js MCP server to a serverless platform that handles scaling automatically while you only pay for what you use?

Let's explore how Azure Functions now supports hosting MCP servers built with the official Anthropic MCP SDK, giving you serverless scaling with almost no changes in your code.

Grab your favorite hot beverage, and let's dive in!

TL;DR key takeaways

Azure Functions now supports hosting Node.js MCP servers using the official Anthropic SDK
Only 1 simple configuration needed: adding host.json file
Currently supports HTTP Streaming protocol with stateless servers
Serverless hosting means automatic scaling and pay-per-use pricing
Deploy with one command using Infrastructure as Code

What will you learn here?

Understand how MCP servers work on Azure Functions
Configure a Node.js MCP server for Azure Functions hosting
Test your MCP server locally and with real AI agents
Deploy your MCP server with Infrastructure as Code and AZD

Reference links for everything we use

Model Context Protocol - Official MCP documentation
Azure Functions - Serverless compute platform
Anthropic MCP SDK - Official TypeScript SDK
Azure Developer CLI - One-command deployment tool
Full sample project - Complete burger ordering system with MCP
Simple example - Minimal MCP server starter
GitHub Copilot prompt helper - Automated setup by Anthony Chu

Requirements

Node.js 22 or higher
Azure account (free signup, or if you're a student, get free credits here)
Azure Developer CLI (for deployment)
GitHub account (optional, for using Codespaces)

What is MCP and why does it matter?

Model Context Protocol is an open standard that enables AI models to securely interact with external tools and data sources. Instead of hardcoding tool integrations, you build an MCP server that exposes capabilities (like browsing a menu, placing orders, or querying a database) as tools that any MCP-compatible AI agent can discover and use. MCP is model-agnostic, meaning it can work with any LLM that supports the protocol, including models from Anthropic, OpenAI, and others. It's also worth noting that MCP supports more than just tool calls, though that's its most common use case.

The challenge? Running MCP servers in production requires infrastructure. You need to handle scaling, monitoring, and costs. That's where Azure Functions comes in.

🚨 Free course alert! If you're new to MCP, check out the MCP for Beginners course to get up to speed quickly.

Why Azure Functions for MCP servers?

Azure Functions is a serverless compute platform that's perfect for MCP servers:

Zero infrastructure management: No servers to maintain
Automatic scaling: Handles traffic spikes seamlessly
Cost-effective: Pay only for actual execution time (with generous free grant)
Built-in monitoring: Application Insights integration out of the box
Global distribution: Deploy to regions worldwide

The new Azure Functions support means you can take your existing Node.js MCP server and deploy it to a production-ready serverless environment with minimal changes. This comes up as an additional option for native Node.js MCP hosting, but you can still use the Azure Functions MCP bindings that were available before.

1 simple step to enable Functions hosting

Let's break down what you need to add to your existing Node.js MCP server to run it on Azure Functions. I'll use a real-world example from our burger ordering system.

If you already have a working Node.js MCP server, you can just follow this to make it compatible with Azure Functions hosting.

Step 1: Add the `host.json` configuration

Create a host.json file at the root of your Node.js project:

{
  "version": "2.0",
  "configurationProfile": "mcp-custom-handler",
  "customHandler": {
    "description": {
      "defaultExecutablePath": "node",
      "arguments": ["lib/server.js"]
    },
    "http": {
      "DefaultAuthorizationLevel": "anonymous"
    },
    "port": "3000"
  }
}

Note: Adjust the arguments array to point to your compiled server file (e.g., lib/server.js or dist/server.js), depending on your build setup. You can also change the port if needed to match your server configuration.

The hosts.json file holds metadata configuration for the Functions runtime. The most important part here is the customHandler section. It configures the Azure Functions runtime to run your Node.js MCP server as a custom handler, which allows you to use any HTTP server framework (like Express, Fastify, etc.) without modification (tip: it can do more than MCP servers! 😉).

There's no step 2 or 3. That's it! 😎

Note: We're not covering the authentication and authorization aspects of Azure Functions here, but you can easily add those later if needed.

Real-world example: Burger MCP Server

Let's look at how this works in practice with a burger ordering MCP server. This server exposes 9 tools for AI agents to interact with a burger API:

get_burgers - Browse the menu
get_burger_by_id - Get burger details
place_order - Place an order
get_orders - View order history
And more...

Here's the complete server implementation using Express and the MCP SDK:

import express, { Request, Response } from 'express';
import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
import { getMcpServer } from './mcp.js';

const app = express();
app.use(express.json());

// Handle all MCP Streamable HTTP requests
app.all('/mcp', async (request: Request, response: Response) => {
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: undefined,
  });

  // Connect the transport to the MCP server
  const server = getMcpServer();
  await server.connect(transport);

  // Handle the request with the transport
  await transport.handleRequest(request, response, request.body);

  // Clean up when the response is closed
  response.on('close', async () => {
    await transport.close();
    await server.close();
  });

  // Note: error handling not shown for brevity
});

// The port configuration
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Burger MCP server listening on port ${PORT}`);
});

The MCP tools are defined using the official SDK:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

export function getMcpServer() {
  const server = new McpServer({
    name: 'burger-mcp',
    version: '1.0.0',
  });

  server.registerTool(
    'get_burgers',
    { description: 'Get a list of all burgers in the menu' },
    async () => {
      const response = await fetch(`${burgerApiUrl}/burgers`);
      const burgers = await response.json();
      return {
        content: [{
          type: 'text',
          text: JSON.stringify(burgers, null, 2)
        }]
      };
    }
  );

  // ... more tools
  return server;
}

As you can see, the actual implementation of the tool is forwarding an HTTP request to the burger API and returning the result in the MCP response format. This is a common pattern for MCP tools in enterprise contexts, that act as wrappers around one or more existing APIs.

Current limitations

Note that this Azure Functions MCP hosting currently has some limitations: it only supports stateless servers using the HTTP Streaming protocol. The legacy SSE protocol is not supported as it requires stateful connections, so you'll either have to migrate your client to use HTTP Streaming or use another hosting option, like using containers for example.

For most use cases, HTTP Streaming is the recommended approach anyway as it's more scalable and doesn't require persistent connections. Stateful MCP servers comes with additional complexity challenges and have limited scalability if you need to handle many concurrent connections.

Testing the MCP server locally

First let's run the MCP server locally and play a bit with it.

If you don't want to bother with setting up a local environment, you can use the following link or open it in a new tab to launch a GitHub Codespace:

Create Codespace

This will open a VS Code environment in your browser with the repo already cloned and all the tools installed and ready to go. Otherwise you can just clone the repo.

Once you have the code ready, open a terminal and run:

# Install dependencies
npm install

# Start the burger MCP server and API
npm start

This will start multiple services locally, including the Burger API and the MCP server, which will be available at http://localhost:3000/mcp. This may take a few seconds, wait until you see this message in the terminal:

🚀 All services ready 🚀

We're only interested in the MCP server for now, so let's focus on that.

Using MCP Inspector

The easiest way to test the MCP server is with the MCP Inspector tool:

$ npx -y @modelcontextprotocol/inspector

Open the URL shown in the console in your browser, then:

Set transport type to Streamable HTTP
Enter your local server URL: http://localhost:3000/mcp
Click Connect

After you're connected, go to the Tools tab to list available tools. You can then try the get_burgers tool to see the burger menu.

Using GitHub Copilot (with remote MCP)

Configure GitHub Copilot to use your deployed MCP server by adding this to your project's .vscode/mcp.json:

{
  "servers": {
    "burger-mcp": {
      "type": "http",
      "url": "http://localhost:3000/mcp"
    }
  }
}

Click on "Start" button that will appear in the JSON file to activate the MCP server connection.

Now you can use Copilot in agent mode and ask things like:

"What spicy burgers do you have?"
"Place an order for two cheeseburgers"
"Show my recent orders"

Copilot will automatically discover and use the MCP tools! 🎉

Tip: If Copilot doesn't call the burger MCP tools, try checking if it's enabled by clicking on the tool icon in the chat input box and ensuring that "burger-mcp" is selected. You can also force tool usage by adding #burger-mcp in your prompt.

(Bonus) Deploying to Azure with Infrastructure as Code

Deploying an application to Azure is usually not the fun part, especially when it involves multiple resources and configurations.
With the Azure Developer CLI (AZD), you can define your entire application infrastructure and deployment process as code, and deploy everything with a single command.

If you've used the automated setup with GitHub Copilot, you should already have the necessary files. Our burger example also comes with these files pre-configured. The MCP server is defined as a service in azure.yaml, and the files under the infra folder defines the Azure Functions app and related resources.

Here's the relevant part of azure.yaml that defines the burger MCP service:

name: mcp-agent-langchainjs

services:
  burger-mcp:
    project: ./packages/burger-mcp
    language: ts
    host: function

While the infrastructure files can look intimidating at first, you don't need to understand all the details to get started. There are tons of templates and examples available to help you get going quickly, the important part is that everything is defined as code, so you can version control it and reuse it.

Now let's deploy:

# Login to Azure
azd auth login

# Provision resources and deploy
azd up

Pick your preferred Azure region when prompted (if you're not sure, choose East US2), and voilà! In a few minutes, you'll have a fully deployed MCP server running on Azure Functions.

Once the deployment is finished, the CLI will show you the URL of the deployed resources, including the MCP server endpoint.

Example projects

The burger MCP server is actually part of a larger example project that demonstrates building an AI agent with LangChain.js, that uses the burger MCP server to place orders. If you're interested in the next steps of building an AI agent on top of MCP, this is a great resource as it includes:

AI agent web API using LangChain.js
Web app interface built with Lit web components
MCP server on Functions (the one we just saw)
Burger ordering API (used by the MCP server)
Live order visualization
Complete Infrastructure as Code, to deploy everything with one command

But if you're only interested in the MCP server part, then you might want to look at this simpler example that you can use as a starting point for your own MCP servers: mcp-sdk-functions-hosting-node is a server template for a Node.js MCP server using TypeScript and MCP SDK.

What about the cost?

Azure Functions Flex Consumption pricing is attractive for MCP servers:

Free grant: 1 million requests and 400,000 GB-s execution time per month
After free grant: Pay only for actual execution time
Automatic scaling: From zero to hundreds of instances

The free grant is generous enough to allow running a typical MCP server with moderate usage, and all the experimentation you might need. It's easy to configure the scaling limits to control costs as needed, with an option to scale down to zero when idle. This flexibility is why Functions is my personal go-to choice for TypeScript projects on Azure.

Wrap up

Hosting MCP servers on Azure Functions gives you the best of both worlds: the simplicity of serverless infrastructure and the power of the official Anthropic SDK. With just one simple configuration step, you can take your existing Node.js MCP server and deploy it to a production-ready, auto-scaling platform.

The combination of MCP's standardized protocol and Azure's serverless platform means you can focus on building amazing AI experiences instead of managing infrastructure. Boom. 😎

Star the repos ⭐️ if you found this helpful! Try deploying your own MCP server and share your experience in the comments. If you run into any issues or have questions, you can reach for help on the Azure AI community on Discord.

Serverless MCP Agent with LangChain.js v1 — Burgers, Tools, and Traces 🍔

Yohan Lasorsa — Tue, 21 Oct 2025 16:09:46 +0000

AI agents that can actually do stuff (not just chat) are the fun part nowadays, but wiring them cleanly into real APIs, keeping things observable, and shipping them to the cloud can get... messy. So we built a fresh end‑to‑end sample to show how to do it right with the brand new LangChain.js v1 and Model Context Protocol (MCP). In case you missed it, MCP is a recent open standard that makes it easy for LLM agents to consume tools and APIs, and LangChain.js, a great framework for building GenAI apps and agents, has first-class support for it.

This new sample gives you:

A LangChain.js v1 agent that streams its result, along reasoning + tool steps
An MCP server exposing real tools (burger menu + ordering) from a business API
A web interface with authentication, sessions history, and a debug panel (for developers)
A production-ready multi-service architecture
Serverless deployment on Azure in one command (azd up)

Yes, it’s a burger ordering system. Who doesn't like burgers? Grab your favorite beverage ☕, and let’s dive in for a quick tour!

TL;DR key takeaways

New sample: full-stack Node.js AI agent using LangChain.js v1 + MCP tools
Architecture: web app → agent API → MCP server → burger API
Runs locally with a single npm start, deploys with azd up
Uses streaming (NDJSON) with intermediate tool + LLM steps surfaced to the UI
Ready to fork, extend, and plug into your own domain / tools

What will you learn here?

What this sample is about and its high-level architecture
What LangChain.js v1 brings to the table for agents
How to deploy and run the sample
How MCP tools can expose real-world APIs

Reference links for everything we use

Use case

You want an AI assistant that can take a natural language request like “Order two spicy burgers and show me my pending orders” and:

Understand intent (query menu, then place order)
Call the right MCP tools in sequence, calling in turn the necessary APIs
Stream progress (LLM tokens + tool steps)
Return a clean final answer

Swap “burgers” for “inventory”, “bookings”, “support tickets”, or “IoT devices” and you’ve got a reusable pattern!

Sample overview

Before we play a bit with the sample, let's have a look at the main services implemented here:

Service	Role	Tech
Agent Web App (`agent-webapp`)	Chat UI + streaming + session history	Azure Static Web Apps, Lit web components
Agent API (`agent-api`)	LangChain.js v1 agent orchestration + auth + history	Azure Functions, Node.js
Burger MCP Server (`burger-mcp`)	Exposes burger API as tools over MCP (Streamable HTTP + SSE)	Azure Functions, Express, MCP SDK
Burger API (`burger-api`)	Business logic: burgers, toppings, orders lifecycle	Azure Functions, Cosmos DB

Here's a simplified view of how they interact:

There are also other supporting components like databases and storage not shown here for clarity.

For this quickstart we'll only interact with the Agent Web App and the Burger MCP Server, as they are the main stars of the show here.

LangChain.js v1 agent features

The recent release of LangChain.js v1 is a huge milestone for the JavaScript AI community! It marks a significant shift from experimental tools to a production-ready framework. The new version doubles down on what’s needed to build robust AI applications, with a strong focus on agents. This includes first-class support for streaming not just the final output, but also intermediate steps like tool calls and agent reasoning. This makes building transparent and interactive agent experiences (like the one in this sample) much more straightforward.

Quickstart

Requirements

GitHub account
Azure account (free signup, or if you're a student, get free credits here)
Azure Developer CLI

Deploy and run the sample

We'll use GitHub Codespaces for a quick zero-install setup here, but if you prefer to run it locally, check the README.

Click on the following link or open it in a new tab to launch a Codespace:

Create Codespace

This will open a VS Code environment in your browser with the repo already cloned and all the tools installed and ready to go.

Provision and deploy to Azure

Open a terminal and run these commands:

# Install dependencies
npm install

# Login to Azure
azd auth login

# Provision and deploy all resources
azd up

Follow the prompts to select your Azure subscription and region. If you're unsure of which one to pick, choose East US 2.
The deployment will take about 15 minutes the first time, to create all the necessary resources (Functions, Static Web Apps, Cosmos DB, AI Models).

If you're curious about what happens under the hood, you can take a look at the main.bicep file in the infra folder, which defines the infrastructure as code for this sample.

Test the MCP server

While the deployment is running, you can run the MCP server and API locally (even in Codespaces) to see how it works. Open another terminal and run:

npm start

This will start all services locally, including the Burger API and the MCP server, which will be available at http://localhost:3000/mcp. This may take a few seconds, wait until you see this message in the terminal:

🚀 All services ready 🚀

When these services are running without Azure resources provisioned, they will use in-memory data instead of Cosmos DB so you can experiment freely with the API and MCP server, though the agent won't be functional as it requires a LLM resource.

MCP tools

The MCP server exposes the following tools, which the agent can use to interact with the burger ordering system:

Tool Name	Description
`get_burgers`	Get a list of all burgers in the menu
`get_burger_by_id`	Get a specific burger by its ID
`get_toppings`	Get a list of all toppings in the menu
`get_topping_by_id`	Get a specific topping by its ID
`get_topping_categories`	Get a list of all topping categories
`get_orders`	Get a list of all orders in the system
`get_order_by_id`	Get a specific order by its ID
`place_order`	Place a new order with burgers (requires `userId`, optional `nickname`)
`delete_order_by_id`	Cancel an order if it has not yet been started (status must be `pending`, requires `userId`)

You can test these tools using the MCP Inspector. Open another terminal and run:

npx -y @modelcontextprotocol/inspector

Then open the URL printed in the terminal in your browser and connect using these settings:

Transport: Streamable HTTP
URL: http://localhost:3000/mcp
Connection Type: Via Proxy (should be default)

Click on Connect, then try listing the tools first, and run get_burgers tool to get the menu info.

Test the Agent Web App

After the deployment is completed, you can run the command npm run env to print the URLs of the deployed services. Open the Agent Web App URL in your browser (it should look like https://<your-web-app>.azurestaticapps.net).

You'll first be greeted by an authentication page, you can sign in either with your GitHub or Microsoft account and then you should be able to access the chat interface.

From there, you can start asking any question or use one of the suggested prompts, for example try asking: Recommend me an extra spicy burger.

As the agent processes your request, you'll see the response streaming in real-time, along with the intermediate steps and tool calls. Once the response is complete, you can also unfold the debug panel to see the full reasoning chain and the tools that were invoked:

Tip: Our agent service also sends detailed tracing data using OpenTelemetry. You can explore these either in Azure Monitor for the deployed service, or locally using an OpenTelemetry collector. We'll cover this in more detail in a future post.

Wrap it up

Congratulations, you just finished spinning up a full-stack serverless AI agent using LangChain.js v1, MCP tools, and Azure’s serverless platform. Now it's your turn to dive in the code and extend it for your use cases! 😎 And don't forget to azd down once you're done to avoid any unwanted costs.

Going further

This was just a quick introduction to this sample, and you can expect more in-depth posts and tutorials soon.

Since we're in the era of AI agents, we've also made sure that this sample can be explored and extended easily with code agents like GitHub Copilot.
We even built a custom chat mode to help you discover and understand the codebase faster! Check out the Copilot setup guide in the repo to get started.

If you like this sample, don't forget to star the repo ⭐️! You can also join us in the Azure AI community Discord to chat and ask any questions.

Happy coding and burger ordering! 🍔

What’s in a Name? Fuzzy Matching for Real-World Data

Renee Noble — Fri, 17 Oct 2025 00:47:36 +0000

🎥 Watch the full PyCon AU 2025 talk here

When you work with human-entered data (registrations, surveys, customer forms, you name it!) you soon discover that people are very creative typists. Names, schools, companies, and addresses come in with abbreviations, nicknames, missing words, and typos galore.

That mess makes it hard to answer even simple questions like: “Do these two records refer to the same person?” or “How many participants came from this organisation?”

At PyCon AU 2025, I explored how different fuzzy matching techniques, from traditional algorithms to generative AI, can help make sense of that chaos.

The Fuzzy Matching Challenge

String comparison looks straightforward until you meet real-world data. “PLC Sydney” might really be “Presbyterian Ladies’ College Sydney.” “Certain Collage” is obviously a typo for “Certain College” (hopefully). And nicknames like Liz, Lizzy, and Elizabeth might all belong to the same person.

That’s where fuzzy matching comes in, using a variety of techniques we can rank how similar different non-identical words are to try and find the most likely match. But the question is, what fuzzy matching algorithms are best suited for matching what types of data? And can generative AI play a part in this matching game?

Comparing Algorithmic Approaches

I put six Python libraries to the test:

TextDistance and Python-Levenshtein – classic edit-distance approaches.
FuzzyWuzzy and RapidFuzz – hybrids that combine multiple distance metrics.
Nicknames and PyNameMatcher – specialised tools for given-name variations.

To test them, I generated around 100 fake student names with nicknames, misspellings, and swapped orderings. Then I measured how accurately each library matched them to their correct counterparts.

RapidFuzz came out ahead, matching almost every record correctly, and doing it fast! The edit-distance methods struggled most with multicultural names where order or character sets varied, and the nickname libraries were strong but less consistent overall.

When Generative AI Shines

Algorithmic fuzzy matching is fast and accurate, but it only looks at characters, not meaning. That’s where I turned to Azure OpenAI Service for a different kind of help.

By feeding in real school-name data, I found that straight out of the box GPT-5 was exceptionally good at recognising and correcting school names, especially when they were abbreviated, misspelled, or included local school nicknames.

For example, it could confidently map:

“PLC Syd” → “Presbyterian Ladies’ College Sydney”
“Cerdon Collage” → “Cerdon College”
“St Cats” → “St Catherine’s School, Waverley”

That level of contextual correction is almost impossible to achieve with pure algorithmic matching unless you maintain a custom dictionary of every possible variation. And who has time for that!

The trade-off, of course, is performance. Generative models are slower and costlier to run at scale. But when used selectively, just for ambiguous or hard-to-match cases, they can dramatically improve accuracy. And of course this is something this specifically works well for names, like schools, that are well documented on the internet – something that doesn’t apply to the names of individual school students.

Can we have the best of both worlds?

hybrid AI + Algorithmic matching!

In practice, the best results came from a hybrid approach, using traditional fuzzy-matching algorithms for most cases, and bringing in Azure OpenAI only when the names got tricky. For example, RapidFuzz could quickly match “Lizzy Wong” to “Elizabeth Wong,” while the generative model was better at reasoning through ambiguous inputs like “Sally-Anne W.” or reversed multicultural name orders. By combining both, I could match almost every student record accurately, keeping the speed of algorithmic methods while adding the contextual understanding of generative AI.

Try It Yourself

🎥 You can watch my full PyCon AU 2025 talk here:
What’s in a Name: Fuzzy Matching Techniques for Proper Nouns

📁 If you’d like to explore this further you can check out my fuzzy matching repo.

Take a look at the libraries and tool I mentioned above, they’re easy to install and experiment with in Python. If you’re already using Azure OpenAI, it’s worth testing how a small retrieval-augmented setup might complement your existing matching logic.

Chat to us!

💬 To chat more about AI solutions you can join the AI Foundry Discord, where advocates like me are chatting about the latest tools all the time.

Join the Azure AI Foundry Discord here

Good luck on your fuzzy matching adventures!

A Better Way to Tune the JVM in Dockerfiles and Kubernetes Manifests

Bruno Borges — Fri, 12 Sep 2025 03:36:26 +0000

When tuning the JVM inside containers, I often see Dockerfiles and Kubernetes manifests with long, hard-to-read java commands packed with -Xmx, -XX:+UseG1GC, and other flags. Every time you want to tweak memory or GC settings, you have to edit those commands and rebuild or redeploy.

Free webinar Java on Kubernetes Performance Engineering

Running Java on Kubernetes? It's harder - and more critical - than you think. Join us September 25th, 2025, for a live webinar with Akamas & Microsoft on tuning Java apps at scale. JVM tips, GC tuning, JDK 25, Project Leyden & more.

What about JAVA_OPTS?

This flag is not read by the JVM itself. It only works if the launch script explicitly uses it and expands its content into the call to the java launcher. It behaves exactly the same as Apache Tomcat's CATALINA_OPTS, which is read by catalina.sh.

There’s a much cleaner way to do this... and it’s built into the JDK. It’s the most modern, well-scoped solution, playing well with deployment orchestration solutions like Kubernetes.

🚀 Enter JDK_JAVA_OPTIONS

JDK_JAVA_OPTIONS is an environment variable that the JVM reads automatically. Whatever you put there gets appended to the command line of every JDK tool (java, javac, jshell, etc.) This means you can move all your tuning flags out of your launcher command, keeping your Dockerfiles and manifests clean and maintainable.

Cleaned-up Dockerfile

Before (messy):

CMD ["java", "-Xmx512m", "-XX:+UseG1GC", "-jar", "app.jar"]

After (clean):

ENV JDK_JAVA_OPTIONS="-Xmx512m -XX:+UseG1GC"
CMD ["java", "-jar", "app.jar"]

Now, if you need to change heap size or GC settings, you just update the environment variable. No need to touch the command.

Kubernetes Example

If your container is likely to end up on Kubernetes, don't even tune the JVM in the Dockerfile. Consider leaving this as an external configuration, coming from the Kubernetes manifest.

This is because the container image doesn't know what memory limits will be applied during runtime. And even if you set a MaxRAMPercentage for the heap, the amount you set may not be ideal if the container ends up with too much memory, potentially wasting memory from the delta not used, for example.

containers:
  - name: myapp
    image: myapp:latest
    env:
      - name: JDK_JAVA_OPTIONS
        value: "-Xmx512m -XX:+UseG1GC"

Your deployment YAML stays clean and your operations team can tune JVM behavior at deploy time without changing the image.

Why JDK_JAVA_OPTIONS Is Better

✅ Cleaner Manifests – fewer arguments to maintain
🔄 Configurable at Runtime – no rebuild required
🛠 Debug-Friendly – JVM prints the options it picked up
🐳 Perfect for Containers – works across Docker, Kubernetes, ECS, etc.
🎯 Applies to All JDK Tools – not just java, but also javac, jshell, etc.

If you’re running Java apps in Docker or Kubernetes, stop hardcoding JVM flags into your command line. Use JDK_JAVA_OPTIONS instead. It makes your images cleaner, your manifests easier to read, and your JVM tuning more flexible.

Precedence, Order of Priority, and Scope

The HotSpot JVM supports, in practice, three environment variables. And for many historical reasons we ended up in this situation.

But in what order are they processed, and where? The rule of thumb is below. Except that in JDK 8, the variable JDK_JAVA_OPTIONS is not supported.


_JAVA_OPTIONS > JDK_JAVA_OPTIONS > JAVA_TOOL_OPTIONS

Besides the order they are processed, there is also where they are processed and how this impacts what parameters are effective.

According to the bug JDK-8170832:

_JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variable are interpreted by the VM, not the launcher [java], hence no @-files or launcher-only options. The former is undocumented and unsupported but widely used; the latter is documented and supported.

You can see for yourself the behaviour of these environment variables with this little project I built (with GitHub Copilot): github.com/brunoborges/jdk-env-vars

Thoughts?

What JVM tuning tricks are you using in containers today?
Have you tried JDK_JAVA_OPTIONS yet?
Did you know about it?

Comment below.

Resources

OpenJDK 21: JAVA_TOOL_OPTIONS documentation
OpenJDK 21: JDK_JAVA_OPTIONS documentation
JDK-8170832: Add a new launcher environment variables

Model Mondays S2E04 - AI Developer Experiences

Nitya Narasimhan, Ph.D — Fri, 11 Jul 2025 03:25:13 +0000

🧪 | Some parts of this blog were generated with AI assistance, and reviewed manually before publishing. To learn more about the why and the how, please refer to this document in our website.

Model Mondays is a weekly series that helps you build your AI Model IQ with 5-min news recaps, 15-min tech spotlights and 30-min AMA sessions with subject matter experts. Join us!

Register for upcoming livestreams (Mon @1:30pm ET)

Register for upcoming AMAs (Fri @1:30pm ET)

Subscribe to the weekly newsletter

Explore Season 1 & Season 2 episodes on our repo!

⁉️ | Have questions on the AI TOOLKIT EXTENSION FOR VS CODE

Download the AI Toolkit and try it!

Join the AMA on Friday, Jul 11 on the Azure AI Foundry Discord.

Visit recaps & resources on the Forum to keep learning.

Spotlight On: AI Developer Experiences

In this episode we got to see a hands-on demo from Leo Yao, a Product Manager for the AI Toolkit, who took us through the various tools and capabilities that this extension brings to Visual Studio Code, to streamline our AI development journey. If you missed the livestream, you can catch up on the recap here:

What You'll Learn

So why should you watch this episode? Simple! If you wanted to see how you could streamline your AI Developer Experience without ever leaving Visual Studio Code, then the AI Toolkit is the extension you want to explore. In the space of just 15 minutes, I got to see Leo complete the following tasks, all within the IDE!

Discover & use GitHub Models with a built-in playground feature.
Deploy models (GPT-4) to Azure AI Foundry directly from VS Code.
Build AI agents with Agent Builder (to createa a math tutor)
Configure agents with prompts & tools (for an escape room helper)
Integrate MCP servers to extend functionality (custom Python code)
Deploy agents locally, and to Azure AI Foundry (for flexibility)

And that was just in 15-minutes. I can only imagine what other features and tools we are yet to discover if we try this out ourselves. Want to get links to the extension, documentation and key resources to skill up? You'll find the links in the deck below:

How to Get Started

Looking back, my first introduction to the AI Toolkit was in Model Mondays Season 1, from Microsoft Product PM Rong Lu. She gave us a comprehensive overview of the various features including support for data generation and evaluation. I recommend taking 15 minutes to review her demo in this episode:

Once you're familiar with the basics, I recommend you check out these three links to dive deeper into the process of building agent-based solutions on Azure AI Foundry with AI Toolkit and Visual Studio Code.

1. AI Toolkit for Visual Studio Code - Getting Started Guide - This is my recommended starting point. The tutorial covers installation, then walks you through the steps for downloading models from the catalog, then testing and integrating models into your application. You can then keep going with more tutorials to learn other features like fine-tuning support.

2. Azure AI Foundry Extension for Visual Studio Code - This extension now lets you work with the Azure AI Foundry platform capabilities directly from VS Code. This screenshot from the docs gives you a sense of the tasks you can achieve from your IDE - including project setup and model deployments.

3. Agent Builder in AI Toolkit -The Agent Builder in AI Toolkit simplifies and streamlines your workflow for building agents - from prompt engineering to tool integration (including with MCP servers). Get an intuitive sense for going from model to prompt to agentic workflows with tooling help.

⁉️ | Have questions? Don't forget to join us for the AMA on Friday (Jul 11) on the Azure AI Foundry Discord. Post your questions early on the Forum or revisit it later to get the transcript and resources from the discussion!

Read The Blog

Want an easy way to catch up on all the news? Check out complete blog series written by our resident student blogger here on Tech Community!

You can also follow her posts, right here on dev.to:

Sharda KaurFollow

Gold @Microsoft MLSA || Technical Content Writer || Open Source Contributor || Web Developer || CUIET MCA'26

Build Your Model IQ!

Model Mondays Season 2 is currently scheduled to go from June to September, covering the 12 key topics shown below.

👉🏽👉🏽 Register for Upcoming Livestreams to get reminders
👉🏽👉🏽 Register for Upcoming AMAs to get reminders

DEV Community: Microsoft Azure

Understanding GitHub Billing and management: from licenses to fair AI credit controls

Series

Problem 1: A central purchase does not identify who is licensed

Solution: Assign seats to named users

Problem 2: Licensed usage has no business owner

Solution: Use cost centers to establish ownership

Problem 3: One group can consume another group's included credits

Solution: Enable the included usage cap

Problem 4: The included usage cap does not stop overage

Solution for Business: Use a $0 hard budget

Solution for Developers: Start with a soft budget

Problem 5: An aggregate budget does not create individual fairness

Solution: Add a cost-center ULB

Problem 6: One baseline does not fit every role

Solution: Add an individual override

Resolution: See the complete control model

Checkpoint: Avoid the most common misunderstandings

Outcome: Different teams, appropriate controls

GitHub Admin UI + Billing API: Better together for smarter spend decisions

Series

Use each surface for what it does best

The question: Spend is up, but what is driving it?

1. Start in the admin UI: Find the increase

Narrow the increase by organization

Connect the increase to a cost center

2. Continue with the API: Answer the repeatable question

Define the reporting question first

Understand the per-user query pattern

Reveal concentration that totals can hide

3. Return to the admin UI: Choose the right control

Set a cost-center user-level baseline

Preserve justified exceptions

Why the UI and API work better together

Make it part of the operating rhythm

The better-together workflow at a glance

Learn more

Turning surprise AI bills into accountable growth with GitHub Billing Controls

Series

Confusion: The bill is higher than expected

Investigation: Follow the spend

Identify the consumption category

Locate the accountable organization

Connect usage to a cost center

Resolution: Put guardrails in place

Set a boundary for shared paid usage

Create accountable room for a cost center

Give different users the right limits

Explain which user limit takes priority

Aftermath: Keep the policy working

A quick reference to the controls

Learn more

Getting started with GitHub Copilot part 2, streamable responses

Series on Copilot SDK

Addressing the problem

Links

Get started with GitHub Copilot CLI: A free, hands-on course

What GitHub Copilot CLI can do

What the course covers

Who this is for

How the course teaches

Get started

Get started with GitHub Copilot SDK, part 1

Series on Copilot SDK

Install

The parts

Your first app

What's next

The JavaScript AI Build-a-thon Season 2 starts March 2!

How the program works!

Phase I: Learn & Skill Up Schedule (Mar 2 - 13)

Phase II: Global Hack! (Mar 13 - 31)

Start Now (Join the Community)

Host Your Node.js MCP Server on Azure Functions in 1 Simple Step

TL;DR key takeaways

What will you learn here?

Reference links for everything we use

Requirements

What is MCP and why does it matter?

Why Azure Functions for MCP servers?

Step 1: Add the `host.json` configuration