Why selftune
Teams do not need more vibes about skill quality.
They need evidence they can review, defend, and act on. selftune exists because skill failures are usually silent, and silent failures are impossible to manage with intuition alone.
The trust deficit
“Did the skill help?” is too vague to run a team on.
Skills fail without an error message. A request that should have routed nowhere simply disappears into the prompt stream, and the team only notices after the user experience is already degraded.
selftune makes that failure mode legible. It shows when a skill fired, when it missed, and what changed before anyone applies a fix.
What teams actually need
Not generic observability
selftune is not another trace viewer with a prettier dashboard.
Observability tools help you inspect model calls, latency, and cost. selftune focuses on the skill decision itself: the routing health, the missed queries, and the review surface that turns evidence into a concrete apply-or-reject decision.
Trace tools answer
What happened inside the model call stack, how much it cost, and where latency accumulated.
selftune answers
Should this skill have fired, what is the evidence that the proposed change helps, and does it regress anything else?
Why that matters
Teams can review one proposal with one shared vocabulary instead of reconstructing intent from traces after the fact.
Who it is for
Serious practitioners and teams ready to invest in skill quality.
selftune cloud is designed for the people who already know that skill quality is a business problem, not a tutorial problem.
That means product teams, consultants, and domain specialists who need routing evidence they can defend to a client, a manager, or a CEO.
Built for
- Teams shipping skill-heavy workflows into production
- Consultants who need reviewable proof, not anecdotes
- Operators who care about confidence, sample size, and regressions
Not the cloud ICP
- People who are still learning what a skill is
- Teams looking for generic token and latency telemetry only
- Organizations that want invisible automation without a review step
Different layer
selftune handles skill QA. Other tools handle traces.
Langfuse, LangSmith, and OpenLIT remain useful for tracing and infrastructure analysis. selftune is for the team that needs reviewable evidence about whether the right skill fired and whether the proposed change is safe to apply.
| Dimension | selftune | Langfuse | LangSmith | OpenLIT |
|---|---|---|---|---|
| Primary layer | Skill QA and routing health | LLM traces and cost | Agent traces and eval tooling | Infra and runtime telemetry |
| Core question | Should this skill have fired, and did the proposal help? | What happened inside the call? | What happened inside the chain? | What is slow or failing in the stack? |
| Evidence surface | Missed queries, confidence, sample size, regression checks | Latency, tokens, traces | Runs, traces, evaluation artifacts | Metrics, spans, infra dashboards |
| Decision surface | Review queue and apply-or-reject workflow | Investigate logs and traces | Inspect runs and custom eval output | Inspect infrastructure dashboards |
| Best for | Teams responsible for skill quality | Observability engineers | Agent platform builders | Runtime and infra owners |
| Relationship | Complementary to tracing tools | Complementary to selftune | Complementary to selftune | Complementary to selftune |
These tools are complementary. They explain the call stack. selftune explains the skill decision and gives your team a review surface for the next action.
Quality assurance for your skills, with the evidence visible.
Start with the hosted review surface if your team needs defensible decisions. Keep the docs and open-source CLI close if you want a local-first proof path.