Welcome back to GitHub Copilot CLI for Beginners! In this series (available in video and blog format), we’ll give you everything you need to get started using GitHub Copilot CLI. So far in this series, we’ve covered how to get started and when to use interactive and non-interactive modes. In this edition, we’ll learn what slash commands are, why they matter, and how to use slash commands to control GitHub Copilot efficiently. You can complete tasks like switching models, checking token usage, and resuming past sessions right from your terminal. Let’s dive in! Understanding slash commands in GitHub Copilot CLI When working in Copilot CLI, one of the most powerful concepts to learn early on is slash commands. Slash commands are built-in controls that you can access directly from the command line. Acting as your control surface within Copilot CLI, slash commands allow you to: Guide Copilot’s behavior Inspect changes Manage context Move efficiently across sessions and projects Keep permissions tidy Slash commands can be thought of as your command center for interacting with Copilot CLI. To look at all of the options available, just type / in the command line for a scrollable list of all currently supported slash commands. Let’s take a look at some of the most popular ones. Choosing the right model Different models are optimized for different kinds of work. If you want to switch models, type /model into the command line. This will display a list of available models, along with key details like: Capabilities: Some are better for quick, lightweight tasks like refactoring, while others more efficiently handle deeper reasoning such as feature planning. Availability: The list may vary depending on your plan or organization’s settings. Cost: Numbers shown on the right of each model indicate cost multiplier, helping you choose the right balance between performance and usage in relation to your plan. Choosing the right model can significantly impact both speed and results. Managing context and token usage Copilot CLI operates within a context window, which determines how much information it can “remember” during a session. If you want to check your current usage, type /context to learn how many tokens you have left, along with system usage and available buffer. If you find that you’re running low on space, you can free up space by typing /compact in the command line. This summarizes your current conversation so you can continue without having to start a new session. Copilot CLI will do this automatically when you approach the limit, but you can also do this manually if you want to transition to a new task or clean up context mid-session. If you’d rather start fresh and completely reset your environment, you can use /clear to clear the session entirely. Working across sessions If you want to resume a previous session, you can type /resume. This will bring up a list of previous sessions you’ve had, including both local and remote sessions. Entering a previous session will show you your session history, and you can pick up right where you left off. Inspecting changes As you work with Copilot to make changes to your project, it’s important to keep track of what’s changed. If you want to see what the changes are, run /diff to see recent updates. This gives you a clear view of what modifications were made during your session, so you can validate changes before moving forward. Navigating projects and directories If you want to work across repositories or directories, you don’t have to exit Copilot. You can type /cwd to change your working directory to another repository. This allows you to scope Copilot’s work to a specific part of your project and helps you stay efficient while multitasking across codebases. Managing tool permissions In the past, you might have granted Copilot CLI permission to perform actions like editing files. Say you’re switching to a repository you want to be more careful in and want to reset those permissions: you can do so by running /reset-allowed-tools. Take this with you Using these slash commands gives you even better control over Copilot CLI—and the more familiar you become with them, the more deliberate your workflow becomes. Whether you’re switching models, managing context, or navigating across projects, using slash commands in CLI gives you the tools you need to stay in control. And if you haven’t already: open up your terminal, type /, and explore! There are many more slash commands to discover. Happy coding! Looking to try GitHub Copilot CLI? Read the docs and get started today. More resources to explore: GitHub Copilot CLI for Beginners video series GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode GitHub Copilot CLI 101: How to use GitHub Copilot from the command line Best practices for GitHub Copilot CLI The post GitHub Copilot CLI for Beginners: Overview of common slash commands appeared first on The GitHub Blog. ​ AI & ML, GitHub Copilot, GitHub Copilot CLI, GitHub Copilot CLI for Beginners The GitHub Blog

Software may be written in programming languages, but human language is at the heart of developer collaboration. Developers explain how projects work in READMEs. They ask for help in issues. They review, debate, and improve code in pull requests. That collaboration often happens in English—but not always. As AI becomes a bigger part of how developers build software, multilingual developer content matters more than ever. Today, GitHub is publishing the GitHub Multilingual Repositories Dataset, a repository-level metadata dataset designed to help researchers and developers discover public GitHub repositories with evidence of non-English natural-language content. When building the dataset, we found that language distribution differs across READMEs, issues and pull requests: Korean is the most common non-English language in issue text, but only the fifth-most common in READMEs. Portuguese tops the non-English README list with more than 3 million repositories. The dataset is now available on GitHub under CC0-1.0. It follows through on a commitment we made in 2025, as part of Microsoft’s European Digital Commitments, to make multilingual data more accessible, including to open source AI developers. What’s in the dataset The GitHub Multilingual Repositories Dataset is intentionally not a dump of repository content. Instead, it is a metadata dataset that helps developers and researchers find repositories where multilingual collaboration may be happening. The dataset covers over 80 million classification rows across more than 40 million repositories. For each public repository, we provide: Language classifications of the README, the most-commented issue, and the most-commented pull request, with the first 150 characters of each used as the input sample. We exclude texts under 20 characters. Classifications for each text source, from fastText, gcld3, and lingua-py, each with a confidence score. The dataset only includes classifications with >0.5 confidence. Repository metadata: creation timestamp, disk usage, stars, forks, primary programming language, SPDX license, issue and pull request counts, and the snapshot date. We deliberately did not collapse the three classifiers into a single label. Different classifiers have different coverage and confidence calibration, especially for lower-resource languages. By exposing all three, we let you decide how strict you want to be. Want a high-precision Greek subset? Require all three classifiers to agree above some confidence threshold. Want broad recall for an exploratory study of Romance languages? One classifier may be enough. What you can build with it The dataset is designed for the kind of work that’s hard to do with general web text: Discover repositories likely to contain developer documentation or collaboration in specific languages. Study how non-English developer communities use issues, pull requests, and READMEs. Build evaluation sets for AI coding tools, doc generators, or review assistants that need to behave well across languages. Encourage decision-makers to expand language coverage for new developer tools and AI features using data-backed arguments on the rich multilingual diversity of developers. Measure representation of European and other underrepresented languages in open source. Some caveats Language identification is hard, especially in software repositories. Repository text is often short. It may include badges, templates, installation commands, code snippets, usernames, or mixed-language content. A 150-character sample may not represent the whole repository. Classifiers also vary in coverage and calibration, especially for lower-resource languages. That is why the dataset should not be treated as a ground-truth benchmark for language identification. Instead, it is designed as a transparent discovery tool. Users can inspect classifications, confidence scores, and sources, then choose the precision and recall tradeoffs that fit their own research or development workflow. The dataset also should not be used to infer sensitive attributes about repository owners, contributors, or communities. The signals are repository-level metadata, not person-level attributes. Why open multilingual data matters Today, many European languages remain underrepresented in the online text used to build and evaluate AI systems. That creates a risk that AI tools work well for some developers, languages, and communities, while leaving others behind. Open data can help close that gap. We built this dataset because developer content is different from general web text. READMEs, issues, and pull requests contain the language of software collaboration: installation instructions, bug reports, feature requests, review comments, and community norms. That context can help build AI systems that better understand how developers actually work. By making multilingual developer-content signals easier to find and analyze, this dataset gives researchers, open source developers, and model builders another tool for studying language representation in software development. It can help identify gaps, support better evaluation, and inform more inclusive AI tools for developers across Europe and beyond. It also reflects a broader principle: Building AI for developers should include the communities, languages, and workflows developers actually use. What’s next We’ll be discussing the dataset, and the broader importance of open data for multilingual AI, at the Open Innovation Dialogue Hub in Strasbourg on June 16. The event is co-organized by the Microsoft Open Innovation Center, the Council of Europe, and GitHub, and will bring together policymakers, researchers, cultural institutions, and open innovation leaders to discuss AI, linguistic diversity, cultural heritage, and open data. Multilingual AI needs multilingual developer communities. We hope this dataset helps more people study, support, and build for them. By releasing it under CC0-1.0 on GitHub, we’re inviting researchers, open source maintainers, and model builders to use it, critique it, extend it, and build evaluation sets and tools on top of it. If you do something interesting with it, we’d love to hear about it. The post Accelerating researchers and developers building multilingual AI with a new open dataset appeared first on The GitHub Blog. ​ AI & ML, LLMs The GitHub Blog

It seems like the latest hotness in git these days is the concept of worktrees. Which… is kind of funny because they’ve been around since 2015. But, nevertheless, they are cool, and you might be wondering why you’d use them, how they differ from branches, and why they are suddenly so popular. Let’s talk about it! Context switching with branches and stashing Let’s say you lived in a worktree-less world, and were working on a ticket, and suddenly an urgent bug came to you and you had to switch contexts. First, you might stash your work: git stash “wip feature login” Then you’d switch to your main branch and update: git checkout main git pull origin main Then make a bugfix branch: git checkout -b hotfix-bug Then you’d fix everything, commit, and push the branch: git add . git commit -m “fix broken submit button” git push origin hotfix-bug Then after merging a pull request, you might return back to your computer and pull main and remove the bug branch: git checkout main git pull origin main git branch -d hotfix-bug And then you could go back to the feature you were working on: git checkout feature-login git stash pop Phew. Where were we? The mental overhead of switching around, reloading files, reinstalling node_modules based on whatever changed, and so on, is a lot. The context switching burden is heavy. Now, this is a basic example, but sometimes developers would work around this kind of chaos with doing some more complicated git stash commands, or even multiple clones of the same repo (I’m guilty of that one). Until… worktrees! Context switching with worktrees With worktrees, you never leave your branch and you never stash, and your editor context for your original feature stays untouched. git worktree add ../hotfix-workspace -b hotfix-bug main This instantly creates a sibling folder called hotfix-workspace, and bases it on main, and checks out a new branch called hotfix-bug. Now you can open that folder in a new editor window (or cd into it) and fix the bug. Your original editor window stays exactly as you left it. cd ../hotfix-workspace # …fix fix fix… git add . git commit -m “fix broken submit button” git push origin hotfix-bug You merge the pull request online just like before, and once it’s merged, you can simply delete the temporary folder. cd ../main-project git worktree remove ../hotfix-workspace This is so much smoother! Worktrees can go beyond the git command line, too. For example, VS Code has full worktree support built in. You have options! And no matter where you work, worktrees give you zero risk of stash conflicts, there’s no editor disruption, and you can truly work in parallel. So… why now? For a really long time, worktrees were relatively unknown. Most developers had never heard of them, because either Git GUIs didn’t support them (or treated them as second-class citizens), or because they just usually followed the known pattern of feature branch, then work, then PR, then merge, then repeat. Now, our work as developers has changed. AI has made us work in parallel more than we ever have before in the history of software development. Developers run so many sessions in parallel, and “code review culture” is growing beyond “code writing culture.” Agents and humans can do more in parallel with worktrees. It’s the default mode for the GitHub Copilot app, and for many other modern tools. What’s the catch? Worktrees do solve a whole lot of issues, but there’s definitely some things to watch out for. Dependency bloat: each worktree folder requires its own copy of your project dependencies. If you’re running npm install or pip install across multiple of them, your computer might get very full, very quickly. Folder management: you have to delete the worktree folders, to avoid cluttering your parent directory over time. Apps like the GitHub Copilot app do often handle this for you, but it’s still something you might have to do yourself if you’re operating in the terminal yourself. Global .gitignore requirements: if you create worktree folders inside your main repo directory, you have to manually add them to .gitignore to not accidentally track them. You can make these worktrees outside of your main repo (and many apps do that by default), but it’s worth noting. One branch limits: Git prevents you from checking out the exact same branch in two different worktrees at the same time to prevent data corruption. How do I use worktrees in the GitHub Copilot app? Great question! What’s awesome is they “just work” out of the box. When you open the app, there’s a dropdown that asks you where you want to run your new session on the home screen. The default is a new worktree. Then, once you kick off a new session, you can click the session name at the top of the app, and you’ll see the (fun!) generated name of your worktree, as well as the path where it’s located, the project that worktree is for, and details about the changes that you’ve made. Easy peasy lemon squeezy! Should I use worktrees? I will give you the most senior developer answer I can: It depends! You might prefer working in one way or another. You might not do as much work in parallel and like the mental model of branches and stashing. You might only do worktrees from now on. You might want to do both! The world’s your oyster, and you can try them all in the GitHub Copilot app today. The post What are git worktrees, and why should I use them? appeared first on The GitHub Blog. ​ AI & ML, Git, GitHub Copilot, git worktrees, GitHub Copilot app The GitHub Blog

As Copilot takes on more agentic work, from planning and editing to debugging, reviewing, and calling tools across longer sessions, efficiency means more than using fewer tokens. It means being smarter about how you use them. Increasing efficiency starts with reducing what Copilot has to repeat from turn to turn, including context, tool definitions, and cached state. It continues with choosing the right model for the job. A quick explanation, a focused edit, and a complex multi-file change should not all be treated the same way. We are working on both: improving the Copilot harness so more of each session goes toward the task itself, and expanding Auto so Copilot can pick the model that fits the work without asking developers to make that choice every time. This post focuses on harness improvements in GitHub Copilot for VS Code and on ongoing work to expand Auto across Copilot surfaces. Increased prompt caching and deferred tools In longer GitHub Copilot sessions in VS Code, the harness prepares a lot of recurring information for the model: instructions, repository context, conversation history, available tools, and the current state of the task. Some of that context is needed. Some of it can be cached, deferred, or loaded only when it becomes relevant. Two improvements in GitHub Copilot for VS Code are doing most of the work here. Prompt caching helps Copilot reuse model state for repeated prompt prefixes instead of recomputing the same prefix on every request. Tool search lets the model load tool definitions on demand, instead of sending every full tool schema into context on every turn. That matters more as agents use more tools. A session may need access to MCP tools, terminal commands, file operations, workspace search, and product-specific actions. Loading every full tool definition up front adds fixed cost to each turn, even when only a small number of tools are relevant to the task. With tool search, Copilot can keep the available toolset broad while sending less unnecessary tool schema into the model. For a deeper technical look at the implementation, including prompt caching, cache-control breakpoints, provider-specific tool search, and how these changes work across long-running agentic sessions, read the VS Code technical deep dive. Where GitHub Copilot auto model selection fits in Auto answers a practical question: which model is the best fit for this task right now? After your first prompt, Copilot uses task intent and current model health to choose a model that best fits the task. Different kinds of work, like quick explanations, focused edits, or multi-file changes, do not all benefit from the same level of reasoning, so Auto makes that call without requiring you to tune model settings. In our evaluations, no single model consistently performed best across tasks. In many cases, a more efficient model reached the same outcome, while stronger models mattered most when the task required deeper reasoning. Auto learns where stronger reasoning improves the result. It routes up when the task demands it and stays more efficient when it does not. The goal is not to trade quality for cost, but to use the model that best fits the work. How Auto selects the right model Auto combines two signals: what model is healthy and available right now, and what kind of work Copilot is being asked to do. Real-time model health: a dynamic engine tracks model availability, utilization, speed, error rates, and cost. A model may be capable of handling a task, but that does not mean it is the best choice at that moment. Auto takes current system conditions into account so Copilot can route to a model that is both capable and ready to respond. Task-aware routing with HyDRA: a routing model that considers factors like reasoning depth, code complexity, debugging difficulty, and tool orchestration needs. HyDRA identifies models that can meet the quality bar for the task, then chooses the best fit among them. Figure 1: Three HyDRA operating points illustrate tunability: (Peak) exceeds Sonnet at 12.9% savings; (Agg.) balances quality for 72.5% savings. Figure 2: HyDRA (Cons.) ties OpenRouter Auto on resolution rate (70.8%) at 3.3x the savings. HyDRA (Agg.) outperforms both Azure Foundry operating modes. Taken together, these signals let Auto avoid a one-size-fits-all approach. The point is not to send every task to the biggest model, or every task to the cheapest one. It is to choose the model that fits the work. Making Auto work in practice Getting routing right in evaluations is only part of the problem. To make Auto useful in real workflows, we also had to account for how developers actually use Copilot: conversations get longer, context builds up, tasks shift, and developers work in many languages. Cache-aware routing. Switching models on every turn may sound flexible, but it can work against efficiency. When a conversation stays on the same model, the prompt prefix can be cached and reused across turns. Switching models mid-conversation breaks that cache, which can cost more than the routing change saves. Auto avoids that by routing at natural cache boundaries: on the first turn, when there is no cache to lose, and after compaction, when Copilot summarizes older turns and the prompt prefix resets. Between those points, the selected model stays in place so the cache can keep building. Routing across languages. Copilot serves developers around the world, so routing has to work in languages other than English. We trained the routing model on conversations across 16 language families, including CJK, European, and others. In evaluations, routing accuracy stayed within four points of the English baseline across language groups, with no statistically significant quality gap. Figure 3: Intelligent routing stays within 4 points of English baseline. Model evaluations across English, European, CJK, and other script families, based on a held out evaluation set sampled from production VS Code chat telemetry across 19 languages. Learning when escalation matters. Instead of labeling tasks as simply “easy” or “hard,” we trained the router to learn where models actually diverge. For each training query, responses

For students and young professionals who refuse to settle, meet the most accessible XPS ever built.   ​  ​For students and young professionals who refuse to settle, meet the most accessible XPS ever built. Laptops Blog | Dell

ITMAITY is a fast-growing technology and digital solutions company delivering innovative, affordable, and professional IT services across India and worldwide. Based in West Bengal, ITMAITY is committed to helping businesses, startups, hospitals, educational institutes, and enterprises build a strong digital presence with modern technology and creative marketing solutions. With a dedicated team of developers, designers, marketers, and IT experts, ITMAITY offers end-to-end digital transformation services tailored to every business need. From professional website development and mobile applications to digital marketing, branding, AI automation, and IT infrastructure solutions — ITMAITY focuses on quality, performance, security, and customer satisfaction. Our Services 💻 Website Design & Development📱 Android & iOS Mobile App Development📈 Digital Marketing & SEO Services🎨 Branding, Graphics & Creative Design🎬 Professional Video Editing & Motion Graphics🤖 AI Automation & Smart Business Solutions🖥️ Computer Sales, Service & Networking📹 CCTV & Security Solutions☁️ Domain, Hosting, Cloud & Business Email Solutions🧾 Billing Software & POS Setup📊 Social Media Management & Ads Campaigns🛠️ Custom Software Development🌐 E-commerce & Business Management Solutions Why Choose ITMAITY? ✔ Professional & Affordable Solutions✔ Latest Technologies & Modern Designs✔ SEO Friendly & High Performance Platforms✔ PAN India & Global Service Support✔ Dedicated Technical Support Team✔ Business-Focused Growth Strategies✔ Creative & Corporate Branding Expertise ITMAITY believes technology should not only look professional but also generate real business growth. The company continuously works on innovative digital strategies to help clients improve their online visibility, customer engagement, and brand value. Whether you are a startup, local business, hospital, educational institute, or large enterprise — ITMAITY provides scalable and reliable digital solutions designed for long-term success. 🌐 Website: www.itmaity.com📧 Email: info@itmaity.com📞 Contact: +91 87590 27112 “Virtual Secure Services Across Worldwide.”

AI has arrived in the enterprise, and the shift is happening all at once. Every function, every role, every workflow is being reshaped. At the same time, a new class of organizations is emerging, one that will look fundamentally different from the companies that defined the last era of business. The winners won’t be those with the most demos, but those that turn AI into a governed, continuously improving system for running real work. This isn’t just about chatbots, either. Those experiences are useful, but they don’t transform how large organizations operate. The real opportunity is teams of agents executing long running work across functions like software delivery, support, finance, HR, and operations — with the identity, context, policy, and human oversight required to trust them in production. To make this possible, enterprises need more than access to a powerful AI model or scalable compute. What determines success is the system around the AI: how agents are built and deployed by engineering teams, how they’re contextualized in the enterprise, how they’re governed and observed in production, and how they improve safely over time. Without that system, AI remains fragmented, fragile, and difficult to trust at scale. We’re taking a fundamentally different approach. We are building a comprehensive agent platform: one that supports many models, is open, and gives you choice and flexibility at every layer of the stack. And we are purposefully designing it with developers at the center. Today, the next pieces of that platform are clicking into place. Building a system for the agentic enterprise To succeed in this new era, an agent platform must meet a higher bar. It must run real production workloads, map real organizational complexity, and manage real business responsibility. We’re building around three key principles: First, it must be a single, integrated system, with support for a wide range of models. Enterprises can’t afford to assemble their agent strategy one piece at a time. Disconnected tools stitched together after the fact can slow teams down and introduce unnecessary risk. Building, contextualizing, running, governing, and improving agents should happen within one coherent system. That’s why we’re bringing together Azure, GitHub, Microsoft IQ, Fabric, Foundry, Windows, Microsoft Security, and Microsoft 365 to operate as a single system you can use to deploy agents at enterprise scale. Enterprises also need the flexibility to choose the right model for the task, balancing quality, speed, and cost — including Microsoft models, partner models, and open models. Second, it must be secured and governed by design. Governance is easy to claim and much harder to deliver. Making it real means starting with a single stack that spans development through production, built on the identity, access, compliance, and security foundations enterprises already trust. By extending Entra, Purview, Defender, Agent 365, and the broader Microsoft Security stack, governance becomes native to the system rather than bolted on later, supporting the ambitions of an AI first enterprise without compromising control. Third, it must improve continuously. Enterprise AI systems can’t be static. Agent behavior, outcomes, and human feedback must flow back into the system, so it can improve safely over time under human oversight. As the system runs, models, workflows, and agents become more capable and more specific to an enterprise’s unique business processes. The result is a system that compounds in value the longer it’s in use. These properties are becoming must-haves, and enterprises that align their AI ambitions with these three principles will pull ahead in quarters, not years. So how does a system like this actually take shape inside a real enterprise? It starts where work begins, with how agents are built. Let’s walk through what that looks like on the platform we’ve built.   1. Build in GitHub GitHub is where your developers already work. It’s where your dependencies live, where your application and code context is kept, where you collaborate with the open source community you depend on, and where you drive innovation. Building agents anywhere else means leaving all that behind. Agents should be built the same way production software is built. You write code with GitHub Copilot to move faster. You bring together the assets that matter most: codebases, work items, agent skills, and tools. And because agents aren’t just code, you bring your evals and observability assets alongside them, all versioned the way any production system should be. Agents must follow a lifecycle: source, test, deploy, observe, and improve. GitHub sets up that lifecycle and provides the necessary controls from day one. The result is a workflow designed for building agents with the right guardrails from the start. And you can do all this in one place, in a new app built for this system. 2. Contextualize with Microsoft IQ Code is only part of an agent. To be useful, an agent also has to understand your business: your customers, your products, your contracts, your processes. Without enterprise context and intelligence you can trust, even the most capable model is guessing. Enterprises require a wide variety of models and the ability to match the right model to the right job, but model choice alone is not enough. Microsoft IQ grounds agents in enterprise context by connecting to your business data wherever it lives, across Microsoft 365, your core business systems (such as customer and revenue data), and other systems your enterprise already relies on, like knowledge bases and your website. With Web IQ, the latest addition to the IQ platform, agents can also incorporate relevant information from the web when appropriate. Contextualizing agents in enterprise data isn’t just about access. Pointing AI at raw information is inefficient and brittle. Microsoft IQ organizes, secures, and surfaces the right information in forms agents can actually use, so they can reach accurate insight without drowning in noise or hallucinating answers. Once agents are grounded in the right context, enterprises can go further. With Frontier Tuning, you don’t just call AI models. You improve how they behave using your data and real-world workflows. That includes Microsoft’s seven new