DEV Community: Rehan Mazhar

How I replaced Gemini in Antigravity 2.0 with any OpenAI-compatible model

Rehan Mazhar — Sun, 31 May 2026 12:41:03 +0000

Antigravity 2.0 is Google’s agentic coding IDE. It gives AI agents filesystem access, MCP tools, subagent orchestration, and browser automation. It’s powerful — but locked to Gemini.
I wanted to use other models. So I built a proxy.
The problem
Antigravity sends massive inline context with every request: 30+ skill descriptions, full plugin lists, user rules, agent frameworks — around 4000 tokens of boilerplate. External models can’t parse this effectively. And Antigravity Desktop requires specific response metadata (safetyRatings, index: 0, groundingMetadata) that OpenAI-format APIs don’t provide.
The solution
A TypeScript TLS proxy (~400 lines) that sits between Antigravity and your model provider:
Antigravity → Proxy (443) → OpenAI API → NVIDIA / OpenRouter
Key features
Context stripping: Removes the ~4000 tokens of inline skills/plugins/rules and injects a compact reference to agent-context.md (a ~150-line runtime definition file)
Bidirectional translation: Converts Google-format messages, tools, and streaming to OpenAI-format and back
Desktop metadata: Adds safetyRatings, groundingMetadata, and index: 0 to every response — without these, Antigravity Desktop silently crashes
429 retry: Exponential backoff (1s → 2s → 4s → 8s) for rate limits
Arg sanitization: Strips Antigravity’s internal metadata fields (toolAction, toolSummary) from tool call arguments
What works
Everything except audio and background project sync. Chat, code gen, file operations (view_file, write_to_file, list_dir, grep_search, run_command), browser automation (Chrome DevTools MCP — open browser, screenshot, console check, JS evaluation), image generation, subagent orchestration, streaming, thinking/reasoning.
The test
I asked the agent to build a landing page for Antigravity 2.0. It:
Read agent-context.md to understand the runtime
Created index.html, styles.css, and script.js with a particle system, terminal animation, and interactive UI
Opened the page in Chrome via the browser MCP tool
Took a full-page screenshot
Checked browser console for errors
Evaluated JavaScript to verify animations and counters were running
Reported results with visual feedback
All through step-3.7-flash on NVIDIA NIM. Not a single Google API call.
Setup
git clone https://github.com/12errh/antigravity-proxy
cd antigravity-proxy
.\setup.ps1
Pick NVIDIA or OpenRouter, paste your API key. The script handles admin elevation, dependencies, TLS certificates, and proxy startup.
To change models, edit proxy/models.json:
{
"claude-sonnet-4-6-thinking": "deepseek-ai/deepseek-v4-flash",
"default": "deepseek-ai/deepseek-v4-flash"
}
Supported providers
Provider
Models
NVIDIA NIM
deepseek-ai/deepseek-v4-flash, stepfun-ai/step-3.7-flash
OpenRouter
Any OpenAI-compatible model
Limitations
Audio: Not mapped yet
Background project sync: Language Server init calls to Google need a Gemini key (sidebar file tree, etc.)
Everything else works transparently.
Try it
https://github.com/12errh/antigravity-proxy
MIT license. Contributions welcome.

[Boost]

Rehan Mazhar — Thu, 21 May 2026 02:46:30 +0000

Tired of the Frontend/Backend split? Meet Zolt: Full-Stack Apps in Pure Python. - DEV Community

Introduction: As developers, we spend half our time managing the "gap" between our Python backends...

dev.to

Why I’m building a Python-only UI framework (and how v1.5 will change the game)

Rehan Mazhar — Sun, 26 Apr 2026 20:54:20 +0000

The Problem:
Building UIs in Python is fragmented. We use one library for web dashboards, another for outdated desktop apps, and a third for terminal TUIs. We’re blocked by the "Frontend Barrier"—the need to learn an entirely separate skill tree just to make our ideas look good.

The Solution: Zolt v1.0
I built Zolt to provide a single, elegant API. It uses an AST-walking compiler to build an Intermediate Representation (IR) tree, which then dispatches to specific renderers for the web, native windows, or the CLI.

The Future: The "Awwwards-Quality" Roadmap (v1.5)
V1.0 proved the concept. V1.5 is about aesthetics. I want Python devs to build sites that are indistinguishable from those made by top-tier design agencies.

We are adding:

A Native Animation API: Use component.animate(slide_up()) to generate professional GSAP micro-interactions.

Built-in 3D: Declare Scene3D or Spline models directly in your Python class.

Figma Integration: A CLI tool that maps Figma auto-layout and typography directly to Zolt components, saving 80% of development time.

The Zolt UI Library: 80+ prebuilt, production-ready components—from pricing tables to full auth flows—that are dark-mode compatible and accessible out of the box.

Join the Build:
V1.0 is ready for your MVPs. V1.5 is bringing the soul. I’d love your feedback on our technical roadmap.

[https://github.com/12errh/Zolt]

Tired of the Frontend/Backend split? Meet Zolt: Full-Stack Apps in Pure Python.

Rehan Mazhar — Sun, 26 Apr 2026 20:47:07 +0000

Introduction:
As developers, we spend half our time managing the "gap" between our Python backends and our JS frontends. I wanted to close that gap. Today, I’m excited to share Zolt v1.

What is Zolt?
Zolt is a unified framework that allows you to build beautiful UIs and strong backends using nothing but Python. No more API boilerplate or context-switching.

The Current State (v1):
v1 is the "Foundation Release." It’s built for developers who need to ship functional, robust apps right now. It handles the logic, the routing, and the layout seamlessly.

The Roadmap (v1.5):
I’m already working on v1.5. While v1 is the solid base, v1.5 is where the magic happens. We are focusing on:

Cinematic Animations: High-end motion design triggered by Python state.

Production Polish: Optimizing for "award-winning" site performance.

True Dark Aesthetics: Built-in support for premium, high-contrast themes.

Try it out:
[https://github.com/12errh/Zolt]
Check out the repo, star it, and let me know what you think. Let's make Python the king of the full stack.

[Link to GitHub]

R1: A Runtime That Runs Tauri Apps in the Browser

Rehan Mazhar — Sun, 15 Mar 2026 22:31:22 +0000

Live demo: https://r1-todo-demo.netlify.app/
Source code: https://github.com/12errh/r1-tauriweb-runtime-v1

The Problem

Tauri is a fantastic framework for building desktop apps with a Rust backend and a web frontend. But sharing a Tauri app with someone still means sending them an installer, asking them to trust an executable, and waiting for them to download 50–100MB. For a lot of use cases — demos, quick tools, apps for non-technical users — that friction kills adoption.

What if you could just send someone a URL?

What R1 Does

R1 is a browser-native runtime for Tauri. You take your existing Tauri project, add one line to your vite.config.ts, run npm run build, and the output is a static folder. Deploy it to Vercel, Netlify, or GitHub Pages. Anyone with a browser can now run your app instantly.

No server. No backend. No installer. Just a URL.

How It Works

The browser is a sandbox — you can't run a native Rust binary inside it. R1 solves this with a layered architecture:

1. Rust → WASM
The R1 Vite plugin automatically compiles your src-tauri/ directory to WebAssembly using wasm-pack during npm run build. The .wasm binary is bundled as a static asset.

2. Kernel Worker
All WASM execution happens in a dedicated Web Worker — never the main thread. If your Rust code blocks for 2 seconds processing a file, the UI stays perfectly responsive.

3. WASI Shim
When Rust is compiled to wasm32-wasi, every std::fs call becomes a WASI syscall. R1 intercepts those syscalls and redirects them to the browser's Origin Private File System (OPFS). Your Rust code calls std::fs::write("/data/todos.json", ...) exactly as it would on a desktop — it just happens to write to OPFS instead of a real disk. Files persist across page refreshes.

4. IPC Bridge
Real Tauri injects window.__TAURI_INTERNALS__ into your app's WebView. R1 patches the same global at boot time. Your frontend calls invoke('add_todo', { text: 'Buy milk' }) exactly as it always did. R1 routes that call through the Kernel Worker to your WASM backend.

5. Event Bridge
Rust can emit events back to JS using r1::emit("progress", payload). These arrive at your listen() handlers in the frontend — the same API you use in a real Tauri app.

6. Service Worker
Asset URLs (convertFileSrc('/app/logo.png')) are intercepted by a Service Worker that reads the file from OPFS and serves it with the correct MIME type.

Current Status

✅ invoke() — Tauri v1 and v2 compatible
✅ std::fs read/write from Rust (via WASI → OPFS)
✅ Rust → JS event bridge
✅ Serde JSON bridge for complex data
✅ WASM panic isolation
✅ Tauri API plugins: fs, event, store, os, path, dialog, clipboard
✅ Virtual Window Manager (macOS, Windows 11, Linux themes)
✅ 31/31 unit tests passing
✅ Live todo demo running on Netlify

Limitations (Being Honest)

The WASI shim covers the most common syscalls but not all of them
shell execute is stubbed — you can't spawn real child processes in a browser
Heavy native dependencies that can't compile to WASM won't work
Best suited for simple to medium complexity Tauri apps right now

Try It

The live demo is a real Tauri todo app — written as a standard desktop Tauri project, then compiled through R1. Add a todo, close the tab, reopen it. The data persists.

If you have a simple Tauri app, I'd love for you to try running it through R1 and see what breaks. That feedback is exactly what drives the next version.

The full architecture roadmap that guided the build is in the repository if you want to understand the design decisions.