DSPy

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Canonical URL

https://heyclau.de/entry/tools/dspy

Source URLs

https://dspy.ai/, https://github.com/stanfordnlp/dspy

Brand

DSPy

Brand domain

dspy.ai

Brand asset source

brandfetch

Safety notes

DSPy changes how language-model systems are constructed and optimized, but it does not prove that a generated answer, optimized prompt, ReAct tool action, retrieved passage, or fine-tuned model is correct or safe., Optimizers can issue many model calls, generate examples, explore instructions, tune prompts, or fine-tune model weights; set budgets, rate limits, evaluation gates, rollback rules, and review ownership before running them., ReAct modules, Python interpreter tools, function tools, retrieval tools, and MCP-converted tools can trigger external APIs, local code, file access, or business actions if wired into a program., Metrics and evaluation datasets can overfit, reward the wrong behavior, or miss safety failures; treat optimizer scores as development signals rather than production approval., Saved programs, optimized prompts, bootstrapped demonstrations, fine-tuning datasets, and experiment artifacts should be reviewed before sharing because they can encode private data or brittle task assumptions., Local model servers, provider endpoints, and LiteLLM-compatible routes need normal timeout, retry, budget, abuse, model-selection, and credential-handling controls.

Privacy notes

DSPy programs can send prompts, messages, typed inputs, retrieved context, tool arguments, generated outputs, optimizer traces, examples, metrics, and fine-tuning data to configured model providers., DSPy LM history can retain prompts, messages, call kwargs, responses, outputs, token usage, cost metadata, and related debugging information unless applications define cleanup and access controls., Caches, saved programs, optimized prompt artifacts, demonstration sets, serialized LM state, experiment logs, and evaluation reports can preserve sensitive task data outside the original source system., MCP integrations and tool calls can move user data, tool descriptions, tool arguments, and tool results into external servers, agent transcripts, provider logs, and downstream system logs., Local models reduce third-party provider exposure but can still leave data in process logs, tracing systems, prompt caches, generated artifacts, and shared infrastructure storage.

Author

Stanford NLP

Submitted by

oktofeesh1

Claim status

unclaimed

Last verified

2026-06-03

• DSPy programs can send prompts, messages, typed inputs, retrieved context, tool arguments, generated outputs, optimizer traces, examples, metrics, and fine-tuning data to configured model providers.
• DSPy LM history can retain prompts, messages, call kwargs, responses, outputs, token usage, cost metadata, and related debugging information unless applications define cleanup and access controls.
• Caches, saved programs, optimized prompt artifacts, demonstration sets, serialized LM state, experiment logs, and evaluation reports can preserve sensitive task data outside the original source system.
• MCP integrations and tool calls can move user data, tool descriptions, tool arguments, and tool results into external servers, agent transcripts, provider logs, and downstream system logs.
• Local models reduce third-party provider exposure but can still leave data in process logs, tracing systems, prompt caches, generated artifacts, and shared infrastructure storage.

• Python 3.10 or newer and a dependency manager for installing `dspy` and optional extras for MCP, retrieval, local models, or deployment workflows.
• Model provider credentials, local model endpoint, Databricks environment, or LiteLLM-compatible provider configuration for the language models used by the DSPy program.
• Training examples, validation examples, metrics, expected outputs, and reviewer ownership before running DSPy optimizers or using optimized programs in production workflows.
• Reviewed data sources, retrieval systems, tools, MCP servers, and Python execution paths before connecting DSPy modules to real files, APIs, databases, or account actions.
• Cache, history, saved-program, artifact, and experiment-retention policies for prompts, messages, outputs, optimized examples, model usage metadata, and cost records.

Show that DSPy is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

[![Listed on HeyClaude](https://heyclau.de/badge/tools/dspy.svg)](https://heyclau.de/entry/tools/dspy)

DSPy side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field	DSPy Python framework from Stanford NLP for programming language-model systems with signatures, modules, tools, metrics, and optimizers instead of hand-written prompts. Open dossier	BAML Open-source domain-specific language from BoundaryML for writing typed LLM functions with structured inputs and outputs, a VSCode playground, and generated clients you can call from Python, TypeScript, Go, and more. Open dossier	MetaGPT Open-source Python multi-agent framework that assigns product manager, architect, project manager, engineer, and other software-company roles to LLM agents for natural-language programming, repo generation, data interpretation, research, debate, and custom agent workflows. Open dossier	Rivet Open-source visual AI programming environment from Ironclad for building, debugging, and embedding complex LLM agents and prompt-chaining graphs, with a desktop app and a TypeScript library. Open dossier
Next stepsDiffers	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierCopy installAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing
Trust	Review first	Review first	Review first	Review first
Review status	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed
Package trust	Package not verified	Package not verified	Package not verified	Package not verified
Source provenance	Source-backed	Source-backed	Source-backed	Source-backed
SubmitterDiffers	oktofeesh1	davion-knight	—	davion-knight
Install risk	Review first	Review first	Review first	Review first
Notes	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓
Brand	DSPy	BAML	—	Rivet
Category	tools	tools	tools	tools
Source	Source-backed	Source-backed	Source-backed	Source-backed
Author	Stanford NLP	BoundaryML	FoundationAgents	Ironclad
Added	2026-06-03	2026-07-09	2026-06-18	2026-07-09
Platforms	CLI	CLI	CLI	CLI
Harness	CLI	CLI	CLI	CLI
Source repo	—	—	—	—
Safety notes	✓DSPy changes how language-model systems are constructed and optimized, but it does not prove that a generated answer, optimized prompt, ReAct tool action, retrieved passage, or fine-tuned model is correct or safe. Optimizers can issue many model calls, generate examples, explore instructions, tune prompts, or fine-tune model weights; set budgets, rate limits, evaluation gates, rollback rules, and review ownership before running them. ReAct modules, Python interpreter tools, function tools, retrieval tools, and MCP-converted tools can trigger external APIs, local code, file access, or business actions if wired into a program. Metrics and evaluation datasets can overfit, reward the wrong behavior, or miss safety failures; treat optimizer scores as development signals rather than production approval. Saved programs, optimized prompts, bootstrapped demonstrations, fine-tuning datasets, and experiment artifacts should be reviewed before sharing because they can encode private data or brittle task assumptions. Local model servers, provider endpoints, and LiteLLM-compatible routes need normal timeout, retry, budget, abuse, model-selection, and credential-handling controls.	✓BAML functions call LLM providers using the credentials you configure, so scope those provider keys to the minimum needed and keep them out of source control. BAML generates client code that runs inside your application; review generated clients before shipping, and treat typed outputs as untrusted input for account, billing, data, or infrastructure actions. Static typing and schema validation reduce parsing errors, but they do not guarantee that a model's answer is correct, complete, or safe. The BAML CLI and VSCode extension run locally and write generated code into your project; run them in an environment where writing those files is expected. Keep production usage and permissions narrower than playground or example projects.	✓MetaGPT can generate full repositories under a workspace from one-line requirements. Review generated code, dependencies, licenses, prompts, and build scripts before running or publishing anything. The framework coordinates multiple LLM roles and can call code, web, RAG, browser, email, GitHub, and provider integrations through its dependencies and optional extras; scope credentials and tools per workflow. Generated requirements, API designs, architecture documents, diagrams, and code can be plausible but wrong. Treat them as drafts until tested against source requirements and local constraints. Data Interpreter and notebook-style workflows may execute code, create plots, read files, and emit artifacts; run them in an isolated environment for untrusted data. Long multi-agent runs can consume significant model tokens and external API quota, so set cost ceilings, timeouts, and stopping criteria before production use.	✓Rivet graphs can include nodes that call LLMs, run code, make HTTP requests, and call into your application's functions, so review what a graph and its nodes do before running it, especially graphs from untrusted sources. The desktop app and embedded graphs use the model-provider API keys and integration credentials you configure; scope those credentials to the minimum needed. When embedding Rivet Core in an application, treat graph inputs and node outputs as untrusted, and gate any node that performs writes or external actions. Node types that execute code or make network calls should run with least privilege and appropriate timeouts. Keep production graphs and their permissions narrower than example graphs.
Privacy notes	✓DSPy programs can send prompts, messages, typed inputs, retrieved context, tool arguments, generated outputs, optimizer traces, examples, metrics, and fine-tuning data to configured model providers. DSPy LM history can retain prompts, messages, call kwargs, responses, outputs, token usage, cost metadata, and related debugging information unless applications define cleanup and access controls. Caches, saved programs, optimized prompt artifacts, demonstration sets, serialized LM state, experiment logs, and evaluation reports can preserve sensitive task data outside the original source system. MCP integrations and tool calls can move user data, tool descriptions, tool arguments, and tool results into external servers, agent transcripts, provider logs, and downstream system logs. Local models reduce third-party provider exposure but can still leave data in process logs, tracing systems, prompt caches, generated artifacts, and shared infrastructure storage.	✓BAML functions send prompts and inputs to the configured model providers, which process that data under their own data-handling terms. Prompt templates, test inputs, and example data can contain personal or proprietary information, so keep them and provider credentials out of version control. Generated outputs, and any logging or tracing you add around BAML calls, can retain prompts and results outside the library. Apply normal retention and access-control policies to BAML source files, generated clients, and test fixtures that include real data.	✓Requirements, prompts, role messages, generated code, diagrams, documents, repo files, notebook outputs, model responses, logs, and traces may contain private product or workspace data. Configured LLM providers, browser/search tools, RAG/vector services, GitHub integrations, email/IMAP tools, cloud providers, and generated workspaces may receive or retain workflow data. Do not commit `~/.metagpt/config2.yaml`, provider keys, local model URLs, generated repos with secrets, workspace logs, notebook outputs, or customer requirements. If teams share MetaGPT outputs, strip private prompts, internal system names, customer data, generated credentials, and non-public architecture details first.	✓Running a Rivet graph sends prompts, inputs, and node data to the configured model providers and any integrated services. Nodes that call your application's code, HTTP endpoints, or data sources can pass local or workspace data into the graph and the model. Prompts, node outputs, and debugging traces in the app or your logs can retain data, so apply normal retention and access-control policies. Model-provider and integration credentials live in the app configuration or your application's environment; keep them out of version control.
Prerequisites	Python 3.10 or newer and a dependency manager for installing `dspy` and optional extras for MCP, retrieval, local models, or deployment workflows. Model provider credentials, local model endpoint, Databricks environment, or LiteLLM-compatible provider configuration for the language models used by the DSPy program. Training examples, validation examples, metrics, expected outputs, and reviewer ownership before running DSPy optimizers or using optimized programs in production workflows. Reviewed data sources, retrieval systems, tools, MCP servers, and Python execution paths before connecting DSPy modules to real files, APIs, databases, or account actions.	A way to install the BAML toolchain (for example the CLI via Homebrew) and, for embedding, the language SDK such as `@boundaryml/baml` for TypeScript or `baml-py` for Python. Model-provider credentials for the LLM providers your BAML functions call. Defined input and output types for each BAML function before generating clients. A build step to regenerate BAML clients when function definitions change, and a place to review the generated code.	Python 3.9 through 3.11 and an isolated Python environment. Node.js and pnpm for workflows that render diagrams or use MetaGPT's documented software-company generation path. LLM provider configuration in `~/.metagpt/config2.yaml`, such as OpenAI, Azure, Ollama, Groq, or another supported provider route. API keys, base URLs, local model endpoints, and generated workspace paths kept outside source control.	The Rivet desktop application (for authoring graphs), or Node.js and npm to embed `@ironclad/rivet-core` or `@ironclad/rivet-node` in an application. Model-provider API keys for the LLM providers a graph uses, plus credentials for any integrations the graph calls. A clear boundary for which application functions and data sources Rivet graphs may call, and vice versa, before embedding. A plan for how graphs are versioned, reviewed, and promoted from local authoring to production use.
Install	—	—	pip install --upgrade metagpt Copy install	—
Config	—	—	—	—
Citations	Source repositorygithub.com 2026-07-18T19:14:44+00:00 Documentationdspy.ai Submitted by oktofeesh12026-06-03 Source methodology →	Source repositorygithub.com 2026-07-18T19:14:44+00:00 Documentationdocs.boundaryml.com Submitted by davion-knight2026-07-09 Source methodology →	Source repositorygithub.com 2026-07-18T19:14:44+00:00 Documentationdocs.deepwisdom.ai Source methodology →	Source repositorygithub.com 2026-07-18T19:14:44+00:00 Documentationrivet.ironcladapp.com Submitted by davion-knight2026-07-09 Source methodology →
Claim	Unclaimed	Unclaimed	Unclaimed	Unclaimed

Source-backed guides for putting this to work.

• Comparison: Pydantic AI vs Agno vs DSPy vs MastraOpen 4 picks in the interactive comparison tool