Voice AI

Stop Guessing Which Prompt Is Better. Test It at the Edge.

Sonam •

Every AI feature eventually gets to the same awkward moment.

Someone changes the prompt.

The new version sounds better in one test. A teammate likes the older version. Another person wants it shorter. The model output feels improved, but nobody is quite sure whether the prompt actually got better or just got different.

That is fine when you are experimenting locally. It gets messy once the prompt is part of a real application.

If an AI assistant writes summaries, classifies tickets, drafts responses, or turns messy text into structured data, prompt changes are product changes. They can affect accuracy, tone, latency, cost, and user trust.

This example turns prompt iteration into something measurable.

edge-prompt-ab-tester is a small TypeScript app that runs on Telnyx Edge Compute. You send it one task and two prompt variants. It calls Telnyx AI Inference for both variants, returns both answers, stores the experiment in a Stateful Actor, and lets users vote on which result is better.

Code:

What the app does

The API is intentionally small:

  • POST /experiments creates a prompt A/B test
  • POST /experiments/<id>/vote records a vote for variant A or B
  • POST /experiments/<id>/close closes an experiment
  • GET /experiments lists recent experiments
  • GET /experiments/<id> returns one experiment
  • GET /stats returns cumulative vote stats
  • GET /health/liveness and GET /health/readiness support health checks

The interesting part is the shape of the workflow.

You are not just asking the model to answer a prompt. You are asking the system to preserve the comparison:

task + prompt A + prompt B
  -> call Telnyx AI Inference for both variants
  -> store both responses in a Stateful Actor
  -> collect votes
  -> track the current leader

That gives you a lightweight evaluation loop without needing a database, dashboard, or separate experiment service before the idea is useful.

Creating an experiment

Here is the kind of request the app expects:

curl -X POST https://edge-prompt-ab-tester-<id>.telnyxcompute.com/experiments \
  -H "Content-Type: application/json" \
  -d '{
    "task": "Write a one-sentence tagline for an edge compute platform.",
    "variant_a": "You are a concise marketing copywriter. Return just the tagline.",
    "variant_b": "You are a technical explainer. Return just the tagline, focus on latency."
  }'

The app runs both prompts against the same task and returns an experiment:

{
  "id": "exp-msf712rs-0",
  "task": "Write a one-sentence tagline for an edge compute platform.",
  "variant_a": {
    "prompt": "You are a concise marketing copywriter. Return just the tagline.",
    "response": "Real-time compute, right where your data lives."
  },
  "variant_b": {
    "prompt": "You are a technical explainer. Return just the tagline, focus on latency.",
    "response": "Execute code milliseconds from your users to eliminate network latency."
  },
  "votes_a": 0,
  "votes_b": 0,
  "status": "open",
  "created_at": "2026-08-04T21:51:55Z"
}

This is a simple example, but the pattern is useful. You can use the same flow to compare:

  • a concise system prompt against a more detailed one
  • a customer-support tone against a technical-support tone
  • a JSON-only instruction against a more conversational instruction
  • a safer refusal policy against a more permissive one
  • two retrieval prompts for the same knowledge base answer

The important thing is that both variants see the same task.

The AI call

The app calls Telnyx AI Inference through:

POST /v2/ai/chat/completions

The sample currently uses:

zai-org/GLM-5.2

For each variant, the prompt becomes the system message and the task becomes the user message. The app runs the two requests in parallel, then stores both responses as part of one experiment.

That keeps the comparison clean. You are not changing the task, the model endpoint, or the app behavior between runs. The variable you are testing is the prompt.

Why Stateful Actors fit this

Prompt testing needs memory.

Not always a large database. But you do need somewhere to store:

  • the task
  • prompt A
  • prompt B
  • response A
  • response B
  • vote counts
  • open or closed status
  • cumulative stats

The example uses a single ABTester Stateful Actor to keep that state.

Inside the actor, experiments are stored by ID. Votes are tracked both per experiment and across the whole collection. The /stats route can then return a quick view of total experiments, open experiments, closed experiments, total votes, and the leading variant.

That is the piece I like here: the experiment state lives with the edge application. You can deploy the workflow as one edge app instead of standing up a separate persistence layer just to test prompt changes.

Recording votes

After reviewing the two responses, a user can vote:

curl -X POST https://edge-prompt-ab-tester-<id>.telnyxcompute.com/experiments/exp-msf712rs-0/vote \
  -H "Content-Type: application/json" \
  -d '{"variant":"a"}'

The actor increments the experiment vote count and updates cumulative vote stats.

When the test is done, close it:

curl -X POST https://edge-prompt-ab-tester-<id>.telnyxcompute.com/experiments/exp-msf712rs-0/close

Then inspect aggregate results:

curl https://edge-prompt-ab-tester-<id>.telnyxcompute.com/stats

Example response:

{
  "total_experiments": 3,
  "open_experiments": 2,
  "closed_experiments": 1,
  "total_votes": 15,
  "leader": "variant_a",
  "leader_votes": 9
}

Running it

Clone the examples repo:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/edge-prompt-ab-tester

Set your Telnyx API key as an Edge Compute secret:

telnyx-edge auth api-key set <YOUR_API_KEY>
telnyx-edge secrets add TELNYX_API_KEY "KEY0123..."

Install dependencies and deploy:

npm install
telnyx-edge ship

The deploy command prints a URL like:

https://edge-prompt-ab-tester-<id>.telnyxcompute.com

Check liveness:

curl https://edge-prompt-ab-tester-<id>.telnyxcompute.com/health/liveness

Then create an experiment, vote, close it, and inspect stats.

Where this pattern goes next

The sample is deliberately small, but it points at a very real workflow.

Most production AI teams eventually need some version of:

  • prompt versioning
  • evaluation sets
  • human scoring
  • regression checks
  • model comparison
  • output quality tracking
  • rollback paths

This example is a starting point for that loop.

Before using it in production, I would add authentication, evaluator identity, duplicate vote prevention, randomized or blinded variants, richer scoring rubrics, and privacy rules for prompts that include customer data.

Still, the core idea is valuable: prompt changes should leave evidence behind.

Instead of asking, "Does this prompt feel better?", you can ask, "What did it produce, who preferred it, and what won?"

Resources:

  • Code:
  • Telnyx Edge Compute docs:
  • Edge Compute quickstart:
  • Telnyx AI Inference docs:
  • Telnyx AI skills and toolkits:
  • Telnyx Portal:

Ready to build with low-latency voice AI?

Join developers building the future of real-time conversations

💬 Join our Slack 🚀 Explore Voice AI