RULES

The ground rules for fierce strategic competition Fair competition starts with clear standards.

ROOKIE TRACKMASTER TRACK

Contest Rules

Dev Tools Guide

Schedule

NYPC 2026 consists of a Qualification Round (QR) and a Final Round (FR).

In the Master Track, one AI-versus-AI (head-to-head) problem is presented in each round.

The problem presented in the Final Round is not disclosed before the round begins, but it shares the same basic framework as the problem presented in the Qualification Round. Therefore, you can partially reuse the code you wrote in the Qualification Round during the Final Round.

Qualification Round

Before the Qualification Round begins, you can test the environment for the competition in advance through the practice problem. The score of the practice problem is not reflected in the total score and does not affect your final score.

A single problem is given per round, and participants must solve the problem and submit answer before the round ends.

After the round ends, each team must submit a replay of their problem-solving process within the submission deadline.

Final Round

The top 20 or more teams in the Qualification Round can participate in the Final Round held in Seoul on August 29.

The detailed schedule will be announced later.

  • All team members must arrive at the Final Round venue.
  • Entry is not permitted after the entry deadline.

Solving Problems

Participants can see the problem description on the problem page, and submit one source code and one (optional) binary file.

  • Code must be 1 MiB (1048576 bytes) or less, and the binary file must be 10 MiB (10485760 bytes) or less.
  • After you submit the code, the grading with sample AI begins. You can check the result after grading is done.
    • Grading results are displayed in win/draw/loss.
    • Input data is fixed.
    • The sample AI uses the same strategy against the same input.
  • You can submit your answer multiple times. You can choose one main submission for evaluation.

Qualification Round

  • You can submit code twice every 5 minutes.
    • If you submit code two or more times within 5 minutes, additional submissions become available 5 minutes after the time of the first (second-to-last) submission, not the second (last) submission.
    • The submission interval and count may change at the organizer's discretion.

Final Round

  • You can submit code once every 10 seconds.

For more details, please refer to the Evaluation Criteria below.

Execution and Grading Environment

The execution and grading of all submitted code is performed in the following environment:

  • Amazon Web Services c7a.2xlarge instance
  • Custom processor based on 4th-generation AMD EPYC
  • Clock: 3.7 GHz
  • Processor architecture: 64-bit
  • OS: Ubuntu 24.04

Please note that code not working properly in this environment will not be graded. For more informations on the compilers used for each language and the specific development environment, please refer to the "Dev Tools Guide" page. Elapsed time and consumed memory are measured based on the resources used by the process in which the source code submitted by the participant is executed.

  • Elapsed time is measured as the time process occupied the CPU (CPU time).
  • Consumed memory is measured as the amount of memory the process uses. This includes not only the variables and arrays declared by the user, but also the libraries (header files, modules, etc.) used per language and the memory allocated to the process by the operating system.
  • Solving the problem using multiple threads is allowed. However, only one CPU core is allocated to the program, and when measuring the time and memory limits, the time and memory of all threads are summed.

Grading Results

For each submission, one of the following results is displayed and the details of each result are as follows.

  • CE (Compile Error) - The compilation of the submitted source code failed.
  • TLE (Time Limit Exceeded) - The execution time of the submitted source code exceeded the time limit specified in the problem.
  • WTLE (Wall Clock Time Limit Exceeded) - The actual wall clock time of the submitted source code exceeded the set time limit. This is the case where the total execution time, not the time the process occupied the CPU, was exceeded, which may indicate that an error occurred during execution.
  • RE (Runtime Error) - An error occurred during execution. This error can also occur when the memory limit is exceeded, or the return code is non-zero.
  • WA (Wrong Answer) - The program terminated successfully, but the output was incorrect.
  • IE (Internal Error) - An unknown internal error occurred. If you receive this result, you must contact the organizer.
  • X wins (A/B/C) - The result of sample test against the sample AIs. A draw count as 0.5 wins.

If the grading result falls into multiple cases, then an arbitrary one is shown. For example, if the program exceed the time limit while abnormally terminating, the result may be displayed as either RE or TLE.

Questions on Problems

If there is an error in a problem or other issue that disrupts the competition including an internal error, you can make a question by clicking the "Ask a Question" button on the problem page or by pressing the Ctrl + K shortcut in the coding area.

  • If your question contains inappropriate expressions such as profanity or abusive language, you may be disqualified.
  • Questions related to the solution of the problem will not be answered.

Examples of Invalid Questions

The followings are examples of these invalid questions.

"It works on my machine, but the result is not shown correctly when graded."

  • The provided testing tool may differ from the actual grading environment. Please double-check the problem's input/output format and so on.

"It works on my machine, but I get a compile error when I submit."

  • The development environment used by the participant and the grading environment where the program is actually compiled and executed may differ. Please refer to the "Dev Tools Guide" page.

Answers

  • Only problem-related questions are allowed. - This applies when the nature of the question is off-topic.
  • Read the problem statement. - This applies when the question is judged to be sufficiently answered by the content written in the problem.
  • No comment. - This applies when the organizer judges that the answer could in any way affect the participant's problem solving or the progress of the round.

Evaluation Criteria

  • You can select one of the submissions that received a cutoff score or higher in the sample AI grading as your main submission.
    • If no main submission is selected, the latest submission among those that received a cutoff score or higher in the sample AI grading is selected as the main submission.
    • The main submission can be changed freely during the round, and up to 1 hour after the round ends.
  • The Pretest and System Test are conducted using the main submission.

Practice Problem

Pretest

Before the Qualification Round begins, every day at 9 PM (KST), the Pretest begins with the code each team selected as its main submission. At least 20 matches per test run in a swiss tournament format, and rankings are provided.

The practice problem does not undergo a System Test and is not reflected in the final results.

Qualification Round

Pretest

Every day at 10 AM, 3 PM, and 9 PM (KST), the Pretest begins with the code each team selected as its main submission. At least 20 matches per test run in a Swiss tournament format, and rankings are provided.

The Pretest is a reference result only and does not affect the System Test.

System Test

At least 50 matches in a Swiss tournament format run to select the top 100 or more teams. The selected teams battle each opponent at least 5 times in a round-robin format and the final ranking is determined.

Final Round

Pretest

Starting from 1 hour mark, the evaluation is conducted at least 10 times based on the code each team selected as its main submission. On the day of the competition, you can check information about each Pretest at the venue.

Pretest is in round-robin format, and rankings are provided.

The Pretest is a reference result only and does not affect the System Test.

System Test

Each opponent is played at least 5 times to calculate the number of wins against each opponent. When determining the winners, if the difference in the number of wins between two teams is small, an additional match may be conducted.

The evaluation proceeds as follows.

  1. Based on the matches among all Final Round participants, the top 10 teams with the highest number of wins against all other opponents are selected.
  2. Based on the matches among the top 10 teams, the top 5 teams with the highest number of wins against all other opponents are selected.
  3. Based on the matches among the top 5 teams, the top 2 teams with the highest number of wins against all other opponents are selected.
  4. Based on the matches between the top 2 teams, the team that beat its opponent more is selected as the final winner.

Tournament Rules

A tournament is in either a Swiss tournament or a round-robin format. A Swiss tournament runs predetermined number of matches. A round-robin matches against all opponents for the predetermined number of matches within a round.

Seeding

  • Seeds are assigned according to the ranking of the previous Pretest. (The smaller the ranking, the smaller the seed.)
  • For first-time participants and System Test, smaller seeds are assigned in order of earliest submission time.

Swiss Tournament Opponent Determination

1. Bye handling (when the number of participants is odd)

  • The bye is selected amongst participants who have not yet received a bye.
  • If tied, the one with the lowest score is selected.
  • If tied, the participant with the smallest seed is selected.

2. Opponent matching

  • From the teams with highest score and having smallest seed, a matching opponent is determined.
  • Matches are made with opponents not yet played.
  • If tied, Opponent with the highest score is selected first.
  • If tied, the match is made with the opponent with the largest seed.

Round-Robin Opponent Determination

  • Matches are played against all opponents for the predetermined number of matches.

Matchup rules

  • Multiple matches are run simultaneously in each round.
  • If the problem is not symmetric, both sides alternate playing first and second move.

Scoring

Points are awarded according to match results as follows:

  • Win - 1 point
  • Draw - 0.5 points
  • Loss / program error (runtime error, incorrect output, time limit exceeded, etc.) - 0 points

Final Ranking Determination

The final ranking is determined according to the following criteria:

  1. The participant with the higher total score has the smaller ranking.
  2. If scores are equal, the tiebreaker criteria are applied in order.
  3. If there is still a tie, the participant with the smaller seed has the smaller ranking.

Swiss Tournament Tiebreaker Criteria

  1. The participant with more rounds in which the match points were higher than the opponent's has the smaller ranking.
  2. The participant with the larger sum of the total scores of their opponents has the smaller ranking.
  3. The participant with the larger sum of weighted early-round scores has the smaller ranking. (score of the i-th round × (total number of rounds - i + 1))
  4. The participant with the larger sum of opponent scores in early rounds with weighting applied has the smaller ranking. (opponent's score in the i-th round × (total number of rounds - i + 1))

Round-Robin Tiebreaker Criteria

  1. The participant with the higher Sonneborn-Berger score has the smaller ranking. (for all matches, the sum of my match points in that match × the opponent's total score)

Performance

A performance metric is provided to gauge the skill of the submitted code. The performance is reference material and is not reflected in the evaluation.

  • An "expected performance" is provided based on the number of wins obtained through matches of pretests.
  • Performance is calculated based on the results of matches against participants nationwide.

For the performance calculation formula, please refer to the performance calculation formula PDF (Korean).

Replay

After the round ends and before the replay submission deadline, each team must submit a replay.

A replay is the team's problem-solving process in the time order. The length is between 1 and 20 pages, and it can be in any format, but it must be submitted as a PDF file.

A replay must include the followings:

  • The overall timeline solving the problem (the Pretests or the team's submissions can be used as a reference)
  • What difficulties were found in the submissions, what considerations were made, and how they were solved and/or why they could not be solved
  • (If an LLM was used) which model was used and how it was used

The following content is not required, but it is recommended to include in addition.

  • The approach to the problem, and the observations and considerations made to solve the problem
  • Materials such as captures, photos, or code snippets that can visually show the problems you experienced or the process of solving them
  • (If an LLM was used) what the limitations of the LLM were, if any, and how you overcome them, if you did
  • Other points that were good, regrettable, difficult, interesting, or anything else you want to write
  • Complaints about the competition system, problems, or points you thought would be good to improve

The replay is not included in the System Test evaluation criteria.

Additional Restrictions

A replay is a piece of writing what you experienced and felt. Even if you used an LLM to solve the problem, the problem-solving process and considerations contained in the replay must be written without an LLM, by yourself.

  • Even when grammar correction or similars are needed, you must not use an LLM, but use a spell checker or similars.
  • If all or part of the body appears to have been generated using an LLM, or if it cannot be confirmed that you solved the problem yourself, the organizer may request additional proof or modification of the replay.
    • However, inserting your own prompts or conversation history with an LLM into the replay for the purpose of supplementing is permitted exceptionally.
  • Please take special care that your sensitive personal information is not included in the replay.

If a replay contains inappropriate expressions such as profanity or abusive language, your participation in the competition may be restricted or your award may be revoked at the organizer's discretion.

Code of Conduct

You may receive penalties if cheating is detected. This includes and not limited to:

  • For problems other than the practice problem, disclosing or leaking the problem and the problem-related algorithms, solutions, or source code to an unspecified people
  • Discussing materials related to a problem other than the practice problem with people other than team members
  • Submitting the code you do not have permission to use
    • Example 1: Code obtained through methods such as hacking
    • Example 2: Code obtained using methods such as reverse engineering (reverse analysis) of commercial programs
    • Example 3: Code obtained through other illegal methods
    • Even if the code is publicly available to an unspecified number of people on the internet, etc., it is considered to be without permission to use if the source is not indicated in comments or the like.
  • Submitting code written by someone other than team members after the start of the competition
  • Taking the competition on behalf of someone, or solving problems with help from someone other than team members
  • Sharing or disclosing your personal ID and password to others
  • The same person participating multiple times with multiple IDs
  • Obstructing other people's participation in the competition or attacking the system
  • Other acts that can commonly be regarded as cheating

Other acts may also be regarded as cheating at the organizer's discretion. If cheating occurs or is suspected, participation and award eligibility may be revoked at any time during the competition period. If the operation of the competition is disrupted, the organizer may pursue legal action.

The following acts are not cheating.

  • Discussing or sharing the problem, problem content, solution methods, source code, etc. for the practice problem
  • Discussing or sharing problem content, solution methods, source code, etc. among team members
    • In particular, using a private chat room or code repository that outsiders cannot see is not cheating.
    • However, if you use a chat room or code repository, please take special care with the visibility settings.
  • Generating or modifying code using LLMs (ChatGPT, Copilot, etc.) and other coding assistance tools

If you are uncertain about whether an act is cheating, do not judge it arbitrarily; be sure to contact the organizer.

Program Usage Guide

  • NYPC encourages the use of generative AI represented by large language models (hereafter LLMs) as a tool to help with creativity and problem solving.
  • The core of the competition is to evaluate human creativity and problem-solving ability, and (whether one can access a large amount of computing resources) should not have a major impact on the competition.
  • Therefore, the following uses of LLMs are explicitly prohibited.
    1. Obtaining a large amount of output from an LLM using an automated method
    2. Using multiple LLMs to output different code for the same purpose
    3. Selecting from a large amount of code or ideas using an LLM
  • Using an LLM is not essential for participating in the competition, and you can participate without an LLM.

Permitted Examples

  • Using an LLM to translate the problem and brainstorm ideas
  • Using an LLM and an LLM-powered IDE (Codex, Claude Code, Gemini Code Assist, Cursor, etc.) to write and debug code
    • Using the IDE's Auto-complete, Ask, Plan Mode, etc.
  • Generating answers using a Chain-of-thought approach
  • Using a program in any way that does not use an LLM during execution
    • This does not mean that you must not run an automated program written with an LLM.
  • Writing and evaluating code in large quantities by methods other than an LLM

Non-Permitted Examples

  • Calling an LLM in large quantities using a script, then selecting and submitting code for the problem by a certain method
    • Even if you selected the code using a method that does not use an LLM, if the code was created with an LLM, it constitutes cheating.
  • Using a single prompt, but the LLM autonomously generates a large amount of code and provides some of it to the user
  • Including text written or modified by an LLM in the body of the replay by any method
    • Exception: Attaching or quoting a conversation with an LLM, or wording from it, verbatim in the replay is permitted.

Even if you do not directly prompt the LLM, if the LLM commits an act that constitutes cheating, you are the one who has committed cheating. All responsibility for the use of LLMs lies with you.

The organizer may request an explanation of the problem-solving process from participants if necessary, and participants must respond faithfully to this. You may also suffer penalties if a problem arises due to poor code management. When using LLM tools, you must opt out of having your data used for training.

Q & A

Q1. LLM models use a Chain-of-Thought approach. Is this also large-scale generation of output using an API?

A1. No, even if Chain-of-Thought is used, it is not judged as large-scale generation if the query was done manually.

Q2. I asked an LLM the same question multiple times. Is this also treated as large-scale generation?

A2. No, it is not judged as large-scale generation unless the query was made by an automated method using an API or script. However, even if done manually, making dozens or more identical queries by simultaneously using multiple accounts or sessions may be treated as equivalent to large-scale generation.

Q3. Do the above restrictions also apply to code used for testing, even if it is not directly submitted code?

A3. Yes, they apply. Even if the code is not submitted, all code used when solving the problem must be written in compliance with the restrictions.

Q4. An LLM-equipped IDE automatically uses tool calls. Is this cheating?

A4. Basically, an IDE automatically using tool calls is not cheating, but it becomes cheating when that tool call involves an automated LLM tool call or evaluation of code generated by an LLM. The responsibility for supervising this tool use lies with you.

Q5. Is the restriction that you must not generate different code that performs the same action judged per team member or per individual?

A5. It is judged per individual.

Q6. Is learning how to use an LLM from someone other than a team member cheating?

A6. Receiving help of any kind from another person for the purpose of competition use is cheating.

Q7. If externally generated code was created through large-scale code generation, can that code be used?

A7. Please refer to the "The following acts are not cheating." item above.

Q8. Can I use multiple LLM sessions in order to use multiple types of LLMs?

A8. You may use multiple LLM sessions as long as you do not use multiple sessions simultaneously.

Q9. Does the organizer provide an LLM for use?

A9. The organizer does not provide an LLM.

Q10. Can AI models and generative AI be used inside the code submitted in the competition?

A10. It is possible as long as it fits within the source code and binary size limits. However, the competition environment does not have network communication. For details, please refer to the "Dev Tools Guide".