GitHub published new Copilot policy and billing changes on 28 August 2026. This is a separate announcement from the review-capability and Actions-retention updates covered earlier. Our assessment: administrators should record deliberate choices before inherited defaults change.
What happened: three upcoming changes
GitHub says credit-card and PayPal customers face upfront seat payments, with changes for existing Business and Enterprise customers starting 1 October 2026. It says plan prices are unchanged.
No earlier than 28 September 2026, web chat, mobile chat and cloud agent will share one policy, enabled by default. Opting out removes web and mobile Copilot access after launch. Web chat retention changes from 28 days to the account’s lifetime.
On 28 September 2026, code-review effort set to Default will use Balanced. Administrators wanting Lite must select it explicitly beforehand. These are announced future changes, not a claim that every account has already migrated.
Why the review setting matters
GitHub’s code-review documentation explains that Balanced uses more AI credits than Lite and can consume slightly more Actions minutes. It also warns that Copilot can miss problems and that people should validate its feedback. More analysis is therefore neither cost-neutral nor a guarantee of correctness.
Our interpretation is that a setting labelled Default is a decision delegated to the platform. That may be appropriate, but a team should know which repositories depend on it. Choose review depth around the consequences of a defect and the usefulness of the feedback, not simply the availability of a stronger setting.
The practical implication
IT Web Builder recommends assigning one owner to coordinate three checks. Engineering should inventory inherited review settings, compare a representative sample of reviews and record its preferred effort level. The information-governance owner should examine what staff put into chat and whether the proposed retention matches internal expectations. The billing owner should confirm the payment route, seat roster and approval process for additional usage.
Do not opt out blindly: communicate the access consequences first and provide an approved alternative where necessary. Equally, do not treat continued availability as evidence that retention has been reviewed. Record who approved each decision and verify the resulting settings after rollout.
A useful completion record is a small checklist with an accountable owner, chosen setting, rationale and verification date. Keep the earlier Actions evidence-retention work separate: retaining release records and retaining conversations serve different purposes and should not inherit the same assumptions.
Key takeaways
Review inherited settings before the announced transition.
Make access, conversation retention and payment decisions together.
Verify the outcome rather than relying on the word Default.
Sources
This article is original analysis written by IT Web Builder. The reporting and product details below were used as references and are credited to their publishers.
GitHub Changelog — Upcoming Copilot policy and billing changesPublished 28 August 2026. Source for the announced timing, policy, retention and billing changes.↗GitHub Docs — About Copilot code reviewLiving documentation checked 28 August 2026; source for review-effort costs and validation guidance, not a separately dated news announcement.↗IT Web Builder publishes original summaries and practical commentary. We do not reproduce source articles. Product claims and announcements are linked to their original publishers so readers can verify the details.