1. What exactly is the problem
During rounds, a specific pattern has appeared: a participant gets ready-made code from an LLM and simply submits it, almost without understanding it. This is not always caught by plagiarism: a person can rename variables, swap some parts of the code.
2. The idea
Xeppelin — an open-source tool, originally made for ICPC, which:
- is launched locally before the contest
- logs file changes in the working directory
- stores a development timeline (when and how the code changed)
- does not record the screen, keyboard, network, or tabs
- after the contest builds a visualization of activity
This is not my tool, but you can find it here
3. What exactly is proposed for Codeforces (implementation, not an idea)
The proposal is to use Xeppelin as an external source of behavioral data, without interfering with CF infrastructure. Workflow:
The participant launches Xeppelin before the round
Solves problems as usual (locally, in an IDE)
After the round Xeppelin produces:
- a file changes log
- an activity timeline
This log can be automatically linked with CF submissions (by contestId + handle)
CF at the same time:
- does not change the submission process
- does not receive data in real time
- does not require anything complex and global except installing 1 piece of software and linking it with codeforces.
4. What data is obtained
From Xeppelin, clear and simple metrics are available:
- number of file changes before AC
- sizes of individual changes
- active work time vs idle time
- whether the code was written gradually or “in one chunk”
- whether the same pattern repeats across multiple problems
These are process metadata, not screen content and not user input.
5. Why this works well specifically against cheaters:
A typical pattern of copying or cheating with an LLM-solution:
- long idle period
- one large file update
- almost no edits
- immediate AC
This pattern:
- rarely occurs for people who actually write code
- is clearly visible exactly in the file timeline
- is hard to fake without actually rewriting the solution
6. How this can be used in practice (without bans)
Xeppelin is not proof, but a signal. Realistic use cases:
- additional input for post-contest analysis
- a basis for provisional rating in clearly anomalous cases
- a tool for moderators/authors, not automatic punishment
7. Why this is safe for CF
- no proctoring
- no interference with submissions
- no mandatory installations
- no real-time load
Xeppelin works completely outside, CF receives data after the contest or only upon request.
8. Limitation and compromise solution
Limitation
An obvious downside of this approach is that it is impossible and unnecessary to cover 100% of participants. Some people will not be able or willing to use an external logger (devices, installation policy, personal reasons).
Trying to make such software mandatory for all rated rounds is indeed too strict and may harm Codeforces accessibility.
Compromise solution (without changing the core CF system)
Instead, the following option is proposed:
- The rating remains the same as now
- Each result gets a status:
Verified — if the participant attached an activity log (Xeppelin)
- Unverified — normal participation, without logs
This is not a separate rating and not a “second league”
- This is an additional layer of trust, similar in spirit to unofficial standings or verified badges
In practice, this gives:
- the ability to filter the leaderboard by Verified
- priority of trust for verified results
- fewer provisional checks for verified participants
At the same time:
- nobody loses access to rating
- the contest format does not break
- honest participants get a clear incentive to confirm the process
9. TL;DR
There is already an existing tool (Xeppelin) that logs the development process without surveillance. It can be directly linked to CF rounds and used as an additional signal against LLM-solution copy-paste — without bans and without breaking the platform.














