No More Switching Tools: Copilot Now Generates and Edits Images Right in Chat

You are coding, and suddenly you need an image. Until now the standard move was: stop, open another tool, describe the request again, generate the image there, and carry it back into the project by hand. On 28 October 2026, GitHub's changelog announced that switch can go away: Copilot can now generate and edit images directly in chat, using natural language, previewing the result inline, and saving it to your project.

This does not turn Copilot into a design tool. It is a pragmatic subtraction: small jobs like 'I need an illustration, a placeholder, a sketch' move into the conversation developers already use. Whether it is worth using depends on three lines: billing runs on a separate track, a preview is not the same as a usable asset, and the watermark is off by default.

What shipped: ask in chat, the image lands in the repo

According to GitHub's changelog, the flow works like this: describe the image conversationally in any Copilot chat session, whether you are starting a new request or in the middle of a coding task. Your selected reasoning model calls a dedicated image-generation tool powered by GPT Image 2.5 Flare; the result is previewed inline and saved directly to your workspace.

The entry points are Copilot chat in VS Code, the GitHub Copilot app, and Copilot CLI. The feature is in public preview for Copilot Pro, Copilot Pro+, Copilot Business, and Copilot Enterprise. Organization and enterprise owners can turn image generation off through Copilot model policies — an important detail for teams with compliance requirements. Access is not universal by default; an administrator can take it back with one switch.

Billing is a separate track. Image requests do not consume the per-message quota of the chat model you picked. They draw on image tokens that count toward your plan's AI credits. In other words, asking for an image in chat will not squeeze out your coding allowance, but it will be recorded in a second ledger. The structure is what matters now: two ledgers, do not mix them up.

What it removes is the switch, not design itself

GitHub frames the feature modestly: it removes a context switch. In the old flow, a request had to be described twice, and the image version could drift away from the code version. Now the request is described once, the image lands in the same workspace as the code, and edits are easy: if an element is wrong, say so in chat and change it, without another export-import round.

That does not mean Copilot has made the design judgment for you. The model does not know whether your brand palette changed, whether the image will appear in formally published documentation, or whether text in the image stays legible at small sizes. What you get is a usable first draft, not a publish-ready final asset. For small vibe coding teams this distinction matters: an AI-generated sketch is fine in a demo, but anything going into a user manual, a homepage, or app store screenshots still needs a human eye first.

One easily missed point: once an image is saved to the workspace, it enters version control. A dozen throwaway attempts generated on a whim will travel with the repository for a long time unless someone cleans them up. A simple rule helps: generated images first go to a drafts folder, and only finalized assets move to the official assets folder. Delete abandoned attempts promptly instead of letting the repo store 'maybe useful later' images.

Watermark off by default: convenient, and your responsibility

GitHub offers an opt-in visible 'Made with AI' watermark on images Copilot generates and edits. Watermarking is off by default, and that default deserves a second of thought.

From a usability view, off by default is right: most of the time you want an internal placeholder or a demo sketch, and a watermark gets in the way. From a responsibility view, off by default means the decision about whether to label AI-generated content is handed to the user. For internal drafts, skipping the label is a small matter. For published content — especially anything that could be mistaken for a real photograph, a real product screenshot, or a real person's photo — skipping the label can mislead readers.

A practical approach is two tiers by use: internal placeholders, demo drafts, and brainstorming sketches do not need agonizing over watermarks; externally published images in documentation and on homepages should either carry the watermark or carry a caption stating they are AI-generated. Teams can write that rule into model policies or internal guidelines rather than leaving it to each person in the moment. A label does not devalue an image; it gives readers a basis for judgment.

What it suits, and what it does not

• Good for: placeholders and sketches — empty-state illustrations, demo interface mock-ups, diagrams in documentation, multiple directions during brainstorming. Small edits also fit, such as 'make the background lighter' or 'remove that element'.
• Good for: quickly testing an idea, for example showing colleagues three homepage image directions before committing, then handing the chosen direction to a designer for refinement. That is much faster than describing it in words.
• Not good for: images that must be exact — real product screenshots, data charts, diagrams with precise text. Model-generated text and numbers are error-prone and must be checked character by character.
• Not good for: images involving real people, real places, or real brand assets, where generated results can distort reality or raise rights issues. Chat generation is not a substitute for photography or licensed assets.
• Not good for: formal publications with hard requirements on copyright and provenance, unless your organization's policy on AI-generated images is already settled.

Three suggestions for small teams

First, manage image generation as part of the conversation, not as a separate design process. Describe the request as concretely as you would to a colleague: purpose, feel of size, subject, background, style, and what to exclude. The more specific the description, the fewer retries. 'Make me a nice image' hands all decisions to the model.

Second, keep a three-step routine: preview, check, finalize. Preview for composition and feel; check character by character for text in the image, count hands and elements, and look for stray odd details; only then move the image into the official assets folder and commit it. Public preview means behavior can still change, so do not wire unchecked images straight into a release process.

Third, reconcile the bill once in a while. At month's end, look at how many AI credits image tokens consumed, which images actually got used, and which were just experiments. If experiments dominate, the descriptions could be more specific — or some jobs were never worth generating, and a stock icon or photograph would have been faster.

One note for administrators: confirm your plan is within the public preview coverage, then decide whether to disable or allow image generation through model policies. If anyone on the team will publish AI-generated images externally, settle the watermark and labelling rules before opening access, not after.

Where it sits in the 28 October batch

Around 28 October, GitHub shipped a wave of Copilot updates, including bigger items like model routing, multi-repository work, and desktop operation. Image generation is a small feature among them, but it has something the bigger ones lack: zero learning curve. No new orchestration concept, no workflow change — just one more sentence in a conversation you already know how to use.

Small features often matter not on launch day but after they become habit. When 'I need an image' stops being a switch, the friction in making demos, documentation, and presentations drops a little. Lower friction means documentation and demos are more likely to be updated promptly, instead of being left until the night before release. For small teams, that unglamorous smoothness is sometimes more valuable than a large feature.

One reminder remains: public preview is public preview. Billing, available models, and preview behavior can all change, and a workflow that feels smooth today may not exist in the same form in three months. Treat it as a productivity helper, not as an irreplaceable step in a critical path.

How to describe it: the description decides how many retries you need

There is a simple test for an image request: read your description to a colleague who has never seen the project. If they cannot picture roughly what you mean, the model will most likely guess too. A good description gives five elements at once: purpose, subject, scene, style, and exclusions. For example: 'An illustration for the empty state of a budgeting app, featuring a dozing cat, on a light cream background, in a flat and simple style, with no text and no real brand logos.' Purpose sets the image's job; exclusions decide how many retries follow.

Editing works the same way. Do not just say 'make it prettier'. 'Prettier' is not an executable instruction, and the model can only switch to a random direction. A more effective edit points at specific elements: 'Change the cat to a stretching pose, make the background lighter, and leave more white space.' Change only one or two elements per edit, look at the result, then decide the next step. Changing five things at once makes it impossible to say which change broke the image.

One category of request needs thinking in advance: text inside images. Models can attempt short words in English or Chinese, but long sentences, slogans, and data labels easily come out with wrong, extra, or fused characters. For any image containing text, the first job after generation is to read it character by character, not just to judge the overall feel. For formal use, the safer route is to have the model produce only the graphic part and add text later with a design tool or code, so the text is fully under control.

The cost ledger: what is free is the switch, not the image

Image generation saves time, not money. Every image consumes image tokens against the plan's AI credits, and a dozen trial-and-error attempts add up. For an individual developer the consumption is usually small; for a team, if everyone generates casually and never cleans up, the month-end credit bill will be higher than expected.

Controlling cost is straightforward. First, write specific descriptions to cut wasted attempts. Second, when you need images in bulk, fix the direction first: produce three small drafts in different directions, pick one, then refine it, rather than producing one image along each of ten directions. Third, clean the drafts folder regularly and count how many images from the month actually got used. If fewer than a third were used, many generations were unnecessary, and the next question should be: does this image really need generating, or would an existing icon, photograph, or screenshot do?

Note also that billing terms can change. The structure — image tokens counting toward AI credits — is settled for now, but exact prices and credit conversion should be checked against GitHub's current documentation. When writing image generation into a team budget, leave some slack rather than extrapolating a full year from the first month's trial consumption.

Working with designers: use it to fix direction, not to finalize

For teams with designers, the best role for Copilot image generation is a direction-draft tool, not a final-artwork tool. A product manager or developer first generates three to five drafts in different directions, then discusses them with the designer: does this direction feel right, which element is worth keeping, which should go. Discussion anchored on concrete images is much faster than pure text description and reduces 'I thought you meant this' misunderstandings.

Final artwork still belongs to the designer, for three reasons: brand consistency needs a human check, since the model does not know your latest palette and type rules; formally published images need traceable provenance and rights confirmation, which chat-generated images leave fuzzy; and fine precision — icon alignment, whitespace proportions, text layout — still needs professional tools to finish. Positioned as 'the starting point for discussion', designers will welcome it. Positioned as 'a designer replacement', it only breeds distrust.

For small teams without a designer, the logic is the same, except you are the one finalizing. The simplified flow is: generate direction drafts in chat, pick one, then make final adjustments yourself with a design tool or code — fixing text, resizing, unifying tones. That last manual pass does not take long, yet it turns an image that 'looks very AI-generated' into one that is presentable.

What common failures look like, and how to handle them

Wrong text is the most common failure: a slogan gains or loses a letter, a stroke goes missing, or mixed Chinese and English breaks oddly. The fix is to shrink the text's job: have the model generate graphics without text and add text later; if text must be generated, check it character by character, and when it is wrong, fix only the text part instead of redrawing the whole image.

Style drift is the second failure. In one set, the first image is flat illustration and the second suddenly turns photorealistic, because the description never fixed the style words. The fix is to write the style description as one fixed sentence and reuse it verbatim every time, for example 'flat illustration, soft palette, generous white space'. Fixed style words are what give a set its coherence.

Extra or missing elements are the third. An extra hand appears, a key object disappears, or the subject is cropped in half. The fix is an itemized check: list the elements that must appear and the ones that must not, then check the result against the list. A checklist sounds clumsy, but it saves far more time than 'it feels off, try again'.

The last failure is not an image failure but a process failure: an image is generated and nobody knows which request or version it belongs to. The fix is a naming convention: put purpose and date in the file name, such as empty-state-cat-draft-2026-10-28, and drop 'draft' on finalizing. Once images in the repo carry names and states, later readers know which ones are usable and which were only attempts.

One sentence: worth turning on, not worth building a critical path on

If one sentence must sum up this feature, it is this: worth turning on and trying, but not worth writing into an irreplaceable critical path. Worth trying because the learning cost is almost zero and the saved switching time is felt every day; not for a critical path because it remains in public preview, billing, models, and behavior can change, and generated results always need a human check. Holding both halves at once avoids two extremes: using it for everything the moment you hear it can draw, or refusing it entirely because it is a preview.

For independent developers and small vibe coding teams, the best trial is one real, small need: an empty-state illustration for the next release notes, or a diagram for a demo video. Walk the full loop once — describe, preview, check, finalize, clean up — and see where your describing habits need to change and whether credit consumption matches expectations. After one full loop, your judgment of the feature is no longer second-hand but tested. That is ultimately how a tool's value is established.