bubbletea

@dumbuffalo Golang Lib for the terminal apps charmbracelet/bubbletea

typeghast: a typing game haunted by your coding agent's context window This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine What I Built There's a dead stretch in every coding-agent session. You hand over a task, the agent starts reading files and running tests, and you sit there watching it scroll. Meanwhile, out of sight, its context window fills up with every file it read, every log it printed, every plan it revised. Past a certain point the agent starts to forget and to contradict itself. People call it context rot, and Context Rot: Why Your AI Coding Agent Gets Dumber Mid-Session by enjoy_kumawat describes it well. typeghast turns that dead stretch into a typing game, and turns context rot into actual ghosts. !typeghast: typing what the agent just did while ghosts named after its context swarm the text, until a compact exorcises them You run it in a split pane next to your agent. It reads the agent's session as it happens and: - gives you the agent's work to type. A local Gemma model turns what the agent just did into short changelog lines: "Implemented a cost pumpkin in the header for tracked sessions." So you learn what changed while you wait, instead of finding out from the diff afterwards. - fills the screen with ghosts as the context fills up. They drift over the words and hide letters. Some hunt your cursor. Near the peak they turn a rotten green. - names every ghost after something haunting the context: ci logs, webhook retries, pagination test. They're the agent's past, still hanging around in the window, taking up space. - exorcises them when you /compact or /clear. The context drops and the ghosts flee. - pays you to type through it. The score multiplier climbs to ×3 at the peak, and a 🎃 pumpkin in the corner shows what the session would have cost at API prices. !Haunted mode: ghosts named after the agent's context drift over the line being typed, with the context meter and cost pumpkin in the header That's the theme as I read it: a ghost in the machine that is literally the machine's own past, and a small ritual for laying it to rest. There's also a normal mode with no agent: you type today's top headlines from DEV, Lobsters and Hacker News. Type a headline without a mistake and its link unlocks. !Normal mode: typing a trending DEV headline, with the unlocked link shown under the text Demo go install github.com/cliffkoome/typeghast@latest typeghast --demo --demo needs nothing else. It plays a made-up agent session, and you control the context with PgUp and PgDn. Home or ctrl+l compacts and triggers the exorcism. To play it for real, run plain typeghast while a Claude Code session is working, and it finds the session on its own, or lets you pick one if several are running. Prebuilt binaries for Linux, macOS and Windows are on the v0.1.0 release. Code {% github cliffkoome/typeghast %} Go, Bubble Tea and Lip Gloss, MIT licensed. It's a single binary with no runtime dependencies. How I Built It Reading the agent's mind (well, its transcript) Claude Code writes each session to a JSONL file under ~/.claude/projects/. typeghast tails that file. Each reply records its token usage, so the context size is simple to get: input + cache reads + cache writes + output, taken from the latest reply. How full is "full"? A fixed number of tokens would be wrong for most models, so the haunting peaks at a fraction (default 40%) of the model's real context window. Window sizes and prices come from LiteLLM's open model catalog. Two things in the transcript caught me out: - Every reply is logged several times, once per content block, up to four copies. Add up usage naively and the cost pumpkin overcharges you up to 4×. Usage is now counted once per message id. - Subagent turns are in the same file. They cost money, so they count toward the pumpkin. But they run in their own context, so they must not count toward the ghosts. The narrator: Gemma 4, on my own GPU Every few actions, typeghast sends a batch of them (files edited, commands run, what the agent said) to a model running locally in Ollama. The model returns JSON: 2 to 4 sentences to type, plus 1 to 3 names for the ghosts. If Gemma is installed it's picked automatically. Here's real output from the session where I built the cost pumpkin: > Added tests for deduplicated spend and pricing logic. > Implemented a cost pumpkin in the header for tracked sessions. > Rendered a haunted frame from the session transcript. > > ghosts: cost pumpkin, haunted frame, status.md The part where Gemma 4 was unusable, and then wasn't I compared Gemma 4 12B with Qwen 2.5 7B on an AMD Radeon RX 6600. Both got the same four batches of real events from one of my sessions. Gemma's first run was a disaster: - about 90 seconds per batch - 2 of 4 batches came back with no JSON at all ollama show gemma4:12b gave it away: Gemma 4 has thinking on by default. It was reasoning at length before every answer, and sometimes it ran out before it ever wrote the JSON. A typing game can't wait 90 seconds for its next sentence. The fix was one field in the request: body, _ := json.Marshal(map[string]any{ "model": n.Model, "stream": false, "format": "json", // Thinking models like Gemma 4 otherwise reason for minutes before // answering, and sometimes run out before writing the JSON. "think": false, // Narration comes in bursts; don't reload the model between them. "keep_alive": "30m", // ... }) | | Gemma 4 12B | Qwen 2.5 7B | |---|---|---| | First call (loads the model) | 9 s | 5.4 s | | Later calls | 3.3–6.1 s | 1.5–1.8 s | | Valid JSON | 4/4 (was 2/4) | 4/4 | | Sentences | clean changelog lines, consistent tense | choppier, mixed tenses | Qwen is faster, but Gemma writes the better lines, and in play the speed doesn't matter. Narration runs in the background while you type the lines already queued, so you never see the wait. Gemma stays the default. It turns out think: false matters for more than speed. Ollama skips your JSON schema when a thinking model answers without thinking by homelabpm explains why. On the same Ollama version I'm running, a thinking model only gets the format enforced after its thinking block. With thinking off, the format applies from the very first token. typeghast also checks every reply and drops anything malformed. The comparison turned up one more bug. My prompt included example ghost names, and Qwen copied them word for word in 3 of 4 batches. Whatever the agent had actually done, the ghosts came back as model.go rewrite, flaky test logs and old todo list. I replaced the examples with an instruction: take each name from the actions above, never invent one. After that, both models named real things every time. Making typing feel good A typing game lives or dies on feel, so: - Correct words flash gold. - Speed lines stream under the letters you just typed once you pass 70 WPM. They grow longer and hotter (yellow, orange, red) up to 130, and they wrap back to the line above, so they don't vanish when you start a new line. - The screen shakes, but only on big moments: a perfect sentence, an unlocked link, every 25-word streak, an exorcism. Shaking on every word made the text jump while you were reading it, so I didn't. Why Open Matters Here Agent transcripts are private by nature. They hold your source code, your file paths, your shell commands, sometimes a secret printed in a log. Sending all of that to someone else's API to power a typing game would be absurd. With an open-weight model in Ollama, the transcript is read from your disk and summarised on your GPU, and none of it leaves your machine. It's free, so it can run constantly. The narrator fires every few actions for as long as the agent works, all day if you let it. Each call is cheap, but metered calls add up. Locally the marginal cost is zero, so the game can narrate everything instead of rationing calls. The narrator works offline. No API key, no account, no rate limit, nothing to sign up for. I could see inside it and fix it. The Gemma problem was solvable because everything was open: I could read the model's capabilities, toggle its thinking mode, and compare it head to head with another open model on my own data, in an afternoon. With a closed endpoint I'd have been guessing at a black box. Nothing is locked in. --model takes any Ollama model, and with no model installed typeghast falls back to the agent's own words. The game still works for everyone. The open model is what makes it good. Prize Categories - Best Use of Gemma. Gemma 4 12B is the default narrator. It writes every sentence you type and names every ghost, entirely on-device, and this post documents how I got it from about 90 seconds per batch to 3–6 seconds.

😤 想给命令行工具做界面，得学一堆终端控制码。bubbletea 4.5 万星，Go 的 TUI 框架，像写普通程序一样做终端界面。 charmbracelet/bubbletea

Building KaizenSQL - My Dev Journey TL;DR KaizenSQL is a CLI tool written in Go, it analyzes SQL code and supports three modes Mentor/Performance/Security. To give it AI-powered capabilities I used Groq api for free LLM tokens. Overall, the main concern and goal with this project was to make the tool fast and pleasant to use. Every decision to be implemented had to take that into account. In this post I'll share the faced scenarios, the good parts and bad ones. Code repo link at the end. ☕ --- HI fellow developer, pal, buddy, maybe a friend reading this 👋. I'm Juan Huanaco, a Systems Engineering student from Peru. 🇵🇪 Today's post is about a small project: KaizenSQL, a Go based CLI tool that analyzes SQL code. First question: Why? Do I need it? Not for now haha, I do not deal with tons of SQL these days. This time it's not about the final product but the <u>pillars and process experience</u> while building it. I like how reliable some CLI based programs are. Just type the command with some arguments and zap⚡! The result is at your screen. "Qué genial, quiero crear algo así..." was my thought. So I wanted to create a tool that reads a file/directory, sends that to an LLM for feedback AND has an intuitive and good-looking UI. On top of that, it had to be fast (as much as it could, I'm looking at you APIs falling several times lol). That's it, up next are the key decisions that made me pause and think through each implementation step. AI Agent brain - No need to think much I use Gemini chat, is smart enough to help me find good resources and give advices. But I didn't want to spend money on trying the API version. Their free tier limits leaves you sweating. For that reason I chose another LLM provider for this project. 💪 That's Groq API, it has a generous limit to use it properly as a sandbox for testing your AI interactions. Also it was designed to be mostly compatible with OpenAI's client library, so you can switch/scale with them or OpenAI APIs in the future without doing lots of changes on connections. It's fast and best part, no need to share card data for their free account. [2026.10.04] ADR-001: Modes definition for inspection After having the initial code for connecting with Groq API successfully, I had an LLM agent ready to deal with text. Now, "...tool to analyze SQL code...", great but what exactly should we monitor? Speed? Security? Both? If so, should it be a single scan for all? One of the constraints was that the specific model I used offered 8k tokens per minute. !Groq site showing available model's limits So I had to ensure to leave enough space for SQL code (which could be pretty big) but also injecting enough proper system prompt. Also this introduces a good reason to add command flags to my tool. The flag module comes in handy: import "flag" func main() { showBanner() checkModeMentor := flag.Bool("m", false, "Use mentor mode [Default]") checkModePerf := flag.Bool("p", false, "Use performance mode") checkModeSec := flag.Bool("s", false, "Use security mode") var chosenMode Mode flag.Parse() and depending on the selected mode (btw they don't add up), we sent a different system prompt to the agent. Also I added a Mentor mode, its value is that it does not solve the problem, but guides you a clue so that you can find the answer yourself. Since developers are directly responsible for coming up with the solution, the new concept is easily sticks in their mind. [2026-10-04] ADR-002: Output tokens limit excedeed when calling the agent 🫣 !A screenshot showing an OTPM error Well... this one was on me haha Of my three executions just one showed the error. Up to this point, I hadn't checked the output limits for qwen/qwen3.8-27b. To my surprise only 1k tokens were offered (7k in / 1k out). Time to change model? Nope, I liked how qwen performed, I used it on another project where I connected Foxit PDF API to a CLI tool. Btw i have a video about that, you can check it 👉 here (warning: behold, just pure and good spanish there 🧑‍⚖️) the fix? just to set the limit explicitly, that's ok for this little project's scope response, err := client.CreateChatCompletion(ctx, openai.ChatCompletionRequest{ Model: k.agentModel, + MaxCompletionTokens: 900, Messages: []openai.ChatCompletionMessage{...} } --- The rest of the Journey Animated banner - Adding Bubbletea I was scrolling on blogs and found one about Github Copilot CLI. I knew some CLI tools add a nice-looking banner to their programs, however an animated one was something I didn't see too much. Easy to say I was impressed first time I saw this: !Github Copilot CLI animated banner In their blog they mentioned the use of Ink 🌈 (a React renderer for building CLIs with JSX). Seemed like a great fit, if only that's wasn't just for NodeJS based tools. 😔 After some googling I found bubbletea (a TUI framework), this awesome open-source solution was the speedtrack I was looking for. But things get better, because Cameron Foxly (principal brand designer at GitHub) created Ascii Motion a website to create ascii animations through an intuitive UI and export them to many formats, one of them was bubbletea anim. !ascii-motion page Wrapping up This concludes the developing journey for this little project. I hope you enjoyed this post as much as I did writing it. ✍️ The repo: KaizenSQL by jhuanaco Setup instructions and the binary -ready to use- live happily there. !KaizenSQL in action gif What's next While coding I noted these: - Add interactive file selection: Instead of passing the filename as a command-line argument, why not list all the .sql files on the current directory and let the user choose taking advantage of bubbletea keyboard interaction. - Heuristic pre-analysis: If we start to inject more rules into the system prompt, eventually we might exceed the ITPM (input token per minute) limit. A pre-analysis on found keywords (JOIN, SINGLE, INSERT, etc) might be used to inject on the prompt just as needed rules. A next step to that approach would be to implement a RAG solution. Will I add these ? Nah, lol The project scope is over, and I know myself enough to tell you that if I not set scope limits, I might keep refactoring, adding, removing code in an unhealthy loop 😂. Also I have other project ideas I want to cook. 👀🧑‍🍳 Thanks ❤️ Special thanks to the people on the open-source world, it was a fun dev experience to work with their great software. And thank you for reading this post. Until the next one. - Go-OpenAI by sashabaranov - Used for communicating with Groq API - Bubbletea by charmbracelet - Text User Interface framework used to add a nice banner. - Ascii Motion by CameronFoxly - Awesome ascii-art animation software

Bubble Tea: The fun, functional and stateful way to build terminal apps (45k stars) What it does All text below is quoted directly from the project README. >The fun, functional and stateful way to build terminal apps. A Go framework based on The Elm Architecture. Bubble Tea is well-suited for simple and complex terminal applications, either inline, full-window, or a mix of both. >Bubble Tea is in use in production and includes a number of features and performance optimizations we’ve added along the way. Among those is a high-performance cell-based renderer, built-in color downsampling, declarative views, high-fidelity keyboard and mouse handling, native clipboard support, and more. Bubble Tea programs are comprised of a model that describes the application state and three simple methods on that model: - Init, a function that returns an initial command for the application to run. - Update, a function that handles incoming events and updates the model accordingly. - View, a function that renders the UI based on the data in the model. >Be sure to check out Bubbles, a library of common UI components for Bubble Tea. Repository charmbracelet/bubbletea Repository stats |Metric|Value| |:-|:-| |Stars|45,293| |Forks|3,184| |Last release|v2.0.10 (2026-09-24)| |Languages|Go 100%| |Contributors|165| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|Copilot: 2| |AI co-authored commits|Copilot: 2| Main contributor |Field|Value| |:-|:-| |Name|Ayman Bagabas| |GitHub|@aymanbagabas| |Commits to this repo|678 (top contributor)| |Company / Location|@GitHub, Brooklyn, NY| |Website|aymanbagabas.com| |X / Twitter|@aymanbagabas| |Followers|611| |Public repos|161| |On GitHub since|2013-01-04|