Coding where context lives and collaboration happens

The best prompt may be the conversation your team has already had or is currently having. Until now, using a coding agent often meant paying context and coordination taxes. Developers had to leave the discussion, open another tool, and reconstruct the problem in a lengthy prompt: what happened, what the team decided, which constraints matter, and what needs to be built.

With GitHub Copilot in Teams, teams can move directly from conversation to action. @mention GitHub Copilot when the team is ready to act, and it can use the conversation alongside repository context to understand the request, implement the change, and create a pull request for review.

This makes working with a coding agent more collaborative and visible. Instead of one developer privately reconstructing the request, teammates can contribute context, correct assumptions, refine the approach in real time, and review the resulting work together.

Let’s explore the new GitHub Copilot in Teams experience to see how it can streamline development tasks:

GitHub Copilot in Teams is available in Teams channels, group chats, meeting chats, and 1:1 chats.

Once the GitHub app is installed and added to the conversation, @-mention GitHub Copilot to bring it into the discussion and start a task. During public preview, users can complete the following scenarios with GitHub Copilot in Teams:

• Build a feature based on requirements discussed in Teams
• Implement a fix for a bug
• Expand test coverage or improve documentation
• Create and update a pull request

No copying the discussion into a CLI. No rewriting it in a desktop app. No asking one developer to translate a team decision into the perfect prompt. GitHub Copilot works where the context already lives, and because that context is shared, working with GitHub Copilot becomes a team activity.

Built around the controls teams already use

GitHub Copilot in Teams works within existing GitHub permissions and repository policies. Branch protections and required reviews continue to apply, and people remain responsible for deciding what gets merged, ensuring that humans stay in the loop at every step.

Availability

GitHub Copilot in Teams is now available in Public Preview. To try it, install the GitHub app for Microsoft Teams and check out our documentation to get started!

Less context reconstruction. More progress from the conversations already happening.

Across Microsoft, "hill climbing" has become shorthand for how real AI progress happens: not in one dramatic leap, but through a disciplined loop. Microsoft AI defines the hill climb as an organization that continuously improves, cycle after cycle, through more compute, better data, and sharper evaluation. Reinforcement fine-tuning in Foundry defines it as improving the deployable model package one measured step at a time across quality, latency, and cost. Different altitudes, same premise: progress is not a one-shot decision. It's a loop.

For most teams, the decision of what model to use when is made manually or with custom routing tools. A developer picks a model based on benchmarks, familiarity, or the last launch that made headlines, ships it, and revisits the choice only when something breaks. In an ecosystem where the frontier moves monthly, that decision goes stale fast. Model router in Foundry Models brings the hill climb to the selection layer.

What's new: a bigger pool, in more places

This release expands where teams can deploy model router, broaden the supported model pool, and delivers updates through a stable endpoint. Together, these changes help teams run production workloads in more locations, match a wider range of tasks to suitable models, and adopt supported updates without changing the application integration.

A refreshed model pool. The supported model list now includes Anthropic Claude Opus 4.8 — a high-capability model built for complex reasoning and long-form generation, for scenarios that demand depth, structure, and quality — and the GPT-5.6 family. Just as importantly, the pool is pruned: gpt-5-chat, gpt-5.2-chat, gpt-5.3-chat, Deepseek-V3.1 have been removed from the model router as models reach the end of their lifecycle and are deprecated in Foundry.

New region availability. The model router is now available in 28 regions for global standard and 21 data zone regions. For many organizations, inference requests must stay within specific geographic boundaries for regulatory, governance, or customer-trust reasons — and intelligent routing shouldn't force a compromise on that. Find the full list of regions here.

The most important detail is what you don't have to do: these updates occur automatically*. The endpoint remains stable as the supported model pool is refreshed, so teams do not need to redeploy the model router to receive the update. Applications can continue using the same integration while the model router evaluates requests against the current supported pool. Teams should continue monitoring routing traces and application outcomes to confirm that quality, cost, latency, and governance requirements are met.

*Models from Anthropic still need to be deployed separately before they can be routed to through the model router.

Interested in hearing more about what's new to the model router? Tune in for the next episode of Model Mondays with Sanjeev Jagtap and Lee Stott, where they talk all things model router from evaluations to hill climbing. Sign up here to watch live or view the replay: Model Mondays - Spotlight On Model router in Microsoft Foundry | Microsoft Reactor

The selection-layer hill climb

At the selection layer, a step is a routing decision. Each one is a micro-optimization against your objective, and each one is instrumented: every response from the model router includes a model field showing which underlying model was selected, so the climb leaves a complete, auditable trail.

Model router supports three parts of the optimization loop: A/B testing to compare two router configurations to understand quality, cost, and latency tradeoffs; model decomposition to use routing results to decompose a single-model application into a multi-model or multi-agent design, and continuous routing to keep the router in production for continuous per-request selection. Each pattern turns model choice into a measured, repeatable process rather than a fixed decision.

1. A/B Testing 

Question: Which model or routing strategy should I use in production?

A/B testing helps teams compare candidate models, model families, or router configurations against the same workload. Representative traffic is sent to competing deployments, and teams compare quality, cost, latency, and governance outcomes. The goal is to understand tradeoffs and identify the model or routing strategy that best meets workload requirements before promoting it to production.

2. Model Decomposition

Question: What work is my application actually doing?

Model decomposition uses model router as a diagnostic tool. By deploying the model router against a representative workload and examining routing telemetry, teams can see how requests naturally separate into different task classes. Simple retrieval, classification, and summarization requests may route to smaller models, while reasoning, planning, and agentic workflows may require more capable models. The goal is not to choose a winner, but to understand the structure of the workload and uncover opportunities for optimization, specialization, or architectural improvements.

3. Route continuously

Question: Why choose a single model at all?

Route continuously is the pattern model router was designed for but is not limited to. Rather than treating model selection as a one-time decision, teams leave the model router in production and allow the best-fit model to be selected for each request. As the supported model pool, regional availability, and platform capabilities evolve, teams can continue using the same endpoint while evaluating whether updates improve workload outcomes. Model selection becomes an ongoing optimization process rather than a project that must be repeated every time the model landscape changes.

Together, these patterns illustrate a broader shift: the model router is more than a model. It is a tool for the optimization loop itself, helping teams evaluate tradeoffs, understand workload behavior, test hypotheses, and continuously refine model selection as requirements evolve. Whether used to compare candidate models, decompose applications into specialized tasks, or automate per-request routing in production, model router turns model selection into an observable, measurable, and repeatable process. As the model landscape continues to change, that optimization loop becomes a durable advantage.

Getting Started

Ready to start your own hill climb? Whether you're exploring the model router for the first time, evaluating routing strategies against your workload, or building a long-term optimization practice, these resources can help you move from experimentation to production with Microsoft Foundry.

• What's new in model router?
  Sign up for the next Model Mondays episode for a deep dive into new features, optimization patterns, and the latest model router updates. 
• How do I build agents with model router?
  Check out the Model Router Agents Lab and build agent experiences with routing, retrieval, web search, tool calling, and multi-agent patterns. 
• How do I evaluate model router?
  Compare model router against baseline models using your own prompts, then review quality, cost, latency, and routing decisions with the Auto Evaluation Toolkit. 
• How do I optimize model router for my workload?
  Start your hill-climbing journey with the Model Mastery workshop, where you'll test one optimization lever at a time and measure how each change impacts workload outcomes.
• How do I build a model router optimization playbook?
  Explore the Model Releases repository to track new capabilities, understand the optimization question behind each release, and try focused notebooks that demonstrate one optimization lever at a time. 

If you use AI coding assistants—whether it is Claude Code, Google Antigravity, OpenAI Codex, GitHub Copilot, Cursor, or Cline—you have likely experienced the Training Cutoff Frustration in Dart and Flutter.

Dart moves fast. Over the last few years, we have seen:

• Dart 2.12: Sound Null Safety (?, late, !, required).
• Dart 2.17: Super-parameters (super.key) and enhanced enums.
• Dart 3.0: Records, pattern matching, switch expressions, and sealed classes (while permanently dropping non-null-safe mode).
• Dart 3.12–3.13+: Private named parameters, constructor shorthands, and primary constructors (class Point(var int x, var int y);).

Because pre-training datasets naturally lag behind the bleeding edge, vanilla LLMs frequently:

1. Reject modern Dart 3.13 syntax as "syntax errors".
2. Write 15 lines of repetitive constructor and equality boilerplate where modern primary constructors belong.
3. Mess up the environment.sdk lower bound (minSdk) in pubspec.yaml.
4. Struggle to rescue pre-2.12 legacy apps because they don't know the exact milestone sequence to cross the null-safety divide.

To solve this once and for all, I extracted and open-sourced dart-sdk-skills.

🎯 What is dart-sdk-skills?

dart-sdk-skills is an authoritative, version-by-version skill package designed specifically for AI coding agents.

Rather than dumping thousands of lines into your prompt on every turn, it uses progressive disclosure:

• The agent holds a compact, fast Feature Matrix covering every version from Dart 1.0 to 3.14.
• When an agent is asked "What's new in Dart 3.13?", "What minSdk do I need for private named parameters?", or "Help me modernize this legacy Flutter app", it dynamically reads the exact changelog reference guide on demand.

🛠️ Two Massive Use Cases

1. Modern Greenfield & Bleeding-Edge Dart 3.13+

Instead of fighting the LLM over modern language ergonomics, your agent immediately knows:

• Primary constructors & this : assert(...) bodies.
• Wildcard variables (_) and digit separators (1_000_000).
• Exact minSdk verification so your pubspec.yaml never breaks CI.

2. Rescuing Legacy Codebases (Dart 1.x & Pre-2.12)

Because Dart 3 completely disallows running without sound null safety, rescuing older codebases requires a strict 4-stage pipeline:

1. Dart 1.x ➔ 2.0: Drop obsolete new keywords and enforce sound static typing.
2. Pre-2.12 ➔ 2.12: Transform @required annotations, uninitialized nullable fields, and defensive runtime assertions.
3. pubspec.yaml: Bump environment lower bound to ^3.5.0 or ^3.13.0 and replace deprecated packages (pedantic, tuple).
4. Dart 3 Modernization: Adopt super-initializers, sealed classes, and pattern matching.

📦 How to Install (One Command)

You can install dart-sdk-skills globally across all your projects in seconds using any skill package manager:

Using npx skills (Universal / Node):

npx skills add RandalSchwartz/dart-sdk-skills -g

Using the Dart skills CLI:

skills add https://github.com/RandalSchwartz/dart-sdk-skills --global --all

Once installed, your agent is automatically equipped with the entire Dart SDK knowledge base.

Check out the full repository on GitHub:
👉 https://github.com/RandalSchwartz/dart-sdk-skills

I've shared a few posts recently talking about how I'm using Cursor to learn and employ agentic development. Primarily that work has all been done via our Agent view, but this is just one of the surfaces you can use with the platform. I had a chance recently to try out the SDK and I thought I'd share a little demo I built with it.

First - some explanation would be helpful. You can use Cursor with the desktop application, on the web, via CLI, on iOS, even via API. But the SDK lets you use the platform from your code. There's an SDK for TypeScript, Python, and a bridge that embeds a TypeScript server and lets you use any language. Honestly I've never seen that before in a platform and it's pretty freaking cool. (And... just to remind folks, I do work at Cursor so I'm biased, but that's absolutely an honest opinion.)

With the SDK, you can do all the things you can usually do with the platform - run prompts in different modes - swap models at will, including the auto router which makes it easier, even kick off agents that run in the cloud. Definitely check the docs for a full detailed list of what you can do, but it's basically the platform itself - in your code.

I built a quick demo with the TypeScript SDK, but then switched over to Python as I felt it a bit easier for me to use. The quickstart shows how easy it is:

import os

from cursor_sdk import Agent, LocalAgentOptions

with Agent.create(
    model="composer-2.5",
    api_key="crsr_key",
    local=LocalAgentOptions(cwd=os.getcwd()),
) as agent:
    print(agent.send("Summarize what this repository does").text())

This returns the final result of the prompt, but you also have the ability to get everything that was generated, so for example, the detailed list of tool calls and such. You can also decide between streaming or just waiting and getting the final result.

All of this just works - which is what you want in a SDK - and the quick start example is one of my favorite things to do with Cursor - basically "what the heck is this repo/set of code doing" - and I thought it would be cool to turn this into a CLI tool.

To be clear, normally I'd use the Cursor Agent window, open the repo or folder, and use Ask mode to describe the project. But if I'm not planning to work with the code later and just want a good explanation, a CLI tool could be useful for this purpose instead.

Of course, the easiest way to build this is to use Cursor itself. I set up a new folder and started a new plan:

/plan create a Python CLI that makes use of the Cursor SDK. The CLI is a 
tool that will scan a code base and generated a detailed report of the 
application/code base of the folder being scanned. What it does, what 
technologies it use, what frameworks are in place, and so forth.

The CLI should support a help command. 
The CLI will scan the current directory by default, but supports an 
argument to specify a path.
The CLI will output Markdown, but an argument allows for a PDF file output.
Require a filename to store the result. 

This created the following plan:

• ""

>>>>>>

""

""""

• ""

By the way, the Architecture was a pretty Mermaid chart that's not rendering on my blog:

The end result - in terminal I can create a report in either Markdown or PDF. I'll share a link to the entire thing below, but let's take a look at the Python file responsible for analyzing the codebase via the Cursor SDK:

"""Run a local Cursor agent to produce a codebase Markdown report."""

from __future__ import annotations

import os
import sys
from pathlib import Path

from cursor_sdk import Agent, AgentOptions, CursorAgentError, LocalAgentOptions

PROMPT = """\
Explore this codebase thoroughly (manifests, configs, source layout, docs) and \
produce a detailed report about the application.

Cover at least:
- Overview / purpose of the project
- Primary languages and runtimes
- Frameworks and major libraries
- Architecture and top-level structure
- Entry points and how to run, build, and test (if discoverable)
- Notable tooling (CI, linters, package managers, etc.)
- Anything else material about how the app works

Rules:
- Do not modify, create, or delete any files.
- Return ONLY Markdown for the report (headings, lists, short code snippets as needed).
- Do not wrap the entire reply in a single fenced code block.
"""


class ScanError(Exception):
    """CLI-facing scan failure with an exit code."""

    def __init__(self, message: str, exit_code: int) -> None:
        super().__init__(message)
        self.exit_code = exit_code


def _require_api_key() -> str:
    api_key = os.environ.get("CURSOR_API_KEY", "").strip()
    if not api_key:
        raise ScanError(
            "CURSOR_API_KEY is not set. Export it before running codebase-report.",
            exit_code=1,
        )
    return api_key


def _extract_markdown(result: object) -> str:
    text = getattr(result, "result", None)
    if isinstance(text, str) and text.strip():
        return text
    raise ScanError("Agent finished but returned no report text.", exit_code=2)


def scan_codebase(scan_path: Path) -> str:
    """Analyze *scan_path* with a local Cursor agent and return Markdown."""
    api_key = _require_api_key()
    cwd = str(scan_path.resolve())

    print(f"Scanning {cwd} with Cursor agent…", file=sys.stderr)

    try:
        result = Agent.prompt(
            PROMPT,
            AgentOptions(
                api_key=api_key,
                model="composer-2.5",
                local=LocalAgentOptions(cwd=cwd),
            ),
        )
    except CursorAgentError as err:
        retryable = getattr(err, "is_retryable", False)
        raise ScanError(
            f"startup failed: {err.message} (retryable={retryable})",
            exit_code=1,
        ) from err

    status = getattr(result, "status", None)
    if status == "error":
        run_id = getattr(result, "id", "unknown")
        raise ScanError(f"run failed: {run_id}", exit_code=2)

    return _extract_markdown(result)

This is pretty robust and the prompt it uses is really well written. (Ok, as a reminder folks, don't forget prompt writing is still important and you can cheat at that by asking your AI agent to improve your prompt before you actually run it.)

I did a quick run of this on my blog and got the following:

This is a rather simple example, but being able to use the Cursor platform in code like this could be really freaking powerful I think. If you've done something like this, I'd love to hear more, share a comment below. You can check out the full code here: https://github.com/cfjedimaster/cursor_python_sdk_cli_demo