Engineering · · 15 min read
Cortex Loom inside GrantTap: where token savings come from
A real Engine experiment reduced repeated source evidence by 56.2%, with zero omitted items. How citations, budgets and scoped delivery make the result useful.
A coding agent spends tokens whenever it reads tool output, reasons about that output, or asks another model to transform it. Much of that spending is necessary. The waste begins when the same source arrives through several tools, when unrelated files accompany one useful definition, or when an assistant repeatedly reconstructs facts already available to the project. GrantTap approaches this as a data delivery problem. The computer can prepare evidence before the coding model sees it, while preserving the identity of the Task and the boundaries of the current repository.
Cortex Loom supplies part of that preparation. Its context compiler is linked into GrantTap Engine alongside Weavatrix repository analysis. The integration is available per Project when Cortex and Engine are enabled. We tested that actual local Engine, rather than substituting a remote summarizer, using source from GrantTap's own context delivery implementation. The result was a measurable reduction for repeated evidence, with no source items omitted. Equally useful, a control with one reading showed almost no reduction. Together, those results explain where the mechanism earns its place and how GrantTap keeps its overhead under control.
Follow the evidence from computer to model
The path starts with a scoped Project view. GrantTap identifies the Task, its current Execution, repository binding, relevant events, knowledge records, and available policy restrictions. It filters knowledge according to visibility before asking Cortex to compile anything. A private record belonging to another Task does not become available just because it would make a packet more complete. Repository identity and source revision also travel with the evidence. This ordering matters: context selection should operate on information the Execution may actually receive, rather than assemble a broad packet and try to remove sensitive pieces afterward.
Engine receives typed evidence items containing identifiers, source labels, content, priority, trust state, derivation, and snapshot identity. Cortex ranks and packages those items inside a budget. Weavatrix can add repository relationships and targeted source windows when a verified local repository binding is available. GrantTap exposes compiler version and revision with the result, so an observation can be tied to the implementation that produced it. The coding model receives a bounded view and can expand the source when needed. Neither the phone nor the coding agent must write an extra narrative report simply to make this pipeline function.
Keep citations when removing repetition
Deduplication is different from asking a model to rewrite code into fewer words. Cortex can recognize repeated source lines, preserve their first occurrence, and replace later occurrences with a citation to that evidence. The retained text remains inspectable. Its trust and provenance remain part of the packet. This is especially useful when a symbol lookup, search follow-up, and definition expansion all return overlapping regions of one file. Those are plausible independent paths to the same source, and a context compiler can reconcile them before their overlap consumes another portion of the upstream model's window.
A citation also imposes a useful responsibility. The packet must contain the evidence being cited, and differences in source revision or trust cannot be flattened merely because two strings look alike. A repeated line may be the same code in two different snapshots, or a proposed patch may resemble the current implementation without being implemented. GrantTap therefore keeps uncertainty visible. The compiler records included and omitted identifiers, whether further evidence is required, and how much text was deduplicated. A compact answer still needs to say what it knows, where that knowledge came from, and which questions remain open.
What our Engine experiment measured
Our controlled experiment used three real TypeScript files from GrantTap's context delivery feature. The first arm supplied each source once. The second supplied the same three sources three times, representing overlapping retrieval of known evidence. Both arms used the actual linked Rust compiler through the Engine Unix socket, a budget of 16,000 estimated tokens, and models disabled. Assertions checked that every supplied item was included and every substantial source line remained available in the compiled output. This deliberately tests the deduplication mechanism; it does not pretend that every ordinary development Task starts with three identical readings.
With one reading, the compiler reported 4,189 candidate tokens and 4,176 delivered tokens, a reduction of roughly 0.3 percent. With three readings, it reported 12,567 candidate tokens and 5,506 delivered tokens, a reduction of 56.2 percent. It removed 325 repeated lines, omitted zero evidence items, and completed that measured compilation in eight milliseconds on the test Mac. These are the linked compiler's token estimates and observed local latency. They are not a provider invoice, a universal performance guarantee, or a claim that a complete agent session became 56.2 percent cheaper. The experiment isolates a specific, verified source of waste.
Count the complete answer
Compiler savings can disappear if a surrounding application appends the packet to an already complete response. GrantTap's compact delivery now budgets the serialized response as a whole. The decision includes the Task envelope, peer Tasks, resource claims, history cuts, citations, and compiler metadata. A compiled representation is chosen automatically only when every event and knowledge record visible in the ordinary compact view is covered by the packet, and the complete alternative is smaller in both characters and UTF-8 bytes. The retained event identifiers support inspection and cursor continuity even when their text is supplied through packet references.
When that condition is not met, GrantTap delivers the compact facts and compiler status with an expansion link. It does not add a second copy of the same narrative. The comparison is deterministic and requires no model call. Character and byte counts are practical guards, not exact provider tokenization, so the implementation does not label them as billed tokens. An explicitly expanded full view remains available for inspection. This makes the default economical while preserving access to the evidence required for a difficult decision, a review, or a contradiction discovered during a test.
Models have a role and a cost
Cortex has optional model assisted routing and drafting paths. Depending on configuration, a local model or an explicitly configured proxy can suggest how to classify a Task or prepare an advisory draft. That can be useful when a request is ambiguous, when natural language needs translation into a structured intent, or when a bounded draft saves work in a stronger upstream model. However, the model name alone proves nothing about savings. Qwen, a Sonnet configuration, or any other backend introduces its own input, output, latency, and quality tradeoffs. Those costs belong in the same accounting boundary as the upstream context they might replace.
In the Engine experiment described here, no classifier or draft model was invoked. The saving came from algorithms and source citations. This distinction is valuable for users who want economical automation without a second assistant rewriting everything the first assistant will read. Optional models should earn their place through measured results on their configured workloads. The Graph and context compiler can still gather, rank, budget, and deduplicate evidence without them. We also keep routing advice separate from permission: a suggestion to use another model does not grant authority to modify a repository or execute a sensitive tool.
Workflows and refactor previews
Cortex's typed sequences turn familiar engineering practices into bounded steps with evidence requirements. A debugging step can request a definition and a relevant test instead of injecting a large general methodology document into every interaction. An implementation step can identify the source needed before proposing a change. The project describes these sequences as a rewrite of engineering mechanics inspired by Superpowers, with no Superpowers runtime dependency. Their economy comes from activating the step that applies now, keeping the required facts visible, and avoiding repetitive instructions that the computer can represent structurally.
Weavatrix Refactor adds another useful boundary. A preview can inspect an exact plan against source and show its consequences before a change is applied. A graph relationship helps identify candidates and dependencies; a preview helps review a concrete edit. Neither is permission to apply the edit automatically. The coding agent still owns the reasoning that the change satisfies the user's request, and the repository's tests supply behavioral evidence. This division lets algorithms perform repeatable inspection while a model concentrates on the engineering decision that benefits from interpretation, rather than redoing mechanical discovery or treating a proposed transformation as an accomplished result.
Completeness protects the saving
A definition packet needs the definition, not merely the beginning of its file. This research also strengthened target handling in Cortex's source discovery. Definition evidence is associated with its named target, so a request involving several symbols or a file path cannot silently let one definition displace another. The regression scenario places a TypeScript function after a long preamble and checks that its body remains present and recognized as complete. That is a functional quality check: a smaller packet is useful only when the agent can still inspect the behavior it came to understand.
Expansion should remain equally specific. If the packet lacks callers, tests, or a complete definition, the next request should target that missing facet. Repeating the entire initial query can bring back the same module map and the same partial window, spending more tokens without resolving the uncertainty. Citations and completeness markers give the agent a concrete reason to request additional source. The workflow finishes with a test, build, or another relevant verification. A successful context operation establishes that evidence was prepared; it cannot establish that an application's bug was fixed or that a refactor preserved behavior.
Use the right boundary for the result
The useful mental model has three layers. Repository analysis supplies source facts and relationships. Cortex prepares a bounded, cited packet. GrantTap carries the Task, coordination, policy, and visibility boundaries around that packet. Savings at one layer do not automatically imply savings everywhere else. A project with repeated source retrieval can benefit substantially from deduplication. A tiny edit in a known file may already have an economical native path. A complex Task may need additional evidence and spend more initially while avoiding a much more expensive incorrect change or repeated investigation later.
For everyday use, begin with the smallest relevant view, preserve identifiers, and expand when a concrete fact is missing. Inspect compiler status rather than assume an enabled switch guarantees that evidence was delivered. Compare the complete exchange, including extra model calls, when evaluating a model assisted configuration. GrantTap's role is to make those choices cheaper and easier to inspect without asking the agent to manufacture telemetry or repeat project history. The verified result from this pass is specific: real repeated source evidence was reduced while remaining available, and compact delivery now has a deterministic guard against duplicate context inflation.
Inspecting architecture on the phone
GrantTap opens the Weavatrix map full screen and fits it to the available viewport. The graph retains depth: drag to rotate and pinch to zoom. Reset brings the received components back into view. This lets a person move from the repository structure to a particular dependency without asking a model to explain the same map again. Labels and colours identify components; colour indicates node type, rather than code health or permission to perform an action.
Selecting a component highlights its neighbours. Its card links to connected components and opens Component details. That sheet shows the identifier, type, full report revision, directed relations and observation counts when the analyser supplied them. A missing count stays unknown. Following a relation continues inspection; Show on graph returns the selected component to the spatial map. The bottom panel opens the complete component inventory, with search across names, types and identifiers without a twenty-result limit.
The code city adds a source-level view to that component map. A tower represents a reported file, and its stacked sections preserve symbol names and measured source locations. Select a tower or a labelled section to open Sections, Links and Health. Sections is a scrollable inventory of every symbol in the received report; file and symbol search reaches the same inventory directly. Selecting a relation opens its actual endpoint, including an observed external service. Repository identity stays attached to the selection, so identical file paths in two linked repositories remain distinct.
Received report updates also refresh an already open city. The current camera and source selection remain available; on Mac, section identity survives inserted rows, and the chosen Health tab and scroll position are retained.
The camera controls are visible beside this inspection: zoom, Fit, top and isometric views, and Orbit or Pan. On Mac, the Repo Lens label rail also scrolls with a wheel or a finger. Full screen retains the chosen file or section and the camera position. On iPhone and iPad, the native scene keeps its camera when colours or visibility settings change, and the compact inspector leaves room for the map. The controls sheet explains the gestures without requiring a model to describe them.
Highlights describe the evidence that was actually received. On Mac, the section-size threshold uses measured source lines and can be adjusted; the source and Health panels show the report revision and analysis status. Coverage, complexity and structural health stay unknown when the analyser did not supply them. Colour and a size warning are useful navigation signals, but they do not certify correctness or authorize an action. The saved Mesh report supplies this entire inspection offline: scrolling a section list or moving the camera adds no context tokens.
Health and Graph share the state of an architecture build. Active Projects request missing or changed reports automatically. An explicit rebuild receives its own receipt from the computer; a periodic publication of a cached graph cannot acknowledge that request. When two phones ask to rebuild the same Project, the computer performs one analysis and returns a receipt to each controller. Received reports and relations stay on the device with the Mesh for offline inspection.
The build card combines the action, progress and explanation in one place. During a rebuild, the last saved map stays visible. A transport failure ends with a retry action; the phone does not keep an indefinite spinner waiting for a computer that has not accepted the request. The information sheet explains automatic refresh and the difference between the repository's Git revision and the analysis content fingerprint. These identifiers serve separate checks: the Git revision locates source, while the fingerprint identifies the analysed content.
The MCP persists usable analysis reports privately on the computer and reuses them after a runtime restart. A new report replaces the saved result when analysis completes. Work is scheduled per repository, so a ready Project can publish its report while another Project is still being analysed. Multiple repository reports share the delivery budget, preserving room for each repository and the Mesh metadata. A partial or unavailable result retains its reported status; it cannot become a complete architecture merely because a reply arrived.
Repository analysis uses a separate Engine connection, keeping policy and Backbone requests available while Weavatrix works. Chat catalogs also continue independently of background Mesh enrichment. Architecture can therefore support context preparation while user decisions remain responsive. A partial report keeps its partial status and exposes the components, relations and code files that are available.
The report information sheet explains gestures, the colour legend, Weavatrix version, revision and report scope. COMPLETE describes the analysis inputs that were processed; it does not establish that every repository dependency is known. Partial reports retain their explicit scope and received versus declared component and relation counts. A component without reported connections is not necessarily independent: the analyser may lack a required input or support for that relationship.
The map and information sheets read the received report. Rotation, search and component navigation do not invoke Cortex, a model or a new repository scan. When the Mesh replica has been saved, this inspection works offline. The interface complements context savings by letting a person check structure and a relation's origin before asking an agent to read more code. The interface illustration uses a deterministic demo revision; token measurements were made separately through the real Engine.
