Your Agent Deserves Its Own Infrastructure. Not Someone Else's API.

June 2026 · Joe Wee, Founder · 6 min read

Google just pulled the API from under 6,000 open-source contributors. Gemini CLI goes dark for free users on June 18. The code stays on GitHub. The power gets cut. If you're building agent workflows on vendor infrastructure, this is your wake-up call.

The Pattern

A developer named Andrea Alberti merged 27 commits into Gemini CLI over months of evening work. On the same day his last PR landed, Google announced Antigravity CLI - a closed-source successor. Free users, Pro subscribers, and individual Code Assist users lose API access on June 18, 2026. Enterprise customers keep it.

Alberti asked the question every open-source contributor should be asking: "Were we essentially working for free on a code base that will only be used in enterprises?"

The Apache 2.0 license stays intact. The code stays on GitHub. But code without the API behind it is a finished house with the power cut.

This Isn't About Licenses. It's About Control.

Redis flipped to SSPL. HashiCorp went BSL. Elastic added three license options. Those were messy license fights with forks and lawsuits.

Google did something cleaner. They didn't change the license. They turned off the API. The code you contributed still exists. It just doesn't do anything anymore.

If a single company controls the API that your tool talks to, the open-source license on the tool is a partial protection at best.

This is the new mechanism. No license flip needed. Just an API deprecation notice and a migration path to the paid product.

But My Agent Already Uses GitHub

Yes, it does. And GitHub is excellent at what it does.

Claude Code runs git commit, git push, gh pr create. Cursor manages branches. Aider handles rebases. Your agent is already a GitHub power user.

But git tracks code changes. It doesn't track project state.

git log tells you what changed. Not what's broken. git diff shows code differences. Not sprint progress. A pull request doesn't know it's linked to a P0 bug that was filed yesterday by another agent working on a different repo. GitHub Issues exist, but they're built for humans who click buttons - not agents who make HTTP calls with severity levels, diagnosis fields, and resolution workflows.

Your agent needs both: GitHub for code (it already has this), AND a persistent project management layer for everything else - bugs with severity and lifecycle, features with kanban status, sprints with computed progress, cross-project contracts.

Git handles code. Nothing handles the project. That's the gap.

And here's the uncomfortable truth: your GitHub repo lives on Microsoft's servers. They can change pricing, restrict API access, or deprecate features. The same pattern Google just demonstrated with Gemini CLI. Your code is on their platform, governed by their terms.

What This Means for Agent Tooling

Right now, thousands of developers are building agent workflows around vendor tools: Gemini CLI, Copilot, Cursor (built on OpenAI's API), Claude Code (built on Anthropic's API). Every one of these tools has the same structural vulnerability Alberti discovered - the code runs on your machine, but the intelligence lives on someone else's server.

Your agent's project management shouldn't have the same dependency.

The Agent Needs a Brain That Doesn't Get Repossessed

Here's what actually happens when a solopreneur uses Claude Code or Cursor today:

The agent writes code. It fixes bugs. It plans features. At the end of the session, the agent forgets everything. Next session, blank slate. The developer becomes the project manager - tracking what's done, what's broken, what's next. In their head.

The agent's context window is temporary. GitHub tracks code changes, not project state. There's no persistent system that says: "Here are your 12 open P0 bugs, Sprint 3 is 73% done, and the auth feature has a regression that was filed yesterday."

That persistent project brain is what your agent needs. And it shouldn't be something a vendor can turn off.

Three Questions Before You Build on Vendor Agent Infrastructure

The Lesson from Gemini CLI

Andrea Alberti's 27 commits are still on GitHub. The code works. The API doesn't answer. His evenings are signed off in commits that sit there like a house with the power cut.

The agent era is here. But the infrastructure layer - where your agent tracks bugs, plans features, manages sprints, and remembers what happened yesterday - that layer has to be something you control. Not something a vendor can deprecate in a blog post.

GitHub holds your code. Your agent needs somewhere to hold everything else - bugs, features, sprints, progress. Somewhere that survives session resets, vendor changes, and API deprecation notices.

We built Buggazi because we hit this wall ourselves. 22 projects. Coding agents across every one. And no persistent project management layer that the agents could read and write to. So we built one. API-first. Agent-native. Your data, your API key, your project state.

The agents handle the grunt work. You make the calls that matter. And nobody can turn off the API because you sent them a PR.

The Gemini CLI story referenced in this post is based on Andrea Alberti's GitHub discussion and the Google Developers Blog announcement.