DSPy

Stanford NLP's framework for "programming—not prompting—language models": you declare what a step should do with typed inputs and outputs, compose those steps in Python, and hand the prompt itself to an optimizer that tunes it against a metric. 37,456 stars / 3,241 forks, MIT, 406 contributors, 653 open issues, created 2023-01-09, last pushed 2026-08-20; v3.3.0 released 2026-08-03 (repo + dspy.ai docs, both read 2026-08-20). The acronym now expands to Declarative Self-improving Python.

This spoke has cited DSPy fourteen times across five pages — as the baseline meaning-typed-programming benchmarks against, as half of the "GEPA + DSPy" loop awesome-hermes-usecases pins under hermes-agent — and never paged it. Routed from the hub 2026-08-20 with awesome-prompts, which files it first under Prompt Programming.

Three abstractions

• Signatures — the task declared as typed inputs → typed outputs (question -> answer), not as a prompt string. The docs' claim for this is portability: the signature survives a model change, the prompt does not.
• Modules — the execution strategy behind a signature, swappable without rewriting the task: Predict, ChainOfThought, ReAct, ensembles, tool use. Same interface, different amount of work.
• Optimizers — given examples and a scoring function, search for the prompt (and sometimes the weights) that maximizes the metric. Thirteen are shipped: MIPROv2, GEPA, BootstrapFewShot, BootstrapRS, BootstrapFinetune, COPRO, SIMBA, InferRules, BetterTogether, Ensemble, KNN, KNNFewShot, LabeledFewShot.

The third one is the load-bearing claim and the reason this page exists: see prompt-optimization. The first two are a calling convention; the optimizer is what makes the calling convention worth adopting.

The lineage is a paper trail

DSPy is unusual in this corpus for arriving with peer review behind it rather than a launch post.

• Dec 2022 — Demonstrate-Search-Predict (arXiv 2212.14024, Khattab, Santhanam, Li, Hall, Liang, Potts, Zaharia): retrieval and LM calls composed as a program. The original DSP the name comes from.
• Oct 2023 / ICLR 2024 — "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines" (arXiv 2310.03714): the framework proper, and the word compiling for what the optimizer does.
• Jun 2024 — MIPRO (arXiv 2406.11695): optimizing instructions and demonstrations across a multi-stage program.
• Jul 2025 — GEPA (arXiv 2507.19457): "Reflective Prompt Evolution Can Outperform Reinforcement Learning."

Four more sit alongside them (DSPy Assertions, fine-tuning-plus-prompt-optimization, prompts as auto-optimized hyperparameters, in-context learning for extreme multi-label classification). The GEPA line matters locally: hermes-agent's self-improvement loop is GEPA over DSPy programs, so a mechanism this spoke recorded as a vendor's closed loop is a published algorithm with a repo.

What the numbers are worth

The docs advertise 6.6M+ monthly downloads and production use at Databricks, Shopify, Dropbox, AWS, JetBlue, Replit and Nous Research, including a Shopify case study claiming ~550× cost reduction. Those are T3 — the maker relaying adoption and a customer's own figure, with no method, baseline or workload stated. The download count measures installs, not programs that kept the optimizer on. Treat the star and contributor counts above as the T1 facts and this paragraph as marketing until someone re-runs it.

The corpus does hold one independent measurement, and it is not flattering. meaning-typed-programming (OOPSLA2 2025, peer-reviewed) benchmarks MTP against DSPy and LMQL and reports up to 10.7× fewer lines to add an LLM feature, 45% fewer lines and faster development in a user study, 98.92% vs 98.23% accuracy on its suite, and fewer tokens on every benchmark tested. Its sharpest line is about trajectory rather than the current gap: MTP "pulls ahead as models get better, while DSPy's accuracy plateaus."

That paper's own stated limitation cuts the other way, and the page already records it: the comparison mostly runs against uncompiled DSPy, and compiled DSPy is the mode this page is about. So the one independent number the corpus has measures the calling convention, not the optimizer.

Neither census counted it as an agent framework

turingpost-13-frameworks lists thirteen agent frameworks and DSPy is not among them. llm-engineer-toolkit lists twenty-seven under Agents and DSPy is not there either — it is filed under LLM Prompts, in a nine-entry category otherwise made of prompt compressors (LLMLingua, Selective Context, PCToolkit). Guidance and LMQL land in a third bucket again, Structured Outputs.

So a 37.5k-star, 406-contributor, ICLR-published framework for building LM pipelines sits outside both counts of the layer it builds at. This is the third and cleanest data point for the agent-framework page's finding that the category has no agreed membership — and it locates the seam. The censuses sort by what you assemble (agents, chains, crews); DSPy sorts by what you optimize. A tool whose selling point is the compile step gets filed next to prompt compressors because both touch the prompt, which is a classification by surface rather than by function. Note that meaning-typed-programming treats DSPy, LMQL and MTP as one comparable class — the peer-reviewed source and the two directories disagree about what kind of thing this is.

Related

prompt-optimization · agent-framework · meaning-typed-programming · byllm · jaseci · hermes-agent · awesome-hermes-usecases · awesome-prompts · omar-khattab · stanford-university · self-improving-agents · agent-evals · langchain · turingpost-13-frameworks · llm-engineer-toolkit