If you are supplementing an existing application, please reply in the original email thread. There is no need to resubmit the same request if the organizing committee can identify your application. State the system name and version, and address each requested item. A new application is needed only when the application itself changes or the committee explicitly asks you to reapply.

If you continue in the original email thread and the committee has already identified your application, you do not need to repeat the same ID. When starting a new thread, discussing multiple systems, or dealing with multiple versions, please identify the relevant application to avoid mixing up different requests.

Please first check your spam folder, email filtering rules, and the email address entered in your application. Then contact the committee to check the delivery record for the original application.

Along with the version name, please provide the corresponding fixed implementation, models, key dependencies, and a description of changes from the previous version. This information helps distinguish versions accurately and keeps the registration consistent with the implementation actually submitted.

Eligibility confirmation and version registration are separate steps. After receiving written approval, check the requirements in the original email and confirm that the new version name, fixed implementation, and required materials are complete. Supply any missing information so registration can proceed. Continuing in the original thread also helps connect the registration with the eligibility arrangement already confirmed.

First check whether the target track uses the same Add/Search URLs already bound to your Key. If the URLs are the same, you may register a new version under the existing Key and start evaluation after meeting the target track's Smoke and admission requirements. If the URLs differ, follow the endpoint-change process to apply for a Key, identifying the original system and application and the intended track so the requests can be linked. Registering a new version does not allow you to resume an old task with a new implementation.

An endpoint-change application is used to review and bind a new integration configuration. The evaluation quota for the same participant identity remains unchanged; it does not provide extra Full runs. Please plan integration and evaluation within your existing quota.

Please contact the committee with the original application, system version, and proposed Health URL. The committee will determine how to add it based on integration requirements and the current task status. To preserve configuration consistency, do not change configurations already bound to tasks yourself.

Please report the actual request-body, storage, and processing capacity, and whether the upgrade changes the implementation. Even if only gateway or resource settings change, explain whether endpoint behavior is affected. Changes to models, algorithms, or retrieval logic must be handled as a new version.

Port connectivity alone does not establish that the endpoint is working. Check whether the request is blocked by the gateway, application, or a downstream service. Provide connection or timeout records to help locate where the request stops. If no HTTP response was received, state that explicitly.

This is not currently supported. Registering a new version under the same evaluation Key cannot change its bound Add/Search URLs. To change them, submit a new evaluation Key application through the official website, including the original system, original application ID, new version, and an explanation of the endpoint changes for review and recordkeeping. Once approved, complete the appropriate track's Smoke test with the newly registered version before proceeding to Full. This process supports consistent recordkeeping; we apologize for the inconvenience.

First check the task ID, time, and evaluation stage to establish whether the logs belong to the same task and whether they come from requests still finishing or from other active tasks. Once those details are aligned, identify what needs attention to avoid accidentally changing a service that is still running.

We recommend continuing in the original thread, specifying the unresolved step and the issue you currently face. This preserves the communication history, connects the follow-up with previous confirmations, and reduces repeated explanations.

You may apply for the Industry leaderboard. Commercialization is not required: non-commercial open-source projects are also eligible, providing a participation route for teams using other open-weight or self-trained models. When choosing a leaderboard, note that Industry entries are not eligible for Cycle 2 cash prizes. Choose according to your actual model configuration and participation goals.

Cycle 2 evaluation is still in full swing. The Coding and Multimodal tracks give research teams, open-source projects, and product teams opportunities to validate memory systems in different task settings and demonstrate their technical strengths. Choose tracks that match your system's strengths and put your research and product capabilities to the test on real tasks.

Teams already participating in the Textual track may also explore Coding and Multimodal according to their capabilities, gaining insight into the system's applicability and opportunities for improvement across more task dimensions. Whether you focus on one setting or explore cross-track applications, we welcome evaluations that showcase your technical strengths.

For specific eligibility, evaluation arrangements, and exceptional cases, the latest rules on the official website and written confirmations from the organizing committee take precedence.