Winner AI¶
Team metrics for AI coding agents. Laptops push their coding-agent sessions into a Postgres schema belonging to their organisation, and managers browse them in a dashboard behind single sign-on.
Winner AI is built for a team, not one person. It gives the organisation a roster, enrolls each laptop with a database login of its own, keeps one organisation's sessions apart from another's, and signs people in through the organisation's own identity provider: any OpenID Connect provider, Auth0 by default. Over those sessions it gives managers the Dashboard, to browse, search and read every session, and the pages built on them: Home, Prompt Coaching, Skills and Benchmarks. One installation serves one organisation.
It is self-hosted. An organisation runs the stack on a host it controls, and its
laptops enroll against that control plane. There is no central service in the middle, and
sessions live only on the laptops and in the database on that host. What can leave is what
the organisation chooses to send: the jobs behind the product pages, the model check the
operator runs in the jobs service, and the control plane for Skills' Generate call a model
endpoint, which defaults to one
running beside the stack under the local-llm profile (a team can set its own on Settings),
and the dashboard's generated insights call a second one. Pointing either at a hosted provider
sends that provider what Model and telemetry lists, call by call.
When the operator sets an error-report DSN, the control plane and the jobs service also
send error reports and timings there, and, with the telemetry secret set and a sweep interval
of a minute or more, the jobs sweep sends cron check-ins, all without text or raw ids, as the
same page lists. When the operator sets them, usage counts also go to an analytics host, with
each control-plane page's page views and its own script errors: event names and counts
under hashed ids, never text (Model and telemetry).
What it does¶
Every enrolled laptop pushes its coding-agent sessions to the organisation's database, and managers read them in a browser. The pages they get:
- Dashboard. Every session of the organisation in one place: browse and search them, read transcripts, star, pin, rename and trash them, and generate insights. Curation is shared across the organisation.
- Home. The team's 30-day spend, and, for each feature that is on, its figure: skills generated, patterns found and what could be saved, prompts flagged. Then credential exposures, active sessions and output tokens; the team's sessions over 7, 30 or 90 days and by agent; each member's sessions over the last 30 days, last activity and push status; and recent sessions.
- Admin. The roster: a manager revokes laptops. With Auth0 Management credentials a manager also adds people; without them, a manager removes and restores people.
- Prompt Coaching. Judges the prompts people typed against a fixed rubric (Verification, Planning, Context, Model fit), shows each finding with a clearer rewrite where it has one, and gives each person a few points to improve.
- Skills. Finds workflows the team repeats across sessions and names
them. A manager turns one into a
SKILL.mdthat loads in Claude Code, Codex and Cursor, edits and approves it, and only an approved version downloads. - Benchmarks. Ranks the prompts the team repeats by what they cost and how often they run, and replays recurring self-contained automation tasks on cheaper models to show whether the answer holds and what it would save. Live traffic is never rerouted.
- Settings. Every value the organisation runs with and the layer that set it, plus the team's own model endpoint and key; the configuration reference lists them.
Prompt Coaching, Skills and Benchmarks are off until the operator lists
them in FLEETVIEW_FEATURES; until then each shows as Soon. A team can
switch a listed one off on Settings, and it shows as Soon again. While the
licence is lapsed the three leave the sidebar
(Licence).
Who it is for¶
- Managers sign in through the browser. Every page above shows the whole organisation, the dashboard included, only to a manager: each checks that the person signed in is a manager of the organisation, and a manager page refuses anyone else.
- Members install the
winnerclient, sign in once withwinner login, and choose which of their repos it may send in the list login shows, and later withwinner repos pick,winner repos allowandwinner repos blockor on their own web page at/repos(Choose which repos send); the sessions of the chosen repos push in the background. The hourly start-commit report keeps to the same choice: it names a recent session's id, start commit and branch only in a chosen repo. They read their own sessions on their laptop in the session collector (agentsview). On the web they see their own Home, their own laptops, their own coaching findings, and the Skills and Benchmarks drawn from their own prompts; every manager page refuses them. - The operator runs the server: installs it, upgrades it to a new
release, sets
.env, and keeps its backups (Install the server, Upgrade and roll back, Back up, restore and uninstall, Troubleshooting).
Where to start¶
| You are | Read |
|---|---|
| Installing Winner AI for your organisation, from choosing the server's name to backups | Start here: the install in order |
| An engineer whose team already runs Winner AI | Laptop client guide |
| Working out whether it fits, or what an installation needs | Overview and prerequisites, and What each feature sends to the model |
| Standing up the server | Network, then Install the server |
| Keeping a bundle install's history safe, or removing it | Back up, restore and uninstall |
| Installing a later release | Upgrade and roll back |
| Running a deployment and something is wrong | Troubleshooting |
| Just signed, or something broke and you need us | Getting started and help |
| Connecting your identity provider, and adding and removing people | Connect your identity provider |
| The JumpCloud administrator, before the install | JumpCloud: before the install |
| Adding an Auth0 organisation's people | Onboard on Auth0 |
| Installing or renewing the licence file | Licence |
How it fits together¶
Data plane. Each laptop's collector runs as agentsview pg push --watch under the
background push winner installs, and sends the laptop's sessions straight to the
organisation's schema. The server runs the Dashboard as agentsview pg serve over the same
schema.
Control plane. Winner AI's own service: sign-in, the roster, device enrollment, and setting up the organisation's database schema and roles. It is never in the path a session takes, so it can be down while laptops keep pushing.
Identity. The organisation's people sign in through its identity provider, and a group or an e-mail list decides who is a manager; on Auth0 with Management credentials, the organisation, its managers and its members live in Auth0 Organizations. A proxy in front of every page, the control plane's and the dashboard's, makes signing in mandatory, and the control plane tells the edge whether a manager belongs to the one organisation the installation serves.
Isolation. One Postgres schema per organisation, plus one database role per enrolled device. A device's credentials reach that organisation's schema and nothing else.
How the data moves draws the connections between them.
What changed¶
The changelog is where each release from 0.4.0 on records what it changed, and whether it asks anything of the people running it.