VibeTracker
A public sentiment tracker for AI models that turns everyday model feedback into live leaderboards, model pages, trends, and use-case comparisons.
VibeTracker is built around a simple premise: benchmarks are useful, but they do not always capture how models feel in day-to-day use. The product gives people a fast way to report whether a model feels better, worse, or mixed for the work they are actually doing.
The app combines public read paths with anonymous-friendly contribution flows. Visitors can scan ranked models, drill into provider and model pages, compare sentiment by use case, and submit lightweight opinions without making account creation the first step.
What it does
- Ranks AI models by community sentiment with sample counts and trend signals.
- Shows model detail pages with sentiment history, recent submissions, and use-case breakdowns.
- Supports anonymous score submissions while reserving stronger trust controls for higher-risk actions.
- Exposes API and CLI surfaces so feedback can be submitted from external tools and terminal workflows.
System design
The project keeps the frontend, backend, auth, and data model in one TypeScript codebase. Next.js handles the public product surface and route handlers, Convex owns realtime data and aggregate read models, and WorkOS provides identity where authenticated actions are useful.
A lot of the engineering work sits in the product edges: making anonymous sessions reliable, keeping leaderboard reads fast, preventing internal validation details from leaking to users, and designing abuse controls that do not destroy low-friction participation.
curl -X POST 'https://vibetracker.app/api/v1/opinions' \
-H 'Authorization: Bearer $VIBETRACKER_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"model": "gpt-4o",
"score": 1,
"useCase": "coding"
}'Challenges
- Balancing anonymous-first participation with abuse prevention and moderation needs.
- Designing leaderboard scores that account for sentiment, recency, and sample size instead of a naive average.
- Keeping browser, API, and CLI submission paths consistent across Next.js route handlers and Convex functions.
What I Learned
- Low-friction contribution products need trust controls that can escalate without making the default path feel heavy.
- Aggregated product surfaces are easier to reason about when raw submissions and precomputed hot-path tables are explicitly separated.
- Public-safe errors matter: validation details that are useful to engineers can be confusing or leaky for end users.