[RFC] Building a Context Rot Guardian Agent Skill (a /compact equivalent) — hitting a wall reading live tokens

[cubaseuser123]

What problem are you trying to solve?

When agent sessions in Antigravity get too heavy, they hit the hard 200k IDE context limit (or Claude limits) and start losing context, auto-truncating, or going into initialization loops. There is no built-in /compact equivalent to gracefully shed token weight while preserving architectural state. I am trying to build an automated background watcher that reads live token metrics to warn the user before this rot sets in, but I cannot find a clean way to read the live "Customization token usage" or prompt size from the IDE without hacking the internal gRPC stream.

Proposed idea

I am building an Antigravity Agent Skill called the "Context Rot Guardian".

1. A manual SKILL.md that can be triggered (e.g., "checkpoint"). It takes all architectural decisions, constraints, and open tasks, and turns them into a highly compressed Knowledge Item (KI) artifact in .gemini/knowledge.
2. A new chat can automatically read this KI to resume seamlessly with an empty context window.
3. The core of this RFC: A background monitor.py script packaged with the skill. Because I can't find a live token endpoint, this script acts as a "Shadow Tracker". It parses static files (mcp_config.json, active skills) for a baseline, watches the brain/<uuid>/ folder to count agent turns, and uses a generic math rule (total log characters / 3.5) or a local Gemma tokenizer to estimate the token payload entirely offline. When it hits 65%, it pops a Windows notification.

My question for the community: Before I build this shadow-tracking logic, is there a hidden debug endpoint, CLI flag, or globalStorage key that just writes the live token count to a local file? Is there a cleaner hook inside Antigravity where an agent can read its own metrics?

Real use cases

• The breaking point: Deep, multi-file engineering tasks (like long refactors, complex scaffolding, or intense debugging sessions) that accumulate massive amounts of tool output and history until the session just dies or loops at the 200k ceiling.
• What success looks like: Getting a simple, native OS toast notification warning us that context is hitting 65%.
• The payout: This lets us trigger a snapshot, open a fresh chat window, load the state right back in, and keep working seamlessly without a catastrophic crash wiping out our architectural memory.

Related skills, tools, or prior art

• Similar skill: Standard /compact slash commands found in other LLM CLI tools (like Claude Code).
• Related discussion: The ongoing community discussions around the 200k IDE context limit and the 7,500 token summarization threshold.

Are you willing to help build this?

Yes, but I need guidance

Before posting

• I searched existing discussions and issues for similar ideas.