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. I measured that sweep on a 44-commit test repo: ten commands, 7,111 bytes of terminal output, 1,886 tokens counted with a standard tokenizer. Multiply by every re-orientation after the context gets compacted, and orientation alone eats a meaningful slice 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. On the same 44-commit test repo, the brief came back at 2,043 bytes and 607 tokens against the sweep's 1,886: 3.1x fewer tokens, and one round trip instead of ten. Those numbers come from a reproducible benchmark, not a guess; the scripts that build the test repo and count the output are checked into the repository.

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 call I measured at 480 tokens. 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.

I will be honest about the counterexample too: against a hand-tuned minimal set of five git commands, the brief costs about 24% more output tokens. The 3.1x saving is against the sweep agents actually run, and the collapse from ten round trips to one holds either way. End-to-end session numbers across different MCP hosts are still unmeasured, so 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, it can only propose, and the proposal goes through a human approval card with a restore point and an audit trail. Understanding your repository cheaply should not cost money. Letting an agent touch history safely is what FluxGit sells.