The art of simplicity

Yesterday I introduced to you statusline command. It allows you to configure a persistent, live bar at the bottom of your CLI session that shows whatever your script prints — token usage, context percentage, current model, cost estimates, session duration, and more. I promised that we would setup something like this: █████░░░░░ 50% 64.0k/128.0k | ✱ Sonnet 4.5 | ~$0.04 | ⏱️ 00:12:34 But yesterday we only got as far as showing this: Hello from PowerShell status line! If you missed the previous post, go read it first, before continuing here. Back? Let's continue... Now we have confirmed the script runs and we've the payload, we can now focus on creating a production-ready version. It extracts context usage, model name, cost (from the payload if available, estimated otherwise), and session duration. I first created my own version but while researching this post I discovered this blog post by Madis Kõosaar: Customize GitHub Copilot CLI Status Line . He created a much...

If you spend serious time in GitHub Copilot CLI, you've probably had that moment. You're deep in a session, things are moving fast, and suddenly you hit context compaction out of nowhere. The /context and /usage commands help, but they interrupt your flow. What if the information was just there , all the time, without you having to ask? That's exactly where the statusline command can help: a persistent, live bar at the bottom of your CLI session that shows whatever your script prints — token usage, context percentage, current model, cost estimates, session duration, and more. Once it's running, it looks something like this: █████░░░░░ 50% 64.0k/128.0k | ✱ Sonnet 4.5 | ~$0.04 | ⏱️ 00:12:34 This guide walks you through the full setup from scratch, including a "hello world" sanity check. In a follow-up post we’ll tweak the result to example above. Status: Custom status line support requires experimental features enabled in Copilot CLI. You can e...

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

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

In the previous post talked about why the GitHub Copilot SDK matters: it gives you a production-grade agent harness out of the box, so you can skip building the infrastructure and focus on your actual product. Now let's make it concrete. This post walks through everything you need to get up and running with the SDK in .NET — from prerequisites to a working streaming agent with a custom tool. What we will build We’ll keep it simple. By the end of this post you'll have a console application that: Connects to Copilot's agent runtime Sends a prompt and receives a streaming response Has a multi-turn conversation with persistent context Calls a custom tool you define in C# Prerequisites You'll need three things before touching any code. 1. .NET 8 or later The SDK requires .NET 8+. Verify your version: dotnet --version 2. GitHub Copilot CLI, installed and authenticated The SDK communicates with the Copilot CLI running as a local process — i...