featuresJune 15, 2026· 3 min read

CPROMPT: version your prompts and A/B test them like code

Prompts are production logic edited like sticky notes. CPROMPT gives them named templates, automatic versioning, rollback, variable rendering, and sticky weighted A/B splits — all surviving restart.

Prompts are some of the most load-bearing strings in a modern app, and most teams manage them worse than they manage CSS: pasted into code, edited live, with no history of what changed or what it did to quality. CPROMPT treats a prompt like the production artifact it is — a named template that versions automatically on every write.

In plain words: Crowkis stores your prompts like versioned code — with history, rollback, variable filling, and per-user A/B tests that stick to the same user every time.

The verbs read like a tiny VCS: SET creates a new version, GET fetches one, VERSIONS lists the history, ROLLBACK reverts to a known-good one, and RENDER substitutes {{variables}} into the template at call time. Nothing is lost; the prompt you shipped last Tuesday is still retrievable after the prompt you shipped today turned out worse.

adoption is one port change

Four doors in, one cache, and the model only sees genuinely new questions.

The A/B layer is where it earns its place in the request path: ABSET defines a weighted split across versions, and AB with a SUBJECT id assigns each user stickily — the same subject always lands in the same bucket, via a hash over cumulative weights — so your experiment is consistent per user instead of flickering per request. The whole thing persists across restarts, so an experiment doesn't reset when a pod reschedules.

The bottom line

Prompt changes are deploys. CPROMPT gives them the version history, the rollback button, and the experiment framework that every other kind of deploy already takes for granted.