# pohuy: an agent style project whose own numbers file reports zero tokens saved

> A TypeScript project that installs a deliberately vulgar Russian register onto coding agents, as a Claude Code plugin, a skill for Cursor, Codex and Windsurf, and a Pi package. Its evidence is borrowed from external studies, its benchmark number comes from a press article, and its package manifest sits four minor versions behind its tags.

**smixs/pohuy** — Режим идиоматического русского мата для AI-агентов. Короче, душевнее, эффективнее. 18+

- Repository: https://github.com/smixs/pohuy
- Stars: 1,373 · Forks: 34
- Language: TypeScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/smixs-pohuy

## The project's own numbers report zero tokens saved

The README contains a summary box that reads like a scorecard, and the first line of it is the one that matters. Tokens saved sits at zero percent. Roots used sits at four. Technical accuracy and clarity both sit at a hundred percent, and a soulfulness row is marked as unbounded.

The text around it says the same thing more directly: the numbers are honest, and the spoiler is that it saves no tokens whatsoever. That is an unusual thing for a prompt project to state in its own README, and it reframes what the project is.

The claim being made is not efficiency. It is that Russian profanity is generative in the same way technical vocabulary is, built from four roots with prefixes and suffixes attached, so a phrase built that way can carry a complete technical meaning in very few characters. The comparison drawn is with another project called caveman, which the README says was the inspiration: caveman saves words, this saves roots.

There is a benchmark claim alongside, on a benchmark named for roots, saying the approach beats frontier models seven times over on root saving. Set against the zero in the scorecard, the two numbers are measuring different things, and the README is clear enough about which is which.

## The benchmark number comes from an article, not from this repository

The evidence base is borrowed, and it is worth being precise about how.

The coding benchmark figure quoted in the README is a SWE-BENCH PRO result of 80.3 percent against 69.2 percent, an eleven point improvement, and it is presented with a link to a Habr article rather than to a result directory in this repository.

The supporting citations are also external. One claim is that repositories where maintainers use profanity in comments received noticeably higher scores, and that is illustrated with a link to a Habr piece and to an Ars Technica article on whether code containing swear words is higher quality than code that does not.

The third citation is about agent behaviour rather than code quality. The README describes a leaked Claude Code file that matched regular expressions for frustration keywords in user messages, and notes that an agent reading profanity in a user's message is treated as a signal to reconsider. That reference points at a PC World write-up.

One person is credited by name for an academic approach to the idea.

So the chain is: an external study on comments, an external article repeating it, a press report about keyword scanning, and an external benchmark write-up. The only artefact this repository produced is the honest numbers file, and that file is the one saying there is no token saving.

## Four roots plus affixes is the actual mechanism

The technical proposal is a morphology argument, and it is the part of the project that could be applied elsewhere.

The claim is that a small set of roots, combined with prefixes and suffixes, generates enough vocabulary to express engineering situations the way technical English does. The README's own gloss on one example is that a single crude phrase carries the meaning of a service having crashed unexpectedly and needing investigation, but conveys it immediately.

The demonstration table is the evidence. Each row pairs a formal English sentence, the kind an ordinary assistant writes, with a short Russian version of the same content. Across sixteen rows the technical content survives intact: a database environment variable name, a hardcoded sleep call, a named dependency, a log statement, a year, a reference to jQuery and callbacks and global state, a replica lag figure, a version suffix in a variable name, an HTTP status code, an unindexed query, an environment difference, a missing error handler, a chain of dependent failures, a clean image, and a hotfix.

That is the real design goal, and it is a reasonable one: keep every identifier and every number, cut the hedging. The register is crude because crudeness is the compression, and the summary box's claim of full technical accuracy is a claim about this table rather than about the agent's reasoning.

## package.json says 0.1.0 and the tags say 1.1.0

The package manifest is at odds with the release history, and with the README's own scope.

The version field reads 0.1.0. The two GitHub releases are v1.0.0, described as the native format, and v1.1.0, described as Codex CLI support, both published on the same day in August 2026 a few hours apart. So a consumer installing from a registry can get 0.1.0 while the repository's tags claim 1.1.0, and nothing in either file reconciles the two.

The description is narrower than the pitch too. It describes a session-scoped Russian engineering response style for one specific agent host, and the keyword list contains a single entry naming that host's package format. The README, by contrast, advertises four agent surfaces.

What the manifest is precise about is the mechanics. The runtime requires Node 22.19.0 or newer, the module is ESM, and there are two scripts: a test that runs a TypeScript test file through the native test runner with a TypeScript loader, and a typecheck with no emit. Two packages are declared as peer dependencies with wildcard version ranges, both belonging to that host's own agent and terminal packages, and a host-specific extension entry points at one TypeScript file.

A lock file is committed even though the project runs on the platform test runner rather than a test framework.

## The published file list omits four directories from the repository

The manifest declares exactly what ships, and comparing it with the repository tree shows what does not.

Included are the Claude Code plugin directory, a commands directory, documentation, the host extension and its own directory, an extensions readme, a skills directory, and the honest numbers file.

Absent from that list, while present at the repository root, are the codex directory, the evals directory, the hooks directory, the output styles directory, and both shell installers.

So a package consumer gets the plugin manifest, the commands, the skills and the documentation, and does not get the Codex integration, the evaluation assets, the hook definitions or the output style definitions. Given that hooks and output styles are how this kind of project attaches behaviour to an agent, those omissions are the difference between installing a style and installing the machinery behind it.

Two other root entries suggest the intended shape. A shell installer exists alongside a separate installer specific to Codex, and a TypeScript configuration file sits next to the manifest. There is also a Claude plugin directory at the root, which is what the Claude Code marketplace install path consumes.

For a project whose whole surface is a handful of prompts and a style definition, the packaging boundary is the part most worth checking before you rely on it.

## Three install commands for four agent surfaces

Installation is three lines, and they do not all target the same kind of host.

```bash
# Claude Code — plugin
claude plugin marketplace add smixs/pohuy && claude plugin install pohuy@pohuy

# Cursor / Codex / Windsurf и прочие - через skills registry
npx skills add smixs/pohuy

# Pi - пакет со скиллом и командой /pohuy
pi install git:github.com/smixs/pohuy
```

The first path treats the repository as a plugin marketplace source and installs a named plugin from it, which is the one path that pulls a whole plugin structure. The second covers Cursor, Codex, Windsurf and others through a skills registry and a single add command, so those hosts receive a skill rather than a plugin. The third installs the repository as a package into one specific host, bringing both a skill and a slash command.

So the same repository is a marketplace plugin, a registry skill and a host package depending on the row, and the codex directory and the Codex installer script at the root are consistent with the second and third rows rather than the first.

The README's own positioning calls the register idiomatic, applied and folk, and carries an eighteen-plus marker. The last section of the file, which promises detail on configuring the command, the terminal interface and the style sources, is cut off after its opening line, so the configuration surface beyond installation is not readable.

## A style is a product decision, not a formatting option

What this repository installs is a register. There is no model, no retrieval and no tool: the artefact is a set of instructions that changes how an existing agent phrases its answers, plus the hooks, commands and output styles that deliver those instructions.

That has an obvious appeal. The before and after table argues, with sixteen examples, that the compressed register loses no technical content while removing the hedging. If a team has already decided that its agents talk too carefully, this is a way to push that decision into the tooling instead of into a style guide.

It also has an obvious limit, and the project is unusually honest about where it sits. The register is crude on purpose, the demonstration material carries an age marker, and the README itself notes that agent tooling scans user messages for frustration language. An agent instructed to answer this way will produce output that reads as unserious to anyone outside the team that chose it.

The practical question is not whether the compression works. The examples suggest it does. The question is where that output is read: an internal terminal, a shared repository, a customer ticket, a code review comment on someone else's project. Those are four different decisions and only one of them is obviously fine.

Project state is small. MIT licensed, default branch main, two releases on one day in August 2026, and a last commit dated 2026-09-16.

## Conclusion

pohuy fits an internal team that has decided blunt register beats corporate hedging in its own tools, and that is comfortable with the output being deliberately vulgar. It does not fit a shared repository, a client-facing surface, or anyone who expects an evidence base. Verify four things before installing it. Read the project's own numbers rather than its pitch, because the summary box reports zero tokens saved and the README says so outright while the benchmark claim is attributed to an external article. Decide where agent output will be read, since the style is the product and the register is crude by design, and the README itself notes that agents scan for frustration keywords. Check what you actually get from a package install, because the manifest's file list omits the Codex integration, the hooks directory, the output styles and both install scripts that sit in the repository. And note the version mismatch: the manifest says 0.1.0 while the tags are 1.0.0 and 1.1.0, both published on 2026-08-07. The last commit on main is dated 2026-09-16, and the license is MIT.

## FAQ

### What is smixs/pohuy?

An MIT licensed TypeScript project that installs a deliberately crude Russian engineering register onto coding agents, so their replies are phrased in that register instead of in hedged formal English. It ships as a Claude Code plugin, as a skill for Cursor, Codex, Windsurf and similar hosts, and as a package for one other host, and it changes phrasing rather than adding any model or tool.

### Does pohuy save tokens?

No, according to the project's own numbers. The summary box in the README reports zero percent tokens saved alongside four roots used, full technical accuracy and full clarity, and the text states outright that it saves no tokens. A separate file in the repository holds the numbers it describes as honest.

### How do I install pohuy?

Three commands: add the repository as a plugin marketplace source and install the plugin for Claude Code, run an npx skills add command for Cursor, Codex, Windsurf and similar hosts, or install the repository as a package for the other supported host, which brings a skill and a slash command. The package manifest requires Node 22.19.0 or newer.

### What evidence does pohuy cite for its approach?

All of it is external. The README links a study reporting that repositories with profanity in comments scored higher, an Ars Technica article on the same question, a press report about a leaked Claude Code file matching frustration keywords in user messages, and a Habr article that carries the coding benchmark figures. The repository publishes no measurement of its own beyond the file that reports zero token savings.

### What does the pohuy npm package ship?

The manifest's file list covers the Claude plugin directory, a commands directory, documentation, the host extension, skills and the honest numbers file. It does not list the codex directory, the evals directory, the hooks directory, the output styles directory or either install script that exist at the repository root, and the manifest version is 0.1.0 while the newest tag is 1.1.0.

## Sources

- [Issues](https://github.com/smixs/pohuy/issues)
- [License: MIT](https://github.com/smixs/pohuy/blob/main/LICENSE)
- [README](https://github.com/smixs/pohuy/blob/main/README.md)
- [Releases](https://github.com/smixs/pohuy/releases)
- [smixs/pohuy on GitHub](https://github.com/smixs/pohuy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/smixs-pohuy