Think of it like having a graduate student who never sleeps — one who reads hundreds of research papers, proposes experiments, runs them on your GPU, and adds the results to a growing knowledge base. Over time it builds a library of techniques that have been actually tested on your hardware, not just described in a paper.
The Scholar searches arxiv, Semantic Scholar, and Hugging Face for papers about making AI language models faster, cheaper, or smarter. It filters out papers that aren't useful for this machine's GPU and hardware, and adds the good ones to the knowledge base.
You see this working when: the knowledge base count on the dashboard goes up, or you see "reading" in the live activity panel.
The Engineer takes a paper from the knowledge base, writes a Python benchmark script to test the idea described in that paper, runs it on the GPU, and records whether the result was better or worse than the baseline. Each run becomes an "Experiment" entry you can review.
You see this working when: the active experiment field updates, GPU load goes up, or the experiments success/failed counts change.
The Manager runs the heartbeat loop — the core scheduler that decides what to do next. It scores techniques based on past experiment results, generates new hypotheses to test, and builds "Inventions" (reusable tools or libraries) when it finds something genuinely useful. It also serves this web dashboard.
You see this working when: the heartbeat mode changes, the learning policy table updates, or new inventions appear.
An experiment is one test of one idea from one paper. ARES picks a paper, writes a short Python script that implements the key idea (for example: a new attention mechanism, a memory compression trick, a smarter tokenizer), runs it on your GPU, and checks whether it actually works as claimed.
Results are classified as Success (it worked and beat the baseline), Failed (it crashed or got worse results), or Pending (not run yet or still in progress).
Over time, the experiments table becomes a real-world benchmark database for your specific GPU — something no paper or leaderboard can give you.
An invention is a standalone, reusable piece of software that ARES built because experiments showed it works. Where an experiment is a quick "does this idea work?" test, an invention is a polished result — something you could actually drop into another project and use.
Each invention has a README, a manifest describing what it does, and source code. They're created when ARES decides an idea is worth packaging up properly rather than leaving as a one-off benchmark script.
Think of experiments as rough drafts and inventions as finished chapters.
Dashboard tab — Your main control room. See what ARES is doing right now, how many experiments have run, what it has learned, and control the batch processing schedule.
Experiments tab — Browse every paper ARES has tested, see whether each one passed or failed, and optionally re-run failed ones.
Inventions tab — Browse finished packages ARES has produced. Each one has its own detail page with the full README and source file listing.
Chat tab — Ask ARES questions in plain English. You can also type commands like scan history 10 to queue up papers, or autonomy on to let the student model generate new hypotheses automatically.
Worker toggle (top right) — Pause the background experiment runner without shutting down the dashboard. Useful when you need full GPU access for something else, then start it back up when you're ready.
Logs tab — Live tail of the raw runtime log. Useful for debugging or seeing exactly what ARES is doing step by step.