Docs · Main track · Submission flow

DocsMain track

Submission flow

From an archive on your machine to a score on the leaderboard.

View as MarkdownThis page as plain text
llms.txtIndex of every docs page, for agents

You submit solver code for the open round's problems; we run it on their private instances and score the results. What the archive must contain is on Submission format.

Three ways to submit

How
DashboardSubmissions page: choose the archive and the environment, check which problems it covers, then Submit.
Starteruv run frontieror submit --wait packs the solvers in solvers/ and submits them. See Example code.
APIPOST /main/submissions, then poll GET /submissions/{id}.

All three run the same checks and count toward the same daily limit.

Before you submit

  • Your team is on the Main track. See Choosing a track.
  • A round is open. See Rounds.
  • Your team has a submission left today: one per UTC day, 4 during the testing stage, reset at 00:00 UTC.

What is checked at upload

The upload is checked straight away. A refused upload stores nothing and does not count toward the day's limit. The checks, in order:

  1. The file is at most 4 MB.
  2. The image is one of ours and the extra packages are valid.
  3. A round is open.
  4. The file is a zip, tar or tar.gz archive with at most 10,000 entries, no links and no unsafe paths.
  5. At least one problem of the open round has a solver. If some have none, you confirm that they score 0.
  6. Your team has a submission left today.

The upload form reads the archive in your browser first and shows, for each problem, whether its solver was found.

Statuses

StatusMeaning
QueuedStored and waiting for a sandbox.
RunningBeing evaluated: first the extra packages are installed, if any, then the instances are run and checked.
CompletedEvery instance has a result. The score counts on the leaderboard if it is the team's best in the round.
FailedThe submission could not be evaluated at all. The reason is shown with it. It still counts toward the day's limit.

Each instance runs in a fresh sandbox, so the submission evaluation time depends on number of problems and time limits per problem.

Why a submission can fail
MessageWhat to do
The archive has no solver for any problem of Round nPut one folder per open-round problem, named by its slug, with solve.py inside.
The archive cannot be used: …The archive could not be extracted. Pack it again with a standard zip or tar tool.
The extra packages could not be installedRead the build log on the dashboard, then fix the list.
Installing the extra packages took longer than 10 minutesRemove packages that build from source, or pin versions with wheels for Linux.
Installing the extra packages ran out of memoryAs above.
Evaluation did not completeSomething went wrong on our side and the submission stopped for two hours. Submit again.

A problem on our side, such as a sandbox that fails to start, is retried automatically. If an instance still fails after 3 tries, it scores 0 with “Evaluation failed on our side”.

What you see afterwards

On the dashboard's Submissions page, each submission shows its status and score. While it is queued or running, an estimate of when its results arrive takes the score's place. Open the submission to see:

  • the environment: the image, the extra packages and their installed versions, or the build log if the install failed;
  • every instance's result, grouped by problem: Feasible with its score, or the reason it scored 0;
  • the archive you uploaded, to download.

The same data, except the estimate, is in GET /submissions/{id}. Solver logs, objective values and run times are not shown, since they could reveal the private instances. How the scores are computed is on Evaluation and scoring.