Comparisons

How Crux compares

Crux isn't trying to replace your SDK. It's a kit of typed building blocks for the harness around it. Pick the ones you need, drop the rest.

Using generateText / generateObject directly

vs. Vercel AI SDK (alone)

Vercel AI SDK is an excellent execution layer, and Crux uses it as its primary adapter. The comparison is about what you get when you add Crux's harness on top.

 
Alternative
Crux
Prompt definition
Inline system/prompt strings per call
Typed, reusable prompt() with schemas
Context composition
Manual string concatenation
Declarative context() with priority-based merging
Multi-provider
Provider-specific model imports
Same prompt definition, swap adapter at call site
Evaluation
Not included
Inline tests, judge scoring, CLI eval runner
Memory
Not included
Working, episodic, semantic, with asContext() / asTools()
Compaction
Not included
Sliding window, budget tracking, key facts extraction

Bottom line: AI SDK handles the model call. Crux handles everything around it. Complementary, not competing.

OpenAI SDK, Anthropic SDK, Google GenAI

vs. Raw SDK calls

Raw SDK calls give you maximum control but zero structure. Crux sits on top, composing your context, validating schemas, and delegating execution to the SDK. You keep full SDK access.

 
Alternative
Crux
Type safety
Manual JSON.parse + casting
Zod schemas, fully inferred types
Context reuse
Copy-paste strings between prompts
Composable context() fragments with priority
Provider switch
Rewrite every call site
Change one adapter import
Testing
Build your own eval harness
evaluate() with variants, gates, replay
Observability
Console.log the request body
Devtools trace every generation
Token management
Count tokens manually
Budget tracking + automatic context dropping

Bottom line: Keep using the SDK. Crux doesn't replace it. Add Crux when you need memory, retrieval, guardrails, routing, evals, or observability around the call.

Template literals and string concatenation

vs. Prompt strings in code

If your app has 1–2 simple prompts, raw strings are fine. Crux adds value when complexity grows. Here's where the line is.

 
Alternative
Crux
1–2 prompts
Simple and sufficient
Unnecessary overhead
Shared context
Copy-paste between files
Define once, compose with use: [...]
Structured output
JSON.parse + manual validation
Zod schema → typed result.object
Multiple models
Separate code paths per provider
Same prompt, different adapter
Quality assurance
Manual testing in playground
Automated eval across model matrix
Team collaboration
Hard to discover, hard to review
Registry, tags, devtools, introspection

Bottom line: Start with strings. Adopt Crux when you have shared context, need structured output, or want automated evaluation.

Full orchestration frameworks

vs. LangChain / LlamaIndex

LangChain and LlamaIndex replace your SDK and own execution. Crux keeps your SDK and owns the harness around it: prompts, memory, retrieval, tools, guardrails, routing, evaluation, observability.

 
Alternative
Crux
Scope
Full orchestration (chains, agents, RAG, vector stores)
The harness around the SDK call (prompts, memory, retrieval, tools, guardrails, routing, evals, observability)
Execution
Own runtime with own abstractions
Delegates to AI SDK / OpenAI / Google directly
TypeScript
Ported from Python, partial type coverage
TypeScript-first, full inference from Zod schemas
API surface
Large. Many concepts, many ways to do things
Small. ~10 core functions, consistent interfaces
Integration
Use their patterns or fight the framework
Compose into any existing architecture
Memory
Built-in vector store + retriever abstractions
Three typed primitives (working, episodic, semantic) + pluggable stores

Bottom line: LangChain replaces your SDK. Crux keeps it. Pick LangChain if you want an all-in-one framework; pick Crux if you want typed building blocks around the SDK you already use.

Try it yourself

Install Crux and write your first typed prompt in under 5 minutes.