Models getting "dumber" after a while but ı give them a solution

Google Antigravity
1

Every developer working with Cursor, Copilot, Antigravity IDE, Claude Code, or ChatGPT has noticed this phenomenon:

The larger your repository gets, the “dumber” your AI model behaves.

It forgets instructions, hallucinates imports, loses track of architectural boundaries, and burns $5 to $20 in API credits just reading raw boilerplate over and over again.

:brain: The Root Cause: “Context Rot” & Attention Degradation

The truth is: the models didn’t get dumber. Your context window is simply drowning.

When an AI coding agent ingests an entire repository, 85–95% of the payload consists of repetitive internal function logic, loops, formatting, and boilerplate that the model does NOT need just to understand how modules interact. The needle gets buried in a 50,000-token haystack.

To fix this once and for all, I built and open-sourced T-Zero Context Architect V3.

:high_voltage: What is T-Zero?

Instead of dumping raw files into the prompt, T-Zero uses an offline Abstract Syntax Tree (AST) engine to extract pure architectural signatures, exported classes, types, function declarations, and module dependencies—stripping implementation bloat while keeping 100% of structural semantics intact.

:bar_chart: Real-World Benchmark (Tested on a ~224k char Python core):

Ingestion Mode Token Count Reduction Ratio Time to Ingest
Raw Source Code 56,037 tokens 0% Baseline
T-Zero Ultra AST 3,088 tokens -94.5% ~8x Faster

That’s a 94.5% reduction in context overhead with zero loss in structural reasoning.

:hammer_and_wrench: Key Capabilities & Features

  1. :robot: Native Model Context Protocol (MCP) Server (13 Autonomous Tools):

    • Direct stdio bridge for Cursor, Antigravity IDE, Claude Desktop, and Cline.
    • get_project_context_tree (T-1 to T-4 hierarchical context trees).
    • query_module_dependencies (AST dependency graph).
    • audit_codebase_quality (code smell & secret leak scans).
    • search_codebase_semantic (100% private in-memory BM25 hybrid search, $0 cost).
    • analyze_change_impact (0-100 blast radius risk score before modifying symbols).

  2. :locked: 100% Zero-Leak Security Architecture:

    • Enforces OS-native credential storage via Windows Credential Manager, Apple Keychain, and Linux Secret Service.
    • Zero telemetry, zero external network calls (unless you configure your own LLM provider).

  3. :shield: GitHub Actions Marketplace Ready:

    • Drop-in CI/CD guard to enforce architecture boundaries and catch leaks before PR merges.

:rocket: 1-Minute Quickstart

Install via PyPI:

pip install tzero-mcp
2

The 94.5% token reduction benchmark in your table is the critical metric here, @Toprak.

Most developers assume that feeding an LLM an entire codebase requires raw source ingestion, but in practice, 80%+ of token consumption in an autonomous loop is burned on internal function bodies, loops, and private helper logic that the model does not need until it actually begins editing that specific method.

Extracting pure AST signatures (classes, type signatures, exported declarations, and import topology) preserves the model’s global structural reasoning while keeping prompt payloads under the attention degradation threshold.

A couple of architectural questions on how T-Zero handles the edge cases:

  1. Dynamic Resolution & Metaprogramming: How does the AST parser handle dynamic module loading (e.g. importlib or dynamic getattr dispatch) where static AST cannot infer the dependency edge?
  2. Blast Radius Calculation: For analyze_change_impact, how are you weighting symbol modifications (e.g. modifying an exported public interface vs a private internal helper)?

Glad to see this packaged cleanly as an MCP server with stdio transport. That is the correct architectural pattern for Antigravity and Claude Code integration.

3

Method 20: Temporal & Contextual Anchoring may be of use.

4

Thanks a lot for the insightful feedback, @dllhell ! You hit the nail on the head: burning 80%+ of the context window on internal imperative loop logic and private implementations before the model even touches the file is the silent killer of autonomous agent loops. Keeping things below the attention degradation threshold was precisely our design north star with T-Zero.

Regarding your architectural questions:

1. Dynamic Resolution & Metaprogramming (importlib, dynamic getattr)

Static AST parsing inherently hits a wall when dealing with dynamic module dispatch and runtime metaprogramming (importlib.import_module, runtime sys.modules patching, or dynamic string dispatch via getattr). In T-Zero, we handle this through a tiered fallback strategy:

  • Explicit Dynamic Pattern Heuristics: In our AST scanner passes, we explicitly flag call sites matching dynamic import wrappers (importlib.import_module, __import__, and string-literal getattr/importlib patterns). When these are detected, the analyzer extracts any reachable string literals or constant arguments to construct speculative dependency edges.
  • Topological & Package-Level Fallback: If the exact target cannot be inferred statically from the AST, T-Zero falls back to treating the caller module as an open dynamic node. In Ultra reduction mode, rather than dropping the edge, we preserve the call site decorator/signature annotations and module-level imports, deferring exact resolution to the agent’s runtime context if an edit or deep inspection is triggered.
  • Zero-Hallucination Guardrails: We inject explicit contextual guardrails (e.g., via the generated blueprint / AGENTS.md) advising autonomous harnesses that unresolved metaprogramming symbols must be verified in the local workspace directory topology before assuming external or missing dependencies.

2. Blast Radius Calculation (analyze_change_impact Weighting)

For change impact analysis and blast radius scoring (implemented in our impact engine / ChangeImpactAnalyzer), symbol modifications are not treated equally:

  • Public Interfaces / Exported API Boundary: Modifications to exported public interfaces (functions/classes present in __all__, top-level module exports, or symbols without a leading underscore _) are assigned high blast radius weights. Changes to their signatures (e.g., parameter addition/removal, type annotations, return types) trigger transitive dependency traversal across all importing modules.
  • Private / Internal Helpers: Internal helper methods (e.g., prefixed with _ or private class members) are scoped strictly to their lexical module or enclosing class. Their blast radius is calculated solely based on internal call graph fan-out within that single module, avoiding false-positive ripple effects across the entire dependency graph.
  • Heuristic Impact Score: The final blast radius score combines symbol visibility (Public vs. Private), fan-out degree (in-degree/out-degree from the import graph), and signature diff severity (e.g., breaking signature changes vs. non-breaking additive updates).

Packaging the engine as an MCP server with stdio transport was essential to give Antigravity, Claude Code, and Cursor native, low-latency access to these AST primitives without the overhead of heavy background services.

Really appreciate the great questions and discussion!

5

Appreciate the detailed breakdown, @Toprak.

Scoping private helpers strictly to internal lexical fan-out while treating public __all__ symbols with transitive traversal is a very tidy way to avoid the false-positive alert fatigue that usually plagues naive AST graphs.

Extracting lean AST topology upfront to stay well below the 30k attention dip–combined with deterministic execution guardrails when the agent actually writes code–feels like the winning architectural pattern for multi-turn autonomous coding.

A clean contribution to the ecosystem.