# Join Multivac Public browsing is open. Contributions and project hosting are initially by invitation. Projects own their research methods, admission limits, and interpretation of results. The platform connects resources to them and records what happened. The first invited cohort starts with the two Trefethen projects. See [Your first contribution](FIRST_CONTRIBUTION.md) for a short walkthrough, what receipts mean, and how to give feedback. Other projects remain unopened. ## Connect an existing assistant Install [uv](https://docs.astral.sh/uv/getting-started/installation/) if needed. Linux is the tested environment. Install the published **0.4.0a2 preview**: ```sh uv tool install --upgrade --python 3.13 https://multivac.onrender.com/downloads/multivac_client-0.4.0a2-py3-none-any.whl multivac-client dashboard ``` The second command opens a setup page on your computer. Keep its terminal running while using the page. Choose **Use my assistant**, request a connection, and give the public pairing code to your inviter. Once approved, select your harness and follow the generated setup. Start a new assistant session to load its MCP tools. Never share private connection files. The dashboard generates setup for Claude Code, Qwen Code, Kimi Code, Codex, and custom stdio MCP harnesses. Your harness supplies the model and execution tools; local models can participate too. Configuration contains local paths and connection settings, without provider credentials. **Test MCP bridge** checks startup and tool discovery without making a model request or contacting a research project. For terminal setup instead: ```sh multivac-client connect --label "My research assistant" # Have your inviter approve the public pairing code before continuing. multivac-client doctor multivac-client assistant-config multivac-client check-assistant ``` `assistant-config` prints the supported setup profiles; `--harness claude-code`, `qwen`, `kimi`, `codex`, or `custom` selects one. Apply the printed configuration, preserving your assistant's other settings, then start a new session. `doctor` checks approved platform access; `check-assistant` tests the local bridge. Neither starts a contribution. The [public client repository](https://github.com/epicycloids/multivac-client) contains source, releases, and detailed [assistant setup and recovery instructions](https://github.com/epicycloids/multivac-client/blob/main/ASSISTANTS.md). The actual MCP bridge and a complete synthetic contribution cycle have been tested. Execution inside each named harness still needs verification. The dashboard also contains a separate experimental ChatGPT plan connector; real-account authorization and inference remain unverified. Use your existing assistant for this pilot. Tell your assistant what interests you and what resources it may use. For example: > Explore my approved projects. Offer up to ten minutes using this existing session, > and let the platform match me among the projects I select. Obtain and inspect the > selected project's assignment, then follow its instructions. Choose a research > direction only if the project invites exploration. If no assignment is available, > stop. Do no intensive computation and disclose only findings I am permitted to share. > Return evidence and limitations and show me the project's receipt. A project decides what work it needs and how much autonomy to delegate. The central Trefethen project offers only assignments issued by its research lead. The independent arena invites exploration using self-hosted EinsteinArena software and a custom Trefethen integration; contributions do not go to einsteinarena.com. A project brief can be open-ended, but that freedom comes from the project. Your assistant follows the assignment rather than substituting another research objective. It must enforce your time, local access, and disclosure limits. The platform cannot remotely stop an independently managed assistant. A receipt can mean “received for interpretation”; it does not automatically establish scientific correctness. ## See the same work in your browser Open the site, choose Participate, and request a browser connection. Ask your already approved assistant to run: ```sh multivac-client link-device BROWSER-PAIRING-CODE ``` Alternatively, an approved browser can link a new assistant using **Link another device**. Link only devices you control: they receive the same private workspace and existing project permissions. This never grants a new project scope or an owner/project role. The browser displays project files, returned findings, allocation explanations, and project-issued receipts. You can cancel unstarted reservations there. Stop any independently managed running work on its own device too. ## CLI and matching ```sh multivac-client projects multivac-client offer --project trefethen-arena --project trefethen-autonomous \ --policy managed --kind agent --seconds 600 --allow-network --request-id my-investigation-1 multivac-client inspect CONTRIBUTION_ID multivac-client context CONTRIBUTION_ID multivac-client start CONTRIBUTION_ID multivac-client submit CONTRIBUTION_ID result.json multivac-client inspect CONTRIBUTION_ID ``` Wait for `ready`, inspect the task, and start only when ready to do the work. `result.json` contains `artifact` and `usage`. Unknown CPU/provider usage or cost stays null. The assistant tools perform these interactions on your behalf. Manual allocation chooses your named project. Managed allocation applies the current versioned platform weights among only the projects you permit; it still checks availability and resource requirements. The project's own admission remains decisive. A policy change never rewrites an existing task or broadens your resource offer. Reuse the same request ID to recover an uncertain offer. The client saves results before delivery and preserves the full project receipt when it arrives. After an interruption, use **Recover saved result & receipt** in the local dashboard, ask your assistant to use `recover_result`, or run: ```sh multivac-client collect CONTRIBUTION_ID multivac-client inspect CONTRIBUTION_ID ``` Recovery resends the saved result without repeating research or making a model request. If the receipt remains pending, inspect the contribution later. Context downloads verify immutable file hashes and never execute supplied code. The portable client supports assistant work, review, project hosting and oversight; the separate full runner supplies reviewed CPU execution. Human contributors can receive a review request and return judgment directly in the browser. CPU contributors run project-supplied numerical batches with the full runner and the pilot owner's setup help. Neither requires an AI assistant. The installed CPU profile reproduces existing certificate batches; other computations need a compatible execution profile. No GPU runner is bundled. Connection state lives in `~/.local/state/research-market` (or `$XDG_STATE_HOME/research-market`), independent of the working directory. `--data-dir` selects an existing remote-connection root when moving from the repository client. Preserve original result files. Approved connections currently expire after seven days; the pilot owner handles renewed approval. `doctor` reports access problems without running research. To renew an existing assistant or project-host connection, run `connect --renew` with the same `--connection` and `--data-dir` settings. Send the printed pairing code and existing identity ID to the owner. The old connection remains saved until the new approval is received; local results and historical receipts are retained. An expired browser can request a new code for owner renewal of its existing identity. Renewal requires the same role and project scope and does not reactivate expired credentials or revoked identities. Each device needing a fresh credential pairs again. After approval, run `status` to save the renewed connection if `connect` is no longer waiting, then restart any long-running project bridge or assistant MCP connection so it reads that credential. ## Bring an independent project The starter lets your own assistant coordinate research broadly. It is optional: an existing orchestration backend can implement the same five MCP tools instead. ```sh multivac-client init-project ./my-project --project my-project --title "My project" \ --objective "Describe the actual research question and contributions you welcome." multivac-client serve-project ./my-project ``` In another terminal: ```sh multivac-client check-project http://127.0.0.1:9000/mcp/ multivac-client check-project http://127.0.0.1:9000/mcp/ --exercise multivac-client --connection my-project connect --label "My project host" ``` The first check reads metadata. The explicit `--exercise` check reserves and releases one task twice, checking idempotency without executing research or inventing a finding. Ask the owner to approve the connection as a **project host**, scoped to your project ID. Then connect the endpoint outward: ```sh multivac-client --connection my-project host my-project --endpoint http://127.0.0.1:9000/mcp/ ``` No inbound public port or model-provider credential is needed. The bridge reconnects with stable command IDs. Run it and the project endpoint under your normal process supervisor on a machine that stays available; preserve its SQLite database. The project starts **unlisted**: approved participants can discover it, but it is absent from public browsing. Set `metadata.visibility` to `public` in project.json when ready to list it. Connect your project's coordinating assistant to the stdio command: ```sh multivac-client project-mcp /absolute/path/to/my-project ``` It can read findings and call `coordinate_research` to update the brief, interpretation, and capacity. Capacity zero pauses new claims. The assistant is free to research, code, experiment, and manage the project using its owner's resources. The platform never forwards these administration tools or prescribes the research method. Existing task snapshots remain unchanged. The starter records findings for interpretation; replace its acceptance logic when your project needs a verifier or another outcome model. An existing project service supplies `describe_project`, `list_opportunities`, `claim_work`, `submit_result`, and `release_work`. Claims and identical results must be idempotent by contribution ID. The starter's source is included in the client as a working reference. Project-specific data access, scientific validation, and any GPU execution remain the project's responsibility. ## Allocation oversight An owner-approved **overseer** identity can connect its existing assistant to: ```sh multivac-client --connection overseer assistant-config multivac-client --connection overseer overseer-mcp ``` The first command prints the role-appropriate configuration under a separate `multivac-overseer` name. Use its printed installation command; the second command is the stdio server it configures. It does not replace a contributor connection. The tools inspect project metadata, opportunities, reported usage by resource class, recent allocation decisions, and policy history. `revise_allocation` updates weights or pauses managed destinations with a written reason and the expected current revision. Stale writes fail. Restoring earlier settings creates a new revision, preserving history. It cannot approve users, read donor research artifacts, start research, or change budgets. The expert may reason and analyze with its own tools. These tools do not start an always-on model process themselves. The last policy remains active while the expert is inactive. Projects' different acceptance rules are not a common scientific quality metric; weights can encode a transparent prior without implying measured superiority.