Most AI coding setups are either smart but slow or fast but shallow.

A lot of them can generate good ideas, but once they need to browse the web, inspect a product, review a UI, or step through a workflow, things start to drag. Every action spins up more overhead. Context gets bloated. Sessions reset. The agent loses state. What should feel like a smooth working session starts to feel like repeated cold starts.

That is why gstack stands out.

At first glance, it looks like a polished collection of Claude Code skills. But under the hood, it is more than a prompt library. It combines two important layers:

1. 1.

   A large set of opinionated workflow skills
2. 2.

   A custom local browser runtime designed for speed and continuity

That combination is the key to why it performs so well in practice.

What gstack Actually Is

The GitHub repo for gstack is structured around a reusable skills system plus a browser subsystem. On the skills side, it includes workflow-oriented commands such as review, QA, release, planning, and product-oriented operational flows. On the runtime side, it ships a custom browse tool backed by a persistent browser daemon rather than relying on repeated one-shot automation calls.

This matters because many “AI workflows” are really just collections of instructions layered on top of generic tools. gstack goes further: it optimizes both the thinking layer and the execution layer.

How gstack Is Set Up

The installation flow is straightforward but deliberate.

You clone the repository into a skills directory and run its setup script. For Claude Code, that typically installs into ~/.claude/skills/gstack. For Codex-style setups, it can target .agents/skills/gstack or ~/.codex/skills/gstack. There is also an auto-detection mode that figures out which host environment is present and installs accordingly.

This tells you something important about the project philosophy: gstack is designed to sit directly inside the agent’s working environment, not as a separate web app or external orchestration service.

Once installed, it exposes a range of slash-style workflows. Examples include product and engineering review flows, QA flows, planning flows, and shipping flows. These are not random commands. They are packaged operating modes.

Instead of making the model improvise from scratch every time, gstack gives it structured workflows with a clear role and purpose.

The Browser Layer Is the Real Performance Engine

The biggest reason gstack feels fast is its browser architecture.

Most agent browser integrations pay a major penalty on every step. They launch a browser process, connect to it, perform an action, serialize results, and shut things down or lose useful state between calls. That creates friction at exactly the point where the agent should feel interactive.

gstack takes a different approach.

It launches a long-lived Chromium daemon once, then sends later actions to that already-running browser over localhost. In practice, that means the first call may take a few seconds, but the next calls can happen in a fraction of that time.

This architecture changes the user experience dramatically. Once the daemon is warm, the system starts to feel less like “run automation again” and more like “continue working in the same live environment.”

That is a huge advantage for agentic tasks like:

• multi-step QA sessions
• product walkthroughs
• iterative bug reproduction
• browsing and comparing several pages
• performing repeated reads and clicks during the same workflow

Persistent State Removes Hidden Friction

Speed is only one part of the equation. Continuity is the other.

Because gstack keeps the browser process alive, it also preserves useful session state across steps. Cookies, tabs, login sessions, local storage, and page context remain available between commands.

That solves one of the most annoying problems in browser-based agent workflows: the system does not have to constantly re-establish context.

In many other setups, the model spends too much effort re-logging in, reopening pages, or rediscovering where it was. Even if each individual action is technically correct, the full workflow feels clumsy because nothing persists.

gstack’s persistent-browser design avoids that. The agent can keep working inside the same environment, which makes multi-step tasks faster, more reliable, and more natural.

The CLI Is Optimized for Low Overhead

Another reason gstack performs well is that it keeps tool communication lean.

Its browser interaction is wrapped in a compiled CLI that communicates through simple local requests and plain text output. That may sound like a small implementation detail, but it has real consequences for LLM performance.

In many agent systems, tool calls add a surprising amount of overhead. There is protocol wrapping, schema expansion, extra metadata, and more verbose exchanges between the model and the tool layer. Over a long session, that can waste both time and context budget.

gstack’s design aims to reduce that cost. By keeping the interface lightweight, it lets more of the model’s attention and token budget go toward the actual task instead of the machinery around the task.

This is especially valuable in workflows where the model needs to inspect, decide, act, inspect again, and repeat. Those loops can become expensive very quickly if every step produces bloated tool chatter.

Stable Refs Make Browser Actions More Reliable

One of the cleverer parts of gstack is its ref system.

Instead of forcing the model to depend on fragile selectors, it converts the accessibility tree into stable, human-readable references. These refs act as handles the model can use for future actions.

That improves performance in two ways.

First, it reduces action failures. The agent is less likely to click the wrong thing or fail because a selector changed.

Second, it reduces hesitation and recovery overhead. If the model can refer to a stable element handle instead of regenerating brittle selectors, it spends less effort guessing and less time waiting on failed interactions.

This is one of those implementation decisions that does not sound flashy, but it contributes heavily to the “it just works” feeling.

Bun Helps Operationally, Not Just Technically

gstack also makes a pragmatic runtime choice by using Bun.

The benefit is not only speed in the narrow benchmark sense. The bigger win is packaging and deployment simplicity. Bun supports TypeScript directly, includes useful runtime capabilities, and can compile the browser tool into a single binary.

That reduces installation complexity and dependency sprawl.

In real projects, this matters a lot. A system that is theoretically fast but operationally painful often loses out to a system that is slightly less elegant on paper but easier to run consistently. gstack appears to optimize for both.

Workflow Design Matters as Much as Runtime Design

It would be a mistake to explain gstack’s performance only in terms of browser speed.

The workflow layer matters just as much.

gstack gives the model strong, opinionated workflows for specific jobs. That means the agent is not dropped into a blank canvas every time. It gets a clearer frame for how to approach review, QA, planning, release, and related tasks.

This improves quality in a quieter but equally important way:

• the model has less ambiguity
• the workflow has more repeatability
• the outputs are more consistent
• the system wastes less effort deciding how to work before it starts working

A lot of AI tools underperform not because the model is weak, but because the operating context is too vague. gstack reduces that vagueness.

Why gstack Feels Better Than Many Other Agent Setups

The real strength of gstack is that it compounds advantages across three layers:

1. Low-latency execution

A persistent browser daemon removes repeated startup cost.

2. Low-friction interaction

A lean CLI plus stable refs reduces tool overhead and action brittleness.

3. High-quality orchestration

Opinionated skills guide the model into stronger workflows.

Most AI setups are strong in only one or two of these areas.

• A prompt library may be thoughtful, but still slow.
• A browser tool may be fast, but feel raw and inconsistent.
• A workflow system may be structured, but weak at execution.

gstack appears effective because it tries to solve all three at once.

That is likely the best explanation for why people experience it as unusually productive.

The Tradeoff: It Is Intentionally Opinionated

Of course, this design has a tradeoff.

gstack is not trying to be infinitely flexible. It is built around a particular philosophy: specific skills, a specific browser runtime design, and a local-first execution style. That makes it more opinionated than a generic agent toolkit.

But that limitation is also part of the strength.

Systems often get faster and more reliable when they stop trying to support every possible path equally well. gstack seems to embrace that idea. It narrows the operating surface so the common paths can be excellent.

Final Takeaway

gstack performs well because it is designed as a full working system, not just a collection of prompts.

Its skill layer improves how the model thinks. Its browser layer improves how the model acts. Its runtime choices improve how quickly and consistently the whole loop executes.

That combination is rare.

If you look at gstack through that lens, its performance becomes easier to explain. It is not magic. It is the result of aligning workflow design, runtime design, and tool design around one goal: making the agent feel fast, persistent, and useful in real work.

Sources

• gstack repository: https://github.com/garrytan/gstack
• gstack browser documentation: https://raw.githubusercontent.com/garrytan/gstack/main/BROWSER.md
• gstack architecture notes: https://raw.githubusercontent.com/garrytan/gstack/main/ARCHITECTURE.md
• gstack package/build configuration: https://raw.githubusercontent.com/garrytan/gstack/main/package.json