The art of simplicity

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...

In the previous post we got a working .NET app talking to the Copilot agent runtime. We created a CopilotSession , sent messages through it, and saw how multi-turn conversations just work — the agent remembered what you said three messages ago without you having to manage that state yourself. That "just works" quality is deliberate, and it's worth understanding what's actually happening underneath. Sessions are the stateful core of the Copilot SDK. How you create, configure, scope, and dispose them determines whether your application is resilient, scalable, and cost-efficient — or fragile and leaky. This post goes deep on sessions: what they are, how their lifecycle works, how to persist them across restarts, and the patterns that hold up in production. The mental model: Client vs. Session Before getting into lifecycle specifics, it's worth being precise about the two core classes and what each one owns. CopilotClient is infrastructure. It manages th...