DEV Community: Mayne

ThinkGraph Tutorial: How to Make Your LLM Actually Think Before Answering

Mayne — Wed, 01 Jul 2026 18:39:51 +0000

In my previous article, I introduced ThinkGraph -- an open-source pipeline that forces LLMs to decompose complex prompts into atomic fact DAGs before answering. This time, let's get hands-on.

What You Will Learn

How to install ThinkGraph for Claude Code, OpenCode, Cursor, and others
How to use the CLI for step-by-step prompt decomposition
How self-consistency voting catches hallucinations
How web grounding fills knowledge gaps without API keys
How to integrate ThinkGraph as an MCP server

Installation

git clone https://github.com/Mayne-X/thinkgraph.git
cd thinkgraph

# Auto-detect and install for all your agents
python install.py

# See what it would do without touching files
python install.py --dry-run

The installer detects OpenCode, Claude Code, Cursor, Codex, Copilot, and Gemini CLI configs and injects the appropriate adapter. Idempotent -- safe to re-run.

CLI Tutorial: Decompose a Complex Prompt

Let's walk through a real example. Say you ask:

"Should we migrate our PostgreSQL database to CockroachDB for a multi-region SaaS product?"

Step 1: Triage

python cli/thinkgraph.py triage "Should we migrate our PostgreSQL database to CockroachDB for a multi-region SaaS product?"

Output: multi-hop -- not trivial, enters the pipeline.

Step 2: Decompose into DAG

The agent (not the CLI) generates a dependency graph like:

{
  "nodes": [
    {"id": "Q1", "q": "What are CockroachDB's multi-region capabilities?", "deps": []},
    {"id": "Q2", "q": "What are PostgreSQL's multi-region limitations?", "deps": []},
    {"id": "Q3", "q": "What is the migration complexity from PG to CockroachDB?", "deps": ["Q1","Q2"]},
    {"id": "Q4", "q": "What is the cost comparison for our scale?", "deps": ["Q1","Q2"]},
    {"id": "Q5", "q": "Should we migrate given Q1-Q4?", "deps": ["Q3","Q4"]}
  ]
}

Step 3: Validate the DAG

python cli/thinkgraph.py validate-dag graph.json

Checks for cycles, dangling deps, orphan nodes, and computes execution batches:

Batch 0: Q1, Q2 (parallel)
Batch 1: Q3, Q4 (parallel)
Batch 2: Q5 (needs Q3 + Q4)

Step 4: Resolve with Web Grounding

Low-confidence sub-questions (< 0.6) can trigger automatic web search:

python cli/thinkgraph.py web-search "CockroachDB multi-region latency benchmark 2026" --num-results 5

No API key needed -- ThinkGraph parses DuckDuckGo results directly via HTTP. This is huge for automated pipelines where you don't want to manage search API credentials.

Step 5: Cache Results

python cli/thinkgraph.py cache-set "what are cockroachdb multi-region capabilities" '{"claim": "CockroachDB offers automated partitioning, survivable across regions", "confidence": 0.92}'
python cli/thinkgraph.py cache-get "what are cockroachdb multi-region capabilities"

Facts persist globally at ~/.thinkgraph/cache.json -- shared across projects and sessions.

Step 6: Self-Consistency Vote

Run synthesis 2-3 times, then vote on consistency:

python cli/thinkgraph.py vote \
  "CockroachDB is better for multi-region due to automated survivability" \
  "CockroachDB offers better multi-region support with automated partitioning and survivability" \
  "For multi-region, CockroachDB has automated survivability which PostgreSQL lacks"

Output picks the Jaccard centroid -- the response with highest average word overlap:

{"winner": "CockroachDB offers better multi-region support...", "scores": [0.72, 0.81, 0.68], "response_count": 3}

Step 7: Prune Unnecessary Nodes

python cli/thinkgraph.py prune-dag graph.json --facts facts.json --prompt "Should we migrate PostgreSQL to CockroachDB?"

If a parent node's answer already covers a child's question, the child is auto-removed. Saves tokens without losing information.

Step 8: Export as Report

python cli/thinkgraph.py export results.json --format markdown > migration-analysis.md

Supports JSON, YAML, and Markdown.

Using ThinkGraph as an MCP Server

This is the slickest integration path. Start the server:

python mcp/thinkgraph_mcp.py

Then configure any MCP-compatible client:

{
  "mcpServers": {
    "thinkgraph": {
      "command": "python",
      "args": ["/path/to/thinkgraph/mcp/thinkgraph_mcp.py"]
    }
  }
}

Seven tools are exposed: triage, validate-dag, vote, web-search, cache-get, cache-set, tokens. Your MCP client can call these directly without the CLI.

A/B Testing Your Prompts

Want to prove ThinkGraph improves quality? Use the A/B scorer:

python cli/thinkgraph.py ab-score \
  "CockroachDB supports multi-region deployments" \
  --ground-truth "CockroachDB supports multi-region deployments with automated partitioning and survivability across regions"

Output:

keyword_recall: 66.67%
precision: 100.00%
claim_count: 1
uncertainty_markers: 0

Compressing Long Contexts

When synthesis context is too long, compress it:

python cli/thinkgraph.py compress long_spec.txt --ratio 0.3

Uses TF-IDF sentence extraction to keep the 30% most important content. No embeddings, no API calls -- pure term-frequency math in stdlib Python.

Writing Custom Plugins

Need a custom resolve function? Register a plugin:

python cli/thinkgraph.py plugin-register my_db_lookup 'def fn(q, ctx): return {"claim": db.query(q), "confidence": 0.95}'
python cli/thinkgraph.py plugin-list
# my_db_lookup, shell, weblookup

The Token Math

ThinkGraph sets a hard ceiling of 4x the direct answer tokens. If the pipeline would exceed that, it aborts to a direct answer. Here's the budget for each stage:

Stage	Max Tokens
Triage	50
Decompose	200
Per sub-question	300
Synthesize	600
Hard ceiling	4x direct answer

This means simple prompts (< 200 tokens) bypass the pipeline entirely. You never pay more than 4x, and most of the time you pay far less.

Why Zero Dependencies Matters

The entire CLI is Python 3.8+ stdlib only. No pip install. No venv. No requirements.txt. Precompiled regex, LRU cache decorators, and sets for membership. It runs anywhere Python runs -- including CI runners, Docker scratch containers, and air-gapped environments.

Test Suite

python tests/test_golden.py       # 15/15 passing
python tests/test_new_features.py # 14/14 passing
python tests/benchmark.py         # 10-prompt quality benchmark

The benchmark scores triage accuracy at 80%, compression quality at 70%, and vote consistency at 64% -- solid baselines that improve with use.

When NOT to Use ThinkGraph

Honest answer: don't use it for simple Q&A ("What is the capital of France?"). The triage stage catches trivial prompts and short-circuits. Also don't use it for creative writing -- decomposition kills flow. But for any prompt involving comparison, planning, analysis, or multi-step reasoning, it shines.

Get Started

The entire project is MIT-licensed at github.com/Mayne-X/thinkgraph. Star it, fork it, break it, fix it. Contributions welcome.

If you want the big-picture overview first, read my introductory article. Or just clone the repo and run python cli/thinkgraph.py triage on your hardest prompt right now.

ThinkGraph forces structured thinking before guessing. Your prompts deserve a foundation, not a hallucination.

38+ Cryptographic Algorithms in Pure Zig - Zero Dependencies, Zero Std Imports

Mayne — Wed, 01 Jul 2026 17:05:36 +0000

I just open-sourced a collection of 38+ cryptographic algorithms written entirely in pure Zig -- zero external dependencies, zero std library imports, zero dynamic allocation.

The repo is called Cryptographic Algorithms for Ziglang and the constraint was simple: every algorithm had to be self-contained with no libsodium, no OpenSSL, no nothing. Just bare Zig.

What is Inside

17 Hash Functions: SHA-256/512, SHA3-256, SHAKE128/256, BLAKE2b, BLAKE3, BLAKE2s, RIPEMD-160/320, Whirlpool, Tiger, MD5, SHA-1, SHA-224/384, Skein-256/512, Grostl-256/512, JH-256/512

6 Symmetric Ciphers: AES-128/256, ChaCha20 + HChaCha20, ChaCha20-Poly1305 (AEAD), TripleDES, Blowfish, Poly1305

5 Password Hashing & KDFs: PBKDF2, bcrypt, scrypt, Argon2id (RFC 9106), HKDF (RFC 5869)

6 Asymmetric Crypto & Key Exchange: RSA (OAEP/PSS, up to 2048-bit), Diffie-Hellman + X25519, ECDSA (secp256k1), EdDSA (Ed25519), BLS (BLS12-381), Schnorr (secp256k1)

4 Post-Quantum Schemes: ML-KEM (Kyber768), ML-DSA (Dilithium65), SLH-DSA (SPHINCS+), NTRU (HPS2048509)

Why This Matters

Zig is gaining traction in systems programming, embedded, and -- critically -- blockchain development. But the Zig ecosystem lacks a comprehensive, self-contained cryptography library. Most projects either link OpenSSL (defeating Zig's cross-compilation advantage) or vendor scattered implementations.

This repo fixes that. Every algorithm lives in a single .zig file with embedded test vectors from RFCs and NIST standards. Run zig test filename.zig and you're done.

The Hard Parts

The "zero std imports" constraint meant writing from scratch:

A 2048-bit BigInt (64 u64 limbs) for RSA and DSA arithmetic
Endianness conversion, bitwise rotation, memory copy -- all hand-rolled
Elliptic curve math for secp256k1, Curve25519, and BLS12-381
NTT polynomial multiplication for ML-KEM and ML-DSA (post-quantum)

No std.mem, no std.math, no std.crypto. It forced a deep understanding of every algorithm.

Blockchain Ready

The algorithm choices are tailored for blockchain work:

secp256k1 ECDSA -- Bitcoin transaction signing
Ed25519 -- Solana and many modern chains
Schnorr -- Taproot upgrade signatures
SHA-256 + RIPEMD-160 -- Bitcoin address derivation
BLS12-381 -- aggregated signatures for consensus

Quick Start

git clone https://github.com/Mayne-X/Cryptographic-Algorithms-for-Ziglang.git
cd Cryptographic-Algorithms-for-Ziglang

# Run all tests
zig build test

# Or test a single file
zig test "Cryptographic Hash Functions/SHA-256.zig"
zig test "Symmetric Key Cryptography/AES.zig"

Requires Zig >= 0.13.

Design Principles

Zero std imports -- every utility is handwritten
Zero dependencies -- pure Zig, no external crates
No dynamic allocation -- all fixed-size stack arrays
Embedded test vectors -- every file tests against known RFC/NIST vectors

Limitations (Honest Ones)

The post-quantum implementations are simplified -- self-consistent but not fully RFC-compliant. BigInt maxes at 2048 bits (enough for RSA-2048, not larger). BLS is a stub with curve constants but no pairing math yet. These are clearly documented.

Get Involved

The entire project is MIT-licensed and available on GitHub at Cryptographic Algorithms for Ziglang. Stars, issues, and PRs welcome.

If you are building a Zig-based blockchain, embedded system, or just want to learn how crypto works under the hood by reading clean Zig code, this repo is for you.

ThinkGraph - Give Your LLM a 50% Accuracy Boost by Building a Fact Foundation First

Mayne — Wed, 01 Jul 2026 17:02:24 +0000

ThinkGraph: Structured Decomposition for LLM Prompts

Every developer using LLMs has experienced this: you ask a complex question, and the model guesses the whole answer at once. It hallucinates details, misses constraints, and assumes facts it should verify first.

ThinkGraph is an open-source skill that intercepts prompts, forces the LLM to decompose them into a dependency graph of atomic facts, resolves those facts sequentially, and then synthesizes a grounded answer.

The result? 50%+ accuracy improvement on multi-hop prompts while actually saving tokens on simple ones.

The Problem: LLMs Guess Whole Answers

Prompt: "Compare React and Vue for a large enterprise dashboard with SSR requirements"

X LLM guesses React is better without checking:
   - SSR maturity of each framework
   - Enterprise adoption rates
   - Team size implications
   - Bundle size trade-offs

The Solution: Build a Foundation First

ThinkGraph adds a 5-stage pipeline before the final answer:

1. Triage

Classify the prompt: trivial? Answer directly (save tokens). Multi-hop/planning? Enter the pipeline.

2. Decompose

Break the prompt into a DAG of atomic sub-questions:

{
  "nodes": [
    {"id": "Q1", "q": "What is React's SSR maturity?", "deps": []},
    {"id": "Q2", "q": "What is Vue's SSR maturity?", "deps": []},
    {"id": "Q3", "q": "Which has better enterprise adoption?", "deps": []},
    {"id": "Q4", "q": "Given Q1-Q3, which is better for a 10-person team?", "deps": ["Q1","Q2","Q3"]}
  ]
}

3. Resolve

Answer each node in topological order. Parallelize independent nodes. Each answer carries a confidence score:

Q1 - React 18+ supports streaming SSR (conf: 0.92)
Q2 - Vue 3 has SSR via Nuxt 3 (conf: 0.88)
Q3 - React is more widely adopted in enterprise (conf: 0.85)

Low-confidence facts (<0.6) can be auto-web-searched via DuckDuckGo - no API key needed.

4. Self-Consistency Vote

Run the synthesis stage 2-3 times, then pick the Jaccard centroid - the response with highest average word overlap with all others.

5. Synthesize

Feed ONLY verified sub-facts into the final prompt.

Token Efficiency

Stage	Max Tokens
Triage	50
Decompose	200
Per sub-question	300
Synthesize	600
Hard ceiling	4x direct answer

Key Design Decisions

No API keys required. The helper CLI does deterministic bookkeeping only.

stdlib only (Python). Zero dependencies.

Works with 6+ agents. OpenCode, Claude Code, Cursor, Codex, Copilot, Gemini CLI.

Quick Start

git clone https://github.com/Mayne-X/thinkgraph.git
cd thinkgraph
python install.py
python thinkgraph.py triage "compare React and Vue for enterprise SSR"
python thinkgraph.py validate-dag graph.json

MCP Server

ThinkGraph also ships as an MCP server (7 tools):

{
  "mcpServers": {
    "thinkgraph": {
      "command": "python",
      "args": ["/path/to/mcp/thinkgraph_mcp.py"]
    }
  }
}

What's Next

CLI interactive mode
Multi-model routing
Streaming DAG emission

Try It

GitHub: github.com/Mayne-X/thinkgraph
MIT License

ThinkGraph forces structured thinking before guessing. Your prompts deserve a foundation, not a hallucination.

I reclaimed 12GB from my SSD with one terminal command (and you can too)

Mayne — Thu, 18 Jun 2026 11:21:50 +0000

I've been a developer for over a decade, and if there's one thing I've learned, it's that our hard drives are basically landfills for build artifacts.

A few weeks ago, I was down to 2GB free on my main SSD. Not because I had tons of important files — but because I had years worth of node_modules folders, .next build caches, dist directories, and other junk scattered across dozens of old projects.

I tried reclaiming space manually. You know the drill — du -sh to find the culprits, then rm -rf them one by one. It works, but it's tedious. I tried npkill — it only handles node_modules. I tried wipe-modules — same limitation. I wanted something that could find everything at once and let me pick what to delete in one go.

So I built ZapDir.

What is ZapDir?

ZapDir is a terminal cleanup tool that scans your projects for heavy build artifacts and lets you delete them through a beautiful interactive interface. It's completely free, open-source under MIT, and runs on Windows, macOS, and Linux with Node.js 18+.

npm install -g zapdir
zapdir

Run that, and you'll see something like this:

⚡  ZapDir  —  Terminal Cleanup Tool

  🗑  Junk Found — Total recoverable:  1.47 GB

  ██████████  node_modules    /node_modules      245.23 MB
  ██████░░░░  .next           /.next               1.23 GB
  ██░░░░░░░░  dist            /dist                89.45 MB

  ✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes

  ✔  Freed 1.47 GB of disk space!

The colored size bars make it obvious what's eating the most space at a glance — red for anything over 500MB, yellow for over 100MB, and green for the rest.

What makes it different from npkill or wipe-modules?

There are other cleanup tools out there, but most of them only handle one pattern. Here's how ZapDir compares:

Feature	ZapDir	npkill	wipe-modules
Patterns detected	13+	1 (node_modules)	1 (node_modules)
Interactive TUI	✅	✅	❌
Color-coded sizes	✅	❌	❌
Dry-run preview	✅	❌	❌
Async scanner	✅	❌	❌
Cross-platform	✅	✅	✅

ZapDir detects: node_modules, .next, .nuxt, .turbo, dist, build, .cache, coverage, out, target, .parcel-cache, __pycache__, and .DS_Store.

What it found on my machine

I ran ZapDir across my development machine and here's what turned up:

Location	What was there	Space recovered
~/Projects/legacy-app	`node_modules` + `.next`	1.8 GB
~/Projects/side-project	`node_modules` + `build`	640 MB
~/Projects/old-tutorial	`node_modules`	420 MB
~/.cache	Various caches	340 MB
Various Rust projects	`target/` directories	2.1 GB
Old Next.js projects	`.next` caches	3.4 GB
Abandoned monorepos	`node_modules` × 5	2.2 GB
Python projects	`__pycache__` + `.cache`	180 MB

Total reclaimed: roughly 12 GB

That's 12 GB I got back without touching a single file I actually needed. The biggest wins were old Next.js projects with massive .next caches (some over 1 GB each) and Rust projects where target/ directories had accumulated to over 2 GB combined.

Is it safe?

Short answer: yes, if you use --dry-run first.

zapdir --dry-run ~/Projects

This scans and shows you exactly what would be deleted without actually removing anything. The output shows every item with its size, path, and a visual bar so you know exactly what you're getting into.

When you're satisfied with the preview, run it without the flag. You'll be prompted to confirm before anything is deleted:

✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes / No

The scanner uses fs.promises.readdir with async parallel traversal for speed, and deletion is done with Promise.allSettled so a permission error on one file won't crash the entire operation — it just skips that file and continues. I've been using it for weeks and haven't lost a single file I needed.

How the scanning works

The core logic is surprisingly straightforward. It walks directories recursively using Node.js's built-in fs.promises, matches directory names against a list of known artifact patterns, calculates sizes using a streaming iterator (to avoid memory issues on huge folders), and presents everything in an interactive selection menu powered by @clack/prompts.

Hidden directories like .git are skipped by default for speed. The entire scan of my home directory — thousands of folders — completes in under 10 seconds.

A practical tip

Here's what I do now: once a month, I run:

zapdir --dry-run ~/Projects

This gives me a quick health check of how much junk has accumulated. When the number crosses 1 GB, I run it for real and reclaim the space. It's become part of my regular maintenance routine, right alongside brew update and npm outdated.

Give it a shot

If you're running low on disk space and have old projects lying around, try it:

npm install -g zapdir
zapdir

It takes five seconds to install and could free up gigabytes. The code is open source under MIT, so you can inspect exactly what it does before running it.

⭐ Star the repo on GitHub if you find it useful — it helps other developers discover it too.

ZapDir is MIT licensed and open source. Contributions, feature requests, and bug reports are welcome on GitHub.

Blazing-fast terminal cleanup tool for heavy build artifacts

Mayne — Thu, 18 Jun 2026 08:45:25 +0000

I've been a developer for over a decade, and if there's one thing I've learned, it's that our hard drives are basically landfills for build artifacts.

So I built ZapDir.

What is ZapDir?

npm install -g zapdir
zapdir

Run that, and you'll see something like this:

⚡  ZapDir  —  Terminal Cleanup Tool

  🗑  Junk Found — Total recoverable:  1.47 GB

  ██████████  node_modules    /node_modules      245.23 MB
  ██████░░░░  .next           /.next               1.23 GB
  ██░░░░░░░░  dist            /dist                89.45 MB

  ✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes

  ✔  Freed 1.47 GB of disk space!

The colored size bars make it obvious what's eating the most space at a glance — red for anything over 500MB, yellow for over 100MB, and green for the rest.

What makes it different from npkill or wipe-modules?

There are other cleanup tools out there, but most of them only handle one pattern. Here's how ZapDir compares:

Feature	ZapDir	npkill	wipe-modules
Patterns detected	13+	1 (node_modules)	1 (node_modules)
Interactive TUI	✅	✅	❌
Color-coded sizes	✅	❌	❌
Dry-run preview	✅	❌	❌
Async scanner	✅	❌	❌
Cross-platform	✅	✅	✅

ZapDir detects: node_modules, .next, .nuxt, .turbo, dist, build, .cache, coverage, out, target, .parcel-cache, __pycache__, and .DS_Store.

What it found on my machine

I ran ZapDir across my development machine and here's what turned up:

Location	What was there	Space recovered
~/Projects/legacy-app	`node_modules` + `.next`	1.8 GB
~/Projects/side-project	`node_modules` + `build`	640 MB
~/Projects/old-tutorial	`node_modules`	420 MB
~/.cache	Various caches	340 MB
Various Rust projects	`target/` directories	2.1 GB
Old Next.js projects	`.next` caches	3.4 GB
Abandoned monorepos	`node_modules` × 5	2.2 GB
Python projects	`__pycache__` + `.cache`	180 MB

Total reclaimed: roughly 12 GB

Is it safe?

Short answer: yes, if you use --dry-run first.

zapdir --dry-run ~/Projects

When you're satisfied with the preview, run it without the flag. You'll be prompted to confirm before anything is deleted:

✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes / No

How the scanning works

Hidden directories like .git are skipped by default for speed. The entire scan of my home directory — thousands of folders — completes in under 10 seconds.

A practical tip

Here's what I do now: once a month, I run:

zapdir --dry-run ~/Projects

Give it a shot

If you're running low on disk space and have old projects lying around, try it:

npm install -g zapdir
zapdir

It takes five seconds to install and could free up gigabytes. The code is open source under MIT, so you can inspect exactly what it does before running it.

⭐ Star the repo on GitHub if you find it useful — it helps other developers discover it too.

ZapDir is MIT licensed and open source. Contributions, feature requests, and bug reports are welcome on GitHub.

PyChase: AST-Powered Duplicate Code Detection for Python

Mayne — Thu, 18 Jun 2026 04:49:03 +0000

The Problem: Hidden Code Duplication

Every codebase accumulates copy-paste clones. They start innocently — "I'll just duplicate this function and tweak it" — but over months they compound into a maintenance tax. When a bug is fixed in one copy, the other 5 copies stay broken. When a feature needs to change, you hunt down every variant by hand.

Traditional duplicate detectors fall into two camps:

Line-based tools (Duplo, Simian) — compare raw text, miss everything after variable renaming
Token-based tools (jscpd, PMD CPD) — slightly better, but still fail when identifiers change
Generic AST tools (SonarQube) — heavy infrastructure, Python support is an afterthought

PyChase takes a different approach: normalized AST fingerprints with MinHash + LSH.

What PyChase Catches

Clone Type	Description	Example	PyChase
Type-1	Exact copy-paste	Same code, same names	✅ 1.000 score
Type-2	Renamed identifiers	`calculate_total` → `compute_sum`	✅ 0.786 score
Type-3	Modified logic	Added/removed statements, reordered	✅ 0.620 score

How It Works

1. Parse to AST

Each .py file is parsed into a Python Abstract Syntax Tree using the standard ast module.

2. Normalize

Variable names, function names, attribute names, string literals, numbers, and docstrings are replaced with generic placeholders. This strips everything except structure:

# These two produce the SAME normalized AST:
def calculate_total(items, rate):
    subtotal = 0
    for item in items:
        subtotal += item.price
    tax = subtotal * rate
    return subtotal + tax

def compute_sum(products, factor):
    result = 0
    for product in products:
        result += product.cost
    fee = result * factor
    return result + fee

3. Shingle

The normalized AST node sequence is broken into overlapping k-shingles (default k=3):

(FunctionDef, arguments, arg) → (arguments, arg, Add) → ...

4. Fingerprint + Match

Each shingle set becomes a structural fingerprint. MinHash signatures compress these into compact 256-bit signatures. Locality Sensitive Hashing (LSH) indexes them — only units sharing a bucket are compared.

This reduces candidate pairs from O(n²) to nearly O(n). For 10,000 functions, that's 50 million comparisons avoided.

5. Cluster + Report

Connected-component clustering groups related matches. Results render as text, JSON, CSV, or an interactive HTML report with collapsible groups and syntax-highlighted code previews.

Quick Start

pip install pychase

# Scan your project
pychase .

# Generate HTML report
pychase --format html --output duplicates.html .

# JSON output for CI
pychase --json --threshold 0.85 ./src

Why MinHash + LSH Matters

Tools like dry4python compare every function against every other function — O(n²). With 10,000 functions, that's 50 million comparisons. PyChase's MinHash + LSH approach reduces this to near-linear time, making it viable for large monorepos and CI pipelines.

Comparison at a Glance

Tool	Algorithm	Clone Types	Setup	Output
PyChase	MinHash+LSH (O(n))	Type-1,2,3	`pip install`	Text, JSON, CSV, HTML
dry4python	Brute-force (O(n²))	Type-2 only	`pip install`	Text, JSON
jscpd	Token hash	Type-1,2	Node.js	Text, JSON, HTML
SonarQube	Custom AST	Type-1,2	DB + server + scanner	Web dashboard

Try It

pip install pychase
pychase --threshold 0.55 --min-lines 2 --min-nodes 10 ./src

GitHub: https://github.com/Mayne-X/PyChase

Docs: https://github.com/Mayne-X/PyChase/wiki

PyPI: [https://pypi.org/project/pychase/]