Zero-Dependency Python Tool TokenPrune: Cut API Payload Tokens by 80% Without a Second LLM

Why Does Your Agent Keep Wasting Tokens?

When building Agents that interact with external APIs (GitHub, Jira, Stripe, or internal microservices), the output returned by tools often floods the context window: avatar URLs, HATEOAS links, node IDs, null-valued keys… This metadata routinely consumes hundreds of tokens, while the genuinely useful information may account for only a small fraction.

The common approach is to bring in an auxiliary model (such as GPT-4o-mini) to summarize the tool output first, then feed it to the main Agent. But this introduces 500ms to 2 seconds of external network latency, plus ongoing API call costs. For high-frequency Agent workflows, this overhead affects both responsiveness and operating costs.

TokenPrune: A Deterministic Local Pruning Solution

A developer released TokenPrune on Reddit—an open-source, zero-dependency Python package. Its approach is straightforward: instead of calling any external model, it performs deterministic pruning and table compression in memory, stripping redundant information from tool output and keeping only what is valuable for Agent decision-making.

Installation is simple:

pip install tokenprune

The core usage is to wrap tool functions with the @prune_tool decorator. When a function returns a dictionary, TokenPrune automatically analyzes its structure, strips null values, compresses repeated key-value patterns, and converts list-type data into a compact table format.

An Example to See the Pruning Effect

Suppose a tool that fetches system logs returns the following dictionary:

from tokenprune import prune_tool

@prune_tool
def fetch_system_logs():
    return {
        "cluster_id": "us-east-1",
        "service_url": "https://internal.aws/k8s/node/12",
        "health": "degraded",
        "errors": [
            {"code": 500, "reason": "Database connection pool exhausted", "doc_url": "https://docs.internal/500"},
            {"code": 503, "reason": "Upstream timeout", "doc_url": "https://docs.internal/503"}
        ],
        "debug_trace": None
    }

After TokenPrune processing, the content injected into the LLM prompt becomes compact YAML:

cluster_id: us-east-1
service_url: https://internal.aws/k8s/node/12
health: degraded
errors: [table: code, reason, doc_url]
  - 500, Database connection pool exhausted, https://docs.internal/500
  - 503, Upstream timeout, https://docs.internal/503

Note that debug_trace: None is simply removed, and the errors list has been transformed from a repeated dictionary structure into a compact format with a table header plus rows. For API responses containing many similar objects, this table compression can significantly reduce the token count.

HATEOAS (Hypermedia as the Engine of Application State) is a REST architectural style: API responses include not only business data but also a set of links pointing to related operations (such as _links, href, next, etc.), letting clients discover available actions by following links. These link fields are valuable for building UIs or navigation, but for an LLM Agent's decision-making they are often just noise—the Agent typically already knows which tool to call and doesn't need to parse the next URL from the response. Similar metadata includes avatar URLs, pagination cursors, node IDs, and so on. TokenPrune's default pruning strips such fields first, but this also means that if some links are genuinely necessary for tracing or subsequent calls, the developer must explicitly preserve them.

Performance Data and Implementation Details

According to the benchmark results published by the author:

• Token reduction: 70%–90% on enterprise-grade API payloads
• Runtime overhead: under 0.5 milliseconds, implemented via pure-Python standard-library AST tree-shaking
• External API calls: 0

This means TokenPrune completes processing entirely within the local process, with no network round-trip and no additional per-token costs. For latency-sensitive Agent scenarios, this is far lighter than calling an auxiliary model for summarization.

The author open-sourced the project on GitHub (GeekyMK/tokenprune) and published it to PyPI.

AST tree-shaking was originally a concept in compilers and bundlers, referring to statically analyzing a codebase's abstract syntax tree at build time and removing unreferenced code to reduce output size. TokenPrune borrows this idea, performing static traversal and rewriting of the structure of tool return objects at Python runtime: identifying keys that can be safely discarded (such as null values and duplicate metadata), and collapsing lists of structurally isomorphic dictionaries into a header-plus-rows representation. Since the entire process relies only on the standard library and completes in memory without triggering any calls outside the interpreter, it can finish in sub-millisecond time and is fully reproducible—the same input always yields the same pruning result, which simplifies debugging and unit testing.

Applicable Boundaries and Open Questions

TokenPrune's pruning logic is based on deterministic heuristic rules, which is both a strength and a limitation. The strength is that it is predictable, debuggable, and free of extra costs; the limitation is that the rules may not cover all API return structures. The author himself acknowledged in the post that he wants to learn from Agent workflow developers "where the heuristics break down" and "which schema formats are most commonly handled."

A few points worth noting:

• Applicability of table compression: When the objects in a list have inconsistent structures, table compression may fail or produce ambiguity, and developers need to confirm whether the output matches expectations.
• Risk of information loss: Pruned fields (such as links like doc_url) may be necessary in certain debugging or tracing scenarios, so Agent design needs to weigh the preservation strategy.
• Coordination with prompt engineering: TokenPrune is only responsible for compressing tool output; how the final prompt is organized still affects overall token consumption.

The tool has not yet been validated in large-scale production environments. The 70%–90% reduction figures come from the author's own testing, and actual results will vary depending on the type of API payload.

Conclusion

TokenPrune offers a lightweight option that bypasses the "auxiliary LLM summarization" route: using deterministic local pruning instead of network calls to achieve token compression in sub-millisecond time. For developers building Agents whose tool output is primarily structured JSON, it is worth evaluating in a test environment whether its pruning rules match their own schemas. The project's future value will depend largely on whether the community can contribute more heuristic rules for different API formats.