Ciphey: A* search over sixteen decoders instead of a neural network in the loop

Two tools with one name and a deliberate replacement

The README opens by saying ciphey is the next generation of decoding tools, built by the same people that brought you Ciphey, and then states flatly that the intent is to replace the original Ciphey with it. That matters because the repository carries both histories. The releases list `v0.12.1` from 2026-08-31 alongside `5.14.0` from 2021-06-06 and `5.13.0` from 2021-05-23, and those two older tags are from the Python project, where the release notes mention `pywhat` requirements and a move away from `yaspin`.

So when you read a benchmark claim in the README, check which tool it describes. The comparison section says the Rust version does roughly seven decodes for every one the old Ciphey manages, a 700% increase, and attributes the old tool's slowness to needing artificial intelligence to decide whether to try Caesar next or Base64 first. The new one's answer to that problem is algorithmic rather than learned.

The repository is Rust, MIT licensed, with 21,622 stars, 1,442 forks and only 12 open issues, last pushed on 2026-09-18. The package description in `Cargo.toml` is precise: Automated decoding tool, Ciphey but in Rust, edition 2021, version 0.12.1.

How the A* search replaces the old decision model

This is the section worth reading twice, because it is the actual invention. The heuristic in an A* search estimates the cost of reaching the goal from the current state, and ciphey's goal is text that looks like language rather than ciphertext.

The pieces fit together like this. Very fast decoders such as Base64 are run first at every node, with the heuristic ignored for them. For the remaining decoders the heuristic comes from `cipher_identifier`, which gives a probability that a given string is a particular cipher. Previous results go into a cache so the same path is not recomputed, and the search tree is pruned to keep memory usage down as it grows.

Two dynamic behaviours make it more than a static search. Decoder statistics are tracked over time, so a popular decoder like Caesar gets prioritised over a rarer one like Beaufort, and popular pairs are tracked too, with base64 leading to base64 named as a common case worth trying early. Between them these turn a naive tree walk into something that gets faster as it is used, which is also why the README describes storing statistics in a database, wired in through `rusqlite` with the `bundled` feature.

Nothing about that loop requires a model. The decoder list in `Cargo.toml` is the concrete surface: `base64`, `base65536`, `base91`, `bs58`, `data-encoding`, `urlencoding`, `z85` and `brainfuck-exe`, with Vigenere, Atbash and Braille added as dedicated implementations elsewhere in `src/`.

Plaintext detection, the sensitivity knob and the optional 500MB model

Search needs a goal function, and ciphey's is a probability that a string is plaintext. Three mechanisms contribute. A qudgaram, trigram and English dictionary checker calculates that probability, with thresholds that change depending on the cipher, on the reasoning that Caesar output looks English-like while Base64 output does not. A database of around 500 popular regexes recognises API keys and MAC addresses, which is a useful signal that a decoded string is a credential rather than prose. And an `is_password` function checks whether a string is an exact password seen in a data dump.

There is also a manual dial. Configurable sensitivity for gibberish detection lets you set Classical ciphers like Caesar to Low sensitivity while most other decoders default to Medium, and the README frames this as reducing both false positives and false negatives across different kinds of encoded text.

Then there is the model, and it is opt-in. Enhanced detection uses a BERT-based model from the `gibberish-or-not` crate, which the README credits with roughly 40% better plaintext detection accuracy. Enabling it costs a one-time 500MB model download and requires a free Hugging Face account. It can be turned on during first-run setup or later with a flag:

ciphey --enable-enhanced-detection

That is the right shape for an optional model: the tool works without it, and you find out the size and the account requirement only if you want the accuracy.

LemmeKnow, Rayon, and why multi-level decoding came back

Two dependencies solve problems the old Python tool could not.

`lemmeknow` at 0.8.0 is the Rust port of PyWhat, used to identify whether a decoded string is an IP address, a domain, a crypto wallet and so on. The README claims it is 33 times faster than the Python version, and turns that into a claim of 3300% faster identification. This is the feature that makes ciphey useful on non-ciphertext input: real log lines and configuration dumps are mostly recognisable tokens, and identifying them quickly is what stops a search down the wrong branch.

Multithreading is handled by `rayon` at 1.12.0, which the README describes as one of the fastest multithreading libraries around. It is honest about the payoff: with only sixteen decoders, most of which are fast, the speedup is not visible yet, and the expected benefit arrives as slower decoders get added.

Multi-level decoding is the third. A path like Rot13, then Base64, then Rot13 is supported because the tool is fast enough, and the README notes a plan to turn it off eventually, which tells you the search space grows faster than the pruning can control it. Combined with the timer, which defaults to 5 seconds in the CLI and 10 in the Discord bot to account for network lag, you get a tool that gives up rather than spinning. The old Ciphey's inability to stop is called out as one of its main problems.

Using it: Discord, cargo, Docker

The README ranks three ways to use it, and the ordering is a small opinion about what the project is for.

The first is the Discord server, where you join the #bots channel and call it with `$ciphey`, with `$help` for the rest. The second is the CLI, installed from source with cargo:

cargo install ciphey

and then called simply as `ciphey`. The third is building the image yourself, and the `justfile` names that image and the architectures it is published for:

docker buildx build --platform linux/arm/v7,linux/amd64,linux/arm64/v8 -t autumnskerritt/ciphey:latest --push .

The `Dockerfile` is a two-stage build that compiles in `rust:alpine` with `build-base`, `pkgconfig` and `openssl-dev`, then copies the release binary into `alpine:3.12` with `ciphey` as the entrypoint. That base image is old enough to be worth noting if you hit an Alpine compatibility problem, since it has not moved in years.

For development there is a `justfile` rather than scattered commands, and it is worth reading because it shows how the project is built and tested. `test-all` runs `cargo build`, `cargo check`, `cargo clippy` and `cargo test`; the individual `test` target uses `cargo nextest run`; and `fix-all` runs clippy with `--fix`, formats, runs the suite, and commits twice under the message Clippy and fmt. Publishing uses `docker buildx` across `linux/arm/v7`, `linux/amd64` and `linux/arm64/v8`. Benchmarking uses `criterion` at 0.8.2 and there is a `benches/` directory, and the release profile sets `lto = "fat"`, `panic = "abort"` and symbol stripping.

Sixteen decoders out of fifty, and a Brainfuck fix

The README states that ciphey supports 16 decoders, that Ciphey supported around 50, and that more are being added, with issue 61 linked as the tracking list. That gap between 16 and 50 is the honest headline of the project, and it is also the gap that makes multi-level decoding and A* pruning less necessary than they will be.

The rest of the README is candid in a way most projects are not. It says the TUI is entirely vibe coded, in a section titled AI Use. It says AI was used to research CTF challenges, producing a list of 15,071 of them, then to scan the writeups for anything about encoding and decoding, and then to build tests from those. That is a genuinely interesting account of how a test corpus was built at a scale a person would not attempt, and it also means a meaningful fraction of the suite's cases are derived from other people's writeups rather than from first principles.

The v0.12.1 release is a good sample of what maintenance looks like here. It bounds the Brainfuck interpreter to 1,000,000 executed instructions so that a non-terminating program fails through the decoder's existing error path instead of hanging, adds a regression test for exactly that, and restores the `rand 0.8` and `half 2.3.1` pins that `candle-core 0.3.3` needs, which repaired cross-platform builds broken by later dependency updates. A DoS report credited to a named researcher is acknowledged in the notes. For a tool that executes arbitrary attacker-supplied bytecode-looking input, a fix like that is not a nicety.

The gap to watch is between what the README advertises and what the decoder list delivers. Sixteen decoders, a search that prunes itself, and a plaintext scorer that decides when to stop are enough to be useful today. The remaining thirty-four, if and when they land, are what turn it into a replacement for the original tool rather than a faster front end for the easy cases.

Editorial conclusion

Ciphey is worth installing if your problem is a string of unknown encoding on a screen, a CTF challenge, or a suspicious token that might be Base64 three times over. It is not a cryptanalysis tool: A star search over sixteen decoders with a plaintext scorer will not recover a key for AES, and the README's claims about cracking hashes are broader than the decoder list supports. Its real strength is the design decision of removing AI from the inner loop, with an optional 500MB BERT model from `gibberish-or-not` available when you want better plaintext detection and a free Hugging Face account to get it. Install it with `cargo install ciphey`, try it on a known double-encoded string to see the decoder chain printed, and note that sixteen of the roughly fifty promised decoders exist today, with the missing ones tracked in issue 61.

Frequently asked questions

Official sources

1. bee-san/Ciphey on GitHub
2. Issues
3. License: MIT
4. README
5. Releases