The art of simplicity

If you've been using GitHub Copilot CLI for a while, you've probably had that Monday morning feeling; staring at your terminal trying to remember exactly what you were doing on Friday. Or maybe you've wondered why some of your Copilot interactions go smoothly while others turn into back-and-forth marathons. Enter /chronicle , an experimental slash command that turns your CLI session history into something genuinely useful. Session history Every time you interact with Copilot CLI, the session data is stored locally on your machine. That's not just a log file — it's a record of your real-world workflow: which branches you worked on, what you tried, when you got stuck, and how you course-corrected. The /chronicle command gives you a structured way to query that history and extract insights you couldn't easily get otherwise. Note: /chronicle is currently an experimental feature. You'll need to run /experimental on (or use the --experimental flag)...

In the previous post I set the stage on deploying to production. We covered managing the CLI process, different isolation patterns and how to scale horizontally. This post covers 2 other aspects important when putting your GitHub Copilot SDK enabled application into production; how to tackle authentication and how to get insights into what is going inside your agentic system. Authentication in production Development uses your personal GitHub credentials via gh auth login . Production backends need a different approach. Service account token (shared CLI): Set COPILOT_GITHUB_TOKEN as an environment variable on the CLI process. All sessions on that CLI use the same token. Simple, but every user is acting as the service account. export COPILOT_GITHUB_TOKEN="gho_service_account_token" copilot --headless --port 4321 Per-user tokens (GitHub OAuth): For multi-tenant applications where users authenticate with their own GitHub identities, pass each user's token wh...

In the previous post we went deep on sessions — how to create, persist, resume, and manage them in .NET. All of that assumes you have a running application talking to a Copilot CLI. In development, that's trivial: the SDK starts the CLI for you automatically. In production, the picture is more complex. This post is about what happens between "it works on my machine" and "it's serving real users." We'll look at how the CLI architecture actually works, when to run the CLI as a separate headless server, the isolation patterns that fit different application types, and how to scale horizontally without losing session state. How the SDK talks to the CLI Before making deployment decisions, it helps to understand the communication model. Every SDK in every language works the same way underneath: Your Application ↓ SDK Client ↓ JSON-RPC ↓ Copilot CLI (server mode) All SDKs communicate with the Copilot CLI server via JSON-RPC. ...

If you use GitHub Copilot, you probably already got the communication that there's a billing change coming on June 1, 2026 that you should understand before it kicks in. GitHub is moving from premium request units (PRUs) to a token-based credit system, and for heavy users, especially those doing agentic work, the cost difference can be significant. The good news (I don't really know if I should call it that): GitHub has shipped a billing preview tool that lets you see your projected costs right now. Here's what's changing, what the impact is, and exactly how to use the preview experience to protect your budget. What's actually changing? GitHub Copilot has historically billed "premium requests" — a flat unit that counted each interaction with advanced models. Starting June 1, that system goes away. In its place is GitHub AI Credits , priced by token consumption: every input token, output token, and cached token is metered at the published API rate fo...

Techorama 2026 was a blast! Great content, great atmosphere and great people. And of course, the main conversation topic was AI and how it will shape our industry. Nobody knows what is coming next but at least we already got a glimpse into the future. I delivered a presentation about integrating the GitHub Copilot SDK into your application and hopefully proved how easy it is to get an agent running inside your systems. AI is moving from assistants we query to agents that collaborate with us inside our applications. By reusing the same agentic loop behind the Copilot CLI, the Copilot SDK makes that shift practical for every developer. In this session, we explore how to embed GitHub Copilot–powered agents directly into your apps, extend them with custom skills, and connect them to your own data and workflows. You’ll see how to design agent behaviors, orchestrate tool use, and create safe, reliable interactions that feel native to your product. Whether you’re building personal ...

If you looked at an older GitHub Copilot SDK example online and copied it over, there is a chance that you see the following error message when you try to execute the code: Unhandled exception. System.ArgumentException: An OnPermissionRequest handler is required when creating a session. For example, to allow all permissions, use CreateSessionAsync(new() { OnPermissionRequest = PermissionHandler.ApproveAll }); at GitHub.Copilot.SDK.CopilotClient.CreateSessionAsync(SessionConfig config, CancellationToken cancellationToken) So, what exactly is happening here? The important part is this: An OnPermissionRequest handler is required when creating a session. The GitHub Copilot SDK is designed with a permission-based execution model . Whenever Copilot wants to execute a tool, access resources, or perform potentially impactful operations, the SDK expects the host application to decide whether that action is allowed. This is done through the OnPermissionRequest callback. With older...