Most people think ASCII art is simple, and a nostalgic remnant of the early internet. But when the GitHub Copilot CLI team asked for a small entrance banner for the new command-line experience, they discovered the opposite: An ASCII animation in a real-world terminal is one of the most constrained UI engineering problems you can take on. Part of what makes this even more interesting is the moment we’re in. Over the past year, CLIs have seen a surge of investment as AI-assisted and agentic workflows move directly into the terminal. But unlike the web—where design systems, accessibility standards, and rendering models are well-established—the CLI world is still fragmented. Terminals behave differently, have few shared standards, and offer almost no consistent accessibility guidelines. That reality shaped every engineering decision in this project. Different terminals interpret ANSI color codes differently. Screen readers treat fast-changing characters as noise. Layout engines vary. Buffers flicker. Some users override global colors for accessibility. Others throttle redraw speed. There is no canvas, no compositor, no consistent rendering model, and no standard animation framework. By the numbers 3 seconds of animation ~20 frames ~6,000 lines of TypeScript Dozens of terminal + theme combinations tested So when an animated Copilot mascot flying into the terminal appeared, it looked playful. But behind it was serious engineering work, unexpected complexity, a custom design toolchain, and a tight pairing between a designer and a long-time CLI engineer. That complexity only became fully visible once the system was built. In the end, animating a three-second ASCII banner required over 6,000 lines of TypeScript—most of it dedicated not to visuals, but to handling terminal inconsistencies, accessibility constraints, and maintainable rendering logic. This is the technical story of how it came together. 📦 What’s new in GitHub Copilot CLI GitHub Copilot CLI brings agentic workflows directly into your terminal—letting you plan projects, modify files, run commands, use custom agents, and delegate tasks to the cloud, all without leaving the CLI. Since its introduction, Copilot CLI has expanded to support richer, more flexible agentic workflows: Works the way you do with persistent memory, infinite sessions, and intelligent compaction Helps you think using explore, plan, and review workflows where you can choose the model at each step Executes on your behalf with custom agents, agent skills, full MCP support, and async task delegation Want to bring these same agentic capabilities into your own tools or products? The GitHub Copilot SDK exposes the same execution loop that powers Copilot CLI, so you can embed agents into any application using your Copilot subscription or your own model keys. Learn more about the Copilot SDK > Why animated ASCII is a hard engineering problem Before diving into the build process, it’s worth calling out why this problem space is more advanced than it looks. Terminals don’t have a canvas Unlike browsers (DOM), native apps (views), or graphics frameworks (GPU surfaces), terminals treat output as a stream of characters. There’s no native concept of: Frames Sprites Z-index Rasterized pixels Animation tick rates Because of this, every “frame” has to be manually repainted using cursor movements and redraw commands. There’s no compositor smoothing anything over behind the scenes. Everything is stdout writes + ANSI control sequences. ANSI escape codes are inconsistent, and terminal color is its own engineering challenge ANSI escape codes like x1b[35m (bright magenta) or x1b[H (cursor home) behave differently across terminals—not just in how they render, but in whether they’re supported at all. Some environments (like Windows Command Prompt or older versions of PowerShell) have limited or no ANSI support without extra configuration. But even in terminals that do support ANSI, the hardest part isn’t the cursor movement. It’s the colors. When you’re building a CLI, you realistically have three approaches: Use no color at all. This guarantees broad compatibility, but makes it harder to highlight meaning or guide users’ attention—especially in dense CLI output. Use richer color modes (3-bit, 4-bit, 8-bit, or truecolor) that aren’t uniformly supported or customizable. This introduces a maintenance headache: Different terminals, themes, and accessibility profiles render the same color codes differently, and users often disagree about what “good” colors look like. Use a minimal, customizable palette (usually 4-bit colors) that most terminals allow users to override in their preferences. This is the safest path, but it limits how accurately you can represent a brand palette—and it forces you to design for environments with widely varying contrast and theme choices. For the Copilot CLI animation, this meant treating color as a semantic system, not a literal one: Instead of committing specific RGB values, the team mapped high-level “roles” (eyes, goggles, shadow, border) to ANSI colors that degrade gracefully across different terminals and accessibility settings. Accessibility is a first-class concern Terminals are used by developers with a wide range of visual abilities—not just blind users with screen readers, but also low-vision users, color-blind users, and anyone working in high-contrast or customized themes. That means: Rapid re-renders can create auditory clutter for screen readers Color-based meaning must degrade safely, since bold, dim, or subtle hues may not be perceivable Low-vision users may not see contrast differences that designers expect Animations must be opt-in, not automatic Clearing sequences must avoid confusing assistive technologies This is also why the Copilot CLI animation ended up behind an opt-in flag early on—accessibility constraints shaped the architecture from the start. These constraints guided every decision in the Copilot CLI animation. The banner had to work when colors were overridden, when contrast was limited, and even when the animation itself wasn’t visible. Ink (React for the terminal) helps, but it’s not an animation engine Ink lets you build terminal interfaces using React components, but: It re-renders on every state change It doesn’t manage frame deltas It doesn’t synchronize with terminal paint cycles It doesn’t solve flicker or cursor ghosting Which meant animation logic had to be handcrafted. Frame-based ASCII animation has no existing workflow for designers There are tools for ASCII art, but virtually none for: Frame-by-frame editing Multi-color ANSI