---

---

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.

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:

1. Establish a universal per-user baseline, the starting limit for every licensed user.
2. Add a cost-center exception where a group's expected outcomes justify a different limit.
3. 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.

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

• Assign enterprise teams to cost centers
• Per-user AI credit budgets available for cost centers
• Cost centers now support included usage caps

AI is changing the technology game so quickly that Microsoft CEO Satya Nadella can’t stop long-posting on Twitter.

Microsoft has been improving its AI prowess, and the company is beginning to use its homegrown AI models inside its own products.

And last week, Redmond detailed progress thereof. Two things matter: First, an internally built AI model “deployed in Excel is on par with GPT-5.6 for the most common tasks while being more cost-efficient,” the company states. I doubt it’s on par with GPT-5.6 Sol, but Microsoft probably doesn’t need to present pure frontier intelligence to the normies; they aren’t reading leaderboards anyway. And the cost point is critical; Microsoft wants to serve lots of AI to its customers without shipping all that revenue to its two portfolio companies, customers, vendors, and competitors, OpenAI and Anthropic.

See also: Microsoft is taking control of its AI future

Second, Microsoft’s MAI-Code-1-Flash model, which was “post-trained within the GitHub Copilot harness,” is being used by “millions of developers” since launch for “their day-to-day work, where it’s outperforming other similarly sized models while using fewer tokens.”

Apart from cost, how does it perform? Microsoft claims that it has an “approximately 10% higher code accept rate than GPT 5.4 Mini and Claude Haiku 4.5 in VS Code,” and slightly better user retention metrics compared to the same.

Is Microsoft suddenly flipping the AI tables? No. But it is proving that it can build AI models itself that work for its customers in production settings. Microsoft is also learning from a massive trove of enterprise coding and work data — you can’t leak to an AI lab when you are the AI lab. In theory, Microsoft should be able to quickly improve its model/harness/workflow combination thanks to that advantage, what it calls its ‘hill-climbing machine.’

Continue reading on Cautious Optimism

This is an excerpt from Cautious Optimism, a modestly upbeat publication focused on technology, business, and power. Read along on Cautious Optimism.

The post Microsoft is racing to make OpenAI optional appeared first on The New Stack.

The Ember project is excited to announce the release of Ember v7.1. This is a standard minor release as part of the Ember Release Train process.

This release contains some serious improvements to the Developer Experience for people using GJS files, adds some new built-in helpers, and furthers our commitment to reduce the number of deprecated npm package warnings seen when generating a new Ember application.

Ember.js 7.1

Ember 7.1 introduces a number of long-awaited new built-in helpers ({{element}}, {{and}}, {{or}}, {{lt}} {{lte}}, {{gt}}, {{gte}}, {{eq}}, and {{neq}}) and a significant improvement to the Developer Experience of using some often used helpers and modifiers in GJS files. Also, the API documentation has been updated so that all the template examples have all been updated to use <template /> tag format.

Element Helper

This release is the first time that the {{element}} helper has been included in Ember.js itself. This helper was originally proposed in RFC #389 - back in 2018! The element helper is a useful tool when you need to generate a specific DOM element based on dynamic data. For example, if you had a component that needed to chose to render a <div> or a <span> based on some data passed to your component, you could do something like this:

{{#if (eq @renderTag 'div')}} 
  <div ...attributes>{{@text}}</div>
{{else if (eq @renderTag 'span')}}
  <span ...attributes>{{@text}}</span>
{{/if}}

As you can imagine this can get a bit hard to manage when needing to cater for many different tag types. But now you can use the {{element}} helper to dynamically generate the tag and use it directly in your code:

{{#let (element @renderTag) as |Tag|}}
  <Tag ...attributes>
    {{@text}}
  </Tag>
{{/let}}

Since the RFC was proposed, Ember developers have been directly consuming the reference implementation for the RFC that was published as an addon, so with this release that addon is no longer needed. With it being available from Ember.js directly that means that it can be included in the set of "Built-in helpers" which you will learn more about if you keep reading 😉

Logical, Equality, and Numeric Comparison Operators

ember-truth-helpers is one of the most popular Ember Addons in the wider ecosystem, and most Ember apps have installed it either directly or indirectly through other Ember Addons depending on it. It is so popular that RFC #562 proposed that the {{and}}, {{or}}, and {{not}} helpers provided by ember-truth-helpers should be included in Ember.js by default. Also, RFC #561 proposed the inclusion of the {{lt}}, {{lte}}, {{gt}}, and {{gte}} helpers into Ember.js and RFC #560 proposed the inclusion of the {{eq}} and {{neq}} helpers.

Because ember-truth-helpers was such a popular (and useful) addon, there was little motivation to do the work and include these helpers in Ember.js by default. But like the {{element}} helper above, now that we have the ability to provide "Built-in helpers" for templates we can significantly improve the ergonomics for Ember developers by finally implementing these RFCs and making the helpers a part of Ember.js by default. With that, I guess it's time to explain what I mean by "Built-in helpers" 😂

Built-in Modifiers and Helpers

In the blueprints shipped with Ember 6.8 we made the new GJS template format the default experience for the generators in apps, so when you generate a component or a route template you will get a .gjs file instead of what was previously a .hbs file. You can read more about the benefits of GJS files in RFC #779, but a very short summary of the biggest difference is that you need to import everything that you use in a GJS file before you use it. This is achieved by compiling GJS files with "strict mode", which means that templates no longer rely on the Ember Resolver to look up Invokables (Components, Helpers, and Modifiers) by name, but instead it checks local scope of the file to find the Invokable before adding it to the template scope.

This one simple change has helped Ember templates feel a lot less "magical" for developers who are new to Ember, no longer having to guess which (potentially nested) addon a random <FancyButton /> component is coming from, but this change did come with a slight cost. Now that you need to import everything that you are using in template, you suddenly need to start importing things that Ember.js automatically provides for you such as the {{on}} modifier, the {{fn}} helper, or the <LinkTo /> component. And to make it even more challenging each of these Invokables are imported from different places: @ember/modifier, @ember/helper, and @ember/routing respectively. While there has been some efforts to improve tooling so that when you use one of these Invokables in a template your editor would help you to auto-complete the import statement for you, this doesn't represent a full fix for the problem and can't help anyone developing in an environment that can't make use of the modern Glint toolchain.

In RFC #997 it was proposed that the {{on}} helper would be automatically imported for you when you use it in a strict template (e.g. GJS) and Ember.js 7.1 is the first version where this RFC has been implemented. This release also includes the implementation for RFC #998 to make the {{fn}} helper be automatically imported into strict templates, RFC #999 for the {{hash}} helper, and RFC #1000 for the {{array}} helper. What's more since the Element helper and the Logical, Equality, and Numeric Comparison Operators described above were added in the Ember.js version that introduced the concept of auto-importing Invokables, they have also been added to the list 🎉

This means that if you had the following (slightly contrived) example of a GJS component template in Ember.js 7.0:

import { on } from '@ember/modifier';
import { fn } from '@ember/helper';

function say(message) { alert(message); }

<template>
  <button {{on "click" (fn say "hello there")}}>Say hello</button>
</template>

can be updated to:

function say(message) { alert(message); }

<template>
  <button {{on "click" (fn say "hello there")}}>Say hello</button>
</template>

which I think we can all agree is a lot better 😍.

Updating API documentation to GJS

Since the new RFC Stages RFC was adopted, we have had a very clear definition of when an RFC is considered done, and the necessary code to implement a new feature being written is only step 3 of 5! Once something is released (Stage 4) we continue to track the work until it becomes Recommended (Stage 5). The precise definition of Recommended is different for every RFC, but it is safe to assume that updating the all the documentation around changes proposed in an RFC will be a prerequisite before an RFC can be marked as Recommended i.e. fully and completely done.

This release includes one of the last changes necessary before RFC #779 (the RFC that introduced GJS files) could be marked as Recommended. All the API documentation embedded in the Ember.js source code (and that gets extracted into the Ember API Docs app) has been updated to use <template> tag syntax rather than "bare templates" that rely on the resolver to find Invokables.

Ember CLI 7.1

This release of ember-cli brings a new library that extracts common deprecation behaviour, a small but important improvement to quest to reduce npm deprecation warnings, and a bugfix to the blueprint system that supports modern JS tooling.

Extract custom semver behaviour into new package

If you are used to Ember’s release process you will know that we do semver a little bit differently to most other projects. We add new features in minor versions in such a way that you can use both the old and the new features side-by-side, giving you time to migrate to the new paradigm. Then when we want to remove code, we add a new deprecation (at least 2 minors before the next major) with clear instructions on how to remove the deprecation before the next major. Then, if you are running your app and all of its tests on the version right before the next major release with no deprecations being thrown, it should be safe to upgrade your Ember version without any problems.

We built this concept into our deprecate() function so that it was aware of what the current version of Ember.js or ember-cli you are using and we made it throw an error if you had passed the version that the code was due to be removed in. This means that we can be certain that no application is relying on this code path, and we can safely remove the code as part of a cleanup without breaking our semver commitments.

For complicated internal monorepo reasons (which should hopefully feature in future releases!) we needed to extract the code that manages these deprecations into a separate library, and this release is the first time we are consuming our own new library. If you like the “Ember way” of doing deprecations you can feel free to start using this library too!

Update many dependencies across majors

We made an important structural change to the ember-cli release process that means that updating dependencies across major boundaries will happen naturally as part of the ember-cli release train. This is the first version where that structural change is paying off, and we updated 6 dependencies (both in ember-cli and the blueprint) across major boundaries (and in some cases across multiple majors!)

Backported support for blueprints written in ESM

Every ember generate call in Ember is backed by a blueprint provided by an Ember Addon. Each blueprint has a "Blueprint index" file that provides some extention points for the blueprint to preform different actions, or customise template variables while the blueprint is being generated. Up until ember-cli 7.1 the Blueprint index files needed to be written as a CJS module using the old module.exports syntax:

'use strict';

module.exports = {
  description: 'A super fancy blueprint',

  // locals(options) {
  //   // Return custom template variables here.
  //   return {
  //     foo: options.entity.options.foo
  //   };
  // }

  // afterInstall(options) {
  //   // Perform extra work here.
  // }
};

We have fixed this now, so you can write your Blueprint index files as true ESM modules:

export default {
  description: 'A super fancy blueprint',

  // locals(options) {
  //   // Return custom template variables here.
  //   return {
  //     foo: options.entity.options.foo
  //   };
  // }

  // afterInstall(options) {
  //   // Perform extra work here.
  // }
};

This may not seem like a major change, but this represents one of the final obstacles to setting type=module in the package.json field of ember-source (which we may be hearing more about in the next release!). If you aren't aware of type=module then you can read more about it in the Node.js documentation page on ESM modules.

This fix was also backported to ember-cli v7.0.1.

Thank You!

As a community-driven open-source project with an ambitious scope, each of these releases serves as a reminder that the Ember project would not have been possible without your continued support. We are extremely grateful to our contributors for their efforts.

Hello Windows Insiders, Today we’re releasing build 29634.1000 for the Experimental (Future Platforms) channel. Release notes can be found over in the Windows Insider Documentation Hub as usual, as well as below. Renewed Windows Insider flight certificate Today’s Experimental (Future Platforms) build contains a renewed Windows Insider flight certificate. Windows Insider Preview builds use flight certificates that are renewed periodically to help ensure Insider devices remain on supported builds and continue receiving future Insider Preview updates. The current flight certificate expires on August 11, 2026, so please update your device to a build containing the renewed flight certificate before that date. For more information, please visit the certificate renewal FAQ. Experimental (Future Platforms) moves to updated WIP UI We conclude the full transition of all Windows Insider builds to the updated WIP channel UI, with those on the 29600 Preview Builds now seeing Experimental (Future Platforms) in the Windows Insider channel settings.

Release notes for Windows 11 Insider Preview Build 29634.1000 for Experimental (Future Platforms)

Changes and improvements gradually being rolled out [Voice Isolation in Voice Access]

• We're introducing Voice Isolation, a new option in Voice Access that helps it focus on your voice, even when others are speaking nearby. Whether you're in a shared office, an open floor plan, or at home with family around, Voice Isolation filters out other voices and background noise so Voice Access can better understand you. All processing happens privately on your device.
• Getting started Voice Access now offers three speech recognition modes under Voice Access settings > Improve speech recognition:
  • Voice Isolation — Filters out other speakers and background noise (one-time voice setup required).
  • Remove background noise only — Filters out non-speech sounds like typing or door slams. No additional setup needed.
  • No filtering — Default microphone input with no additional processing.
• To set up Voice Isolation, select it from the menu and follow the short, guided setup where you'll read a brief paragraph aloud so Voice Access can learn your voice. It only takes a minute, and your voice data never leaves your device

[Narrator] Braille displays now connect instantly with Narrator

• We're making refreshable braille displays easier to use in Windows. Narrator now supports displays that use the HID standard — an open industry standard for braille displays. If your display supports HID, simply connect it via USB and start reading — true plug-and-play with no additional setup required. For Bluetooth, pair your HID braille display in Settings > Bluetooth & devices just like any other accessory, and you can work wirelessly without being tethered to your PC.
• Compatible HID displays include models like the Orbit Reader 20, Orbit Slate 340, Freedom Scientific Focus 40, and APH Mantis Q40.
• HID braille displays now work during the initial Windows setup experience (OOBE) over USB — meaning users who are deaf-blind can set up their PC independently, right from the first screen. You can customize braille input and output options anytime in Settings > Accessibility > Narrator > Braille.

[Account Control]

• The Windows 11 Account Control flyout has a refreshed, modern design and a clear subscription badge to make the user's account status instantly visible. This helps users easily identify their plan, discover benefits, and explore upgrades.

Feedback: Share your thoughts in Feedback Hub (WIN + F) under Settings > Start Menu. [Input]

• The emoji panel (Windows key + period (.)) now uses GIPHY as the GIF provider, delivering a smoother GIF browsing and sharing experience following the deprecation of the Tenor API.

[Settings]

• Improved reliability of navigating to the Startup apps page in Settings.

[Taskbar]

• Improved reliability of loading the system tray area of the taskbar when using your PC in a tablet posture.

[Start menu]

• Improved reliability of Start menu view preferences, ensuring your selected view is retained.
• Improved keyboard navigation when keyboard focus is set to the apps list within Start menu.

[Date and Time]

• Improved detection for triggering time zone change notifications.

[Display and Graphics]

• Improves the reliability of rendering content while scrolling for certain apps spanning across multiple monitors.

Thanks, Stephen and the Windows Insider Program team