# PromptCache > PromptCache is a hosted prompt management service for teams building on large language models. Prompts are written once, saved as immutable numbered versions, pinned to environments, and served over a stable REST API, an official JavaScript and TypeScript SDK, a remote MCP server, and an n8n community node. Source: https://promptcache.app/ --- ## Key facts - A prompt has one live draft and any number of published versions. Publishing snapshots the draft into a numbered version that can never change. - Environments point at a chosen version, so a rollback is repointing the environment rather than reverting code and redeploying. - PromptCache does not proxy model traffic. It returns the rendered prompt template and you call your own model provider directly. - PromptCache is a hosted service and is not self-hostable. Teams that require self-hosting should look at Langfuse, which is covered honestly on the comparison page. - Plans are Free at $0, Pro at $30 per month, and Enterprise at a quoted price. The free tier is self-serve and paid plans are invoiced directly rather than through a checkout. - The REST API base URL is https://api.promptcache.app and the JavaScript SDK is published on npm as @optiqlabs/promptcache-sdk. - The remote MCP server is https://api.promptcache.app/api/mcp, authenticated with OAuth 2.1 and PKCE, and works with Claude Code and other MCP clients. ## Pages ### PromptCache | AI prompt management for teams Source: https://promptcache.app/ Store, version, and ship prompts for your team: REST API, org workspaces, API keys, and a public gallery. Built for LLM apps. ### Public prompt gallery | PromptCache Source: https://promptcache.app/prompts Browse, fork, and run community prompts for Claude, GPT, and other LLMs. Every prompt is versioned and callable over the REST API. ### Pricing | PromptCache Source: https://promptcache.app/pricing Start free and upgrade as your team grows. Compare prompt limits, workspace seats, and API quotas across every PromptCache plan. ### About | PromptCache Source: https://promptcache.app/about Why we built PromptCache: prompts belong in version control and behind a stable API, not hardcoded in application source. ### Contact | PromptCache Source: https://promptcache.app/contact Questions about PromptCache, billing, or support? Reach the team and we will get back to you. ### Privacy policy | PromptCache Source: https://promptcache.app/privacy How PromptCache collects, stores, and processes your data, including prompts, account details, and usage analytics. ### Terms of service | PromptCache Source: https://promptcache.app/terms The terms that govern your use of PromptCache, including acceptable use, billing, and account termination. ## Pricing | Plan | Price | For | Includes | | --- | --- | --- | --- | | Free | $0 | For individuals getting started with prompt versioning | 100 prompts, 1 user seat, Core version history, Community support | | Pro | $30/month | For teams that need room to grow | Unlimited prompts, Unlimited users, Full version history, Priority support, Team collaboration | | Enterprise | Custom | Dedicated deployment with custom configurations | Dedicated instance, Custom configurations, SSO / SAML, Dedicated support, SLA guarantee | The free tier is self-serve. Paid plans are invoiced directly rather than through a checkout. ## Frequently asked questions ### Do I have to send my model calls through you? No. PromptCache returns the rendered prompt; you call your own model provider directly. Nothing proxies your traffic. ### What happens to a published version if I edit the draft? Nothing. A published version is immutable. The draft is separate and affects nobody until you publish again. ### Can I self-host it? No. PromptCache is a hosted service. If self-hosting is a requirement, the Langfuse comparison covers that trade-off honestly. ### How does billing work? The free tier is self-serve. Paid plans are invoiced directly rather than through a checkout, so talk to us when you outgrow free. # Guides # What is prompt versioning? > Prompt versioning is the practice of saving each change to an AI prompt as an immutable, numbered snapshot. Each version can be pinned to an environment, compared against any other, and rolled back independently, so changing production wording becomes a deliberate, recorded act instead of an edit buried in a code diff. Source: https://promptcache.app/blog/what-is-prompt-versioning Published: 2026-09-17 | Updated: 2026-09-17 | Author: Viraj Lakshitha | Tags: prompt versioning, LLM, prompt management --- Prompts drift. A wording tweak to stop a model rambling, a new constraint bolted on after a support ticket, an instruction someone removed because it "seemed redundant", six weeks later the prompt in production is not the prompt anyone designed, and nobody can say when it changed or why. Prompt versioning is the fix, and it borrows its shape from something engineering teams already trust: release management. ## What does versioning a prompt actually mean? Three things have to be true before a prompt is meaningfully versioned. **Every change produces an immutable snapshot.** Not a diff in a file, not an edit log, a numbered version whose content can never change once created. Version 4 is version 4 forever. **Something records which version is live.** A version nobody points at is just history. The useful part is a pointer, often called an environment, a label, or a tag, that says "production resolves version 4." **Moving the pointer is a deliberate act.** Publishing a draft should not silently change what production serves. The two operations are separate on purpose. If your setup has all three, you can answer the question that matters during an incident: _what exactly was this model asked to do at 3am, and what changed since?_ ## Why not just keep prompts in Git? This is the most common objection, and it is a reasonable one. Git already versions text. The problem is not storage. It is coupling. When the prompt lives in the source tree, changing the prompt means changing the application: a commit, a review, a pipeline, a deploy. That is exactly the right amount of ceremony for a change to your retry logic, and far too much for changing the word "concise" to "brief." Worse, the rollback story is bad. Reverting a prompt means reverting a commit and shipping again, while the bad prompt keeps serving traffic for however long your pipeline takes. Prompt versioning separates the two release cycles. The application deploys when the application changes. The prompt moves when the prompt changes. Neither blocks the other. > Keeping prompts in Git is not wrong. It is just a decision to give wording changes the same release cadence as code, which is a cost worth paying deliberately, not by default. ## Drafts, versions, and environments Most tools converge on roughly the same three concepts, even where the vocabulary differs. | Concept | What it is | Who changes it | | ----------- | ------------------------------------------------------ | --------------------- | | Draft | The live, editable state of a prompt | Anyone authoring | | Version | An immutable numbered snapshot of a draft | Created by publishing | | Environment | A pointer to the version that a given context resolves | Moved deliberately | The important property is that these move independently. You can publish version 7 while production stays on version 4, the new version exists, is testable, and is not yet serving anyone. ## What rollback looks like This is where versioning earns its keep. With prompts in code, rollback is: identify the commit, revert it, run CI, deploy, wait. Minutes at best. With versioned prompts, rollback is repointing production from version 5 back to version 4. The next API call resolves the older snapshot. No pipeline, no deploy, and the application binary never changed. ```ts // The application calls the same endpoint regardless of which version is live. const { renderedContent } = await client.prompts.invoke(promptId, { variables: { customerName: 'Ada' }, }); ``` Notice what is _not_ in that code: a version number. The application asks for the prompt; the environment decides which version that resolves to. Which is precisely why rollback needs no deploy. ## When you do not need this Honesty is worth more than a pitch here. If you have one prompt, one developer, and no production traffic, versioning is overhead. Put the string in your source file and move on. The cost of prompt versioning is real, another system, another concept for new teammates to learn. The moment it starts paying for itself is usually one of these: - Someone who does not deploy code needs to change prompt wording - Two environments need different prompt versions at the same time - You have had to answer "what changed?" about model behaviour and could not ## Where to go next If you are at the point where prompts need structure, [how to organize prompts efficiently](/blog/how-to-organize-prompts) covers naming, variables, and keeping a library navigable. If you are wiring this into an application, [prompt API best practices](/blog/prompt-api-best-practices) covers pinning, variable handling, and key scoping. PromptCache implements the model described here, drafts, published versions, and environment slots, behind a REST API and [TypeScript SDK](https://docs.promptcache.app/sdk). You can also [browse public prompts](/prompts) to see versioned prompts in the open. ## Frequently asked questions ### Why not just keep prompts in Git? Git versions your source, so a prompt change is a code change: commit, review, redeploy. That is appropriate for logic and heavy for wording. Prompt versioning separates the two, letting a prompt move through its own release cycle while the application binary stays put. ### What is the difference between a draft and a version? A draft is the live, editable state of a prompt. Publishing snapshots that draft into a numbered version that can never change. Drafts are where you work; versions are what your application resolves. ### How does rolling back a prompt work? If each environment points at a chosen version, a rollback is repointing that pointer at the previous version. No revert commit and no redeploy, the next API call resolves the older snapshot. ### Does prompt versioning require changing application code? No. The application calls a stable endpoint for a prompt and receives whichever version the target environment currently resolves to. Version changes happen behind that call. # How to organize prompts efficiently > Organize prompts by the job they do rather than the model they target: give each a predictable name, extract every changing value into a named variable, keep one prompt per task instead of branching inside a template, and separate what is being tested from what is serving production traffic. Source: https://promptcache.app/blog/how-to-organize-prompts Published: 2026-09-17 | Updated: 2026-09-17 | Author: Viraj Lakshitha | Tags: prompt management, team workflow, LLM --- A prompt library goes bad quietly. It starts as six prompts everyone remembers. Then someone adds `summarize-v2-final`, someone else copies a prompt to tweak it for a different model, and a year later there are forty prompts and nobody is confident which ones production actually calls. Nothing dramatic happened. There was just never a structure. ## Name prompts after the job, not the model The most common naming mistake is encoding implementation details into the name: `gpt4-summarizer`, `claude-ticket-parser-v3`. Model names age badly. When you migrate providers, either every name lies or you rename everything and break every caller. Version suffixes are worse, that is what versioning is for, and a name ending in `-v3` guarantees a `-v3-final` eventually. Name for the job being done: | Avoid | Prefer | | ------------------ | -------------------------- | | `gpt4-summarizer` | `support-ticket-summary` | | `claude-parser-v3` | `invoice-field-extraction` | | `prompt-new-2` | `onboarding-welcome-email` | A good test: if someone reads the name in an application log with no other context, do they know what it does? ## Extract every changing value into a variable The second failure mode is prompts that differ only in a substituted value. Someone needs the summary prompt for a different tone, copies it, changes two words, and now there are two prompts that will drift apart. If a value changes per call, it is a variable, not a new prompt. ```text Summarize the following support ticket in {{sentence_count}} sentences. Tone: {{tone}}. Ticket: {{ticket_body}} ``` Define variables alongside the template, each with a name, a type, and a default where one makes sense. Variables discovered only at call time are undocumented API surface: when a caller forgets one, the template renders with a blank where meaning should be, and the model produces something confidently wrong rather than failing. ## One prompt per task, fork when wording truly diverges Resist branching inside a template. A prompt with `{{#if model == "claude"}}` inside it is two prompts wearing a trench coat, and it will be impossible to evaluate either half. The rule of thumb: - **Same task, different values** → one prompt, more variables - **Same task, genuinely different instructions per model** → fork into separate prompts - **Different task** → always a separate prompt Forking is not a failure. It is the correct move when two paths have really diverged, and it is much easier to reason about than conditional logic inside a template. ## Separate what is being tested from what is serving This is the structural decision that matters most, and the one teams skip. Authoring, testing, and serving production traffic are three different activities, and they need to be visibly separate. If editing a prompt immediately changes what customers see, every experiment is a production change. The pattern that works: 1. Edit the draft freely. It affects nobody 2. Publish when the change is worth keeping. This creates an immutable version 3. Point a non-production environment at the new version and exercise it 4. Move production only when you mean it The point is not process for its own sake. It is that "I am trying something" and "customers are now seeing this" should never be the same keystroke. ## Decide who can change what Once more than one person touches prompts, access matters, and it is usually the thing that gets bolted on too late. Two questions worth answering early: **Who can move production?** Publishing a version and promoting it are different privileges. Plenty of teams want writers publishing freely while a smaller group controls what production resolves. **What can each integration do?** A service that only renders prompts should hold a read-scoped key. If your summarization worker's credentials can also delete prompts, that is a blast radius with no upside. ## A structure that holds up Putting it together, a library that stays navigable past the first dozen prompts tends to look like this: - Prompts named for their job, stable across model migrations - Every per-call value a declared variable with a type - One prompt per task; forks where instructions genuinely diverge - Drafts, published versions, and environment pointers kept distinct - Scoped keys, with production promotion held more tightly than authoring None of this requires a particular tool. It does require deciding on the structure before the library grows past the point where anyone remembers what is in it. ## Related reading [What is prompt versioning?](/blog/what-is-prompt-versioning) covers the draft/version/environment model in more depth. [Prompt API best practices](/blog/prompt-api-best-practices) covers the calling side, pinning versions, handling missing variables, and scoping keys. PromptCache organizes prompts this way by default: named prompts with typed variables, published versions, and environment slots. [See how it works](/pricing) or [browse the public gallery](/prompts). ## Frequently asked questions ### How many prompts is too many for one workspace? Volume matters less than whether a prompt can be found by name. Problems begin when two prompts do nearly the same thing and nobody can say which one production uses. ### Should each model have its own prompt? Only where wording genuinely diverges. Prefer one prompt per task with variables for the parts that change; fork to a separate prompt when a model needs materially different instructions. ### Where should prompt variables be defined? Alongside the template, with a name, type, and default. Variables discovered only at call time become undocumented API surface that breaks silently. # Prompt API best practices > A prompt API should be stable across every prompt change: applications call one endpoint per prompt, environments decide which version resolves, required variables fail loudly rather than rendering blank, and API keys are scoped to a single workspace with read-only access wherever writes are not needed. Source: https://promptcache.app/blog/prompt-api-best-practices Published: 2026-09-17 | Updated: 2026-09-17 | Author: Viraj Lakshitha | Tags: prompt API, REST API, LLM, best practices --- Once an application fetches its prompts over the network instead of reading them from its own source, the prompt store becomes a production dependency. It sits in the request path, it can fail, and a careless change to it can alter behaviour for every caller at once. These are the practices that keep that dependency boring. ## Pin production to an explicit version The default in most tools is to resolve "latest". It is convenient and it is the wrong setting for production. Resolving latest means anyone publishing a prompt changes production behaviour immediately, including someone who was only trying something out. The blast radius of a publish becomes the entire production surface. Point each environment at a chosen version, and move that pointer deliberately: ```ts // The caller names the prompt and the environment, never a version number. const { renderedContent } = await client.prompts.invoke(promptId, { environment: 'production', variables: { ticketBody }, }); ``` Keeping the version out of application code is the point. The environment decides what resolves, so promoting or rolling back never requires a deploy. ## Fail loudly on missing variables When a required variable is absent, there are two possible behaviours, and only one of them is defensible. Rendering the template anyway produces a prompt with a hole in it, `Summarize the following ticket:` followed by nothing. The model will answer. It will answer confidently. And the failure surfaces days later as "the summaries got weird" rather than as an error with a stack trace. Fail the request instead. A missing required variable is a programming error, and it should look like one. There is a legitimate place for lenient rendering: previewing a draft while authoring, where half-filled output is the point. Keep that mode clearly separate from the one production calls. ## Scope keys narrowly, one workspace each Treat prompt API keys exactly like database credentials, because that is what they are. | Consumer | Needs | Should not have | | ----------------- | ------------- | ----------------------------- | | Rendering service | Read + invoke | Publish, delete | | CI evaluation job | Read | Any write | | Admin tooling | Full | Production promotion, ideally | A key bound to one workspace limits what a leak reaches. A read-only key on the service that merely renders prompts means a compromised worker cannot rewrite what every other caller resolves. Rotate on a schedule, and make sure revoking a key is something you can do in seconds without a deploy. ## Cache the template, not the completion Prompt fetches are network calls, and you do not want one on every request. But be precise about what is cacheable. **The resolved template is safely cacheable.** A published version is immutable, so version 4 of a prompt is byte-identical forever. Cache it as long as you like. **The model completion is not.** Different variables produce different output; caching across variable sets is a correctness bug, not an optimization. The subtlety is invalidation. If you cache by prompt name, you must invalidate when the environment pointer moves, or a rollback will not take effect until your TTL expires, which is precisely when you least want to wait. Either cache by resolved version id, or keep the TTL short enough that a rollback is meaningfully fast. ## Degrade deliberately when the store is unreachable Any network dependency fails eventually. Decide in advance what happens, because the default, an unhandled exception in your request path, is rarely what you want. The options, roughly in order of preference: 1. **Serve the last known good template from cache.** Versions are immutable, so a stale cached version is a valid prompt, not a corrupted one. 2. **Fall back to a bundled default** for paths that must never fail, accepting that it may be older. 3. **Fail the request explicitly** where a wrong prompt is worse than no answer. What to avoid is silently substituting an empty or partial prompt. A degraded prompt that still calls the model spends money to produce output nobody should trust. ## Keep the call surface stable The last practice is the one that makes everything above possible: application code should name _what_ it wants, never _which revision_. One endpoint per prompt. Variables passed as structured data. Environment selection from configuration, not hardcoded. When those hold, every prompt change, publish, promote, roll back, happens without touching the application. When they do not hold, you have re-coupled prompt changes to deploys, and you are back where you started with extra network calls. ## Related reading [What is prompt versioning?](/blog/what-is-prompt-versioning) explains the draft, version, and environment model these practices assume. [How to organize prompts efficiently](/blog/how-to-organize-prompts) covers the authoring side. The [PromptCache API docs](https://docs.promptcache.app/prompts) document the invoke surface, variable handling, and key scopes described here. ## Frequently asked questions ### Should production pin an exact prompt version? Yes. Resolving "latest" means an unrelated publish can change production behaviour without a deploy. Pin an environment to a chosen version and move it deliberately. ### What should happen when a required variable is missing? Fail the request. Rendering a template with a blank where a value belongs sends a malformed prompt to the model and surfaces as a confusing output rather than an error. ### How should prompt API keys be scoped? One workspace per key, with the narrowest scope the caller needs. A service that only renders prompts should not hold a key that can publish them. ### Should prompt responses be cached? Cache the resolved template, not the model output. A pinned version is immutable, so it caches safely until the environment pointer moves. # Prompt management tools compared (2026) > Nearly every tool in this category now versions prompts and promotes them to environments by label, so that is no longer a useful way to tell them apart. What differs is the centre of gravity, observability, evaluation, gateway routing, or the prompt store itself, and whether your model traffic has to pass through the vendor. Source: https://promptcache.app/blog/prompt-management-tools Published: 2026-09-17 | Updated: 2026-09-17 | Author: Viraj Lakshitha | Tags: prompt management, tools, comparison --- Search "prompt management" and you get a dozen products that describe themselves almost identically. Reading their marketing pages does not separate them, because at the feature-checklist level they have converged. So let us start by removing the criterion most comparison posts lead with. ## Versioning is table stakes now As of September 2026, every established tool in this space versions prompts and lets you promote a version to an environment by label or tag. Verified against each vendor's own documentation: | Tool | Prompt versioning | Environment / label promotion | | -------------------------------------------------------------------------------------- | ------------------------- | ---------------------------------------- | | [Langfuse](https://langfuse.com/docs/prompt-management/get-started) | Yes | Labels, including `production` | | [PromptLayer](https://docs.promptlayer.com/features/prompt-registry/overview) | Yes, with commit messages | Release labels such as `prod`, `staging` | | [LangSmith](https://docs.langchain.com/langsmith/prompt-engineering-concepts) | Yes, commit hashes | Movable tags | | [Braintrust](https://www.braintrust.dev/docs/guides/prompts) | Yes | Environment parameter | | [Helicone](https://docs.helicone.ai/features/advanced-usage/prompts/overview) | Yes, with rollback | Production, staging, development, custom | | [Portkey](https://portkey.ai/docs/product/prompt-engineering-studio/prompt-versioning) | Yes | Labels, including three defaults | | PromptCache | Yes | Preview and production slots | If a comparison tells you that one of these tools "adds versioning" others lack, it is out of date. Pick on something else. ## The question that actually separates them **Does your model traffic pass through the vendor?** This is an architectural fork, not a feature, and it has consequences that are hard to reverse later. **Gateway-delivered prompts.** Helicone's documentation describes prompts being retrieved through its AI Gateway, you send `prompt_id` and inputs, and Helicone compiles the prompt and sends it to your chosen model. Portkey describes itself as an AI gateway with prompt management and routing built in. In both cases the prompt and the model call arrive together. That buys real things: automatic tracing of every call, cost attribution, provider failover, retries. It also means the vendor sits in your request path and sees your prompts and completions. **Standalone prompt delivery.** The other model returns the rendered template and stops. Your code calls the model with your own credentials. You get no automatic tracing from the prompt store, you have to instrument it yourself, but the vendor is not in the path between you and your provider. Neither is better in the abstract. But "do I want a proxy in front of my LLM traffic?" is a decision to make on purpose. ## What each tool is built around Beyond that fork, the useful distinction is centre of gravity: the problem the product was designed to solve first. **Langfuse** is open-source and self-hostable, combining tracing, evaluation, and prompt labels. Its SDKs cache prompts client-side, so after the first fetch they are served from memory. If keeping trace and prompt data on your own infrastructure is a requirement, self-hosting is the differentiator that matters most here. [Comparison →](/compare/promptcache-vs-langfuse) **PromptLayer** pairs a versioned registry with a playground, analytics, and evaluations, and supports protecting important labels behind approval workflows. It is organized around prompts as a shared team asset. [Comparison →](/compare/promptcache-vs-promptlayer) **LangSmith** versions prompts by commit hash with movable tags, inside LangChain's broader platform. If you already run LangChain, the integration story is the reason to pick it. [Comparison →](/compare/promptcache-vs-langsmith) **Braintrust** is built around evaluation. Prompt versioning and environments are present, but the depth is in measuring whether a prompt actually performs. If your open problem is "is this prompt better?", start here. [Comparison →](/compare/promptcache-vs-braintrust) **Helicone** is observability-first, prompts are delivered through the same gateway that records your calls, with variables, prompt partials, and instant rollback. [Comparison →](/compare/promptcache-vs-helicone) **Portkey** is a gateway first: routing, failover, and provider abstraction, with a prompt studio attached. Versioning is available on all pricing tiers. [Comparison →](/compare/promptcache-vs-portkey) **PromptCache** is the prompt store on its own. Prompts are published into numbered versions, environment slots decide what resolves, and the API returns the rendered template, it does not proxy your model calls. Its distinctive integration paths are a remote MCP server used from Claude Code and other MCP clients, an n8n community node, and a public prompt gallery with forking. It does not attempt to match the evaluation depth of Braintrust or the tracing depth of Langfuse and Helicone. ## How to choose Rather than comparing feature grids, name your open problem: - _"I cannot tell why output changed."_ → Observability-first: Helicone, Langfuse - _"I cannot tell if this prompt is better."_ → Evaluation-first: Braintrust - _"I need failover across providers."_ → Gateway: Portkey - _"My data cannot leave our infrastructure."_ → Self-hostable: Langfuse - _"We already run LangChain."_ → LangSmith - _"I just need prompts out of the codebase and behind a stable API."_ → A standalone store such as PromptCache Most teams have exactly one of these problems at a time. Buying for the other five is how you end up with a tool nobody logs into. ## A note on this comparison PromptCache publishes this, so read it accordingly. The check we hold ourselves to: every claim above is drawn from the vendor's own public documentation and linked, and each [individual comparison page](/compare) carries the date it was last verified. These products ship quickly. If something here is out of date, [tell us](mailto:hello@promptcache.app) and we will correct it. ## Frequently asked questions ### What is the difference between prompt management and LLM observability? Observability records what happened after a call: inputs, outputs, latency, and cost. Prompt management governs what gets sent in the first place. Most established tools now do both, so the practical question is which half the product was designed around. ### Do I need a separate tool if I already use an LLM gateway? Often not. Gateways like Portkey and Helicone include prompt management, but they deliver prompts through their proxy, so your model traffic passes through the vendor. A standalone prompt store returns the rendered template and leaves the model call to you. ### Does every prompt management tool support versioning and rollback? As of September 2026, all of the established tools reviewed here do. Langfuse, PromptLayer, LangSmith, Braintrust, Helicone, Portkey, and PromptCache all version prompts and let you move an environment pointer between versions. Treat versioning as table stakes rather than a differentiator. ### Are open-source prompt management tools viable in production? Yes, and several are self-hostable. The tradeoff is operational: you run the database, upgrades, and availability yourself in exchange for keeping prompt and trace data on your own infrastructure. # Comparisons # PromptCache vs Langfuse > Langfuse is open-source and self-hostable with tracing and evaluation alongside prompt labels; PromptCache is a hosted, prompt-focused service with MCP and n8n integration paths. Source: https://promptcache.app/compare/promptcache-vs-langfuse Compared with: Langfuse (https://langfuse.com) | Claims verified against vendor documentation on: 2026-09-17 | Updated: 2026-09-17 --- Both tools version prompts and promote them to environments by label, so the choice is not about which one "has versioning". It is about self-hosting, how much observability you want bundled in, and how you integrate. ## Feature comparison | | PromptCache | Langfuse | | ------------------------ | -------------------------------------------------- | ---------------------------------------------------------- | | Prompt versioning | Numbered versions created by publishing | Versions with labels | | Environment promotion | Preview and production slots | Labels, including `production`; protected labels available | | Self-hosting | No, hosted service | Yes, self-hosting documented | | Open source | No | Yes | | Tracing / observability | Not offered | Core product capability | | Evaluation | Evals workspace with datasets and multi-model runs | Core product capability | | Client-side caching | Not documented | SDKs cache prompts client-side after first fetch | | Proxies your model calls | No | No | | MCP server | Yes, remote MCP over OAuth 2.1 + PKCE | Not documented | | n8n node | Yes, read-only community node | Not documented | | Public prompt gallery | Yes, with forking | Not documented | ## Where Langfuse is the better choice **You need to self-host.** This is the clearest dividing line. Langfuse is open source and documents self-hosting; PromptCache is a hosted service only. If prompt and trace data cannot leave your infrastructure for regulatory or policy reasons, that decides it, and nothing below outweighs it. **You want tracing and prompt management from one vendor.** Langfuse combines prompt labels with tracing and evaluation. PromptCache does not offer tracing at all, you would instrument your own calls or run a separate observability tool alongside it. **Latency on prompt fetches concerns you.** Langfuse documents client-side caching in its SDKs, so prompts are served from memory after the first fetch. **You want an open-source dependency.** If avoiding a proprietary vendor in your stack is a requirement, Langfuse qualifies and PromptCache does not. ## Where PromptCache differs **Assistant and workflow integration.** PromptCache runs a remote MCP server with OAuth 2.1 and PKCE, so prompts can be read and rendered directly from Claude Code and other MCP clients, plus a read-only n8n community node for workflow automation. Langfuse's documentation does not describe equivalent integrations. **A smaller surface.** Langfuse is an LLM engineering platform; prompt management is one part of it. If prompts are the only problem you have, most of that platform is unused. PromptCache does one thing, which means less to learn and less to run, and also means it will not grow into your observability tool. **A public gallery.** Prompts can be published publicly with organization attribution and forked by others. ## Honest limitations Billing on paid plans is invoiced manually rather than through self-serve checkout. Langfuse is a more mature and considerably broader product, and if you are evaluating on breadth it wins that comparison outright. ## Sources - [Langfuse prompt management documentation](https://langfuse.com/docs/prompt-management/get-started) - [PromptCache documentation](https://docs.promptcache.app/) Claims about Langfuse are drawn from the page linked above. Where its documentation does not state something, this page says "not documented" rather than asserting absence. ## Frequently asked questions ### Can PromptCache be self-hosted like Langfuse? No. Langfuse is open source and documents self-hosting; PromptCache is a hosted service only. If prompt and trace data cannot leave your own infrastructure, that decides the question on its own. ### Does either tool proxy your model calls? Neither does. Both return the prompt and leave the model call to your code, so choosing between them is not a decision about what sits in your request path. ### Which one gives you tracing and evaluation? Langfuse, where both are core product capabilities. PromptCache ships an evals workspace with datasets and multi-model runs but does not offer tracing, so you would instrument your own calls or run a separate observability tool alongside it. ### How does environment promotion differ? Langfuse uses labels, including a production label, with protected labels available. PromptCache uses preview and production slots, each resolving one chosen numbered version. # PromptCache vs PromptLayer > PromptLayer pairs its prompt registry with a playground, analytics, and evaluations; PromptCache keeps the surface smaller and focuses on the API and integration path. Source: https://promptcache.app/compare/promptcache-vs-promptlayer Compared with: PromptLayer (https://www.promptlayer.com) | Claims verified against vendor documentation on: 2026-09-17 | Updated: 2026-09-17 --- PromptLayer and PromptCache are the closest pairing in this comparison set: both are built around a versioned prompt registry that applications read at runtime, and neither proxies your model calls. The difference is breadth. ## Feature comparison | | PromptCache | PromptLayer | | ------------------------ | --------------------------------------- | ------------------------------------------------ | | Prompt versioning | Numbered versions created by publishing | Version history with commit messages | | Environment promotion | Preview and production slots | Release labels such as `prod` and `staging` | | Approval workflows | Not offered | Important labels can be protected with approvals | | Organization | Prompts, tags, organization workspaces | Folders, tags, workspace search | | Playground | Draft preview with variable injection | Playground for testing changes | | Analytics | Not offered | Prompt-level logs, analytics, evaluations | | Runtime access | REST API and TypeScript SDK | Python and JavaScript SDKs | | Proxies your model calls | No | No | | MCP server | Yes, remote MCP over OAuth 2.1 + PKCE | Not documented | | n8n node | Yes, read-only community node | Not documented | | Public prompt gallery | Yes, with forking | Not documented | ## Where PromptLayer is the better choice **You want approval gates on production changes.** PromptLayer documents protecting important labels with approval workflows. PromptCache separates publishing from promotion but does not offer a formal approval step, so if a reviewer must sign off before production moves, PromptLayer covers that natively. **You want prompt analytics in the same tool.** PromptLayer includes prompt-level logs, analytics, and evaluations tied to each template. PromptCache has an evals workspace for running experiments, but does not provide production analytics on how a prompt performs under real traffic. **You have a large library to navigate.** Folders plus workspace search is a meaningfully better organizational model once a library grows large. **Your stack is Python-first.** PromptLayer documents both Python and JavaScript SDKs. PromptCache publishes a TypeScript/JavaScript SDK; Python consumers would call the REST API directly. ## Where PromptCache differs **Assistant and workflow integration.** The remote MCP server means prompts are reachable from Claude Code and other MCP clients through an OAuth flow, and the n8n node exposes read operations to workflow automation. PromptLayer's registry documentation does not describe equivalent paths. **Immutable numbered versions.** Publishing snapshots a draft into a version that cannot change, and environment slots point at a chosen version. Functionally close to release labels, with the distinction that the snapshot is explicitly immutable. **A public gallery.** Prompts can be shared publicly and forked, which PromptLayer's documentation does not describe. ## Honest limitations Paid plans are invoiced manually, there is no self-serve checkout. PromptLayer is the more established product with a broader feature set around the registry, and if you want prompt management, testing, and analytics from one vendor it is the more complete answer today. ## Sources - [PromptLayer Prompt Registry documentation](https://docs.promptlayer.com/features/prompt-registry/overview) - [PromptCache documentation](https://docs.promptcache.app/) Where PromptLayer's documentation does not address a capability, this page records it as "not documented" rather than claiming the feature is absent. ## Frequently asked questions ### How similar are PromptLayer and PromptCache? They are the closest pairing in this comparison set. Both are built around a versioned prompt registry that applications read at runtime, and neither proxies your model calls. The difference is breadth rather than approach. ### Does PromptCache support approval workflows? Not as a formal step. PromptLayer documents protecting important labels with approvals. PromptCache separates publishing a version from pointing an environment at it, which is a safety boundary but not a reviewer sign-off. ### Is there a Python SDK for PromptCache? No. PromptLayer documents both Python and JavaScript SDKs. PromptCache publishes a TypeScript and JavaScript SDK, so Python consumers would call the REST API directly. ### Which tool gives you prompt analytics? PromptLayer, which includes prompt-level logs, analytics, and evaluations tied to each template. PromptCache has an evals workspace for running experiments but does not report on how a prompt performs under real production traffic. # PromptCache vs LangSmith > LangSmith versions prompts by commit hash with movable tags inside LangChain’s wider platform; PromptCache is a standalone prompt store with its own REST API and SDK. Source: https://promptcache.app/compare/promptcache-vs-langsmith Compared with: LangSmith (https://www.langchain.com/langsmith) | Claims verified against vendor documentation on: 2026-09-17 | Updated: 2026-09-17 --- LangSmith and PromptCache both let an application pull a specific prompt revision at runtime. They differ in how a revision is identified, and in how much platform comes along with it. ## Feature comparison | | PromptCache | LangSmith | | ------------------------ | -------------------------------------------------- | -------------------------------------------------- | | Version identity | Sequential numbered versions | Automatic commits with unique hashes | | Environment promotion | Preview and production slots | Tags as movable pointers to commits | | Runtime fetch | `invoke` over REST API and SDK | `client.pull_prompt("name:commit_hash")` | | Version comparison | Diff view between any two versions | Playground comparison across variants and datasets | | Evaluation | Evals workspace with datasets and multi-model runs | Playground testing across datasets | | Tracing / observability | Not offered | Core platform capability | | Framework positioning | Framework-agnostic | Part of the LangChain platform | | Proxies your model calls | No | No | | MCP server | Yes, remote MCP over OAuth 2.1 + PKCE | Not documented | | Public prompt gallery | Yes, with forking | Not documented | Both use the same underlying idea for promotion: a movable pointer that application code references instead of a fixed revision, so moving between versions needs no deploy. LangSmith calls it a tag; PromptCache calls it an environment slot. ## Where LangSmith is the better choice **You already run LangChain.** This is the main reason to choose it. LangSmith is part of that platform, and if your application is built on LangChain the prompt store, tracing, and evaluation all sit in the ecosystem you are already in. Adding a separate prompt vendor to a LangChain stack is friction with little to show for it. **You want tracing alongside prompts.** LangSmith is an observability platform first. PromptCache does not offer tracing, you would instrument calls yourself or run a separate tool. **You want commit-hash addressing.** Referencing an exact immutable hash is familiar if you think in Git terms, and it makes "exactly this revision" unambiguous in code. **You want to compare prompt variants against datasets in a playground.** LangSmith documents testing across multiple variants and datasets interactively. ## Where PromptCache differs **No framework assumption.** PromptCache is a plain REST API with a TypeScript SDK. Nothing about it expects a particular orchestration framework, which matters if you call provider SDKs directly or expect to change frameworks. **Human-readable version numbers.** Versions are sequential integers rather than hashes. `v4` is easier to discuss in a standup or an incident channel than a truncated hash, though it carries less information. **Assistant and workflow integration.** The remote MCP server exposes prompts to Claude Code and other MCP clients over OAuth, and an n8n community node covers read operations in workflow automation. **A public gallery.** Prompts can be published publicly with attribution and forked. ## Honest limitations Paid plans are invoiced manually rather than through self-serve checkout. LangSmith is part of a considerably larger and more mature platform. If you want prompt management, tracing, and evaluation from one vendor, particularly on a LangChain stack, this comparison is not close. ## Sources - [LangSmith prompt engineering concepts](https://docs.langchain.com/langsmith/prompt-engineering-concepts) - [PromptCache documentation](https://docs.promptcache.app/) Claims about LangSmith come from the page linked above. Its documentation does not discuss framework coupling directly, so the positioning note above reflects that LangSmith is published as part of the LangChain platform rather than any stated technical dependency. ## Frequently asked questions ### How do LangSmith and PromptCache identify a prompt version? LangSmith creates automatic commits with unique hashes, pulled by name and commit hash. PromptCache uses sequential numbered versions that an environment slot resolves. ### Do you need LangChain to use LangSmith prompts? LangSmith is part of the LangChain platform, so if your application already runs LangChain the prompt store, tracing, and evaluation all sit in the ecosystem you are in. PromptCache is framework-agnostic and reached over its own REST API and SDK. ### Does either tool proxy your model calls? Neither does. Both hand the prompt back and leave the provider call to your code. ### How do the two handle promotion between environments? Both use a movable pointer that application code references instead of a fixed revision, so moving between versions needs no deploy. LangSmith calls it a tag; PromptCache calls it an environment slot. # PromptCache vs Braintrust > Braintrust is built around evaluation depth, with prompt versions and environments attached; PromptCache focuses on storing and serving prompts and does not match that evaluation scope. Source: https://promptcache.app/compare/promptcache-vs-braintrust Compared with: Braintrust (https://www.braintrust.dev) | Claims verified against vendor documentation on: 2026-09-17 | Updated: 2026-09-17 --- These two products answer different questions. Braintrust is organized around _is this prompt any good?_ PromptCache is organized around _which prompt is production running, and how do I change it safely?_ Both do some of the other's job. Neither does it as well. ## Feature comparison | | PromptCache | Braintrust | | ------------------------ | ------------------------------------------------------------- | ---------------------------------------------------- | | Prompt versioning | Numbered versions created by publishing | New version with unique ID on each save | | Environment promotion | Preview and production slots | `environment` parameter for dev, staging, production | | Version pinning | Environment slot resolves a chosen version | Pin a version in code, or default to latest | | Evaluation | Evals workspace: datasets, multi-model runs, streamed results | Core product, the platform is built around it | | Local compilation | Not documented | `loadPrompt()` compiles locally without an API call | | Runtime access | REST API and TypeScript SDK | SDK `invoke()`, REST API, `bt` CLI | | Tracing integration | Not offered | Prompts nest as child spans in instrumented traces | | Proxies your model calls | No | `invoke()` calls the model; `loadPrompt()` does not | | MCP server | Yes, remote MCP over OAuth 2.1 + PKCE | Not documented | | Public prompt gallery | Yes, with forking | Not documented | ## Where Braintrust is the better choice **Evaluation is your actual problem.** If the open question is whether a prompt change improved anything, Braintrust is built for that and PromptCache is not. PromptCache does ship an evals workspace with datasets, multi-model runs, and streamed per-case results, but Braintrust's entire product is organized around measurement, and the depth is not comparable. **You want prompts inside your traces.** Braintrust documents prompts automatically nesting as child spans within parent traces when called from instrumented code. That connection between "which prompt ran" and "what the trace shows" is genuinely useful during debugging, and PromptCache offers nothing equivalent. **You want local compilation.** `loadPrompt()` compiles a prompt locally without an API call, which removes the prompt store from your request path entirely. **You want a CLI.** Braintrust documents a `bt` command-line tool for browsing and testing prompts from the terminal. ## Where PromptCache differs **Promotion is explicit rather than a default.** Braintrust's documentation notes you can pin a version or rely on the latest by default. PromptCache requires an environment slot to point at a chosen version, there is no "latest" resolution in production, which removes a class of accidental change. **It does not call the model for you.** PromptCache returns the rendered template; your code makes the model call with your own credentials. Braintrust's `invoke()` calls the model on your behalf, though `loadPrompt()` gives you the local path. **Assistant and workflow integration.** The remote MCP server and n8n community node have no documented equivalent in Braintrust. ## A note on scope If you are choosing between these two, it is worth asking whether you are really choosing. Teams running serious evaluation and teams needing a prompt store are often at different stages of the same journey, and the products do not overlap enough to make one a drop-in replacement for the other. ## Honest limitations Paid plans are invoiced manually, with no self-serve checkout. On evaluation specifically, the thing Braintrust exists to do | PromptCache is not a substitute. ## Sources - [Braintrust prompts documentation](https://www.braintrust.dev/docs/guides/prompts) - [PromptCache documentation](https://docs.promptcache.app/) Where Braintrust's documentation does not address a capability, this page records it as "not documented" rather than asserting absence. ## Frequently asked questions ### Does PromptCache do evaluation the way Braintrust does? Not to the same depth, and the honest answer is that it is not close. PromptCache ships an evals workspace with datasets, multi-model runs, and streamed per-case results. Braintrust is organized around measurement as its entire product. ### Does Braintrust proxy your model calls? It depends on the method. Braintrust documents an invoke method that calls the model for you, and a loadPrompt method that compiles a prompt locally without an API call. PromptCache never calls the model under any method. ### Can prompts be compiled locally without a network call? Braintrust documents loadPrompt for exactly that, which removes the prompt store from your request path. Local compilation is not documented for PromptCache. ### Which problem is each tool built for? Braintrust answers whether a prompt is any good. PromptCache answers which prompt production is running and how to change it safely. Both do some of the other job, and neither does it as well. # PromptCache vs Helicone > Helicone compiles and sends prompts through its AI Gateway alongside observability; PromptCache returns the rendered template over a standalone REST API and never proxies your model traffic. Source: https://promptcache.app/compare/promptcache-vs-helicone Compared with: Helicone (https://www.helicone.ai) | Claims verified against vendor documentation on: 2026-09-17 | Updated: 2026-09-17 --- Helicone and PromptCache both version prompts, support multiple environments, and roll back without a deploy. The decision between them turns on one architectural question: whether your model traffic should pass through the vendor. ## Feature comparison | | PromptCache | Helicone | | ------------------------- | --------------------------------------- | --------------------------------------------------------- | | Prompt versioning | Numbered versions created by publishing | Built-in version control with instant rollback | | Environment promotion | Preview and production slots | Production, staging, development, and custom environments | | How prompts are delivered | REST API returns the rendered template | AI Gateway compiles the prompt and sends it to your model | | Proxies your model calls | No | Yes, the gateway is the documented integration path | | Observability | Not offered | Core product capability | | Variable syntax | `{{variable}}` with typed definitions | `{{hc:name:type}}` with string, number, boolean, custom | | Prompt composition | Not offered | Prompt partials via `{{hcp:prompt_id:index:environment}}` | | Version comparison | Diff view between any two versions | Compare versions, one-click promotion | | MCP server | Yes, remote MCP over OAuth 2.1 + PKCE | Not documented | | n8n node | Yes, read-only community node | Not documented | | Public prompt gallery | Yes, with forking | Not documented | ## The architectural difference Helicone's documentation is explicit about the integration model: you include `prompt_id` and `inputs` in a chat completion request to the AI Gateway, and "your prompt is automatically compiled with the provided inputs and sent to your chosen model." The prompt and the model call arrive together. That is the design, and it buys real things: every call is observable by default, cost and latency are attributed automatically, and there is no separate instrumentation step. PromptCache returns the rendered template and stops. Your code calls the provider with your own credentials. Nothing about your completions passes through PromptCache. Neither is universally correct: - A proxy gives you observability for free but places a vendor in your request path - A standalone store keeps the path short but leaves instrumentation to you ## Where Helicone is the better choice **You want observability without building it.** This is the strongest argument. Helicone is an observability product; prompts are delivered through the same gateway that records your calls. PromptCache gives you none of that. **You want prompt composition.** Helicone documents prompt partials, referencing message blocks from other prompts by id, index, and environment. That is a genuinely useful primitive for shared system-prompt fragments, and PromptCache has no equivalent. **You want typed variables enforced at the gateway.** The `{{hc:name:type}}` syntax carries type information into the compilation step. **You are consolidating vendors.** If you would otherwise buy prompt management and observability separately, one tool covering both is a reasonable simplification. ## Where PromptCache differs **Your model traffic stays yours.** No proxy, no vendor between your application and your provider. For teams with data-handling constraints, or who simply do not want a dependency in the completion path, this is the deciding factor. **No gateway coupling.** Because prompts are fetched independently of the model call, changing providers, using multiple providers, or calling a self-hosted model requires nothing from PromptCache. **Assistant and workflow integration.** The remote MCP server over OAuth and the read-only n8n node have no documented Helicone equivalent. ## Honest limitations Paid plans are invoiced manually, with no self-serve checkout. On observability, Helicone's core competence | PromptCache offers nothing, and if that is on your list you will need a second tool alongside it. ## Sources - [Helicone prompt management overview](https://docs.helicone.ai/features/advanced-usage/prompts/overview) - [PromptCache documentation](https://docs.promptcache.app/) Claims about Helicone are drawn from the page linked above. That page does not discuss self-hosting, so this comparison makes no claim either way. ## Frequently asked questions ### Does Helicone proxy your model calls? Yes. Helicone documents including a prompt id and inputs in a request to its AI Gateway, which compiles the prompt and sends it to your chosen model. PromptCache returns the rendered template and stops, so your completions never pass through it. ### What does routing prompts through a gateway buy you? Real things: every call is observable by default, cost and latency are attributed automatically, and there is no separate instrumentation step. The trade is a vendor in your request path. Neither model is universally correct. ### How does the variable syntax differ? Helicone uses a typed placeholder syntax supporting string, number, boolean, and custom types. PromptCache uses double-brace variables with typed definitions stored alongside the template. ### Can prompts be composed from other prompts? Helicone documents prompt partials that reference another prompt by id, index, and environment. PromptCache does not offer prompt composition. # PromptCache vs Portkey > Portkey describes itself as an AI gateway with prompt management and routing built in; PromptCache does not route model traffic and focuses on the prompt store itself. Source: https://promptcache.app/compare/promptcache-vs-portkey Compared with: Portkey (https://portkey.ai) | Claims verified against vendor documentation on: 2026-09-17 | Updated: 2026-09-17 --- Portkey describes itself as an AI gateway with prompt management and routing built in. PromptCache is a prompt store that does not route model traffic. That difference in category matters more than any feature in the table below. ## Feature comparison | | PromptCache | Portkey | | --------------------------- | ------------------------------------------- | ---------------------------------------------------------------------- | | Product category | Prompt store | AI gateway with prompt management | | Prompt versioning | Numbered versions created by publishing | Automatic new version on each modification | | Draft vs published | Draft, then publish to create a version | Update saves locally; publish marks the production default | | Version addressing | Environment slot resolves a version | `@12`, `@latest`, or label such as `@production` | | Labels | Preview and production slots | Production, staging, development defaults plus unlimited custom labels | | Multiple labels per version | One slot points at one version | A version can carry multiple labels | | Version history | Timeline with diff between any two versions | History, restore, side-by-side comparison | | Gateway routing | Not offered | Core product capability | | Provider failover | Not offered | Core product capability | | Proxies your model calls | No | Yes, the gateway is the product | | MCP server | Yes, remote MCP over OAuth 2.1 + PKCE | Not documented | | Public prompt gallery | Yes, with forking | Not documented | Both products separate saving a change from making it live, Portkey distinguishes updating from publishing, PromptCache distinguishes publishing a version from pointing an environment slot at it. The mechanics differ; the safety property is the same. ## Where Portkey is the better choice **You need routing and failover.** This is the real reason to choose Portkey. If calls should fail over between providers, or you want one interface across several model vendors, that is the product's core competence and PromptCache offers nothing comparable. **You want richer label semantics.** Portkey documents unlimited custom labels and multiple labels per version. PromptCache has two fixed slots, preview and production. For teams running more than two environments, Portkey's model is more flexible. **You want version addressing options in code.** Referencing `@12`, `@latest`, or `@production` from the same call site is convenient when different callers need different resolution behaviour. **You are already routing through a gateway.** Adding a separate prompt store when your gateway already manages prompts is redundancy without much return. ## Where PromptCache differs **No proxy.** PromptCache returns the rendered template; your application calls the model itself. Portkey's value depends on your traffic flowing through it. If you do not want a vendor in the completion path, that is disqualifying regardless of the prompt features. **Fewer moving parts.** A gateway is infrastructure, another hop, another failure mode, another thing to reason about during an incident. If prompts are the only problem you have, a prompt store is a smaller commitment. **Assistant and workflow integration.** The remote MCP server over OAuth 2.1 and PKCE, plus a read-only n8n community node, have no documented equivalent in Portkey's prompt versioning documentation. ## Choosing between them The question is not which has better prompt versioning, both are competent, and Portkey's labelling is more flexible. The question is whether you want an AI gateway. If yes, use Portkey's prompt management and skip the separate store. If no, a gateway is a large dependency to adopt for prompt features you can get without it. ## Honest limitations Paid plans are invoiced manually, with no self-serve checkout. Portkey's prompt versioning is available across all its pricing tiers, and as a product it is broader and more established. ## Sources - [Portkey prompt versioning documentation](https://portkey.ai/docs/product/prompt-engineering-studio/prompt-versioning) - [PromptCache documentation](https://docs.promptcache.app/) Where Portkey's documentation does not address a capability, this page records it as "not documented" rather than asserting absence. ## Frequently asked questions ### Is Portkey a prompt manager or an AI gateway? Portkey describes itself as an AI gateway with prompt management and routing built in. PromptCache is a prompt store and does not route model traffic. That difference in category matters more than any individual feature. ### Can one prompt version carry several labels? In Portkey, yes: it documents production, staging, and development defaults plus unlimited custom labels, and a version can carry more than one. In PromptCache, one environment slot points at one version. ### How is a specific version addressed at runtime? Portkey documents addressing a version number, latest, or a label such as production. PromptCache resolves the version an environment slot currently points at. ### Does PromptCache offer provider failover? No. Routing and failover between model providers are core Portkey capabilities and PromptCache offers nothing comparable. If calls should fail over between providers, that decides it.