Direct SDKs (no framework) vs DSPy
Both are alternatives to LangChain. Here's how they stack up — verified facts, no spin.
Also searched as DSPy vs Direct SDKs (no framework) — same comparison, one verdict.
Direct SDKs (no framework) and DSPy are closely matched on ownership (93 vs 88) — this one comes down to pricing and to which trade-offs below you can live with.
Direct SDKs (no framework)
TOP PICKThe 2026 consensus: official SDKs + a few hundred lines you own.
The strongest LangChain alternative today is often no framework at all. Modern models ship native tool calling, structured outputs, and long context — the very things LangChain was built to scaffold — so the official Anthropic/OpenAI/Mistral SDKs (MIT/Apache-licensed) plus a small amount of your own orchestration code covers most real applications. You keep full debuggability (a stack trace is your code, not five layers of framework), zero dependency churn, and total freedom to swap providers. Engineering write-ups since 2024 keep landing on the same conclusion: start direct, add a framework only when a specific need demands it — not the other way around.
DSPy
Programming, not prompting — Stanford's optimizer-driven approach.
DSPy (MIT, from Stanford NLP, ~34k stars) replaces hand-tuned prompt strings with something closer to software engineering: you declare what a step takes in and produces (a Signature), compose modules, and let an optimizer compile the best prompts and few-shot examples against your own metric and data. When quality matters and you're tired of prompt whack-a-mole, DSPy turns the tuning into a reproducible build step. It's the most intellectually distinct alternative on this list.
Side by side
6 points of comparison, every one read from a verified field. Green marks the side that wins a row outright. A dash means we do not hold that fact — never that it is zero.
| Direct SDKs (no framework) | DSPy | |
|---|---|---|
| Sovereignty ScoreOur transparent 0–100 composite for data ownership and exit cost. | 93 | 88 |
| Open source | Yes | Yes |
| Self-hostable | Yes | Yes |
| Local-first data | Yes | Yes |
| License | Your code (official SDKs: MIT / Apache-2.0) | MIT |
| Pricing | Free — you pay only your model provider; no framework tier, no per-seat tooling | Free (MIT) |
Direct SDKs (no framework) is Macrostack's recommended LangChain alternative, so it's our pick here.
Weighing both against staying on LangChain? Is LangChain free? What it actually costs →
Direct SDKs (no framework)
Strengths
- +Every line is yours: debugging is a stack trace, not archaeology
- +No abstraction churn or breaking framework releases
- +Trivially swaps model providers; pairs cleanly with MCP for tools
- +Less code than the equivalent chain in many real apps
Trade-offs
- −You write your own retries, streaming, and evaluation plumbing
- −Big multi-agent orchestration is where hand-rolling gets costly
DSPy
Strengths
- +Optimizes prompts against your metric — reproducibly
- +Declarative modules stay stable as models change underneath
- +Research-grade ideas with a real production following
Trade-offs
- −A genuinely different mental model — real learning curve
- −Optimization runs cost tokens; needs a decent eval set
Which one fits you
The trade-offs above, turned into a decision. Find the line that describes your team.
Choose Direct SDKs (no framework)
if a lower exit cost matters more to you than any single feature, and every line is yours: debugging is a stack trace, not archaeology.
Choose DSPy
if optimizes prompts against your metric — reproducibly.
Neither, yet
if both carry a real cost you should weigh first — you write your own retries, streaming, and evaluation plumbing, and a genuinely different mental model — real learning curve. If either of those is a dealbreaker for your team, the shortlist is wrong rather than the choice.
Direct SDKs (no framework) vs DSPy — common questions
Is Direct SDKs (no framework) a better fit than DSPy for llm & agent frameworks?
It depends on what you are optimising for, and the honest split is this: Direct SDKs (no framework) scores 93 to DSPy's 88 on data ownership and exit cost, so it is the safer choice if you care about being able to leave. DSPy earns its place on a different axis — optimizes prompts against your metric — reproducibly. Neither is a wrong answer for every team; the table above is the actual comparison.
What happens if we want to switch later?
Direct SDKs (no framework) keeps its data local or in open formats, so leaving is an export rather than a negotiation. DSPy is still self-hostable, so the files stay on your server either way — but it is not local-first by design, so check what its export produces before you rely on it.
Can I self-host Direct SDKs (no framework) or DSPy?
Both can be self-hosted. The difference is what it costs you in time rather than whether it is possible — see the setup and maintenance rows above.
Are Direct SDKs (no framework) and DSPy both alternatives to LangChain?
Yes — both appear in our LangChain comparison, which is why they are worth putting side by side. People usually arrive here already having decided to move off LangChain and now choosing between the two replacements, which is a narrower and much easier question.
More LangChain head-to-heads
Related alternative guides
Facts verified 2026-07-16. Licenses and pricing change — spotted something out of date? That's a correction we want.