Slopo: embedding-based duplicate detection for codebases that outgrew review
Embedding-based code duplication detector
At a glance
- What is it?
- Slopo is a Python CLI that embeds source files and clusters the ones whose vectors sit close together, then ranks those clusters by how far apart the code lives. It is built to feed AI coding agents a shortlist of likely duplicates, not to replace a linter.
- Who is it for?
- Adopt Slopo if your repository is large enough that a coding agent cannot hold the whole thing in context and you are already paying for an agent workflow, since the README argues embedding API calls cost far less than agent tokens. Skip it if you want deterministic, exact-match duplication checking, if you cannot send source code to an external embedding provider, or if your project is small enough that an agent already sees the related code by following references.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The duplication class that exact-match tools miss
Slopo targets a specific failure mode. Two pieces of code implement the same behaviour, are not copy-pasted, and do not share identifiers, so neither a text diff nor a symbol-based clone detector flags them. The README frames this as the case where an AI agent, working from the files it currently has open plus whatever it can reach by following references and matching names, simply never encounters the existing implementation and writes a second one. The tool's stated purpose is to close that gap by comparing meaning rather than text across the entire repository. The audience is narrow and explicit: developers using AI coding agents on large or loosely structured codebases. The README also names a second use case, whole-repository analysis for refactoring and maintenance, and a first use case, reviewing uncommitted changes against the rest of the codebase before committing. Ten languages are listed as supported: Python, TypeScript, JavaScript, Java, Kotlin, C#, Go, Rust, PHP and Elixir.
Embeddings, cosine proximity, and a distance-weighted ranking
The mechanism is described plainly in the README. An embedding model converts a code snippet into a vector; snippets with similar meaning produce vectors that are close together. Slopo treats proximity between vectors as a signal of potential duplication, regardless of how differently the two snippets are written. What distinguishes the ranking from a plain similarity sort is the second axis. Slopo also measures how far apart the two snippets sit in the codebase, whether in different modules or separated inside one large file, and raises the priority of pairs that are further apart. The output is clusters of similar code ordered by similarity and by that distance. The README is direct about what the clusters are for: they are input for a coding agent, which then decides whether a cluster is a genuine duplicate. Slopo does not make that final call itself. That division of labour is the design, and it means the tool's value depends on an agent being present to triage the output. The README points to an example report generated from Slopo's own src directory at git tag v0.2.0.
Installing with uv and configuring a model provider
Installation goes through uv, which the README notes installs Slopo from PyPI into an isolated virtual environment so Python does not need to be installed separately. The two commands are uv tool install slopo and, for updates, uv tool upgrade slopo. The README states there are no automatic updates or notifications, so the upgrade command is the only path to a newer version. Setup is a single command, slopo init, which writes a config file template containing further instructions. According to the README, only two things are strictly required in that config: the directory holding the code to analyse, and the embedding model configuration. On model choice, the README recommends Jina AI for code-focused models available both via API and for local use, and Voyage AI, but only its general-purpose model, since the README says Voyage's code-focused models are not suitable here. Jina issues API keys with free tokens for non-commercial use without registration, though the README notes free tokens are not always granted and speculates this is IP-based abuse prevention, labelling that a guess rather than official information. It also warns that Jina's API sometimes delays the first request while servers start. For local inference, the README names Ollama running jina-embeddings-v2-base-code, a small model that runs on CPU but may be significantly slower than the API depending on hardware. Any provider supported by LiteLLM can be configured, and any OpenAI-compatible server is supported. The README includes one explicit warning about model configuration: do not use higher embedding dimensions. The truncated text cuts off mid-sentence there, so the reasoning behind that warning is not available in the supplied material.
The dependency on an agent, and the cost argument behind it
Slopo's pitch rests on a claim about token economics that the README states but does not quantify: API access to embedding models costs practically nothing compared to the models used in AI agents, and if an agent receives a report of already-found duplicates it does not spend tokens locating them itself. The README hedges appropriately, saying total cost and token usage should reduce. There is a second, less obvious argument about precision. Coding agents, per the README, perform best on one focused task, and a cluster of similar code paired with a focused instruction is exactly that shape. The agent loads only relevant data into context, which the README says reduces the chance of drifting or missing something. Both arguments assume you already run an agent. Without one, Slopo still produces clusters, but the triage step that separates real duplicates from coincidental similarity falls to a human reading a report. The README does not describe a built-in interactive triage mode, so that workflow is unverified from the material available.
Where Slopo is the wrong tool
The clearest limitation is structural: Slopo detects similarity, not duplication, and it says so. Two snippets can be semantically close and still be legitimately separate, and the tool pushes that judgement downstream. If your team wants a deterministic answer, a clone detector operating on syntax trees or token sequences gives one without an API call. A second constraint is data egress. The recommended path sends source code to Jina or Voyage, and while the Ollama route keeps inference local, the README notes that model may be significantly slower on CPU depending on hardware. For repositories where sending source to a third party is not acceptable, the local option is the only one, and its throughput is unstated in the material. Third, the tool is a semantic layer over an existing workflow, not a replacement for one. If your project is small, or well structured enough that an agent finds related code by following references, the README's own framing suggests the blind spot Slopo addresses may not exist in your repository. Fourth, the free Jina tier is explicitly unreliable in the README's account, and the author admits the reason is a guess. Building a workflow on that tier carries a risk the documentation does not resolve.
How this differs from syntax-based clone detection
The natural comparison is a classical clone detector such as jscpd or PMD's CPD, which normalise tokens or syntax trees and report matches above a threshold. Those tools are deterministic, run offline, cost nothing per scan, and produce no false positives from shared meaning alone, because they only match shared structure. Their blind spot is exactly Slopo's target: a reimplementation that shares no tokens with the original. Slopo inverts the trade. It catches the case token-based tools cannot see, at the price of a model provider dependency, per-scan inference cost, and a result set that requires judgement to filter. The two are complements rather than substitutes, and the README's own positioning supports that reading, since it concedes agents already catch much ordinary duplication and presents Slopo as covering the remainder. Choosing between them is really a question of what your review process already catches. If exact clones are your problem, a token-based tool answers it with less infrastructure.
Licence, maintenance, and the upgrade path
Slopo ships under AGPL-3.0, which matters more here than for a library you link against, because the AGPL's network clause applies to software offered over a network. Running slopo as a CLI on your own machine is the documented use, and the README describes nothing else. If you were to wrap Slopo in an internal service that other people interact with over a network, the licence terms would need review by someone qualified to give that advice, which this article is not. On maintenance, the release cadence visible in the material is tight: v0.5.1 on 22 August 2026, v0.6.0 on 25 August, and v0.7.0 on 3 September, with the last push to the default branch on 6 September 2026. That is three releases in under two weeks, which suggests active work but also a moving target. The README is explicit that there are no automatic updates or notifications, so uv tool upgrade slopo is a manual step, and the config template written by slopo init may change between versions. The project is not archived. A config file generated by an older version is worth re-checking against the template after an upgrade, since the README gives no compatibility promise for it.
Editorial conclusion
Adopt Slopo if your repository is large enough that a coding agent cannot hold the whole thing in context and you are already paying for an agent workflow, since the README argues embedding API calls cost far less than agent tokens. Skip it if you want deterministic, exact-match duplication checking, if you cannot send source code to an external embedding provider, or if your project is small enough that an agent already sees the related code by following references. Before committing, run slopo init, confirm which embedding provider your config points at, and check the dimensionality guidance in the generated config template, because the README warns against higher embedding dimensions and that setting is easy to get wrong on the first try.
Community notes