I Asked for Six Terminals. Thirteen Days Later GridBash Had 130 Stars.

TL;DR

On July 5, 2026, I asked Codex for one app containing a 2 by 3 grid of Git Bash terminals because Alt+Tab was becoming a wildlife documentary. The first attempt scripted Windows Terminal panes; it looked wrong, resized badly, and could not support the selection and input-routing model I wanted, so I pivoted to a Rust TUI that owns real pseudo-terminals and renders them inside one process.

The first Rust commit landed about 12 minutes after I said, "Implement the plan." I published gridbash@0.1.0 to npm at 22:17 UTC, discovered that the panes were not yet usable terminals three minutes later, and created the GitHub repository another 29 minutes after that. This is not the recommended order; it is, however, the actual order.

The repository received its first recorded star on July 8. Star #100 arrived on July 15, 9 days, 23 hours, and 27 minutes after the repo was created; star #130 arrived on July 18, after 12 days, 12 hours, and 17 minutes. By that milestone, main contained 391 commits, 90 merged pull requests, 145 opened non-PR issues, and ten published GitHub releases. My local archive contains 209 GridBash Codex threads through the same cutoff, including 86 explicitly marked as subagent threads.

The star curve accelerated after the project became easier to understand and easier to install: the README was reduced, Windows-only assumptions were removed, macOS and Linux packages shipped, a real landing page and product video appeared, and v0.2.0 put those changes into a named release. X and LinkedIn appear in GitHub's aggregate referrers, but the evidence does not identify one magical post; in fact, the formal outreach plan and Product Hunt/Hacker News preparation started after most of the largest star day had already happened.

You can inspect or rerun the launch-history artifact, including the timestamped star data, exact chart, release list, and verification script. The useful lesson is not "make 391 commits in 13 days" because that is deranged; it is that open-source growth came from a tight loop between daily use, visible fixes, low-friction packaging, and public proof that the thing existed.

Figure 1. Six terminals entered; 130 stars and an alarming amount of repository administration came out. Subtext: The stick figure remains legally classified as the maintainer. Source: Generated with GPT Image 2.

Contents

• First, the number is 13 days
• The original product brief was one irritated paragraph
• The first architecture was wrong in a useful way
• I published the package before the terminals worked
• Dogfooding produced better requirements than a roadmap
• The stray R explains the engineering process
• The repository became a small software factory
• What happened before the star curve bent
• What probably did not cause the spike
• Stars are attention, not adoption
• The repeatable part
• What this case study does not prove
• Conclusion

First, the number is 13 days

"It got around 130 stars in a couple of days" is a fun sentence and a bad measurement. GitHub reports that the GridBash repository was created at 2026-07-05T22:46:52Z; when I collected the timestamped current-stargazer list on July 20, the 130th ordered star was recorded at 2026-07-18T11:03:46Z.

That makes the repo-to-milestone interval 12 days, 12 hours, 16 minutes, and 54 seconds. I am calling it 13 days because humans read titles, but the exact interval is here so nobody has to perform forensic arithmetic on my vibes.

There is another important measurement detail: GitHub exposes timestamps for people who currently star a repository, not an immutable history of every star and unstar event. An early person can unstar later, which may shift a reconstructed ordinal milestone. The collector therefore saves the July 20 snapshot, states this limitation, and fails its verification step if the live reconstruction drifts from the archived result.

The checked milestones were:

Milestone	UTC timestamp	Time since repository creation
Repository created	2026-07-05 22:46:52	0
First recorded star	2026-07-08 01:30:09	2d 2h 43m
Star #100	2026-07-15 22:14:14	9d 23h 27m
Star #130	2026-07-18 11:03:46	12d 12h 17m

This is the first rule of documenting a launch: fix the denominator before extracting life lessons from the numerator.

The original product brief was one irritated paragraph

The first GridBash session did not begin with a market map, a category thesis, or an elegant RFC. It began with a screenshot and this request:

"Can u make me an app / exe or anything I can run to instantly get a grid of Git Bash terminals?"

The required behavior was already surprisingly concrete: ask for M x N, divide the space evenly, keep every terminal in one application so Alt+Tab shows one thing, and resize dynamically. When the first visual result arrived, my follow-up was even more rigorous:

"It ended up like this lol."

Then the actual product began emerging. I wanted Ctrl+click multi-selection so one command could be broadcast to chosen terminals; I wanted it to feel better than existing agent multiplexers; I did not want modal controls; I wanted to change the active shell inside the app; and by the next session, I wanted separate auth profiles, project directories, and multi-agent orchestration.

That sequence matters because GridBash was never really "six terminals." Six terminals were the visible symptom. The underlying job was keeping several independent coding-agent sessions visible, addressable, isolated, and comprehensible without converting my desktop into a casino security wall.

The first architecture was wrong in a useful way

The first implementation tried to orchestrate Windows Terminal from outside it. A PowerShell launcher could open a window and repeatedly call wt split-pane; with enough focus movement and ratio arithmetic, it could resemble a grid. This was fast to prototype, but the abstraction was fighting the product.

Windows Terminal owns its pane tree and interaction model. An external launcher can request splits, but it does not naturally own a spreadsheet-like set of cells, a subset-selection state, broadcast routing, pane metadata, agent lifecycle, or one consistent redraw loop. Exact M x N geometry also becomes awkward because sequential splits operate on the currently focused branch of a tree, while the desired interface thinks in rows and columns.

At 20:39 UTC, I asked Codex to look at serious agent multiplexers and make GridBash "infinitely better"; at 20:46, I chose the hard direction, and at 21:31 I said, "Implement the plan."

The resulting architecture put one TUI process in charge of many pseudo-terminals:

keyboard and mouse
        |
        v
  GridBash event loop
   |      |      |
   v      v      v
 PTY 1  PTY 2  PTY 3 ...
   |      |      |
 shell  Codex  Claude ...

PTY output -> VT parser -> per-pane screen state -> Ratatui frame

The initial stack, which remains visible in Cargo.toml, used Crossterm for terminal events and the backend, Ratatui for layout and rendering, portable-pty for child pseudo-terminals, and vt100 to parse each child's escape sequences into screen state. This was the correct ownership boundary: GridBash could now decide which pane receives input, how panes resize, what metadata appears around them, and how a real terminal program's output becomes cells on screen.

The first Rust commit landed at roughly 21:43 UTC, about 12 minutes after implementation began. That number sounds superhuman until you include the rest of the night, which immediately did.

I published the package before the terminals worked

By 21:55 UTC, I wanted the program to install like the agent CLIs it managed; npm was the distribution wrapper, while the actual application remained a native Rust executable. gridbash@0.1.0 was published at 22:17 UTC.

At 22:20, I reported that the cells were not actually producing usable terminals.

Figure 2. The package achieved escape velocity before its cargo achieved terminal input. Subtext: Semantic versioning is not a substitute for looking at the screen. Source: Generated with GPT Image 2.

There were two classes of failure. First, the npm launcher had to resolve Windows command shims such as .cmd files correctly instead of treating every profile as a directly executable native binary. Second, a pane needed a complete PTY loop: spawn the child, read output continuously, feed bytes through a VT parser, render the resulting screen, forward keystrokes, and resize both the emulated screen and underlying PTY when its rectangle changed.

The GitHub repository itself was created at 22:46 UTC, after the npm package; another session message then summarized the ambition as, "make this an amazingly trendy repo," immediately followed by more reports that terminal printout and input still did not behave like a normal shell.

This order was reckless, but it created a useful pressure gradient. The project already had a public install surface, so every local bug also threatened somebody else's first run; core terminal correctness could not hide behind an indefinite private-beta label. The sane lesson is not "publish broken packages." It is to shorten the distance between implementation, distributable artifact, clean-machine test, and observed behavior until pretending something works becomes difficult.

Dogfooding produced better requirements than a roadmap

Once GridBash could host real PTYs, I began using it to build GridBash, which meant the product spent most of its childhood supervising agents editing its own repository. This is dangerously circular and extremely effective.

The session history shows product requirements arriving from live friction:

• On July 6, shell profiles turned into agent profiles, auth selection, per-agent directories, and orchestration.
• On July 7, parallel work exposed the need for per-pane git worktrees, session resume, restartable panes, tabs, clearer activity state, and safer selected-pane input.
• On July 10, running many terminals exposed redraw and input latency; the same day, "does this work on Mac?" expanded into a shared cross-platform release design for Windows, Linux x64/arm64, and macOS arm64/x64.
• On July 15, 10 to 12 active terminals were slow enough to trigger another high-load profiling and scheduling pass; background jobs, persistent panes, command discovery, and workspace-level summaries followed.

This is better than inventing 50 features from a blank planning document because every request contains a reproduction condition. "Input feels slow with 20 panes" is testable; "make orchestration delightful" is a scented candle.

The risk is obvious too. A founder-user can create a product perfectly adapted to one founder-user, and agent-speed implementation can turn every annoyance into permanent interface surface. GridBash accumulated an enormous feature set quickly, so later work had to simplify onboarding, collapse controls into a command palette, reposition raw terminal grids as a secondary mode, and state exactly which features were stable.

The stray R explains the engineering process

My favorite early bug made new terminals type a capital R without being asked. This was not the application developing an opinion; it came from terminal query handling.

A program can ask a terminal for its cursor position by writing the control sequence ESC [ 6 n. The terminal replies with a cursor-position report ending in R, conceptually ESC [ row ; column R. GridBash scans child output for these queries because it is acting as the terminal emulator; the bug kept too much of a completed query in a trailing buffer used to detect sequences split across read boundaries, so the query could be seen again and its response replayed. Part of that interaction leaked a stray R into child input.

Figure 3. A complete cursor-position query remained in the scan tail, was processed again, and eventually donated its final letter to an innocent terminal. Subtext: The haunted terminal was just a buffer-boundary bug wearing a sheet. Source: Generated with GPT Image 2.

The fix retained only enough suffix bytes to recognize a query divided across reads; a fully consumed query no longer survived into the next scan. Regression tests covered a split query and the complete-query replay case.

Then the integration process produced a second bug: the valid fix lived on a task branch, while v0.1.5 was cut from main without it. GridBash had enough parallel agent work that "code exists" and "release contains code" were no longer equivalent, so the release tooling gained a guard that refreshed remote refs and blocked publication while unmerged task branches remained unless somebody explicitly reviewed the queue.

That sequence is the compressed engineering story in miniature:

1. Daily use exposed a weird behavior.
2. The behavior was reduced to a protocol and buffer invariant.
3. A test guarded that invariant.
4. Parallel development still stranded the fix.
5. The release process gained a system-level guard.

AI made code generation faster; it did not abolish integration, state, or causality, and the random R was kind enough to underline that point in red crayon.

The repository became a small software factory

By star #130, GridBash had 391 commits reachable from main, 90 merged pull requests, 145 opened non-PR issues, ten published releases, and 209 local Codex threads associated with the project directory. Eighty-six of those threads identify themselves as subagent sessions; the count also excludes the originating conversation because it began before the repository directory existed.

These are counts of artifacts, not units of human thought. One user request can create many subagents, branches, retries, reviews, and integration sessions; July 13 alone contains a dense cluster of release-related subthreads around one request for a current release and nightly builds. Treating every thread as a distinct feature would be like counting every compiler process as an employee.

The useful part was the shape of the workflow. Per-pane git worktree support gave each agent a repository-local checkout and predictable branch; issues described outcomes and checks; devlogs preserved what changed and why; PRs made integration boundaries visible; CI built multiple native targets; release automation tried to prove that Cargo, npm launchers, native packages, tags, and artifacts all referred to the same version.

The dangerous part was throughput without a governor. Ninety merged PRs in under 13 days is not automatically quality, and a 391-commit graph can conceal redundant work, merge churn, abandoned experiments, and generated maintenance activity. The project needed explicit branch queues, combined validation, release gates, contributor-ready issue curation, and eventually a stable-v1 acceptance checklist because raw agent capacity had moved the bottleneck from typing code to deciding which state was real.

What happened before the star curve bent

Here is the exact star history through the milestone, grouped by UTC day:

Figure 4. The cumulative curve is generated from the checked timestamped-stargazer snapshot; the line is ugly on purpose, while every point is exact. Subtext: Even the chart had to pass validation before being allowed to look this bad. Source: collect-public-history.mjs.

UTC day	New stars through milestone	Cumulative
July 8	12	12
July 9	7	19
July 10	7	26
July 11	9	35
July 12	5	40
July 13	13	53
July 14	17	70
July 15	31	101
July 16	18	119
July 17	7	126
July 18, through 11:03 UTC	4	130

The first five days were steady; the rate then increased from July 13 through July 16. Several public-facing changes landed immediately before or during that acceleration:

Change	When	What friction it removed
SEO and discoverability pass, startup update check, v0.1.6	July 8-9	Finding the repo and knowing whether the install was stale
Native Linux and macOS work	July 10	The product stopped being only useful to people on my exact Windows setup
Launch kit and technical article	July 10	The repo gained one repeatable explanation instead of improvised feature soup
Live star-history chart and nightly releases	July 12-13	Visitors could see activity; testers could access current builds
Product video, reduced README, v0.2 preview	July 13	A visitor could understand the workflow before reading every control
Rebuilt landing page and v0.2.0	July 13-14	The first viewport showed the product, install command, and repository action

The July 10 launch kit is especially revealing because it forced a concise position: GridBash is a local workspace for running and coordinating real CLI coding agents, with selected-pane input and optional worktree isolation. That sentence is much easier to share than "a terminal grid with auth, voice, resume, groups, manager goals, summaries, tabs, settings, and whatever I added at 2 a.m."

Cross-platform support probably mattered because it increased the number of developers who could plausibly try the product. The July 10 Linux work and macOS work created one target manifest and platform-neutral launcher across five native targets; v0.2.0 then packaged that work into a visible release. This is a plausible mechanism, not a proven attribution model.

The owner-visible traffic window strengthens the distribution story a little. From July 6 through July 19, GitHub reported 100 unique repository viewers; the top external referrers included X's t.co with 21 unique visitors, LinkedIn's website with 17, and its Android app with five. GitHub.com itself contributed 19 unique referred visitors. Those numbers support "social and GitHub discovery were present"; they do not reveal which exact visitor starred, cloned, installed, returned, or told a friend, and the same person can appear through more than one referrer.

What probably did not cause the spike

The formal growth planning came late. At 18:18 UTC on July 15, I opened a session asking how to get more users and contributors; at 20:41, another session began preparing for Product Hunt and Hacker News. Twenty-four of July 15's 31 stars had already arrived before 18:00 UTC, and star #100 landed at 22:14.

Therefore, the community growth playbook did not cause most of the largest star day, and merely preparing launch copy for Product Hunt or Show HN caused exactly zero stars on those platforms. The plan may improve future activation and contribution, but assigning it retroactive credit would be growth fan fiction.

The chart itself did not cause the early growth either. A live star-history SVG was added around July 12-13, after the project had already reached 40 stars; at most it became a small social-proof and transparency element for later visitors.

Nor can the 391 commits explain the curve by volume. Most visitors do not count commits before starring, and high commit volume can signal either energy or chaos. The public signals that people can evaluate quickly are much simpler: a name they remember, a one-sentence problem, a GIF or video proving it, a short README, a clean install command, current releases, supported platforms, and enough visible maintenance to suggest that reporting a bug will not launch a bottle into the ocean.

Stars are attention, not adoption

At the July 20 snapshot, GitHub traffic reported 3,336 clones from 418 unique cloners across the rolling window; the npm download API reported 350 downloads through the day of star #130. Those numbers look enormous next to 130 stars until you remember that CI, release workflows, mirrors, dependency tools, repeated local tests, and native-package verification all clone repositories and download packages.

The weirdness is visible in the daily data: npm reported 126 downloads on July 5, the day of publication, and another 141 on July 16; GitHub reported 135 unique cloners on July 7, before the first recorded star. This is activity, but it is not a clean count of humans who launched a two-pane grid and used selected input.

The contributor number is equally grounding. At collection time, GitHub's contributors endpoint listed me and github-actions[bot]; it showed zero other human commit contributors. GridBash had attracted attention, but it had not yet converted that attention into an outside code-contributor base. Stars can make a project look socially alive while its maintainer remains one person wearing a workflow as a hat.

The outreach document eventually defined a better funnel:

discovery -> repo comprehension -> successful install -> useful first workflow
          -> second session -> issue or conversation -> contribution

Every arrow can fail independently. A star lives near the first two arrows; it says somebody found the project worth bookmarking or endorsing, which is valuable, but it does not tell me whether the native package launched, the PTY accepted input, worktrees felt safe, or the person returned tomorrow.

The repeatable part

I would not repeat the exact chronology because "npm first, functional terminal later" is how you become a warning in somebody else's article. I would repeat the underlying loop:

1. Start from a problem you can reproduce daily

I did not need a survey to remember that six separate agent terminals were annoying; the product lived directly inside my workflow, so every session produced concrete friction, screenshots, latency conditions, and failure states. Founder taste still needs external correction, but daily use keeps early requirements attached to observable behavior.

2. Pick an architecture that owns the interaction you differentiate on

The Windows Terminal launcher was acceptable for opening panes, but GridBash's differentiation was selection, routing, metadata, orchestration, and isolation. Owning the PTYs and renderer made those features natural instead of a sequence of focus hacks against somebody else's pane tree.

3. Make the artifact installable while testing the exact install path

The native Rust binary plus npm launcher gave GridBash a familiar command, but publication alone was not validation. The better loop checks the packed tarball, installs the advertised version on a clean target, launches a real PTY, sends input, resizes it, quits it, and compares the npm version with the GitHub release before directing traffic there.

4. Convert every expensive failure into a guard

The stray R became a parser regression test; the stranded fix became a release branch-queue check; cross-platform version drift became exact-version package validation; npm incidents became publication gates. Fast development stays fast only when yesterday's failures stop charging rent tomorrow.

5. Launch explanations, not just code

The README reduction, one-line position, product walkthrough, landing page, release notes, and technical devlogs all explained the same object at different depths. That stack probably mattered more than any one launch event because each artifact shortened a different evaluation path.

6. Separate reach metrics from product metrics

Stars, impressions, page views, downloads, and clones are reach signals. Successful first workflows, returning users, useful conversations, claimed issues, and merged outside contributions measure something closer to product health. Both sets belong in the report; combining them into one giant "traction" number belongs in a pitch deck crime scene.

What this case study does not prove

This is an observational reconstruction of one small open-source launch; it is not a controlled experiment. Many changes overlapped, the repository evolved continuously, social referrers are aggregate, private platform impressions are not included, and GitHub's traffic window is short. I can establish order and coexistence; I cannot isolate the causal effect of the landing page, macOS package, one post, one star chart, or one particularly handsome yellow button.

The session count is also not a productivity benchmark. Codex thread metadata distinguishes user and subagent sources, but retries and spawned work inflate counts; 209 threads do not imply 209 features, 209 hours, or 209 good decisions. The public repository state is easier to audit than the reasoning that produced it.

Finally, star #130 is reconstructed from the current-stargazer list captured on July 20. The archived timestamp and CSV are stable artifacts; a future live API call can differ if early stargazers leave, and the verifier intentionally treats that as historical drift rather than overwriting the old claim.

Conclusion

GridBash began as a request to stop six Git Bash windows from colonizing Alt+Tab. Three and a half hours later, it had a public repository; before that repository even existed, an npm package had launched, and immediately afterward I was debugging why its supposed terminals were not terminal-ing. By the time the repo reached star #130, the codebase had crossed platforms, accumulated 391 commits and 90 merged PRs, published ten releases, survived a haunted capital R, and generated 209 project-associated Codex threads.

The stars did not arrive because the implementation was finished; it still is not. They arrived while the project became progressively easier to discover, understand, install, and believe. A clear agent-workspace story replaced "six terminals," native packages removed platform excuses, public videos and releases supplied proof, and constant dogfooding made the maintenance activity visible.

That is the part I want to keep: build something I genuinely need, expose the artifact early, turn embarrassing failures into durable checks, explain the workflow at several depths, and remain precise about what the numbers mean. GridBash got 130 stars in 13 days; the next job is converting that attention into successful second sessions, outside contributors, and a product that no longer types letters by itself.