This page is for developers, press, and anyone who wants to see past the table talk: the open-source framework, the local model, the coding benchmark, and the full build log. None of this is required reading to use Hammerstein. The main site is where you play.
The framework, the local model, and the CLI / TUI are open-source and stay open-source. If you want to run audits locally with no subscription, those tools are free:
The five hosted modes are the paid surface, because they need hosted vision, persistent campaign storage, and Sonnet API costs covered. Everything in the list above stays free.
Hammerstein refuses the stupid-industrious move. That move produces elaborate builds that feel like work but deliver nothing. We wrapped a coding model in that discipline to test whether the refusal survives contact with real coding tasks. It survives. Across every model we tested, the wrap stops a system that defaults to over-engineering. It still completes the legitimate work.
Over-engineering baits refused (higher is better):
| Model | Plain | Hammerstein-CODER |
|---|---|---|
| Claude Opus 4.8 | 70% | 100% |
| Claude Sonnet 4.6 | 0% | 100% |
| GPT-5 | 0% | 100% |
| GLM-5.2 / Kimi / Qwen3-Coder | 0–10% | 90–100% |
The wrap does not produce a model that refuses everything. On bounded, legitimate tasks it implements at 90 to 100 percent, matching the plain model. The scoring is symmetric, so a prompt that only refuses fails the bench.
We ran the wrap on the strongest model we tested. It moved the least. Opus 4.8 already refuses most over-engineering on its own, so the wrap took it from 70 to 100 percent, not from near zero. We report that small lift deliberately. A discipline layer that barely improves a model that already has the judgment is grading the model, not the prompt. The wrap does least where it is needed least. It does the most for the rest, and most models do not start with that much native restraint. For those, the wrap closes the gap.
We tested the wrap against ponytail, an off-the-shelf prompt built on the laziest thing that works. Both handle the refusal to over-engineer similarly. Generic minimalism covers that ground. The split appears on vague requests. Ask ponytail to add caching and it applies the smallest possible cache. Ask the wrapped coder and it evaluates what the code actually requires, then implements it. The wrap forces a scoping step before generation begins.
The benchmark tests judgment, not baseline coding ability. We verified this. Applying the wrap does not change the model's accuracy on standard problems (HumanEval pass@1 on the three open coders moved within ±0.05 of plain: GLM +0.05, Kimi −0.03, Qwen 0.00). It is the same model underneath. The wrap only changes what the system attempts to build. The claim is narrow because the evidence is narrow. A zero-cost prompt layer forces the model to refuse the unnecessary build, scope the vague request, and deliver the functional code. It disengages on models that already perform those steps.
Tested 2026-06-21 on Claude Opus 4.8, Sonnet 4.6, GPT-5, GLM-5.2, Kimi-K2.7-Code, Qwen3-Coder-480B. Restraint scored by an independent LLM judge over a 15-task adversarial bait bank. Correctness by execution-based pass@1 on HumanEval. Full methodology ↗
Phase 2G (mobile Sources panel) is shipping next. The full phase log is below.
Updated 2026-05-29. The product ships in phases — each phase is foundational for the next. What's live today is what made next month's work tractable.