DEV Community

Cover image for I built a local-first alternative to LangSmith – 3.7K downloads, zero marketing
Shivnath Tathe
Shivnath Tathe

Posted on

I built a local-first alternative to LangSmith – 3.7K downloads, zero marketing

I was debugging a RAG pipeline at work, and I needed traces.

LangSmith was the obvious choice. Except it requires a cloud account, and I was running the model locally on Ollama. It felt wrong to send traces to a third-party server when the model itself never left my machine.

So I looked at alternatives. Self-hosted Langfuse needs Docker. Arize Phoenix is feature-rich but overkill for what I needed. Everything in the space was either cloud-first or required infrastructure I didn't want to manage.

I just wanted to drop a decorator on a function and see what happened.

So I built that.

What OpenSmith does

from opensmith import trace

@trace
def my_pipeline(prompt):
    response = llm.call(prompt)
    return response
Enter fullscreen mode Exit fullscreen mode

That's the whole API. @trace on any Python function, sync or async. Traces store in SQLite at ~/.opensmith/traces.db. Run opensmith ui and you get a dashboard at localhost:7823.

Nothing leaves your machine.

The install is one line

pip install opensmith
opensmith ui
Enter fullscreen mode Exit fullscreen mode

No config file required to get started. No environment variables. No Docker Compose. It just works.

What I just shipped

The first version was the decorator and a basic dashboard. Functional, but barely. This update is a lot more:

Redesigned dashboard. The old one looked like I built it in an afternoon (I did). The new one is actually good. Search, filters, token usage breakdown per trace, cost estimates, all of it.

Live trace updates over WebSocket. The dashboard now updates in real time as your pipeline runs. No refresh.

CLI search and filters. opensmith traces now supports filtering by status, tags, date range, function name. Useful when you've got hundreds of traces and need to find the one that broke.

JSON and CSV export. opensmith export dumps everything in either format. I use this to feed traces into notebooks for analysis.

OpenTelemetry export. If you already run Jaeger or Grafana Tempo:

pip install "opensmith[otel]"
# then set:
OPENSMITH_OTEL_ENDPOINT=http://localhost:4318
Enter fullscreen mode Exit fullscreen mode

Traces go straight to your existing OTel backend.

Optional Postgres backend. SQLite is the default and honestly works for most cases. When it's not enough:

pip install "opensmith[postgres]"
# then set:
OPENSMITH_DB_URL=postgresql://...
Enter fullscreen mode Exit fullscreen mode

Token budget alerts. This one I use a lot:

@trace(token_budget=4000)
def expensive_step(docs):
    ...
Enter fullscreen mode Exit fullscreen mode

Fires an alert if the function exceeds the budget. Useful when you're watching costs across a long multi-step pipeline.

opensmith init. Generates a config file in your project root. Good for teams where you want consistent settings.

Auto port detection. opensmith ui no longer breaks if 7823 is already taken. Finds the next available port automatically. Small thing, was annoying before.

Autopatch for zero-code tracing

If you don't want to add @trace everywhere, autopatch handles it:

from opensmith import autopatch

autopatch("openai")      # patches OpenAI client
autopatch("anthropic")   # patches Anthropic client
autopatch("litellm")     # patches LiteLLM
autopatch("chromadb")    # patches ChromaDB
autopatch("qdrant")      # patches Qdrant
autopatch("pinecone")    # patches Pinecone
Enter fullscreen mode Exit fullscreen mode

One line per integration. Every call gets traced automatically.

The numbers

3.7K total PyPI downloads as of July 2026. 116 last week, 701 last month.

I've spent ₹0 on marketing. Everything came from LinkedIn posts and word of mouth. That tells me the problem is real. It also tells me I have a distribution problem, because OpenSmith doesn't rank for "LangSmith alternatives" anywhere. That space is owned by Langfuse and Arize Phoenix.

I'm not sure how to fix that yet. Writing articles like this one is the plan for now.

Why local-first matters

There's a real argument for keeping traces local that goes beyond privacy.

When your model is local (Ollama, llama.cpp, LM Studio), your entire inference stack is on your machine. The traces should be too. Sending them to a cloud service introduces a dependency on network availability, on a third party's uptime, on their pricing decisions next quarter.

Local-first means the tool works on a plane. Works when the API is down. Works when you're iterating fast and don't want to think about it.

I think this matters more as local LLM tooling matures. Ollama has made running models locally genuinely easy. The observability layer should match that energy.

Full CLI

$ opensmith ui          # start dashboard
$ opensmith traces      # list recent traces
$ opensmith stats       # token + cost summary
$ opensmith export      # export to JSON or CSV
$ opensmith clear       # clear local traces
$ opensmith init        # create opensmith.json config
Enter fullscreen mode Exit fullscreen mode

Try it

pip install opensmith
opensmith ui
Enter fullscreen mode Exit fullscreen mode

Website: opensmith.shivnathtathe.com

GitHub: github.com/shivnathtathe/opensmith

If you're building agents, RAG pipelines, or anything that calls an LLM, I'd genuinely love feedback. What's missing? What's broken? What would make you actually use this over the alternatives?

And if you find it useful, a star on GitHub helps a lot for an open-source project.



Top comments (0)