gpt6-Astra (冷咖啡 / CHA): a six-seat prompt workbench for Claude, Grok, DeepSeek, GLM and Gemini

What 冷咖啡 actually is, and who it is for

The repository is named 3641397194-wq/gpt6-Astra and the README brands it as 冷咖啡 / CHA, with the tagline gpt6 Astra-claude-grok4.6-deepseekv4.1-glm5.3-gemini. That tagline reads like a list of model names, and the README's second section does present six of them as 模型席位, or model seats: GPT-6 Astra / Codex, Claude Code, Grok 4.6, DeepSeek v4.1, GLM 5.3 and Gemini. The important detail is what the tool does with those names. It does not call them. It writes prompt packs into each seat's local instruction layer, so the same workbench can be pointed at whatever CLI or editor extension you already have installed for that model.

The problem it addresses is drift between seats. If you keep separate prompt files for Claude Code, Codex and Gemini, they fall out of sync, and there is no record of what the file looked like before the last edit. 冷咖啡 puts the target, context, output and check into a four-panel structure the README calls 四格分镜, and gives each seat a preview, run, verify and restore path. The audience is narrow: people who already juggle several model CLIs and want one place to deploy and roll back prompt packs. It is not for someone who wants a chat interface.

The seat model: how a deploy reaches six different tools

The mechanism is file writing, not API calls. The README states that the desktop preview, run, verify and restore actions for all six seats write into that model's own local instruction layer, and that the original is backed up under a cha-backups directory in the corresponding folder. So a deploy is a write plus a backup, and restore is a copy back from that backup. verify checks the marker blocks, which implies the tool wraps its injected content in identifiable delimiters so it can tell its own edits apart from yours.

The repository layout supports this reading: coldbrew.py at the top level, seats.py and gemini_seat.py beside it, plus desktop/ and tools/. The per-model Python files suggest each seat has its own adapter, and the separate gemini_seat.py hints that Gemini's target file or format differs enough from the others to need its own module. The README points to docs/SEAT-PACKS.md for the injection positions and the original manuscript notes, which is where the actual per-seat paths would live. That document is the one to read before deploying anything, because the README does not list the target paths inline.

The design trade-off is visible here. Because everything is local file rewriting, the tool has no way to know whether the target CLI will actually read the file you injected into, and no way to detect a format change in that CLI. A deploy can succeed and still have no effect. The verify action checks marker blocks, not model behaviour, so it confirms the write landed, not that the prompt works.

Installing gpt6-Astra and running a first deploy

The README gives two entry points. The Python side is driven by coldbrew.py, and the desktop side is an Electron app under desktop/. The first example activates the profile MAX and sends a prompt, which is the quickest way to see whether the CLI responds at all.

python coldbrew.py --activate 冷咖啡 --profile MAX --prompt "把这段需求拆成可执行步骤"

If that returns without error, the next step is a single seat rather than all six. The README shows one command per seat with --action deploy and --json, and running one first keeps the blast radius small. Note that the seat identifiers are not uniform: five are plain names and one is glm-5.3 with a dot.

python coldbrew.py --activate 冷咖啡 --seat claude --action deploy --json
python coldbrew.py --activate 冷咖啡 --seat glm-5.3 --action deploy --json

After a deploy, check that a cha-backups directory appeared next to the file the seat writes into. The README says verify checks the marker blocks and restore rolls back, so the pair to try next is verify, then restore, on the same seat. If verify fails, do not run restore blindly; the backup from the first deploy is the only copy of your original.

The desktop app is a separate install. The README's commands are PowerShell-flavoured, and npm run pack:win builds a Windows portable package.

cd desktop
npm install
npm start

The README does not document a Python version, a package manifest, or any dependency list for coldbrew.py, so treat the Python side as something you inspect before running.

Where 冷咖啡 breaks down

The most concrete limitation is that the README never states which files the six seats write into. It defers that to docs/SEAT-PACKS.md. Without reading that file you cannot know whether a deploy is about to touch a project-local config or something in your home directory, and the backup directory is created in the corresponding folder, which means backups are scattered rather than centralised. If you deploy to six seats across six tools, you now have six cha-backups directories to track.

The second issue is that the seat list mixes products that are not the same kind of thing. Claude Code and Codex are coding agents with their own instruction files. Gemini and Grok are chat products. The README's claim that all six share one local instruction layer is a claim about the tool's file-writing targets, not about those products having equivalent extension points, and the existence of a separate gemini_seat.py suggests the abstraction leaks at least once.

The third is the framing. The repository topics include jailbreak and security-research, and the title uses 破甲越狱. Whatever the intent, that framing means the prompt packs are aimed at bypassing model restrictions. That is a real operational risk: providers change enforcement, packs stop working, and the tool has no mechanism to tell you a pack has been neutralised. It will report a successful write either way.

Finally, this is the wrong tool if you want a stable prompt library. There is no versioning of the packs themselves in what the README describes, only backup and restore of the target file. You get one level of undo per seat, not a history.

Compared with keeping prompt files by hand or using a prompt manager

The obvious alternative is a plain dotfiles repository. You keep one instruction file per tool, symlink or copy it into place, and use git to track changes. The difference in approach is that git gives you full history and diffs, while 冷咖啡 gives you a single backup directory per seat and a restore command. Git is better at history. 冷咖啡 is better at the multi-seat write itself: one command with --seat and --action deploy against a uniform interface, plus a verify step that checks its own marker blocks. If your problem is remembering which of six files you edited last, the tool addresses that directly; git does not.

A second alternative is a prompt-management service that hosts prompts and serves them over an API. That inverts the architecture: prompts live remotely and clients fetch them. 冷咖啡 keeps everything local and rewrites files in place. For anyone working inside a corporate network or offline, local rewriting is the only option that works. For a team that needs the same prompt across many machines, a hosted manager is the better fit, because 冷咖啡 has no documented sync or team feature in the README.

The third comparison is with doing nothing and letting each tool manage its own instructions. Claude Code, Codex and the others each have their own configuration conventions. 冷咖啡's value is only as large as the number of seats you actually use. With one seat, it is an extra layer over a file you could edit yourself.

Maintenance, licensing and upgrade cost

The last push to the repository was on 2026-09-11, four days before this writing, and the repository is not archived. The README labels the current visual system NOIR MANGA RELEASE 2.3.6 and there is a VERSION file at the top level, so releases appear to be tracked in-repo rather than through tagged GitHub releases; the material retrieved no releases. The upgrade cost is therefore manual: you pull, read VERSION, and re-run deploys for whichever seats changed. Because a deploy overwrites the seat's instruction layer and backs up the previous version into cha-backups, upgrading means another round of backups and another round of verify calls per seat. Six seats means six of each.

The licence is reported as NOASSERTION, which means GitHub could not map the LICENSE file to a recognised identifier. There is a LICENSE file at the top level, so terms exist, but you have to read that file yourself to know what they are. Two things follow. First, do not assume a permissive licence just because the code is on GitHub. Second, the repository ships prompt packs whose content is described in the topics as jailbreak material; if you redistribute or bundle those packs, the licence on the code and any terms attached to the pack content may differ. This is not legal advice, and the README does not discuss licensing at all.

Editorial conclusion

Adopt gpt6-Astra if you already run several coding or chat CLIs side by side and want one command that writes the same instruction layer into each seat, with a local backup you can restore. Do not adopt it if you are looking for GPT-6 Astra the model: the repository is a prompt workbench, and the README does not document any hosted model or API of its own. Before relying on it, read docs/SEAT-PACKS.md to see which file each seat writes into, then run the verify action for one seat and confirm that the cha-backups directory appears next to the file it touched.

Frequently asked questions

Official sources

1. 3641397194-wq/gpt6-Astra on GitHub
2. Issues
3. Project website
4. README