xAI’s newest coding model landed in Copilot on launch day. For agencies and SMB product shops, the useful part is not the model name. It is another option in a tool most teams already pay for, billed in a way that rewards careful use.
GitHub started rolling Grok 4.7 into Copilot on 21 September 2026, the same day xAI published the model. That is a short changelog line, and it is easy to treat it as another model picker update. For a five-person product team or an agency shipping client work from VS Code, it is more concrete than that. You now have a reasoning model aimed at longer coding jobs inside the editors, CLI, and agent surfaces you already use, without standing up a second AI stack.
GitHub describes Grok 4.7 as a reasoning model built for agentic coding and complex, multistep workflows, following Grok 4.6. xAI, which now brands parts of this work as SpaceXAI, positions 4.7 as its strongest model so far for coding and knowledge work. The company says it was trained on a larger base than 4.6, with a longer reinforcement-learning run weighted toward tasks that take hours rather than minutes. The practical claim is that the model stays on a hard job longer and checks its own work more carefully before it hands you a result.
What actually shipped, and where you will see it
Availability covers Copilot Pro, Pro+, Max, Business, and Enterprise. That list includes the individual paid plans most freelancers and small shops use, and the org plans agencies already buy for shared billing and policy. GitHub says you will be able to pick Grok 4.7 in Visual Studio Code, Visual Studio, Copilot CLI, the Copilot cloud agent, the Copilot app, JetBrains IDEs, Xcode, and Eclipse. The rollout is gradual, so a teammate may see it in the picker before you do.
Business and Enterprise admins control access through the model policy in Copilot settings. New models are enabled by default unless an admin has turned off global default enablement or has disabled this model specifically. That is a change worth noticing if you run Copilot for a client-facing team. You do not need a special enablement ticket for 4.7 to appear, which also means it can show up in someone’s picker before finance has looked at the usage bill.
xAI also shipped the model the same day in Cursor, Grok Build, and the Grok API. Copilot is the channel that matters if your team already standardized on GitHub. You change the model in a dropdown and watch how it behaves on real tickets, without moving the repo or teaching anyone a new IDE.
Price, context, and what the numbers actually tell you
Grok 4.7 keeps the same list price as Grok 4.6: $2 per million input tokens and $6 per million output tokens. There is a faster variant at twice the price and twice the output speed. Third-party writeups put the context window at 500,000 tokens and the knowledge cutoff around May 2026. Those figures come from xAI’s launch materials and secondary model cards, not from GitHub’s changelog. GitHub only says Copilot bills the model at provider list pricing under usage-based billing.
That billing line is the part SMB operators should read twice. A Copilot subscription covers a lot of everyday assist, but premium models on usage-based billing are not “included forever at the monthly seat price.” If someone leaves Grok 4.7 selected for every chat, every agent run, and every long refactor, the invoice follows token volume. For a studio that already watches cloud spend, treat this like any other metered API. Set an owner, set a monthly cap conversation, and decide which jobs deserve the more expensive model.
xAI’s published scores are a direction signal, not a buying decision. On CursorBench 4.0, which stresses longer coding tasks, Grok 4.7 is listed at 46.3 percent against 40.4 percent for Grok 4.6. On Terminal-Bench 4.0 the jump is sharper, from 20.3 percent to 38.0 percent. DeepSWE v1.1 is listed at 71.0 percent in a high-effort setting. Other frontier models still lead some tables. The honest read for a small team is that 4.7 looks like a better long-job Grok at the same unit price, not a promise it will beat every other picker option on your codebase.
Why this is relevant if you run an agency or an SMB product team
Most small teams do not have a model research function. They have a backlog, a few developers, and a monthly software bill they already resent. Copilot is already in that bill. Adding Grok 4.7 does not create a new vendor relationship, a new SSO project, or a new data-processing review if you already accepted Copilot and xAI models in that tenant. The switching cost is close to zero. That is the leverage.
The work that actually burns hours in a small shop is rarely a single function. It is a three-hour bug that crosses two services, a client change request that needs a migration plus tests plus a careful PR description, or a junior who needs an agent to explore a brownfield repo before touching production. Those are the jobs GitHub is pointing at when it talks about agentic and multistep workflows. If 4.7 is even modestly better at staying on those jobs, the win shows up as fewer stalled tickets, not as a benchmark screenshot.
Agencies have a second use that in-house product teams feel less often. You bounce between client stacks. One week it is a Next.js storefront, the next week a .NET internal tool, the week after a WordPress plus custom plugin mess. A model that can hold more of a repo in context and keep going through a longer plan is useful when nobody on the team is a deep expert in that client’s stack. You still review the output. You just spend less time teaching the tool the shape of the project.
There is a knowledge-work angle that is easy to miss if you only think of Copilot as autocomplete. xAI says 4.7 is better at documents and longer office-style tasks. Inside Copilot that will not turn the tool into a full office suite, but it can make chat and agent runs more useful on tickets that mix code with specs and client-facing writeups. That mixed work is most of an agency week.
How to try it without creating a surprise invoice
Start with one workflow, not a company-wide default. Pick a job type you already measure: failing tests on a known service, a well-scoped refactor, or a Copilot cloud agent run against a small internal repo. Run the same prompt against your current default model and against Grok 4.7. Score three things only: did it finish, how much did you have to correct, and how ugly was the diff. Ignore eloquence. Small teams waste money on models that write confident paragraphs and still miss the ticket.
Keep autocomplete on whatever model already feels cheap and stable. Use Grok 4.7 for planning, multi-file edits, and agent runs that would have taken a human a couple of hours. That split matches how the model was trained and how Copilot bills. It also keeps juniors from burning premium tokens on “rename this variable” questions. If you are on Business or Enterprise, decide the policy before the model appears everywhere. Enabled-by-default is convenient. It is also how quiet spend happens.
Watch two operational details that have nothing to do with quality. Gradual rollout means your evaluation window will be messy, so note which machines actually have the model before you draw conclusions. GitHub has also been rotating older Grok versions out of Copilot on a schedule. Treat the Grok family as the standard and the point release as the current engine.
A sane default for the next two weeks
If you already pay for Copilot and you ship software every week, turn Grok 4.7 on for a short, supervised trial. Give it the longest, messiest ticket you were going to do anyway. Have a senior review the first five outputs the way they would review a new contractor. If the model saves a real afternoon, leave it in the picker for those jobs and keep everyday complete on a cheaper model. If it does not, you lost an afternoon of evaluation and you still have every other model you had on Monday.
That is the whole story for most SMBs. A capable coding model showed up inside a tool you already run, at a published token price you can forecast, on launch day instead of three months later. You do not need a strategy offsite. You need one owner, one test repo or one live ticket, and a rule for when the expensive dropdown is allowed to stay selected.