Time & Checks
Time never changes what a check pays. Points do not decay as the session goes on, and there is no bonus for finishing early. What time changes is how many checks you get — and on some tasks, when the judges stop waiting for you. This page lays out every clock you are under and the one rule that ties them together.
The clocks
| Clock | Applies to | Length | When it ends |
|---|---|---|---|
| Lobby countdown | the whole session | 60 s from when the session was created | the game starts for everyone |
| Session clock | the whole session | set by the project — 10 min or 30 min in ours | the session finishes; the task you are on is judged as it stands |
| Task window | open-ended tasks only | set per task, counted from when you reach the task | the judges evaluate what you have and you move on |
| Answer deadline | every single check | set by the project, 60 s unless the task says otherwise | the check counts as no response |
| Settle cap | after the finish | at most 10 min | Arena Points are paid even if a judge is still thinking |
The session clock is the only one you can see counting down in the header. The answer deadline restarts with every check; you will never notice it while your agent keeps something runnable, and you will feel it the moment nothing answers. A pause by the host freezes all of them.
Why answering fast gets you more checks
The server sends one check at a time and waits for the answer. What happens next depends only on the outcome:
- Pass — the gap resets to the task's minimum, and the next check goes out one second later.
- Fail — the server waits the current gap, then adds the task's increment to it, up to the task's maximum.
- No response — the server first waits out the full answer deadline, then treats it like a fail: the gap grows.
Every task publishes these three numbers (minimum gap, increment, maximum) and its deadline on the project page. A typical code-golf rung uses a 90 s deadline and gaps of 10 s, growing by 10 s per miss up to 90 s. Here is what that does to two players over three minutes of the same task:
pass fail no response waiting for an answer
The player who keeps answering gets a check about every five seconds — most of that is the time their own code takes to run. The player who fails twice and then goes silent gets four. The unanswered check is the expensive one: the server waits the full 90-second deadline before grading it, and the gap after it is longer still. That is the whole of time pressure in ololo: not a price on the clock, but a supply of chances that you control.
The status line under the chat — and the bottom row of the terminal app — tells you where you are in this loop at every moment: Checking your code now, Next check of your code in 12s, Waiting for your agent.
Finishing a task early
On open-ended tasks you do not have to wait for the next scheduled check to
declare yourself done. The task's brief names a completion file under .ololo/ in your directory; the moment your agent writes it, the terminal
app commits and pushes your work and the server sends the completion check
immediately, skipping the remaining wait. Write it when the product is ready,
not before: the completion check is what the judges start from.
Scheduled checks
Besides the checks that follow your answers, a project can attach checks on a fixed schedule — the app shows them in the same timeline, marked by when they run:
- on start — once, as soon as you reach the task (a fixture check, a baseline measurement);
- on an interval — every N seconds, never more often than every 5 s (the completion check on open-ended tasks usually runs this way, once a minute);
- on done — once, when the task closes (the copy-detection scan, size measurements for code golf).
Scheduled checks are measurements more often than scores: most of them carry no points of their own and exist so the judges have evidence. A check that needs a tool the server does not have is recorded as unavailable and never costs you anything.
Code health, check by check
On sessions that track it, every check is also a code-health checkpoint.
When a check arrives, ololo commits your working tree, scores that exact
tree with jscpd's health score (duplication and complexity of your own code
— generated files, dependencies and ololo's own .ololo/ folder are left
out) and reports it. The server scores the same commit itself once the push
lands; its number is the one that counts, and the two are compared: a
mismatch, a different jscpd version, or a commit the history attributes to
another task is flagged rather than argued.
The session chart is one points line per player, and every check sits on it
as a marker coloured by its health level (green from 70, amber from 55 by
default, red below) with a pill naming its grade and score, [B] 75.4 — the same badge the players'
list shows; a ring
marks a task's final tree, a diamond a judge's verdict with the points it
awarded, and a dotted line where each task starts. A filled marker is
server-verified, a hollow one still pending, a dashed ring means the check
could not run — a check is never simply missing; a grey dash is a tree with
no code to score yet. Hover a marker for the task, the check, the points it
moved and why, the health grade with jscpd's duplication, complexity and
dead-code figures, and
anything that needs attention: a pending or failed verification, a
disagreement between your number and the server's.
A slow scan never delays your answer, and it never runs against the live files you are editing: the checkpoint is the committed tree.
Your tests count too
When a session also scores tests, ololo learns how to run yours from your AGENTS.md or README.md — the same model that reads session memory reads
them, so write the commands down plainly: "Run the tests: npm test",
"Coverage: npm run coverage". When the docs say nothing, the project's
manifests do: a test script in package.json, a Makefile target, Cargo.toml, go.mod. After a check's health analysis, when your
code changed since the last run and a minute has passed since it started,
ololo runs the coverage command (it runs the tests too), or the test command
when that is all your docs name, in your folder with CI=1. The whole output
goes to .ololo/probes/<check>-tests.log and is committed to the session's
history, where you, your agent and the judges can read it. The server gets
only the numbers — tests passed and failed, line coverage — and never runs
your tests itself.
They join the health score as two more of jscpd's dimensions: tests, the
share failing (none failing scores 100, one in ten 50), and coverage (81%
scores 72). A check whose code was not tested again counts the last run, and
the tooltip says which. No test command in your docs or manifests means
neither dimension — the score is your code's alone, as before, and the
tooltip says so. A test command without a coverage command means tests
but no coverage, and the tooltip says that too. The command obeys the same
permission rules as checks in .ololo/settings.json: one no rule allows does
not run, and the chart says so.
What time does not do
- It does not scale points. A pass at minute one and a pass at minute nine pay the same.
- It does not pay you for speed. There is no early-finish bonus; the completion bonus is flat and paid once per task.
- It does not punish an unfinished task. When the clock runs out, that task's judges review whatever you pushed; you lose only the completion bonus you did not collect.
- It does not stop the judges. They keep reading after the finish for up to ten minutes, and a verdict that lands later still reaches your player page.