by VariatCopy (LX AI)
VariatCopy — Two angles for every product, ready to test. Use it as decision-support: demo mode works without a live key; live runs require configuration. No fabricated metrics, and no claims for SSO/CSV/Slack unless that surface is actually shipped.
Decision-support only — confirm before you publish or act.
I started with a simple prompt that asked the model to produce two contrasting messages for the same product. The first angle focuses on price or promotion, the second on quality or craftsmanship. I gave the model a fixed structure: hook, body, call‑to‑action, and a one‑line hypothesis that states what we expect to learn if we test the variant.
The prompt contains three parts: a short description of the product, a request for two variants, and a format specification. I keep the description under 80 characters to stay within the model’s context window. The format specification uses markdown‑like headings so the output can be split reliably.
Each variant returns four fields: hook (max 8 words), body (one or two sentences, max 20 words), CTA (imperative phrase, max 5 words), and hypothesis (a single clause that can be tested with an A/B test). I store the raw text in a temporary file under the product’s .data/ directory.
After generation I run a quick sanity check: I verify that the hook does not repeat the product name verbatim, that the body contains at least one adjective, and that the CTA does not include punctuation that could break a URL. If any check fails I retry with a slightly higher temperature.
When you launch VariatCopy without providing an API key the tool switches to demo mode. In this mode I use a small, deterministic language model that is bundled with the binary. It does not call any external service, so no network request is made.
The demo model runs entirely on the CPU of the host machine. It loads a quantized version of a 125 M parameter model that has been fine‑tuned on public copy‑writing datasets. Because the model is local, latency is low and there is no usage cost.
All inputs and outputs stay inside the working directory. The tool writes a file named demo‑output.json that contains the two angles and the hypothesis. You can inspect this file to see exactly what the model produced.
The hook, body, CTA, and hypothesis are presented in the terminal as plain text. No styling is added, which keeps the output easy to copy into a design file or a ticketing system.
Demo mode is intended for quick checks and for learning how the prompt works. It does not guarantee the same quality as a live run with a larger model, and it may produce repetitive phrasing after several iterations.
To get results from a hosted language model you must supply a valid API key. The tool reads the key from an environment variable named VARIATCOPY_KEY or from a plain‑text file called .variatcopy‑key in the project root.
I avoid storing the key in the application’s configuration file because that could be accidentally committed to a repository. Instead I recommend adding the line export VARIATCOPY_KEY=your_key_here to your shell profile or using a direnv hook.
You can choose between two endpoints: a fast, lower‑cost model suitable for many iterations, and a higher‑quality model that consumes more tokens. The selection is made with the --model flag; the default is the fast variant.
Each request has a hard timeout of 12 seconds. If the model does not respond within that window the tool returns an error and logs the attempt. I also added a simple token counter that warns you when the estimated cost for a batch exceeds a threshold you set in .variatcopy‑config.
If the API returns an error code the tool prints the message exactly as received, without reformatting. This makes it easier to see whether the problem is authentication, rate limiting, or an invalid prompt.
Once you have the two angles you can use them as a basis for a quick review before you commit to a final copy. I treat the output as a checklist rather than a final answer.
I place the two hooks side by side and ask: does one hook speak more directly to the visitor’s immediate need? If the product is a commodity, a price‑focused hook may win; if the product is a niche tool, a quality‑focused hook may resonate better.
The body sentences are examined for clarity and for the presence of concrete details. I look for vague adjectives like “great” or “amazing” and replace them with specific attributes such as “battery life of 12 hours” or “machined from aerospace‑grade aluminum”.
I verify that each CTA uses a strong verb and does not rely on jargon. Examples that work well are “Start your trial”, “Download the guide”, or “Schedule a demo”. If the CTA contains a preposition that could be misread I rewrite it.
The one‑line hypothesis is written as a testable statement: “If we show the discount‑led version then click‑through rate will increase by at least 5 % compared to the baseline.” I copy this line into the test plan so the experiment team knows what to measure.
I want to be clear about the limits of VariatCopy so you do not rely on it for things it cannot do.
The tool does not promise that either variant will improve conversion, engagement, or any other metric. Outputs are generated from statistical patterns in the training data and should be treated as starting points only.
You must still read the copy, check for brand voice, and verify any factual statements. The model can produce plausible‑sounding text that contains inaccurate details.
VariatCopy only writes text to standard output or to a file. It does not connect to ad platforms, email services, or content management systems. You must manually copy the result into your workflow.
If the current build does not include those integrations you should not assume they exist. I have deliberately avoided claiming support for features that are not present in this release.
See the OWASP LLM Top 10 for guidance on prompt injection risks: https://owasp.org/www-project-top-10-for-large-language-model-applications
For a structured risk approach, consult the NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
I use VariatCopy at the very beginning of the copy‑creation stage, before any design work starts. The tool helps me generate a pair of opposing ideas quickly, which I then discuss with the product and design teams.
After a feature spec is written I run VariatCopy with the product name and a one‑sentence value proposition. The two angles give me a concrete starting point for a headline and a supporting paragraph.
I take the hook and body from each variant and place them into two separate landing‑page templates. The CTA from each variant is kept unchanged so the only difference between the pages is the messaging.
I save the raw JSON output alongside the feature spec in the repository under docs/copy‑variants/. This makes it easy to review what the model suggested when we later look at test results.
Because the output is plain text I can diff it across runs. If I change the prompt or the model temperature I can see exactly how the wording shifts, which helps me tune the tool over time.
When an A/B test finishes I note whether the hypothesis was supported or refuted. I then add a short comment to the variant file indicating the outcome. Over time this creates a small library of what kinds of angles tend to work for our audience.
Two angles for every product, ready to test.
Operators and builders who need a fast first draft or checklist from VariatCopy.
Yes in explicit Demo mode. Live AI requires a configured key.
No. Outputs are decision-support; you still review before publishing or acting.
Only if those features are implemented in this product build — do not assume them from marketing copy.
Runs may be stored locally under the product's .data/ boundary; treat demos as ephemeral.