Your agent's context window is the new CPU.

The tax is real and nobody itemizes it.

Everyone tunes agents for model quality and prompt design, then feeds them the chattiest data source on the machine. A broad orientation sweep can require separate status, history, refs, diff, stash, tag, remote and submodule calls. Repeat it after context compaction and orientation consumes part of the session before any work happens. The agent does not get slower. It gets shallower: less room to read your actual code, earlier summarization, more guessing.

Speed was the old bottleneck and machines got fast. For an agent, tokens are the bottleneck now. They are the CPU cycles of a session, and git output is an unprofiled hot loop.

One call, budgeted like a performance target.

FluxGit's MCP surface treats this as an engineering constraint, not a slogan. repo.brief, shipped 2026-06-10, replaces the orientation phase with one read-only call: HEAD and branch with ahead-behind, any in-progress merge or rebase or cherry-pick, a working-tree summary, stash count, recursive submodule drift rolled up, recent commits one line each, detected commit conventions, and a hints field with the recommended next step. It is advertised first in tools/list on purpose: it is the call every session should start with.

The part I care most about is not the aggregation, it is the budget. The payload size is capped by a regression test in CI, the way you would cap a latency budget. If a change makes the brief exceed its cap, the build fails. The useful claim today is structural: one typed call returns the core orientation fields that otherwise require several Git commands. A numerical benchmark will return only after its repository builder, path normalization, environment manifest and captured artifacts reproduce the published result end to end.

The same economics, three more times.

Once you frame tokens as the scarce resource, several existing FluxGit tools turn out to be context plays. repo.scope answers a subtree question, working-tree changes, churn, recent commits and owners in one typed call. repo.conflictPreflight answers "would this merge conflict" from merge-tree analysis before the agent proposes anything; on my benchmark it does not save output tokens over raw merge-tree, its value is one structured call and the guarantee that nothing in the working tree was touched. diff.semantic lets the agent review what a refactor did structurally instead of parsing a five-thousand-line patch; with FluxGit running it returns the real structural payload, and standalone it reports supported=false and routes to the text-diff fallback. I make no token claims for it yet; measured numbers will follow the same benchmark discipline. fleet.radar compresses the state of many repositories into one attention stack without a single fetch. Different features, one principle: fewer, denser answers.

Output size depends on the question and a hand-tuned CLI sequence may be smaller than an aggregated response. End-to-end session cost also depends on how an MCP host loads and caches tool schemas. Until the repaired benchmark measures those boundaries reproducibly, they stay out of the headline.

Why this is free.

The entire read-only surface, twenty-three tools including repo.brief, works with any MCP-compatible host. Most of it runs against plain local git without the desktop app installed. The business is the governance layer on top: when the agent wants to write through FluxGit, it can only propose, and the proposal goes through a human approval card with operation-specific preview and recovery context plus an audit trail. Understanding your repository cheaply should not cost money. Letting an agent touch history safely is what FluxGit sells.