The framework provides two transformation engines and is explicit about when to use each. Token-based transformation operates on the flat, UUID-tracked token stream with clause context; it is faster and simpler and is the recommended default for most queries. AST-based transformation, built by the AST Builder (tamper_framework/ast_builder.py), constructs a hierarchical representation of the query with subquery detection and function-call handling; it is more accurate on nested structure and is recommended for complex queries.

The distinction matters most for deeply nested queries, which the documentation calls out as a potential failure point for the simpler approach and, in the worst case, an edge case to work around by simplifying the query. The published benchmarks put both engines at millisecond scale: about 1ms for a simple 10-token query, about 5ms for a 100-token query, and about 10ms for a nested subquery. Because those costs are trivial next to the network round-trips of an actual SQLMap run, the token-vs-AST choice is really about correctness on nesting, not speed. Exposing the tradeoff to the user, rather than hiding it, is consistent with the framework’s overall honesty about its scope and limits.