Two twenty-character IDs, and a dictionary nobody documents

Two program IDs, and an install that adds an index

The dependency does not come from the default package index. The install line names an extra index URL alongside the package name:

pip install programasweights --extra-index-url https://pypi.programasweights.com/simple/

That is the first thing to notice, because it means the distribution lives on a host the project controls rather than on PyPI proper. Once installed, the whole API surface used in the example is two calls and two prints:

import programasweights as paw

to_claudish = paw.function("ca9d5165b6c8e6615529")
to_english = paw.function("e469f61ccab2699fbd51")

print(to_claudish("Only owners can merge."))
print(to_english("The honest shape is asymmetric: the data is correct; the format is hard to read. Correctness landed; legibility did not."))

Each call loads a program by a twenty-character hexadecimal ID and returns something callable, one ID per direction, and both are called tiny. The dependency file at the repository root contains exactly one line, naming that one package, so there is no second library to learn. The result is a project whose Python footprint is a single import and two identifiers.

Download once, run locally, and pass no token limit

The runtime contract is three sentences long and the third is the interesting one. The programs download once and then run locally, so the hosted hub is a distribution point rather than an inference service. The instruction is to pass no max_tokens, on the grounds that the runtime stops naturally at EOS. That is a negative instruction where you would normally expect a parameter, and it is the kind of detail that matters: a small program asked to rewrite one sentence does not need a budget, and setting one introduces a truncation mode that the project has chosen not to expose. It also means the natural end of the output is defined by the program rather than by the caller, which is why the same call can be used in both directions without tuning.

The two example sentences reveal what each direction expects

The Python example is short enough to read as documentation. The English to Claudish direction is handed a single declarative sentence about who can merge, and the reverse direction is handed something much longer: a paragraph-level observation that the data is correct while the format is hard to read, that correctness landed and legibility did not. The command line examples push the same asymmetry further, with a release approval sentence in one direction and a paragraph about holding a line until tests pass in the other. So the short input goes in, the long input comes out. That is the one piece of real evidence in the repository about what the two programs are tuned for, and it suggests the register is verbose and the English is terse, which is the opposite of what the name implies.

A dictionary directory, and no mention of it anywhere

The repository has eight top-level entries and one of them is a dictionary folder. The README never refers to it. It also does not describe translate.py beyond the two command lines in the usage section, so the wrapper is shown being used without ever being explained, and it does not say whether the dictionary is a lookup table, generated output, or a hand-maintained lexicon. For a project whose entire subject is a vocabulary, that is the first directory a reader would open and the last one the documentation mentions. The honest summary is that the README documents the hosted programs, the install, and the specs, and leaves the local artefacts to be inferred from the file list.

The specs are the part meant to travel

Two spec files sit in a specs directory, one for English to Claudish and one for the reverse, and the README is explicit about their purpose: copy either spec into your own PAW program, or adapt it for another model or workflow. That sentence reframes the project. The two program IDs are hosted conveniences, while the spec is the durable artefact, and the instruction to adapt it for another model says so directly. It also means the project is not trying to be a dependency. Nothing in the README asks you to import Claudish in production code; it asks you to take a description of the register and build your own version of it, which is a different kind of contribution from the usual.

Credited, disclaimed, and released under MIT

The provenance paragraph is short and does two jobs. It credits gvzdv/claudish-to-english as the inspiration, which is worth noting because the credit runs in one direction only, from this project back to a prior repository. And it states that this is an unofficial parody project and is not affiliated with Anthropic, which matters given what the name is a play on. The project is licensed MIT with the licence text at the repository root, and a .github directory sits alongside it. There are no GitHub releases at all, so the only way to obtain the programs is by their IDs, and the last push to the main branch is dated August 29, 2026.

The README describes Claudish with one adjective

What Claudish actually is gets one word in this repository: deliberately over-engineered. The rest of the definition is delegated. Plain English is the other side of the pair, so the project is a translator between two registers rather than a specification of a language, and the demonstration of what the over-engineered side looks like is carried by four sample sentences and a hosted demo rather than by a grammar, a syntax section, or a worked example with output shown. That is a legitimate choice for a parody, and it is also the limit of what the README can tell you. Anyone who wants to know the rules has two places to go, the two spec files and the demo, and the repository points at both without previewing either.

Editorial conclusion

Claudish suits you if you want to see what a deliberately over-engineered register looks like as a working bidirectional translator, and you are willing to read the spec files rather than the README for the actual definition. It does not suit you if you need a documented language with a grammar, because the README describes the register in one adjective and leaves the rest to the demo. Before building on it, read both spec files, and note that this is an unofficial parody with no releases and a last push dated August 29, 2026.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository