Sponsoring and Dispatching Runs
Know when to use sponsorship versus direct dispatch, what gets queued, and who controls the resulting run once money or a personal API key is involved.
Sponsorship and BYOK solve different problems
Sponsorship is the public fast lane. It moves a public problem or rerun immediately and uses omegaXiv-managed compute. BYOK direct dispatch is the private control lane for Pro members and admins who want the run tracked in their own workspace with their saved key.
Use sponsorship when you want a public problem to move now without assuming technical workspace ownership. Use direct dispatch when you need ongoing control, private branching, or Pro-scoped run management.
- Public problems can be sponsored by any signed-in member.
- Direct problem or paper branch launches require owner, collaborator, admin, or Pro-eligible direct access.
- If you do not have a saved key, sponsorship remains the fallback path for dispatch.
Who controls the run after dispatch
Ownership changes depending on how the run started.
Sponsored runs have tighter control rules than normal public browsing. The sponsoring user or an admin keeps the non-admin write controls for sponsored runs, including the ability to answer needs-input prompts or modify certain run actions.
Direct launches through your own API key are tracked in your runs workspace. That launcher receives the credited run record and can continue the work from their own workspace view.
A public problem can still remain view-only for users who did not fund or launch the active sponsored run.
This is intentional so funding and decision responsibility stay aligned during the active execution window.
What improves dispatch quality
- ✓Verify the problem description includes success criteria and relevant references.
- ✓Check the estimate fields if GPU or dataset assumptions materially affect cost.
- ✓Use sponsorship when turnaround matters more than queue ranking.
- ✓Use direct BYOK only if you are prepared to manage the run from your own workspace.