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 single git status on a busy working tree can run hundreds of tokens. Multiply by the command list above, then by every re-orientation after the context gets compacted, and orientation alone can eat 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 FluxGit's own repository the brief comes back under 1,500 characters, roughly the cost of a single verbose git status, for the whole orientation phase.

The same economics, three more times.

Once you frame tokens as the scarce resource, several existing FluxGit tools turn out to be context plays. diff.semantic lets the agent review what a refactor did structurally instead of parsing a five-thousand-line patch, and honestly reports supported=false when it cannot. repo.conflictPreflight answers "would this merge conflict" from merge-tree analysis before the agent proposes anything, which is cheaper than proposing, failing and re-planning. fleet.radar compresses the state of many repositories into one attention stack without a single fetch. Different features, one principle: fewer, denser answers.

What I have not done yet is publish a rigorous token benchmark across hosts, raw CLI versus the MCP tools on identical tasks. The character caps are tested in CI; the end-to-end session numbers are still anecdotes from my own use, and I want real measurements before putting a multiplier in a headline.

Why this is free.

The entire read-only surface, twenty-one 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.