Promptel vs DSPy.
DSPy is a programming model for LLM pipelines. Promptel is a DSL for prompts. They overlap on "treat prompts as structured artefacts" and diverge on almost everything else. Picking between them is mostly picking how much of your control flow you want the framework to own.
| Dimension | Promptel | DSPy |
|---|---|---|
| Primary origin | Skelf Research, MIT | Stanford NLP, MIT |
| Mental model | Prompts are structured assets with typed params and technique blocks | Pipelines are programs; "prompts" are compiled artefacts produced by optimisers |
| Runtime language | Node.js (≥ 18) library + CLI | Python framework |
| Authoring surface | .prompt DSL or YAML; same AST | Python modules subclassing dspy.Module / dspy.Signature |
| Provider story | OpenAI, Anthropic, Groq via official SDKs; one-flag swap | Many providers via DSPy LM adapters; chosen at configure() time |
| Techniques | CoT, FewShot, ZeroShot, ToT, ReAct, SelfConsistency as named DSL blocks | CoT, ReAct, ProgramOfThought, etc. as composable Python modules |
| Optimisation | Out of scope; prompts are static and human-edited | Core feature: teleprompters / optimisers compile demos and few-shot exemplars |
| Eval integration | Pure functions over inputs; bring your own harness | First-class metrics + compile-time evaluation are part of the framework |
| Output structure | JSON output schema in the prompt; lowered per provider | Signature input/output fields; framework parses model output to fields |
| Surface area | Small: parser, executor, providers, format converter, CLI | Larger: signatures, modules, optimisers, retrievers, assertions, history |
| Lock-in vector | Bet on the DSL grammar; prompts are still readable text | Bet on the programming model; pipelines are Python objects |
| When to pick it | You want diffable, reviewable prompts and provider portability | You want a pipeline that learns its own few-shot exemplars from data |
Pick Promptel when
- You want prompts in source control as files a human can read.
- You are in Node and prefer a small library to a framework.
- You want to swap providers without touching prompt definitions.
- You are comfortable hand-tuning prompts, not asking the framework to optimise them.
Pick DSPy when
- You are in Python and want pipelines as composable modules.
- You have labelled data and want an optimiser to learn few-shot demonstrations.
- You are building research-grade systems where the prompt-as-artefact is intentionally a moving target.
- You are happy to own the framework upgrade lane as it evolves.
Sources: github.com/skelf-research/promptel, github.com/stanfordnlp/dspy. Corrections welcome via GitHub issue.