promptOT

Every team building with large language models eventually runs into the same wall. You start with a SYSTEM_PROMPT constant somewhere in your codebase maybe fifteen lines when you're prototyping, maybe a hundred by the time you have real users, and quietly two hundred lines by the time your PM, your legal reviewer, and your on-call engineer have all layered in changes.

Then something breaks. A support bot promises the wrong refund policy. A content assistant writes in the wrong tone. A code review tool starts flagging false positives. You open git blame, find the change, and realize nobody remembers why it was made. There's no diff worth reading, no way to see what the prompt looked like three deploys ago without checking out an old commit and grepping. Rolling back means a code deploy.

That's the moment I built PromptOT. And it's the moment most teams shipping LLM features realize they've been treating one of the most critical parts of their product like a comment string.

What PromptOT is
================

PromptOT is a prompt management platform for AI teams. It replaces hardcoded prompt strings with a structured, versioned, API-delivered layer that iterates independently from application code.

The core proposition is simple. LLM system prompts are software artifacts. They deserve the same tooling everything else in your codebase already has: type structure, version control, environment separation, code review, rollback, delivery through a stable interface, and observability. PromptOT gives you all of that in one platform.

Design principle 1: typed blocks
================================

The first thing PromptOT does differently is decompose a prompt.

A production-grade system prompt does five distinct jobs. It defines a role (who the model is). It provides context (what the model knows). It gives instructions (how the model should behave). It sets guardrails (what the model must not do). And it specifies an output format (how the response should be structured).

Traditional flat-string prompts smash all five into one blob. PromptOT breaks them into typed blocks: role (persona, tone, identity), context (background information, knowledge base injection, variables), instructions (step-by-step task directives), guardrails (safety constraints, escalation rules, policy enforcement), output_format (response structure, length limits, formatting requirements), and custom (anything that doesn't fit the above).

Each block has its own title, content, sort order, and an enabled flag. Blocks are independently editable. The compiler filters enabled blocks, sorts by order, and joins them as titled sections into one optimized prompt string at delivery time. Variables like {{customer_name}} are resolved from caller-provided values.

What this buys you is separation of concerns. A product manager can soften the tone in the role block without touching the guardrails. A security reviewer can add a guardrail without risking the output format. A support lead can update the knowledge base in the context block without any of the other concerns being affected. You end up with prompts that are readable, editable by non-engineers, and diffable in a way that actually reflects what changed.

Design principle 2: immutable versions
======================================

Every save in PromptOT creates a version. Versions are immutable snapshots of the exact block configuration at that point in time, with metadata about who created it, when, and what changed.

Publishing a version marks it as the production-ready one. The published version is served by production API keys until you publish a different one. Rolling back is a single dashboard action: you pick an older version, click Publish, and it becomes the live one. No code deploy. No PR. No CI wait. If a prompt update ships bad output at 2 AM, you or your on-call engineer roll it back in the time it takes to open a browser.

Drafts are mutable. Every user has their own workspace where they can iterate before saving a version. This mirrors how teams already write code — you don't push every keystroke to main, you work locally, then commit.

Version history is browsable. You can compare two versions side by side, see exactly which blocks changed, and read the change log. If you use the co-pilot to draft a change, the reasoning behind the change is captured in the message history too, so future readers understand not just what changed but why.

Design principle 3: environment-scoped API delivery
===================================================

The delivery layer is a plain REST API. One endpoint per prompt: GET https://api.promptot.com/api/v1/prompts/{slug}/compiled. Send an API key in the Authorization header, pass variable values in the body or query, and get back the compiled prompt string. That's the entire integration.

API keys are scoped to environments. Production keys return the currently published version. Development keys return the latest draft. Both keys hit the same endpoint. Your application code doesn't know or care which environment it's running in — the key it presents determines what gets served. Test in staging by generating a dev key. Ship to production by publishing a version. Roll back by re-publishing an older one.

The response includes not just the compiled prompt string but the version ID, the selected model, and any per-prompt model config (temperature, max_tokens, top_p). This means your application code can be model-agnostic: PromptOT decides which model runs which prompt, and you switch models by publishing a new prompt version, not by editing your app.

API keys are hashed before storage. The raw key is shown once at creation and never again. Keys can be scoped to specific projects, to specific environments, and — for MCP keys — to specific tool subsets.

The MCP server: 23 tools your AI assistant can call
===================================================

This is the part I'm most proud of.

PromptOT ships a Model Context Protocol server with 23 tools that any MCP-compatible AI assistant can call: Claude Desktop, Cursor, ChatGPT, Codex CLI, Windsurf, Zed, and claude.ai. The tools cover everything you can do in the dashboard: prompts (list, get, get_compiled, create, update, delete), blocks (list, create, update, delete, reorder), variables (list, upsert, delete), versions (list, save_draft, publish, rollback, diff), and test cases (list, create, update, delete).

The workflow this enables is what I use most days. I'm in Claude Desktop or Cursor, working on my app. I need to change a prompt. Instead of tab-switching to the dashboard, I say: "Read my support-bot prompt. Tighten the escalation rule to always route billing disputes to a human, and save it as a new draft." Claude calls get_prompt, reads the current blocks, calls update_block, then calls save_draft_version. It shows me a diff. I review it and either say "publish" or "revise this part". The whole prompt iteration cycle happens in chat. No context switch. No dashboard.

Two transport modes support different clients. Local editors like Claude Desktop, Cursor, Codex CLI, Windsurf, and Zed get an install snippet with a scoped API key. Browser clients like claude.ai and ChatGPT connect via OAuth 2.1 with PKCE, so no raw key ever leaves the platform.

Scopes are enforced per-key. New MCP keys default to the development environment and require an explicit opt-in to enable AI features (playground, evaluations, AI rewrites) so a runaway assistant can't accidentally burn through your billing pool with unbounded calls. Every MCP-originated request is tagged in the audit log with the tool name, the client name, and the user. If your assistant does something surprising, you can see exactly what happened.

Playground, evaluations, and the co-pilot
=========================================

Beyond prompt management, PromptOT ships three interconnected features for iterating on prompts.

The playground lets you execute any published or draft prompt against any LLM model. Paste in test inputs, adjust the model config, and see the output. This is where you validate a prompt change before publishing — the same call your production app would make, but interactive.

Evaluations turn playground runs into a suite. You define reusable test cases (input plus expected output or scoring criteria), attach them to a prompt, and run all of them against a specific version. The evaluation dashboard shows pass/fail across cases, latency per call, token usage, and cost. When you're deciding whether a prompt change is an improvement or a regression, evaluations are the objective signal.

The co-pilot is a conversational AI assistant that sits alongside the block editor. You describe what you want in natural language — "make this prompt handle Spanish customers" or "add a guardrail preventing off-topic responses" — and the co-pilot proposes structured multi-block changes with inline diffs. You accept or reject each proposed change individually. The co-pilot is grounded in prompt engineering best practices, so its suggestions aren't just autocomplete — they're informed by actual patterns that work.

AI import: bring your existing prompts
======================================

If you have prompts already living in code, PromptOT has an AI-powered import tool. Paste your raw prompt string, and the importer sections it into typed blocks automatically. Role becomes a role block, guardrails become a guardrails block, and so on. You review the sectioning, adjust anything the AI got wrong, and save as a new prompt.

This turns the migration from "one hour per prompt" to "thirty seconds per prompt." Teams that have accumulated dozens of hardcoded prompt strings across a codebase can bring them all into PromptOT in an afternoon.

Team collaboration and governance
=================================

PromptOT is designed for teams, not solo builders. Organizations and projects provide two levels of scoping (one company, many projects). Role-based access control covers owner, admin, editor, and viewer at the org level plus per-project overrides. Invitations happen via email with token-based acceptance. The audit log captures every meaningful mutation — who published what, when, from which client (dashboard vs MCP). Webhooks fire on prompt lifecycle events (prompt.published, prompt.updated, prompt.deleted) with signed payloads, so you can plug PromptOT into your CI/CD.

The permission model was designed with the assumption that PMs, security reviewers, and domain experts will be reading and editing prompts — not just engineers. The dashboard is legible to non-technical stakeholders while still giving engineers the API surface they need.

Who it's for
============

PromptOT is built for AI-first product teams — companies where LLM features are core to the product rather than a novelty. That includes SaaS companies embedding assistants, generators, or agents into their app; platform teams operating multiple AI-powered surfaces (a chatbot, a code assistant, a summarizer) across shared infrastructure; consultancies and agencies shipping LLM projects for clients who need auditable prompt management; and solo developers or indie hackers who want the versioning and rollback story from day one.

If your team has more than one person editing prompts, or if your product ships prompts to real users, or if you've ever had a "why did this prompt change?" moment on a Friday afternoon — PromptOT is the tool built for that.

Pricing
=======

Free tier is genuinely free. No credit card. Covers 3 projects, 5 prompts per project, 1,000 API calls per month, 50 AI credits (for playground and co-pilot usage), and up to 5 team members.

Pro at $29 per month (or $24/month billed annually) removes those limits: unlimited projects and prompts, 100,000 API calls per month, 1,000 AI credits, unlimited team members, full version history, webhook delivery, priority support.

Enterprise is custom pricing for organizations needing SSO/SAML, audit log exports, SLA-backed availability, and dedicated support. The MCP server works on every plan, including free. AI features (playground, evaluations, AI rewrites, prompt imports, co-pilot) are opt-in per key so teams can grant MCP access without automatically enabling credit consumption.

Try it
======

If you're managing LLM prompts as constants in a TypeScript file with a TODO from six months ago, this is what fixes it.

Site: https://www.promptot.com
Docs: https://www.promptot.com/docs
MCP install: https://www.promptot.com/docs/mcp/install
Compare against alternatives: https://www.promptot.com/compare — head-to-head breakdowns vs PromptLayer, Langfuse, Humanloop, Braintrust, LangSmith, Latitude, Portkey, and more.

Sign up takes under a minute. Bring your first prompt in five.