RTK and Pump-Me
RTK and Pump-Me both move output processing outside the language model. My reason for developing Pump-Me is to let the AI author a reusable observation contract: define the facts needed for a decision, implement them in a provider, then compose its local objects within one task budget and outcome contract.
The RTK observations here are pinned to commit a4cddfc5ce6e6412c66e9729c4200792d822a964. The source manifest records hashes and links. RTK was inspected, not executed in this verification run.
Represent RTK accurately
RTK is a Rust CLI proxy with specialized command handlers, agent integration and output-reduction tracking. Its command modules support structured formats, state-machine parsing, flag injection and flag-aware behavior. It cannot fairly be described as a regex-only line remover. RTK command-module documentation (ouvre dans une nouvelle fenêtre).
It also provides TOML filters, with project-local and user-global files in addition to built-in filters. Those suit predictable text and support filtering, replacements and limits. More involved structured parsing belongs in Rust modules. Custom filter activation is subject to RTK's documented trust mechanism. RTK filter documentation (ouvre dans une nouvelle fenêtre).
RTK's contribution guidance emphasizes preserving requested detail, respecting correctness, providing fallback paths and maintaining low overhead. These are design intentions, not measurements from this article. RTK contribution guide (ouvre dans une nouvelle fenêtre).
RTK also has tee/recovery machinery for retained output. Recovery conditions matter: the ability to retrieve hidden detail is not the same as initially delivering it to the model. RTK tee implementation (ouvre dans une nouvelle fenêtre).
The interface chosen for the agent
| Question | RTK | Pump-Me workflow in this series |
|---|---|---|
| What does the agent receive? | Filtered command output from specialized handlers. | One bounded JSON task envelope, with projected domain data and aggregate status. |
| Where is structured parsing done? | Rust command handlers can parse machine formats. | Tool-specific PowerShell providers reduce native output into business objects. |
| How is support added? | TOML filters or Rust modules, depending on the operation. | Independent OPumper module, parser fixtures, descriptor and session contribution. |
| How are ordinary commands reached? | Explicit proxy calls and agent hook/rewrite integrations. | Explicit generated .ps1 tasks using verified Pump-Me routes. |
| What happens when coverage is missing? | Follow the selected handler/filter's documented fallback behavior. | Engine native passthrough exists; the example's preflight rejects the missing route. |
| How are many operations composed? | Depends on the surrounding agent workflow. | Local objects plus Invoke-OutputPumpStep and one task-wide budget. |
| What evidence is supplied here? | Pinned primary sources. | Executed provider, streaming and task-budget fixtures. |
This comparison describes the interfaces inspected here. It does not imply that RTK cannot be composed by a script, or that a structured parser automatically guarantees complete information.
What authoring the contract enables
The agent controls the meaning and shape of .Data: parsing machine records, normalizing paths or states, calculating useful summaries and preserving completion evidence. Once registered, that capability is available to subsequent scripts. The model consumes the result rather than repeatedly interpreting a terminal transcript.
Compared with a declarative text filter, a PowerShell provider can express more involved parsing and domain logic. RTK's Rust handlers can also implement such logic. The distinction developed here is the explicit agent workflow: documentation, scaffold, tested provider, catalogue registration and object composition, with the resulting code owned and versioned by the user. It is a way to build reusable observation contracts, rather than an exclusive claim to structured parsing.
The promise depends on validation. A compact object with a wrong count or silently missing failure is a poor contract. The generator and documentary registration guide the lifecycle; semantic fixtures, native failure cases and supported-format checks establish whether the implementation is useful.
When the investment is useful
Pump-Me is a useful fit when the same capability will serve repeated requests, an internal tool needs a domain-specific interface, or the agent must decide whether to retry, narrow scope or act on a result. A team can share providers and their fixtures through ordinary repositories. These situations give a reusable contract opportunities to repay its authoring and maintenance effort.
For an occasional command already covered by an installed RTK handler, RTK can avoid writing a PowerShell provider. Its proxy approach also suits environments that prefer its existing integrations and do not want to maintain PowerShell modules. Existing coverage matters for both tools: using an available Pump-Me provider has a different initial cost from authoring one.
| Consideration | RTK | Pump-Me workflow |
|---|---|---|
| Initial effort | Configure and verify existing coverage; author a filter or Rust handler if needed. | Activate and verify an existing provider; research, implement and test a missing contract. |
| Repeated requests | Reuse the selected handler or filter. | Reuse registered providers and compose their named fields locally. |
| Information retained | Depends on the handler, filter and requested flags. | Depends on the provider contract, completeness and task projection. |
| Maintenance | Validate custom filters or handlers against tool behavior. | Validate parsers, field semantics and documentation against supported formats. |
| Failure risk | Incorrect reduction can hide necessary evidence. | Incorrect parsing or projection can hide necessary evidence; envelope status must remain visible. |
This table identifies work to measure. It assigns no universal cost or risk ranking. Reuse, correct providers and a guided generation-to-validation workflow determine whether the approach pays off for a particular workload.
Retained information is part of the measurement
For the worktree question, score the answer against an explicit oracle: count, path, HEAD, branch, detached/bare/locked/prunable state, native exit outcome and completion. A shorter answer that silently loses one required field is not an equivalent result.
For TODOs, define the scope and unit: source files selected by the command, matching lines rather than occurrences, and errors that invalidate an exact total. Preview records and complete counts are separate metrics.
The Pump-Me fixture deliberately produces truncated previews with complete counts. It also demonstrates failure retained under a tight task budget. Those observations establish specific contract behavior; they do not establish comparative token savings.
Measure the costs separately
| Metric | Reproducible method |
|---|---|
| Output bytes | Count UTF-8 bytes of the exact documents delivered to the agent, including status and retry output. |
| Output tokens | Use the same named tokenizer/model for all captured outputs; do not relabel byte counts as tokens. |
| Retained information | Compare required fields and outcomes against the same fixture oracle. |
| Execution overhead | Record elapsed time for raw CLI, proxy/provider and final composition; separate warm sessions from fresh PowerShell startup. |
| Retries | Count narrowed/corrected queries needed to answer the original question, including their output and elapsed time. |
| Initial provider effort | Record documentation research, generation, implementation, testing and review time, plus model input/output used to do that work. |
| Repeated use | Reuse the same validated provider over a stated number of comparable requests and include maintenance costs. |
Use fixed repositories and tool versions, verify source hashes and alternate execution order. Distinguish cold startup, module activation, native execution and serialization. Report distributions across repeated runs rather than a single stopwatch result. Keep any full benchmark captures local; the agent consumes only bounded measurements.
The runner's measurements.json records JSON bytes, required fields retained, caller-generation time, task-execution time and retries separately for the main request and reuse request. It also times the scaffold generator. These are single-fixture observations in an initialized session, not a comparative benchmark. Full provider research, implementation and review effort is explicitly unmeasured; scaffold time cannot stand in for that cost. No tokenizer or RTK runtime result is inferred.
For N requests, the total cost is the initial authoring/validation cost plus the sum of execution, output, retry and maintenance costs. Dividing the initial cost by N expresses amortization. It does not prove a break-even point without measured values.
RTK itself explains that advertised reductions concern command output rather than a complete model bill. The same discipline applies to Pump-Me: fewer output bytes can help, but JSON metadata, script generation and provider maintenance also have costs. RTK savings explanation (ouvre dans une nouvelle fenêtre).
Why I choose objects for this workflow
The main value is inspectable reuse of a contract the agent helped define. Once GitWorktrees exists, the AI uses WorktreeCount and Complete directly, while the parser, route, documentation and fixtures live in the user's repository. The next task combines those objects without relearning a CLI table. Its value comes from useful information per request and justified reuse; the smallest possible output is not sufficient by itself.
RTK offers a broadly integrated command proxy. Pump-Me asks the agent to follow an explicit scripting contract and to invest in providers when required. The best choice depends on the task, installed coverage and the information the agent must retain. This article supplies execution evidence for Pump-Me's contract and a protocol for a fair performance comparison; it supplies no invented comparative savings.
Previous: Existing Pumps in Practice · Next: Sources and Verification