When Christian Simpson, a retro gaming YouTuber also known as Peri Fractic, bought the remains of an early PC company called Commodore in 2025, he decided to pick up right where the original Commodore left off. Which meant starting product development in the mid-1990s. Simpson and his team first set to work reviving the company's most iconic product, and you can now buy a Commodore 64 that is the spitting image of the 1982 original (other than the Wi-Fi connectivity, the USB ports, and a few other slightly modern niceties). It's a pure nostalgia play, and by most accounts, a very good one. Commodore says it has sold 30,000 of them since last …

Read the full story at The Verge.

As the rest of the country celebrated the USA's first World Cup win and the New York Knicks championship, Anthropic spent its weekend fighting the Trump administration over its latest model release. At 5:21 PM on Friday, the company received a US export control directive to suspend access to its Mythos 5 and Fable 5 AI models by "any foreign national" inside or outside the US, "including foreign national Anthropic employees." The only way that was possible, Anthropic determined, was to completely disable products it spent the past week hyping - and travel to Washington, DC in hopes of changing President Donald Trump's mind. Now, over the com …

Read the full story at The Verge.

Recorded live at the AI Agent Conference, Ryan sits down with Apollo GraphQL CEO Matt DeBerglis to discuss how enterprises can leverage GraphQL and MCP as a structured semantic architecture to feed clean data to autonomous agents, safeguard internal microservices against unprecedented "east-west" data exfiltration risks, and rein in skyrocketing token spend by explicitly querying only the exact context required.​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌​‌‍​‌‌‍‍‌‍‍‌‌‌​‌‍‌​‍‍‌‍‍‌‌‍​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‍‌‌‍‍‌‌​‌‍‌‌‌‍‍‌‌​​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​​‍‌‍‌‌‍‌‍‌​‌‍‌‌​‌‌​​‌​‍‌‍‌‌‌​‌‍‌‌‌‍‍‌‌​‌‍​‌‌‌​‌‍‍‌‌‍‌‍‍​‍‌‍‍‌‌‍‌​​‌‌‍​​​‍​​‌‍​​​​​‍‌‌‍​‍​​‍​‍‌​‌​​​‌​​‌‍‌​​‍‌​‌​‌‍​‌​‌​​​​‍‌​‍‌‌‍​‌‌‍​‍‌‍​​‍‌‌‍‌‌​‌​​​‌‍‌​​​‌‌‍​‍​‌​​​​‌‍‌‍‌‍​‌‍​‌​‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‍‌‌‌‍​‌‍​‌‍‌‌‌​‍‌​​‌‌​​‌‍​‍‌‍​‌‌​‌‍‌‌‌‌‌‌‌​‍‌‍​​‌‌‍‍​‌‌​‌‌​‌​​‌​​‍‌‌​​‌​​‌​‍‌‌​​‍‌​‌‍​‍‌‌​​‍‌​‌‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‌‍‍‌‌‍‌​​‌‌‍​​​‍​​‌‍​​​​​‍‌‌‍​‍​​‍​‍‌​‌​​​‌​​‌‍‌​​‍‌​‌​‌‍​‌​‌​​​​‍‌​‍‌‌‍​‌‌‍​‍‌‍​​‍‌‌‍‌‌​‌​​​‌‍‌​​​‌‌‍​‍​‌​​​​‌‍‌‍‌‍​‌‍​‌​‍‌‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‍‌‌‌‍​‌‍​‌‍‌‌‌​‍‌​​‌‌​​‍‌‍‌​​‌‍‌‌‌​‍‌​‌​​‌‍‌‌‌‍​‌‌​‌‍‍‌‌‌‍‌‍‌‌​‌‌​​‌‌‌‌‍​‍‌‍​‌‍‍‌‌​‌‍‍​‌‍‌‌‌‍‌​​‍​‍‌‌

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!

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.

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.