GitHub Copilot's new Microsoft Teams integration can turn a channel discussion into an asynchronous coding-agent session. The public preview is convenient, but its billing boundary is easy to misread: the model work consumes AI credits, while the cloud sandbox has separate compute, memory, and storage charges.
A limit on one path does not control the other. This matters to engineering and FinOps teams deciding whether a conversational coding pilot is actually bounded. Here is how the two billing systems work, where each can be stopped, and what to capture from the first session before expanding access.
What does the Teams integration start?
GitHub's August 21 announcement says a paid Copilot user can mention @GitHub in Teams to start a cloud-agent session. People in the conversation can ask questions, add context, and steer the work. A participant with write access to the repository can trigger Copilot to make changes.
The agent then works asynchronously in a cloud sandbox. Participants can follow it from Teams and continue with its artifacts in GitHub, a terminal, the Copilot app, or an IDE. GitHub labels the feature a public preview, and its current setup documentation also requires Microsoft Public Developer Preview in the Teams client.
Nothing in the launch material establishes a typical session length, token count, sandbox size, task success rate, or savings figure. Those values must come from the organization's own pilot.
Why does one Teams task reach two billing systems?
The model and the execution environment are different resources. GitHub measures Copilot model interactions in AI credits. It measures the cloud machine that carries out the work through cloud-sandbox resource meters.
GitHub's AI-credit documentation says the model and token volume determine the interaction cost. Input, output, cache-read, and cache-write tokens are priced for the selected model, then converted at a fixed rate of one AI credit to $0.01 USD. Cloud-agent work is among the features that consume those credits.
The cloud-sandbox documentation defines three other meters:
Scroll sideways to see all 3 columns.
| Cloud resource | What GitHub measures | Current published price |
|---|---|---|
| Compute | Time while the sandbox is running | $0.000024 per compute second |
| Memory | Memory allocated while the sandbox is running | $0.000003 per GiB second |
| Storage | Snapshot storage while a stopped sandbox is retained | $0.005 per GiB month |
Memory billing follows the amount allocated, not the amount actively used. Compute and memory stop accumulating while a sandbox is stopped, but a retained snapshot can continue to accrue storage charges until the sandbox is deleted. GitHub's $10 monthly preview entitlement ended after July 2026; the current documentation says all use is billed after that period.

Which control stops AI-credit spending?
Copilot Business and Enterprise pool included AI credits at the billing-entity level. GitHub currently lists standard monthly amounts of 1,900 credits per Business seat and 3,900 per Enterprise seat. Existing customers have promotional amounts of 3,000 and 7,000 respectively through September 1, 2026; unused credits do not roll over.
After the pool is exhausted, behavior depends on the additional-usage policy. GitHub says paid additional usage is enabled by default for organizations and enterprises. If it remains enabled, activity continues against paid usage and the applicable dollar budgets. If an administrator disables it, affected usage is blocked until credits refresh.
User, cost-center, organization, and enterprise controls can also stop usage at their respective scopes. GitHub does not automatically fall back to a cheaper model when a budget is exhausted. A stopped agent may therefore be a budget outcome rather than a service failure, and a lower-cost continuation must be designed explicitly rather than assumed.
Which control stops the cloud sandbox?
Cloud sandboxes do not use the bundled-AI-credits budget type. GitHub directs administrators to a product-level cloud-sandbox budget or a SKU-level budget for a specific sandbox resource. Enabling Stop usage when budget limit is reached blocks additional cloud-sandbox use when that budget reaches 100%.
That separation creates four possible operating states: both paths available, model usage blocked while sandbox budget remains, sandbox usage blocked while AI credits remain, or both blocked. A dashboard showing available AI credits cannot establish that a Teams task can start its environment. A cloud-sandbox budget with headroom cannot establish that the model is allowed to continue.
The owner assignment also matters. GitHub says sandbox usage is billed to the account that owns the repository when a session starts from a repository context. Record the billed owner during the pilot instead of assuming that the person who mentioned the bot pays for the environment.
What should the first cost record contain?
Pick a small internal task with a known expected output, such as changing one test fixture or correcting a documentation defect. Name the repository and base branch in the Teams request. Set conservative stop conditions for AI-credit paid usage and cloud-sandbox spending before starting, rather than relying on an alert after charges accumulate.
Capture the session identifier and model, start and stop times, repository owner, AI credits consumed, sandbox compute, allocated memory, retained snapshot storage, and final disposition of the sandbox. Then pair those charges with the useful result: no change, investigation only, issue, pull request, or accepted merge. Cost without disposition cannot tell a team what the spend produced.
A stopped sandbox deserves an explicit final decision. Delete it when no resumption evidence is needed, or record who owns the snapshot and when it must be deleted. This is a recommendation from BaristaLabs, not a lifecycle rule published by GitHub. It follows directly from the documented fact that stopped-session storage remains metered.
Use the same task definition for a small sample before comparing sessions. Different repositories, models, dependency installs, and requested outcomes can change both token and sandbox use. A single run can verify that metering and stop controls are visible; it cannot establish a representative unit cost.
Budget the model and the machine separately
The Teams integration gives a conversation a direct route to model reasoning and a cloud execution environment. Those resources share a task but not a budget. Administrators need an AI-credit decision and a cloud-sandbox decision before the first shared coding session begins.
The practical rollout question is not merely whether the organization can afford Copilot seats. It is whether the team can identify the owner, meter, stop condition, and useful outcome on both sides of one session. BaristaLabs can review one Teams-to-GitHub cost path and help turn that first run into a decision about wider access.
Sources
- GitHub Changelog: Shared agentic work with GitHub Copilot in Microsoft Teams, August 21, 2026.
- GitHub Docs: Integrating Copilot cloud agent with Teams, accessed August 23, 2026.
- GitHub Docs: Usage-based billing for organizations and enterprises, accessed August 23, 2026.
- GitHub Docs: Billing for cloud and local sandboxes for GitHub Copilot, accessed August 23, 2026.
GitHub controls preview availability, billing units, prices, included credits, policies, and budget behavior described in its sources. BaristaLabs supplies the operating interpretation and pilot recommendations.
Conversational automation cost review
Trace the whole session before broad rollout
BaristaLabs can help connect the trigger, model usage, sandbox lifecycle, repository scope, and stop conditions for one reversible pilot.
Bring one low-risk internal task and current GitHub budget settings; do not bring credentials, private thread exports, or production secrets.
Turn this idea into a pilot
Which workflow should go first?
Use the readiness check to compare impact, effort, risk, owner, and next step before requesting a review.
- 3-5 minutes
- Deterministic score
- No sensitive data
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.
