This Word Does Not Exist: a two-model GPT-2 dictionary for generating fake words and definitions
This Word Does Not Exist
At a glance
- What is it?
- The project trains a forward GPT-2 model that maps a made-up word to a definition and an inverse model that maps a definition back to a word, with a blacklist filter in between. It is a research artefact you run from a Python class, not a packaged service.
- Who is it for?
- Adopt it if you want a small, self-contained GPT-2 pair for generating neologisms and their definitions, and you are comfortable wiring up three downloaded model files and a WordGenerator instance yourself. Do not adopt it if you need a maintained inference server, a stable API surface, or a training corpus you can ship without checking Apple dictionary and Urban Dictionary terms first.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 91 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 problem: inventing a word and a definition that agree with each other
Generating a plausible nonce word is easy. Generating a nonce word and a definition that reads as if a lexicographer wrote both is harder, because the two halves have to be consistent. The README states the project "allows people to train a variant of GPT-2 that makes up words, definitions and examples from scratch", and the sample output it gives is a noun, incromulentness, glossed as "lack of sincerity or candor" with the usage line "incromulentness in the manner of speech". That pairing is the whole point.
The audience is narrow. It suits someone who wants to run a demo site, a bot account, or a dataset of invented lexical entries, and who is willing to train or download models rather than call a hosted endpoint. The repository topics list gpt-2, transformers and natural-language-generation, which is a fair description of the machinery. Nothing in the README suggests a library for general text generation. The output is a dictionary entry, and the code is organised around that shape.
Two GPT-2 models pointing in opposite directions, plus a blacklist
The architecture is a pair of fine-tuned GPT-2 checkpoints. The README labels them plainly: the "Forward Model (word -> definition)" and the "Inverse model (definition -> word)". A third artefact, blacklist.pickle.gz, is a filter. The three are distributed as separate downloads from a Google Cloud Storage bucket, and the WordGenerator constructor takes a path for each: forward_model_path, inverse_model_path and blacklist_path.
The data flow through the public API is direct. generate_word() produces a word from scratch. generate_definition("glooberyblipboop") takes a word you supply and returns a definition. generate_word_from_definition("a word that does not exist") runs the inverse direction. The blacklist sits in that loop to keep the models from emitting entries that already exist or that should not be surfaced, which is why it is a required constructor argument rather than an optional one. The device argument is set to "cpu" in the README example, and quantize is a boolean, so the same class can run on a smaller footprint if you accept the accuracy trade-off that quantisation normally implies. The README does not state how much accuracy is lost.
Getting it running: a class, three paths, and a website dev server
Inference needs the Python dependencies pinned in cpu_deploy_environment.yml, plus the three model files. The README gives the import and construction exactly:
from title_maker_pro.word_generator import WordGenerator word_generator = WordGenerator(device="cpu", forward_model_path="<somepath1>", inverse_model_path="<somepath2>", blacklist_path="<blacklist>", quantize=False)
Then print(word_generator.generate_word()), print(word_generator.generate_definition("glooberyblipboop")) or print(word_generator.generate_word_from_definition("a word that does not exist")). There is no CLI documented in the README. The entry point is the class.
The website under ./website is a separate application. The README's instructions are cd ./website, pip install -r requirements.txt, pip install aiohttp-devtools, then adev runserver. That is a development server, and the README does not describe a production deployment path for the site, so treat adev as a local preview rather than a serving story. The homepage at thisworddoesnotexist.com is the hosted demo, and the README also points to a Twitter bot at robo_define.
Training means sourcing a dictionary you may not have the right to redistribute
The training path is the least finished part of the project, and the README says so in its own way by pointing to notebooks as "raw thoughts". Two extraction routes are offered. title_maker_pro/dictionary_definition.py pulls from Apple dictionaries, with a path example under /System/Library/Assets/com_apple_MobileAsset_DictionaryServices_dictionaryOSX/. That path exists on macOS, which makes the extraction step platform-bound. The second route is title_maker_pro/urban_dictionary_scraper.py, which scrapes Urban Dictionary.
Both sources carry terms of use that the repository does not resolve for you. If you train on Apple dictionary content or scraped Urban Dictionary entries and then publish the resulting model weights, you are the one making that call. The MIT licence on the code does not travel with the training data. That distinction matters more here than in a typical repository because the training corpus is the product.
Once a dictionary is extracted, title_maker_pro/train.py is the master training script, and scripts/sample_run_parsed_dictionary.sh is given as a sample recent run. The README does not publish hardware requirements, wall-clock training time, or a corpus size, so the cost of reproducing the released checkpoints is unknown from the material available.
Where it breaks: distribution, drift, and the wrong use case
The model files live on a public storage bucket rather than a package registry. There is no release history in the material retrieved for this repository, so there is no versioned artefact to pin and no changelog describing what changed between checkpoint revisions. The filenames carry a v1 suffix, which suggests the authors version by filename, but nothing states a compatibility contract between a checkpoint and a given code revision. If the bucket entries move or are removed, the documented setup stops working and there is no fallback path in the README.
The blacklist is a pickle file. Loading a pickle means executing whatever the file instructs the interpreter to run, so a blacklist fetched from a network location is a trust decision, not a data decision. That is a property of the format, not a criticism of this project specifically, but it is worth knowing before pointing blacklist_path at a URL you downloaded.
It is also the wrong tool for several jobs. If you want a general-purpose text generator, a dictionary-entry model is a poor fit. If you need deterministic output, sampling-based generation will not give it to you. If you need definitions of real words, this is the opposite of what it does. And if you need a supported service with an SLA, a repository whose README routes you to notebooks for training details is not that.
What a general LLM API does differently
The obvious alternative is a hosted large language model prompted with a definition-writing instruction. The difference is not quality, it is structure. A prompt-based approach uses one model for both directions: you ask for a word and a definition in a single call, and the consistency between them comes from the prompt and the model's context. This project instead splits the task across two fine-tuned GPT-2 checkpoints, one per direction, and adds a blacklist stage that a prompt cannot easily replicate because the filter is a separate artefact rather than an instruction.
That split has a practical consequence. Two small checkpoints can run on a CPU, which the README's device="cpu" example and the cpu_deploy_environment.yml file both indicate is a supported configuration. A hosted API moves the compute off your machine but adds a network dependency and per-call cost. The trade is control and offline operation against convenience and model capability. If your goal is a bot that posts one invented word every few hours, either works. If your goal is to study how a small model learns the word-definition mapping, the two-checkpoint design is the more inspectable one, because you can query each direction independently.
Maintenance cost and what the MIT licence does and does not cover
The repository is not archived and the last push recorded is 2026-06-17, so it is still being touched. There are no retrieved releases, which means upgrades are a matter of pulling master and re-downloading checkpoints rather than bumping a version. For a project of this shape, the recurring costs are the model downloads, the Python environment from cpu_deploy_environment.yml, and whatever you spend re-extracting a dictionary if you retrain. The README does not describe a migration path between checkpoint versions, so assume that a code change and a checkpoint change are coupled until you verify otherwise.
The MIT licence covers the source code in the repository. It does not grant rights over Apple dictionary content or Urban Dictionary content that the extraction scripts read, and it does not automatically cover the pre-trained weights hosted on the separate storage bucket, because those are not files in the repository. If you plan to redistribute a fine-tuned model, check the terms attached to the training source separately. This is a description of what the licence text does and does not reach, not legal advice.
Editorial conclusion
Adopt it if you want a small, self-contained GPT-2 pair for generating neologisms and their definitions, and you are comfortable wiring up three downloaded model files and a WordGenerator instance yourself. Do not adopt it if you need a maintained inference server, a stable API surface, or a training corpus you can ship without checking Apple dictionary and Urban Dictionary terms first. Before committing, verify that the forward, inverse and blacklist artefacts at the storage.googleapis.com paths in the README still resolve, and confirm the quantize flag you intend to use on your target device.
Community notes