DEV Community: Nirbhay Hiwse

I Built Markups: A Free, Open-Source Markdown Editor That Doesn't Need an Account

Nirbhay Hiwse — Sun, 13 Sep 2026 06:47:12 +0000

Markdown is one of those formats developers end up using almost everywhere.

README files. Documentation. Architecture notes. API docs. Project specifications. AI-generated content. Blog drafts. Changelogs. Notes written during debugging sessions.

The format itself is simple.

The workflow around it isn't always.

Sometimes you just want to open a Markdown editor, write something, see the rendered result, and export it.

Instead, many tools push you toward an account, a cloud workspace, or a larger platform before you can even start writing.

That was the problem I was trying to solve when I built Markups.

Open it. Write Markdown. See the result. Keep control of your document.

Live: markups.dev

Source: github.com/Nir-Bhay/markups

What is Markups?

Markups is an open-source, browser-based Markdown editor designed to make Markdown work feel simple again.

You can open markups.dev and start writing without downloading a desktop application or creating an account. The editor provides a split Markdown and live-preview workflow, along with features that become useful when a document stops being "just text" — diagrams, equations, code blocks, navigation, linting, templates, and export options.

The current project combines a developer-oriented editor experience with a local-first approach to document handling.

                 ┌──────────────────────┐
                 │      Markdown        │
                 │   file / document    │
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │       Markups         │
                 │  Edit + Preview      │
                 └───────┬─────┬────────┘
                         │     │
              ┌──────────┘     └──────────┐
              ▼                           ▼
       ┌─────────────┐             ┌─────────────┐
       │   Preview   │             │   Tools     │
       │   Render    │             │ Mermaid     │
       └──────┬──────┘             │ KaTeX       │
              │                    │ Code blocks │
              │                    └──────┬──────┘
              ▼                           │
       ┌──────────────────────────────────┘
       │
       ▼
 ┌────────┬────────┬─────────┐
 │  .md   │  HTML  │   PDF   │
 └────────┴────────┴─────────┘

The goal isn't to replace every development tool you already use.

It's to make the Markdown layer between those tools easier to work with.

Why I built it

The more Markdown I worked with, the more obvious the friction became.

A .md file is portable by design. You can open it in an editor, commit it to Git, send it to someone, put it in a repository, or publish it somewhere else.

So I kept asking myself:

Why should editing that file require a full cloud workflow?

I wanted a tool where the first step is simply:

Open the editor
      ↓
Start writing
      ↓
Preview the document
      ↓
Export / save

No onboarding flow.

No mandatory workspace setup.

No need to turn a simple Markdown file into a hosted account just to edit it.

That became one of the design principles behind Markups.

The simplest feature: you can just start writing

One of the most important decisions in Markups is also one of the easiest to explain:

You don't need to create an account just to edit Markdown.

Open markups.dev, and the editor is there.

That changes the interaction from:

Open editor
   ↓
Create account
   ↓
Verify / sign in
   ↓
Create workspace
   ↓
Create document
   ↓
Start writing

into:

Open markups.dev
      ↓
Start writing

For a lot of small documentation tasks, that's exactly what I want from a tool.

A developer-oriented editor, not just a textarea

Under the hood, Markups uses Microsoft's Monaco Editor, the same editor technology used by VS Code. That gives the editing surface a much more familiar developer feel than a basic browser text box.

The editor supports things like:

light and dark themes
multiple editor themes
minimap support
line wrapping controls
font customization
bracket matching
a developer-oriented editing experience

If you already spend your day in an IDE, the editor doesn't feel completely foreign when you move over to Markdown.

Live preview changes the workflow

Writing Markdown and reading rendered Markdown are two different activities.

You need both.

Markups provides a live preview so you can edit the source and immediately see how the document is going to look.

┌─────────────────────────┬─────────────────────────┐
│     Markdown Source     │     Rendered Preview    │
│                         │                         │
│ # API Documentation     │ API Documentation      │
│                         │ =================      │
│ ## Authentication       │ Authentication         │
│                         │                         │
│ - Bearer token          │ • Bearer token         │
│ - Expiration            │ • Expiration           │
│                         │                         │
└─────────────────────────┴─────────────────────────┘

The current editor supports split view as well as a single-pane workflow, synchronized scrolling, and a document mode for a more rendered-document-oriented editing experience.

Markdown support for real documentation

A Markdown editor becomes much more useful when it can handle the things developers actually put into their documents.

Markups supports common GitHub-flavored Markdown patterns such as:

headings
links
lists
tables
task lists
footnotes
alert-style blocks
code blocks

It also extends the document with:

KaTeX for math

$$
E = mc^2
$$

Mermaid for diagrams

flowchart TD
    A[Developer] --> B[Markdown]
    B --> C[Markups]
    C --> D[Live Preview]
    C --> E[Export]
    D --> F[Review]

Syntax-highlighted code blocks

async function getUsers() {
  const response = await fetch("/api/users");
  return response.json();
}

This matters because modern technical documents are rarely just paragraphs.

They contain code, architecture diagrams, tables, equations, checklists, examples, and structured notes.

Mermaid is especially useful for technical documentation

One thing I like about Markdown-based diagrams is that the diagram can live with the documentation.

For example:

flowchart LR
    Client --> API
    API --> Auth
    Auth --> Service
    Service --> Database

Instead of maintaining a paragraph explaining the architecture and then keeping a completely separate image somewhere else, the diagram can be part of the document's source.

Change the architecture?

Change the Markdown.

That is a very natural workflow for developers.

Math support when Markdown needs to be more technical

There are documents where plain Markdown isn't enough.

Research notes, educational content, engineering documentation, data explanations, and technical articles can all need equations.

With KaTeX support, you can write mathematical expressions directly in the document:

$$
\frac{d}{dx}x^n = nx^{n-1}
$$

The point isn't to turn Markups into a mathematics product.

It's simply to avoid having technical content break when the document needs one more layer of structure.

Export without rebuilding the document somewhere else

Another practical part of the workflow is export.

From the same document, Markups can produce:

                  ┌─────────────┐
                  │   Markups   │
                  └──────┬──────┘
                         │
           ┌─────────────┼─────────────┐
           ▼             ▼             ▼
        Markdown        HTML          PDF
           │             │             │
           ▼             ▼             ▼
        .md file     Web-ready     Shareable
                      document      document

The current project supports downloading Markdown, exporting to HTML, and exporting to PDF. Existing Markdown files can also be imported so you can continue working on a document you already have.

That makes the workflow useful when Markdown is the source of truth, but the final output needs to be something else.

Features I find useful once a document gets bigger

Markups isn't limited to editing and previewing.

The current project also includes features aimed at longer or more repetitive documents:

Feature	Why it is useful
Multi-tab documents	Work on more than one document without constantly replacing the current file
Templates	Start common document types faster
Text snippets	Reuse Markdown boilerplate
Focus mode	Remove distractions while writing
Typewriter mode	Keep the active writing position visually centered
Word / character count	Useful for articles and documentation with size constraints
Reading time	Quick estimate for longer documents
Table of contents	Navigate large documents quickly
Markdown linter	Catch formatting and style issues while writing

These are small things individually.

Together, they make Markdown feel more like a real writing environment instead of a box where you paste syntax.

Where Markups fits into a developer workflow

This is where I think the project gets more interesting.

You don't have to use Markups for everything.

It works well as a layer around workflows you already have.

1. README files

You can draft or clean up a README in Markups, review the rendered result, then save the Markdown file back into your repository.

Repository
   │
   └── README.md
          │
          ▼
       Markups
          │
     ┌────┴────┐
     ▼         ▼
  Edit      Preview
     │         │
     └────┬────┘
          ▼
      Save .md
          │
          ▼
       Git commit

2. Technical documentation

API docs, installation guides, contributor docs, deployment notes, internal specifications, and architecture documents are all natural Markdown use cases.

3. Architecture notes

Mermaid makes it easy to keep architecture diagrams close to the documentation itself.

4. AI-generated Markdown

This is becoming a particularly interesting workflow.

AI coding assistants can generate:

README drafts
implementation plans
technical documentation
changelogs
issue descriptions
architecture notes
project specifications

But generated Markdown often still needs human review.

Markups can be used as that review layer:

AI assistant
     ↓
Generated Markdown
     ↓
   Markups
     ↓
Review + edit + preview
     ↓
Final Markdown
     ↓
Git / Docs / Publish

The idea is simple: let AI produce a first draft, then use a human-friendly editor to make it actually yours.

5. Blog and technical article writing

Markdown is also a natural format for writing developer articles.

With live preview, a table of contents, word count, reading-time information, and export options, Markups can work as a focused writing environment before content is published elsewhere.

6. Working with unreliable internet

Because the application is built as a Progressive Web App and uses browser caching, the project is designed to continue working after the initial application load. The repository includes a PWA manifest and service worker for this behavior.

That means a weak connection does not have to be the thing that stops you from writing.

The local-first idea

A big part of Markups is not a flashy feature.

It is the architecture choice behind the workflow.

The project is designed around browser-based, local-first document handling rather than making a hosted account the center of the product.

A simplified view looks like this:

flowchart TD
    U[Developer] --> B[Browser]
    B --> E[Markups Editor]

    E --> R[Markdown Renderer]
    E --> S[(Browser Storage)]
    E --> P[Live Preview]

    R --> P

    E --> M[Mermaid]
    E --> K[KaTeX]
    E --> H[Syntax Highlighting]

    E --> X[Export]
    X --> MD[.md]
    X --> HTML[HTML]
    X --> PDF[PDF]

The important part is the direction of the workflow:

you start with the document, not with an account.

Privacy and document control

I wanted Markups to be useful for documents that people may not want to put into a hosted workspace simply to edit them.

The current project is built around client-side document handling and does not require an account for the core editing workflow. The project also uses browser storage for local persistence and export/save operations happen from the browser.

That gives the workflow a different feel from cloud-first editors:

Your document
     │
     ▼
   Browser
     │
     ▼
   Markups
     │
     ├── Edit
     ├── Preview
     ├── Persist locally
     └── Export

There is no mandatory hosted workspace sitting between you and the first edit.

For developers, that can be useful when working on unfinished ideas, private documentation, internal notes, or project material that simply doesn't need to live in another service.

The goal is not "your files are magically private because the app says so." The goal is to keep the architecture simple enough that the user remains close to the document.

Offline-first: what that actually means here

Markups is implemented as a Progressive Web App.

The project includes a web app manifest and service worker so the application can cache the resources required to run after the initial load.

In practical terms, the intended workflow is:

First visit
    ↓
Application loads
    ↓
Browser caches app resources
    ↓
You can install/bookmark it
    ↓
Connection disappears
    ↓
The app can continue working from its cached resources

This is particularly useful for the kind of editor that does not need a server round-trip just to render Markdown.

One important distinction: offline application availability is not the same thing as cloud synchronization.

Markups is not trying to become a cloud document collaboration platform. The project is deliberately much more focused than that.

Markups compared to a cloud-first workflow

There are plenty of excellent Markdown editors already.

Tools such as StackEdit and HackMD are useful for different workflows, especially when cloud synchronization and collaboration are part of the requirement.

Markups takes a different position.

Workflow need	Markups approach
Start editing immediately	No mandatory account for the core editor workflow
Markdown source	First-class editing surface
Live rendered output	Yes
Mermaid diagrams	Built in
Math	KaTeX support
Code blocks	Syntax highlighting
Local/browser workflow	Core design direction
Offline-oriented use	PWA + browser caching
Export	Markdown, HTML, PDF
Open source	Yes
Cloud collaboration	Not the primary goal

The comparison isn't about declaring one product universally better than another.

It is about choosing the right workflow.

If you need a collaborative cloud workspace, use a tool designed for that.

If you want a focused Markdown editor that you can open and start using, Markups is built around that experience.

A small example: from idea to technical document

Imagine you're building an API and want to document it.

You might start with:

# User API

## GET /users

Returns a list of users.

## Authentication

Use a bearer token.

http
Authorization: Bearer


## Architecture

mermaid
flowchart LR
Client --> API
API --> Auth
Auth --> UsersService
UsersService --> Database

plaintext

Then you can immediately see:

whether your headings make sense
whether code blocks render correctly
whether your diagram communicates the architecture
whether the document is readable as a finished page

And when you're done, you can keep the .md source or export the document to HTML/PDF.

That's the workflow I care about most.

Not "write Markdown because Markdown is cool."

Write Markdown because it is useful — and make the editor around it useful too.

How to get started

You don't need a complicated setup.

1. Open Markups

Go to:

👉 https://markups.dev/

2. Start writing

Open the editor and begin with Markdown on the source side.

3. Preview as you go

Use the live preview to check the rendered document while you write.

4. Import an existing file

Already have a .md file? Import it and continue from there.

5. Add richer content

Try:

Mermaid
KaTeX
code blocks
tables
task lists
footnotes

6. Export when you're finished

Save the Markdown source or export the document as HTML/PDF.

Useful shortcuts

Shortcut	Action
`Ctrl + S`	Save Markdown
`Ctrl + P`	Export / print to PDF
`Ctrl + O`	Import Markdown

Why open source?

Another important part of Markups is that it is open source and released under the MIT license.

That matters to me because a developer tool should be inspectable.

You can read the code.

You can understand how the application works.

You can contribute.

You can fork it.

You can adapt it for your own workflow.

Repository:

👉 https://github.com/Nir-Bhay/markups

What Markups is — and what it isn't

Markups is a focused Markdown workspace.

It is not trying to replace:

VS Code
GitHub
a full documentation platform
a real-time collaborative workspace
your Git workflow

Instead, it sits in a much smaller space:

Write
  ↓
Preview
  ↓
Improve
  ↓
Export / Save

That simplicity is intentional.

What I'm exploring next

There are still plenty of areas where a Markdown editor can get better.

Some ideas I'm exploring include:

stronger offline workflows
better document organization
more developer-oriented templates
richer Markdown diagnostics
improved import/export workflows
better project/document management
additional publishing workflows

These are ideas, not promises about the current release.

One of the nice things about keeping the project open source is that the roadmap doesn't have to come entirely from one person.

Final thoughts

The interesting part of Markups isn't really Markdown syntax.

Markdown already works.

The interesting part is the workflow around it.

Does writing a README need an account?

Does editing a .md file need a cloud workspace?

Does documentation always need to live inside another platform?

I don't think it has to.

Sometimes a tool should simply:

Open
 ↓
Write
 ↓
Preview
 ↓
Export
 ↓
Done.

That's the idea behind Markups.

A free, open-source Markdown editor that you can open in your browser and start using without a mandatory account.

If that matches the way you work, give it a try.

🔗 Links

Live App: https://markups.dev/

GitHub: https://github.com/Nir-Bhay/markups

And because the project is open source, feedback, issues, and contributions are always welcome.

Built for people who just want to work with Markdown.

Learn how Antigravity Usage Intelligence lets you monitor token consumption, cache savings, and quotas in Google’s Antigravity IDE.

Nirbhay Hiwse — Sat, 12 Sep 2026 07:08:24 +0000

Figure: Example Antigravity Usage Intelligence dashboard in VS Code, showing token usage charts and quotas.

For developers building with Google Antigravity (an AI coding IDE), tracking how many tokens, API calls, and reasoning steps each workflow uses is crucial. The open-source Antigravity Usage Intelligence VS Code extension exposes hidden usage details: per-session token breakdown (input vs cache vs output vs internal reasoning), live quota status, and a GitHub-style activity heatmap. This article explains how Antigravity usage is measured today, how you can monitor it, and how the extension makes it visible.

How Antigravity Usage Works

Google’s Antigravity is an agentic development platform (using Gemini/Claude models) that runs multi-turn AI tasks. Unlike a simple chat, an Antigravity session can generate millions of tokens per task. In fact, in active projects “pairing with frontier models pushes tens of millions of tokens daily”. Antigravity uses cached context, internal “thinking” tokens (especially with Claude/Gemini), and external tools, so one session’s workload can vary greatly.

Antigravity’s subscription plans impose token quotas: Pro and Ultra users get the highest quotas refreshed every 5 hours (with generous weekly limits), while non-Pro accounts receive a smaller quota refreshed weekly. However, the built-in UI mainly shows whether a request succeeded, not a breakdown of usage. Developers face issues like:

Hidden Context Burn: No visibility into whether an agent re-used 200K cached tokens vs rebuilding a fresh 200K token prompt.
Buried Reasoning Overhead: Modern models consume extra internal reasoning tokens (e.g. Claude’s “thinking”), which aren’t shown.
Unverified Quotas: Fixed limit alerts (e.g. “5-hour limit”) can be misleading if you want real-time remaining quota.
Zero Session Forensics: No quick way to audit individual sessions (duration, tokens, tools used).

Antigravity Usage Intelligence solves this by running 100% locally and reading Antigravity’s session data. It connects to the local language server to fetch your account’s actual quota and then provides a real-time “command center” inside your IDE with the missing usage details.

Token Types and Data Sources

The extension breaks down tokens into categories. The table below describes each:

Token Type	What it Includes	Example Source
Fresh Input	Non-cached prompt text (new input)	Your initial prompt or file contents
Cache Hits	Tokens served from Antigravity’s cache	Re-used conversation history or context
Output	Model-generated response tokens	AI’s answer text or code diff
Reasoning	Internal “thinking” tokens (Claude/Gemini)	Hidden multi-step reasoning tokens

Example (7-day run):

Total tokens: 2,800,000,000
Cached tokens: 2,530,000,000 (∼90% from context cache)
Output tokens: 220,000,000
Reasoning tokens: 8,490,000
Tool calls: 19,576

In this example, the vast majority of tokens came from the prompt cache (2.53B), highlighting how much work Antigravity saved by reusing context. These details only appear when you analyze the raw session data.

Live Quota Monitoring

The extension also keeps track of your subscription quota. It uses Antigravity’s local language server RPC to query your plan details and usage. The dashboard shows, for each model family (e.g. Gemini Flash, Claude Sonnet): your tier (e.g. Google AI Pro), remaining quota percentage, used prompt/flow credits, and a live countdown to the next refresh. For example, you might see:

Gemini 3.8 Flash — Used: 73% (Reset in 02:15:42)
Claude Sonnet 4.6 — Used: 88% (Reset in 02:15:42)

By default, Pro/Ultra plans reset every 5 hours. If the language server is offline, the extension falls back to a rolling 5-hour window estimate. You can configure warning thresholds (e.g. 75%, 90%, 100%) to get alerted before you hit a hard limit.

Daily Activity Heatmap

Figure: Example weekly activity heatmap (each cell = one day; darker green means more tokens used).

The extension includes a GitHub-style heatmap showing your activity over days and weeks. Darker tiles mean higher token throughput. There is also a 24-hour chart that highlights your peak coding hours. For example, you might discover that most of your token usage happens on weekday mornings, with evenings much lighter. These visual cues help you spot patterns (heavy coding days, all-nighters, etc.) at a glance.

Session Inspector and Tool Tracking

For detailed auditing, the Session Inspector pane lists individual sessions. For each session it shows: the unique session ID, project path, duration, turn count, and a token distribution bar (fresh vs cache vs output vs reasoning). It also lists what tools were used (e.g. run_command, view_file, grep_search, etc.) with counts. You can copy the session ID or export a markdown report. This makes it easy to investigate unusual cases: e.g. you might find one session used a large number of tokens because it ran a long grep_search on a huge codebase.

Installation

Via VS Code Marketplace: Open Extensions (Ctrl+Shift+X), search for Antigravity Usage Intelligence, and click Install. Or install via CLI:

   code --install-extension nirbhay-hiwse.antigravity-usage-intelligence

Open VSX (e.g. VSCodium/Cursor): Run

   ovsx get nirbhay-hiwse.antigravity-usage-intelligence

Manual VSIX: Download the .vsix from the GitHub Releases and run:

   code --install-extension antigravity-usage-intelligence-1.0.7.vsix

The extension relies on Python (no extra libraries). It auto-detects your Python installation. If needed, set antigravity-stats.pythonPath in settings to your python executable. After installation, it watches Antigravity’s local data and will automatically parse new sessions.

To use it, open the Command Palette (Ctrl+Shift+P or Cmd+Shift+P) and run Antigravity Stats: Open Full Screen Dashboard. This opens the interactive analytics view. You can also enable a daily token count in the status bar via the antigravity-stats.showStatusBar setting, and refresh data manually with Antigravity Stats: Refresh Stats.

Security: The extension uses read-only access (?mode=ro) to Antigravity’s local SQLite databases and connects only to 127.0.0.1 (no internet). No external telemetry is sent.

Localization & Geofactors

All timestamps and charts use your system’s local timezone. For example, if your computer is set to GMT+5:30, the heatmap’s “days” align with that day boundary, and countdown timers show local time. Currently, Google’s Antigravity quotas are the same globally, so region-specific settings aren’t needed. (Enterprise/managed accounts may have custom quotas, which the extension will display as reported by the local server.)

Conclusion

Antigravity Usage Intelligence brings transparency to AI coding workflows. By breaking down token usage (fresh vs cache vs reasoning), showing daily trends, and syncing with your official quota, it turns Antigravity from a black box into an observable system. This helps you optimize performance (e.g. maximizing cache usage) and avoid surprises from hidden limits. Install it and let your usage data guide your AI development.

Learn more and get the extension on GitHub. Happy coding!

Antigravity Usage Intelligence: Track Tokens, Quotas, Cache, Reasoning, and Agent Activity

Nirbhay Hiwse — Sat, 12 Sep 2026 06:53:15 +0000

Antigravity Usage Intelligence: Track Tokens, Quotas, Cache, Reasoning, and Agent Activity

I’ve been using Antigravity heavily for development, and one thing kept bothering me:

I could see the agent doing a lot of work, but it was hard to understand how much was actually being used.

How many tokens were going through my sessions?

How much of that was fresh input versus cached context?

How much reasoning was happening?

Which projects were using the most?

How often was I hitting the quota?

And what did my usage actually look like over time?

That led me to build Antigravity Usage Intelligence, an open-source usage tracker and analytics dashboard designed around those questions.

GitHub: https://github.com/Nir-Bhay/antigravity-usage-intelligence

What Antigravity usage actually looks like

Antigravity has become much more agent-oriented. With Antigravity 2.0, Google introduced a standalone desktop experience alongside features such as subagents, scheduled tasks, agent management, CLI support, and other tools for longer and more autonomous workflows.

That changes the way we think about usage.

A simple prompt counter is not enough anymore.

An agent can perform multiple turns, call tools, read files, generate output, use reasoning, and reuse cached context during a single task.

The official Antigravity documentation also explains that quota limits are tied to the amount of work performed by the agent, which can vary significantly from one task to another.

That makes visibility much more useful than simply knowing whether a request succeeded.

So what does this project track?

The dashboard breaks usage into several parts instead of showing one mysterious number.

Token breakdown

The dashboard separates:

Fresh input tokens
Cached prompt tokens
Output tokens
Reasoning or thinking tokens

That distinction matters.

For example, two agent sessions can both look like large workloads, while their actual token behavior is very different because one relies heavily on cached context.

The goal is not to turn token usage into a billing calculator.

The goal is to make the behavior of your AI development workflow visible.

Live quota monitoring

One of the most useful parts is quota visibility.

The extension can query Antigravity’s local language server and surface information such as:

Subscription tier
Remaining quota
Usage percentage
Reset timing
Prompt and flow credits where available

When live server data is unavailable, the project can fall back to local rolling-window calculations.

That distinction is important because local estimates and server-reported quota are not the same thing.

I would treat the server-side value as the authoritative quota signal and the local calculations as a useful approximation for understanding recent activity.

A GitHub-style activity heatmap

Numbers become much easier to understand when you can see them over time.

The activity heatmap gives a quick visual view of when you were actually using Antigravity.

Instead of opening individual sessions, you can quickly spot:

Heavy coding days
Quiet periods
Long runs of activity
Changes in usage patterns

It is basically a contribution graph for your agent activity.

That sounds small, but it changes the experience.

After a few weeks, you start seeing how your development habits actually look.

Daily token trends

The dashboard also shows usage over time.

This helps answer questions like:

Am I gradually using more AI every week?

Which days have the highest token consumption?

Did one project cause a sudden spike?

Am I relying more on reasoning-heavy models?

Those are much more useful questions than simply asking how many messages you sent.

Model-level visibility

Antigravity can work with multiple models, and the project identifies model activity so you can see which models are actually being used during your workflows.

For example, the current Antigravity model lineup includes Gemini and Claude reasoning models, with availability depending on the user's plan.

That makes model-level analytics particularly useful when you're comparing different workflows or trying to understand where your usage is going.

Reasoning tokens deserve their own metric

One thing I wanted to make visible was reasoning usage.

With thinking-oriented models, a task may involve significantly more internal reasoning than what you see in the final response.

Treating all tokens as one number hides that difference.

Separating reasoning tokens gives you another lens into how your agent is working.

It is not necessarily about using fewer tokens.

Sometimes more reasoning is exactly what you want.

The point is to understand the tradeoff.

Session-level inspection

When a task goes wrong, aggregated statistics are not enough.

The session inspector lets you drill down into individual sessions and look at things such as:

Session ID
Workspace/project
Duration
Turn count
Token distribution
Tool executions
Errors

Tool calls are also categorized, so you can see the type of work the agent actually performed.

That makes it easier to investigate long-running or unexpectedly expensive sessions.

Tool usage is a useful signal too

Agent development is not just about model responses.

A large amount of useful work happens through tools.

Reading files, searching code, running commands, replacing content, writing files, and other actions all contribute to the overall shape of a session.

Tracking tool requests gives another way to understand whether an agent was mostly answering questions or actually doing work inside a codebase.

Privacy was a design requirement

This was important from the beginning.

The project is designed to operate locally.

It reads local Antigravity data and communicates with the local language server through loopback rather than sending your usage history to a remote analytics service.

The repository also documents read-only database access and local caching so that active sessions are not unnecessarily disturbed.

There are no external telemetry calls in the project.

That means you can inspect your usage without handing your development history to another analytics backend.

Why build this when Antigravity already shows usage?

This is probably the most obvious question.

Antigravity already provides quota information, especially through its current settings and model interfaces.

The difference is depth.

A quota indicator tells you where you stand.

An analytics dashboard can help explain why you are there.

Those are different problems.

If you are doing serious agent-based development, historical context becomes useful:

Which project consumed the most?

Which days were the heaviest?

How much context was cached?

How many tool calls did the agent make?

Which sessions were unusually large?

How does my usage change over time?

That is the gap this project is trying to fill.

What I learned from tracking my own usage

The biggest lesson is that token usage is not a single number.

A large token count can come from very different workflows.

A session may have:

Large cached context
Relatively small fresh input
High reasoning overhead
Many tool calls
Large generated output

Looking only at the total hides the interesting part.

Once the data is separated, you can start thinking about how you work with agents, not just how much you use them.

Who is this useful for?

I think it is most useful for developers who:

Use Antigravity regularly
Work on large or multi-file projects
Use agentic workflows heavily
Want to understand quota behavior
Experiment with multiple models
Prefer local and privacy-conscious tooling
Want historical usage data rather than only current quota

It is probably unnecessary if you only use Antigravity occasionally and never care about usage patterns.

Installation

You can install the extension from the VS Code-compatible marketplace or use the repository directly.


bash
git clone https://github.com/Nir-Bhay/antigravity-usage-intelligence.git
cd antigravity-usage-intelligence
npm install

Managing Multiple GitHub Accounts with GitHub Codespaces Without Constant CLI Context Switching

Nirbhay Hiwse — Sat, 05 Sep 2026 16:28:17 +0000

Using one GitHub account is easy.

Using two is manageable.

Using three or four while working across different repositories, organizations, and Codespaces is where the workflow starts getting messy.

I know because I use GitHub for more than one context.

There is a personal side.

There are project-specific environments.

There can be organization or client access.

And once GitHub Codespaces enters the picture, authentication isn't the only thing you have to think about.

You also have to think about:

Account
Repository
Codespace
SSH host
CLI context
Remote workspace

This post explains the problem, what GitHub supports today, and the architecture I used in Antigravity Codespaces Pro to make multiple-account Codespaces management less painful.

First: multiple GitHub accounts are supported

Let's get one misconception out of the way.

GitHub CLI does support multiple accounts.

GitHub's official documentation explains that you can authenticate multiple accounts on the same GitHub platform and switch between them using:

gh auth switch

GitHub also explains that the CLI can sometimes determine the intended account from repository context, while some commands need explicit context.

So the problem is not:

GitHub doesn't support multiple accounts.

It does.

The problem is:

How do you manage several accounts without turning your development environment into a collection of context switches?

That's a different problem.

The normal workflow

Imagine you have:

Account A → personal projects
Account B → company work
Account C → client repositories

And Codespaces under each.

The normal CLI-oriented workflow might look like:

gh auth switch --user account-b
gh codespace list
gh codespace ssh

Then later:

gh auth switch --user account-a
gh codespace list
gh codespace ssh

Again, this works.

But now think about an editor that is already open with an active remote workspace.

The real question becomes:

Which account is active?
Which Codespace belongs to it?
Which SSH configuration belongs to that environment?
Can I switch without disturbing something else?

That is where small pieces of friction start accumulating.

Why this becomes more annoying with SSH

GitHub CLI can generate OpenSSH configuration for Codespaces using:

gh codespace ssh --config

GitHub explicitly documents this as an integration point for standard OpenSSH-based tools.

That means each remote workspace can effectively become an SSH host.

Conceptually:

GitHub Account A
   ↓
Codespace A
   ↓
SSH host A

GitHub Account B
   ↓
Codespace B
   ↓
SSH host B

Now multiply that by several environments.

Your ~/.ssh/config can become one more thing you have to keep synchronized.

That was one of the reasons I wanted to automate the configuration rather than asking developers to maintain it manually.

The approach inside Antigravity Codespaces Pro

The extension treats an account as a separate authentication context.

The project supports multiple GitHub accounts simultaneously, with account-specific credentials stored through the editor's secure storage facilities rather than plain-text configuration. The implementation then performs API operations in isolated contexts rather than repeatedly changing one global CLI state.

Conceptually:

                Codespaces Manager
                        │
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
      Account A     Account B     Account C
          │             │             │
       Token A       Token B       Token C
          │             │             │
       Spaces A      Spaces B      Spaces C

Each account can be queried independently.

That means the dashboard can show:

Personal
Work
Client

at the same time.

Instead of repeatedly asking:

Which account should my CLI be using right now?

the UI asks:

Which environment do you want to open?

That's a much better abstraction for a graphical development tool.

Why credential isolation matters

Multi-account development isn't just a convenience problem.

It is also a security problem.

You don't want the credentials for one environment accidentally becoming the credentials for another.

That's why I didn't want a design where the extension writes personal access tokens into ordinary configuration files.

The project uses the editor's SecretStorage API for credentials and keeps account contexts isolated.

The mental model is simple:

Never:
token → plain text config

Prefer:
token → OS / editor secure credential storage

This doesn't magically solve every authentication problem, but it gives you a much safer foundation.

SSH configuration should also be predictable

One of the more frustrating things with remote development is a broken SSH configuration.

A good automation layer should avoid:

append random config
append same block again
break existing config
lose backup

The extension instead uses generated SSH blocks and atomic file handling, with backup behavior described in the project documentation.

The goal is that running synchronization repeatedly should not slowly destroy the configuration file.

Why a dashboard makes more sense than a terminal here

The terminal is excellent for commands.

For example:

gh codespace list
gh codespace stop
gh codespace rebuild
gh codespace ssh

GitHub officially supports these Codespaces operations through the CLI.

But once you have:

5 Codespaces
3 GitHub accounts
different repositories
different branches
multiple machine sizes

a command-by-command workflow starts making less sense visually.

So the extension provides a Cloud Hub dashboard.

The current dashboard includes things like:

account filters
workspace cards
running/stopped states
repository and branch information
start/stop controls
rebuild actions
SSH actions
port access
search
quick connect

These are all directly reflected in the current project implementation and metadata.

The cost side of multiple Codespaces

There is another reason to make the workspace state visible.

Cloud compute has a cost model.

GitHub explains that only running Codespaces incur CPU charges, while stopped Codespaces still incur storage charges.

It also explains that compute usage is measured in core-hours, so larger machines consume those hours faster.

That means a dashboard showing:

8 workspaces
0 running
8 stopped

isn't just pretty UI.

It provides immediate operational information.

You can see what is active and what is not.

That helps reduce the chance of leaving an expensive environment running simply because you forgot about it.

Multiple accounts + AI coding agents

This is the other scenario that pushed me toward the architecture.

Modern coding workflows don't always look like:

type
compile
type
compile

AI coding agents may spend several minutes:

reading files
searching code
planning changes
running commands
building
testing

During periods with little interactive terminal input, connection reliability becomes more important.

The extension exposes SSH keepalive configuration such as:

{
  "antigravity-codespaces.serverAliveInterval": 30,
  "antigravity-codespaces.serverAliveCountMax": 10
}

The project uses these settings to send keepalive traffic over the SSH connection and reduce idle-connection failures during longer agent workflows.

I want to be precise here:

keepalive does not guarantee that every network failure disappears.

It is a connection-resilience measure.

That distinction matters.

A practical example

Imagine this setup:

Personal GitHub
└── portfolio
    └── Codespace

Work GitHub
└── company-api
    └── Codespace

Client GitHub
└── ecommerce-platform
    └── Codespace

Without a management layer, you may find yourself doing:

switch account
list spaces
find space
start space
generate SSH config
connect

Then repeat everything for another account.

With a workspace-oriented UI, the target becomes:

Accounts
├── Personal
├── Work
└── Client

Codespaces
├── portfolio
├── company-api
└── ecommerce-platform

Select the environment.

Connect.

That is the abstraction I wanted.

The architecture

The project is intentionally built around a few separate responsibilities:

┌──────────────────────────────────────┐
│              IDE UI                  │
│ Cloud Hub / Quick Connect / Accounts │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│          Authentication Layer         │
│       OAuth / PAT / GitHub CLI        │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│           GitHub API Layer            │
│     Account-isolated API requests     │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│             SSH Manager               │
│      Generated + synchronized config  │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│         GitHub Codespaces             │
│       Remote container / VM           │
└──────────────────────────────────────┘

The goal is separation.

Authentication should not become UI state.

UI state should not become SSH configuration.

SSH configuration should not become account switching.

Each layer has its own job.

What I would recommend for developers with multiple accounts

If you only have one GitHub account and one Codespace, the standard GitHub workflow is probably enough.

I wouldn't install another tool just because it exists.

The management layer becomes interesting when your environment looks more like:

multiple accounts
+
multiple Codespaces
+
Remote-SSH
+
Cursor / Windsurf / VSCodium
+
AI agents

At that point, automation starts saving cognitive overhead rather than just keystrokes.

Why I built this

The original problem wasn't:

I need another GitHub tool.

It was:

I don't want my development environment to depend on remembering which account, command, SSH host, and browser tab I need to use next.

That distinction shaped the entire product.

So Antigravity Codespaces Pro is essentially a workspace manager for GitHub Codespaces that happens to live inside the IDE.

The current project supports Cursor, Antigravity IDE, VS Code / Code-OSS, Windsurf, and VSCodium, alongside multi-account management and SSH automation.

Final thoughts

GitHub has already built most of the underlying infrastructure:

Codespaces
GitHub CLI
SSH
Port Forwarding
Authentication
Remote Development

The interesting engineering problem is what happens between those primitives and the developer's workflow.

That's the layer I decided to work on.

And I'm still iterating on it.

Open source repository:

Nir-Bhay/antigravity-codespaces

How to Use GitHub Codespaces in Cursor, Windsurf, VSCodium, and Other VS Code Forks

Nirbhay Hiwse — Sat, 05 Sep 2026 16:24:19 +0000

GitHub Codespaces is a great way to move your development environment into the cloud.

The container, dependencies, source code, and compute all live remotely, while your local machine becomes the client you use to work on the project.

For standard Microsoft VS Code, GitHub provides a dedicated Codespaces experience.

But things get more complicated when your editor is Cursor, Windsurf, VSCodium, Code-OSS, or another VS Code-based editor.

That is where I kept running into the same problem.

The cloud environment was already working.

GitHub Codespaces was working.

The repository was working.

SSH was working.

The part that was missing was the glue between GitHub Codespaces and the editor.

So I ended up building that glue.

This article explains the underlying workflow first, and then shows how I use Antigravity Codespaces Pro to simplify it.

The actual problem

Let's say your development setup looks like this:

GitHub Repository
       ↓
GitHub Codespaces
       ↓
Remote Linux container
       ↓
SSH connection
       ↓
Cursor / Windsurf / VSCodium

The important part is that Codespaces itself isn't the difficult piece.

GitHub already provides CLI commands for listing, creating, stopping, rebuilding, SSHing into, and forwarding ports from Codespaces. GitHub's CLI also supports generating OpenSSH configuration for Codespaces.

The problem starts when you want a non-Microsoft VS Code-based editor to behave like a first-class Codespaces client.

Then the workflow can become:

Open GitHub.
Find the Codespace.
Make sure it is running.
Install/authenticate GitHub CLI.
Configure SSH.
Find the correct Codespace host.
Open Remote SSH.
Select the host.
Wait for the remote server.
Start working.

It works.

But it is a lot of ceremony for something that should feel like:

Open editor → select cloud workspace → code.

How GitHub Codespaces actually works here

The first thing to understand is that a Codespace is a remote development environment.

GitHub's own CLI exposes commands such as:

gh codespace list

to list Codespaces, and:

gh codespace ssh -c <codespace-name>

to open an SSH session.

You can also generate OpenSSH configuration with:

gh codespace ssh --config

which is useful for tools that integrate with OpenSSH. GitHub CLI documents this specifically as a way to make Codespaces behave more like normal SSH hosts for tools such as ssh, scp, rsync, and sshfs.

That is the key idea.

You don't need the browser to be your only interface.

You can use the standard SSH layer as the bridge between the editor and the cloud environment.

Step 1: Install GitHub CLI

Install GitHub CLI for your operating system and authenticate:

gh auth login

GitHub documents GitHub CLI as the command-line interface for working with GitHub and Codespaces.

Then verify your Codespaces are visible:

gh codespace list

You should see your available environments.

Step 2: Connect to a Codespace through SSH

For a direct terminal connection:

gh codespace ssh -c <codespace-name>

GitHub notes that the Codespace must have an SSH server available. The default dev container includes an SSH server; custom images may need the SSHD feature added to devcontainer.json.

For example:

{
  "features": {
    "ghcr.io/devcontainers/features/sshd:1": {
      "version": "latest"
    }
  }
}

The exact container setup depends on how your Codespace is built.

Step 3: Generate SSH configuration

This is where the workflow becomes useful for editors such as Cursor and other Remote-SSH-compatible tools.

GitHub CLI supports:

gh codespace ssh --config

You can use its generated OpenSSH configuration with your local SSH config. GitHub provides this capability specifically so Codespaces can integrate with standard OpenSSH tooling.

Conceptually, you end up with:

Local editor
     ↓
Remote SSH
     ↓
OpenSSH configuration
     ↓
GitHub CLI
     ↓
Codespaces
     ↓
Remote container

That means the editor doesn't need to understand every Codespaces-specific detail itself.

It can communicate through the normal remote-development stack.

Why Cursor users often end up doing this manually

This isn't just theoretical.

Developers have been sharing Cursor + Codespaces SSH workarounds involving GitHub CLI, gh codespace ssh, generated SSH configuration, and Remote-SSH. Cursor community discussions also contain requests around Codespaces support and reports of connection problems.

The result is usually a manual chain of configuration.

For one Codespace, that may be fine.

For five or ten Codespaces, it starts becoming repetitive.

For multiple GitHub accounts, it becomes even more interesting.

The multiple-account problem

GitHub CLI supports multiple accounts, including multiple accounts on GitHub.com, and provides gh auth switch for changing between them.

That works, but there is an important workflow problem.

Suppose you have:

Personal GitHub
Work GitHub
Client GitHub
Open Source GitHub

and Codespaces running under several of those accounts.

Now your workflow isn't simply:

Start Codespace → Connect

It becomes:

Which account?
Which Codespace?
Is the correct CLI account active?
Which SSH host?
Which repository?

The technical system works.

The human workflow becomes the bottleneck.

That distinction matters.

The approach I took

Instead of making developers repeatedly jump between browser sessions, CLI profiles, and SSH configuration, I wanted the editor to expose Codespaces as workspace objects.

So I built Antigravity Codespaces Pro around that idea.

The current project supports:

Cursor
Antigravity IDE
VS Code / Code-OSS
Windsurf
VSCodium

and provides a dashboard for managing Codespaces rather than treating every environment as a manual SSH setup.

The extension currently supports:

Quick Connect
Multi-account management
Start / Stop
Rebuild
SSH configuration
Port discovery
Workspace dashboard
Remote environment monitoring
AI-agent keepalive settings

The current extension metadata is version 5.0.8 and includes keywords around GitHub Codespaces, Cursor, remote development, SSH, cloud IDEs, AI agents, and developer tools.

Quick Connect

One of the simplest ideas in the extension is a quick launcher.

The default shortcut is:

Alt + C

The goal is to make a Codespace feel closer to a local project.

Instead of searching through browser tabs:

Alt + C
↓
Search workspace
↓
Enter
↓
Connect

The launcher is designed to search across the connected Codespaces and prioritize active environments.

Why start/stop controls matter

There is also a resource-management problem with cloud development.

A Codespace that remains running continues consuming compute resources.

GitHub's documentation states that running Codespaces incur CPU charges, while stopped Codespaces continue to incur storage costs.

GitHub also measures Codespaces compute in core-hours, where the machine's core count affects how many core-hours are consumed.

So:

Start → work → stop

isn't just a UI preference.

It can be a useful cost-management habit.

That's why the dashboard exposes lifecycle controls instead of making you return to the GitHub website every time.

Port forwarding is another hidden source of friction

A cloud development environment is not very useful if your application is running remotely and you have no easy way to access it locally.

GitHub CLI supports port forwarding with:

gh codespace ports forward 8000:8000 -c <codespace-name>

and provides commands for inspecting and changing port visibility.

For a web developer, this matters a lot.

Your application might be running at:

inside the Codespace.

A good remote-development workflow should make those ports discoverable without another round of manual commands.

That is one of the reasons the extension includes forwarded-port discovery.

What this setup is actually useful for

This workflow is especially useful when:

your laptop is not powerful enough for your full development environment
you switch between machines
your repositories require heavy dependencies
you work with AI coding agents
you maintain separate GitHub accounts
you use Cursor or another VS Code fork
you want reproducible Linux environments
you want your development environment to stay close to the repository

You don't need all of these use cases.

Even one of them can justify a cloud development environment.

A simple mental model

Think of the system as five layers:

┌──────────────────────────────┐
│          Your IDE            │
│ Cursor / VS Code / Windsurf  │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│       Remote Development     │
│      SSH / Remote-SSH        │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│         GitHub CLI           │
│    Codespaces + Auth         │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│      GitHub Codespaces       │
│      Remote Linux VM         │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│     Repository / Container   │
│   Code + Dependencies + App  │
└──────────────────────────────┘

Once you understand this architecture, the setup stops feeling mysterious.

Where Antigravity Codespaces Pro fits

I didn't build it to replace GitHub Codespaces.

GitHub Codespaces is still the cloud environment.

I built the extension to make the client-side management workflow less repetitive.

That's an important distinction.

The project is open source and MIT licensed.

Repository:

Nir-Bhay/antigravity-codespaces

Final takeaway

GitHub Codespaces is already a very capable remote-development system.

The friction appears when you want to use it outside the most straightforward Microsoft VS Code workflow.

The underlying technologies are already there:

GitHub Codespaces
+
GitHub CLI
+
OpenSSH
+
Remote-SSH

The missing piece is often the developer experience around them.

That was the problem I wanted to solve.

Not another cloud IDE.

Just a better way to get from:

I have a Codespace

to:

I'm coding in it.

What does your current GitHub Codespaces workflow look like?

Do you use the browser, VS Code, Cursor, SSH, GitHub CLI, or something else?

Why GitHub Codespaces Fails in Open-Source IDEs (and How I Fixed It)

Nirbhay Hiwse — Thu, 03 Sep 2026 07:07:42 +0000

Microsoft's GitHub Codespaces is easily one of the best cloud developer environments available today. You click a button, a container boots in the cloud, and within 30 seconds you have a fully configured Linux environment with all your dependencies pre-installed.

But the moment you step outside standard Microsoft VS Code — into Google Antigravity IDE, Code-OSS, Gitpod, or VSCodium — the whole experience falls apart.

I ran into three specific technical walls that forced me to build my own solution: Antigravity Codespaces Pro. Here is the breakdown of why it broke, and how I engineered around each limitation.

Problem 1: The Proprietary Extension Lock-in

The official GitHub Codespaces extension relies on closed-source VS Code APIs and telemetry hooks that only exist in Microsoft-branded binaries. If you inspect the Open VSX registry or try running the official VSIX inside Code-OSS or Antigravity IDE, it fails to initialize the connection authority. You get a blank sidebar and silent errors in the output channel.

The Fix:

You don't actually need Microsoft's proprietary extension host to talk to a Codespace. The GitHub CLI (gh) already has a built-in proxy mechanism:

gh cs ssh -c <codespace-name> --stdio

By generating dynamic SSH config blocks pointing to this ProxyCommand, any remote SSH client — including Open-Remote-SSH and Antigravity IDE — can attach to the remote container over standard port 443 without needing closed-source binaries.

Host cs.<codespace-name>
    HostName cs.<codespace-name>
    User codespace
    ProxyCommand gh cs ssh -c <codespace-name> --stdio
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Problem 2: The Multi-Account CLI Bottleneck

Most developers juggle more than one GitHub account: a personal profile, a work handle, or client organization access.

Normally, the gh CLI operates with a single active token. Running:

gh auth switch --user account-b

switches your entire machine's context globally. If you have an active Codespace running under account-a, running CLI commands or background sync scripts under account-b immediately causes OAuth authentication collisions and dropped sessions.

The Fix:

Instead of switching global accounts, the extension queries the secure OS credential store, extracts cached OAuth Bearer tokens for all authenticated accounts, and passes them independently via environment variables:

// Token-isolated execution — no global CLI state hopping
const env = { ...process.env, GH_TOKEN: accountToken };
execFile('gh', ['api', '/user/codespaces'], { env }, callback);

Every account is polled in parallel. Your local git config and global CLI state remain completely untouched.

Problem 3: Silent WebSocket Drops During Long AI Agent Runs

In editors like Google Antigravity IDE or Cursor, autonomous AI agents can run for 10–20 minutes analyzing files or running background benchmarks.

During these phases, the SSH client often sends zero interactive terminal input. Standard OS TCP timeouts or home Wi-Fi NAT routers see this as an idle connection and silently terminate the socket (wsarecv: An established connection was aborted). The editor UI hangs, but the remote container has no idea you disconnected.

The Fix:

The extension automatically injects strict keepalive parameters into every generated ~/.ssh/config host block:

Host cs.*
    ServerAliveInterval 30
    ServerAliveCountMax 10
    TCPKeepAlive yes

This forces the SSH tunnel to send a low-level probe every 30 seconds. If an adapter blinks or the internet switches, it retries cleanly instead of hard-dropping the session.

The UI: Bento Grid Cloud Hub

Rather than stuffing everything into a tiny sidebar tree, I built a full-window Bento Grid dashboard:

Live resource monitoring: vCPU counts, RAM allocations, and cloud region for each instance.
Direct lifecycle controls: Turn ON cold containers, Stop idle ones to save GitHub billable core-hours, or trigger full clean DevContainer rebuilds.
Alt + C Quick Connect: A fuzzy-search launcher accessible anywhere in the editor without touching the mouse.
Port Forwarding Discovery: Scans forwarded container ports with 1-click browser links.

Getting Started

The extension is fully open-source under the MIT license and available across both major registries:

VS Code Marketplace: nirbhay-hiwse.antigravity-codespaces
Open VSX Registry (Antigravity IDE & Code-OSS): nirbhay-hiwse.antigravity-codespaces
Source Code & Issues: GitHub Repository

If you use non-Microsoft editors or juggle multiple cloud accounts, give it a spin. Feedback and PRs are always welcome!

How to Use GitHub Codespaces in Google Antigravity IDE (and Manage Multiple Accounts)

Nirbhay Hiwse — Thu, 03 Sep 2026 07:01:50 +0000

If you use Google Antigravity IDE, Code-OSS, or any open-source editor, GitHub Codespaces has no native extension support.

To solve this, I built and open-sourced Antigravity Codespaces Pro.

Features

Native Codespaces in Antigravity IDE: Connect to your cloud VMs with 1-click.
Multi-Account Engine: Manage multiple GitHub accounts in parallel without CLI profile switching.
Bento Cloud Hub Dashboard: Full-page visual dashboard with live container status and hardware specs.
Alt + C Quick Connect: Fuzzy-search and attach in 2 seconds.
AI Agent KeepAlive: Prevents WebSocket drops during long AI sessions.

Install Now

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=nirbhay-hiwse.antigravity-codespaces
Open VSX Registry: https://open-vsx.org/extension/nirbhay-hiwse/antigravity-codespaces
GitHub Repo: https://github.com/Nir-Bhay/antigravity-codespaces