Choose a simulator.
Chat or API.

Physim and CellSim

Choose a simulator in the workspace sidebar. Physim runs coupled physiology; CellSim runs the full-cell model. Switching starts a new conversation. Reopening a conversation restores its simulator, proposals, results and downloads.

CellSim exposes named initial-state changes, supported parameters, state trajectories, fluxes and continuation from completed runs. Its API uses duration_s and observation_times_s, in seconds. The default is 10 simulated seconds. Explicit durations are honored. Model details distinguish the requested window from previously validated runs. The current reference is the canonical chemical model; its profile identifies the checkpoint and current validation scope. Saved results retain their original model version. Per-neighborhood live activity is not yet streamed by this runner.

GET /api/cellsim/model
GET /api/cellsim/model/search?q=ATP&kind=state
POST /api/cellsim/runs
Authorization: Bearer <your-personal-key>
Idempotency-Key: cell-baseline-1
Content-Type: application/json

{"duration_s":10,"readouts":["M_atp_c","M_adp_c"]}

Use the returned run ID to retrieve status and accepted results at /api/cellsim/runs/<id> and /api/cellsim/runs/<id>/results. The run cards and Trajectories tab use the same data.

Two training workflows

Symbolic Life is being built for managed trace generation and direct reinforcement learning against Physim. Both share task definitions, difficulty settings, environment versions and verification. The web app and API are interfaces to both workflows.

1. Write a task or generate a task set with a defined context, intervention, target and answer contract.
2. Choose a difficulty profile or assess an existing task. Structural depth and information budgets guide generation; model pass rates calibrate measured difficulty.
3. Validate the task against the simulator, establish its reference result and freeze the task and grader versions.
4. Run managed model attempts, or connect your own trainer to isolated environment instances.
5. Collect traces, outcomes, rewards and reproducibility metadata.

Generate samples for me

The task generator has an n-hop difficulty slider. Choose a source control, set the depth, and preview a task targeting a real downstream variable. Download its draft JSON or open it in chat. Depth counts the shortest directed source-dependency path, including intermediate assignments; empirical difficulty is recorded separately.

Select a model or supported inference endpoint, sampling settings and attempt count. The managed runner executes the tasks and exports JSONL attempts alongside a task manifest and run metadata. Each attempt should retain the model’s returned messages, tool calls, observations, submission, verifier result and execution status.

Give my trainer environment access

Choose the task distribution, difficulty profile and instance count. Your own inference and training loop resets episodes, takes actions, receives permitted observations and submits answers for reward. The web app configures and monitors the pool; your code controls the training loop through the API.

The capacity target is up to 1,000 isolated environment instances. Logical instance count and simultaneous GPU simulation throughput are separate; pool capacity and throughput must be measured before they are offered as a service guarantee.

Current availability

Model discovery, chat model selection, fresh native runs, continuation and result downloads are available through the explorer and API. Recorded tasks support isolated episodes, numerical grading and JSONL traces. Automatic task admission, empirical difficulty calibration, managed batch rollouts, complete training-sample bundles and scalable pools are still being built. Native jobs run in isolated GPU workers within the deployment’s available capacity.

Why numerical simulation and RL?

Our working definition of biological superintelligence is performance beyond human experts at predicting downstream responses and reasoning about coupled biological systems across unfamiliar contexts. This is a research goal; it is not a capability demonstrated by the current preview.

A numerical simulator encodes explicit mechanisms and computes the consequences of an intervention. It can reset a context, construct matched controls, and generate new tasks with checkable outcomes. A task asks the model to reason about a biological system. The simulator supplies the reference against which its answer can be checked. A task grader converts the simulated outcomes into feedback about a prediction or decision. Reinforcement learning can use repeated interaction and reward to improve the agent’s strategies, while varied tasks and held-out contexts test whether the improvement generalizes.

There is precedent for this learning mechanism. AlphaGo Zero achieved superhuman Go performance through reinforcement learning from self-play under known game rules. Learning Dexterous In-Hand Manipulation demonstrated policies trained in simulation transferring to a physical robotic hand, using randomized simulation conditions to improve robustness. These results motivate the approach; they do not establish transfer to biological reasoning.

Biological models approximate real systems. Numerical verification checks that a trajectory satisfies the implemented model; independent experimental validation tests whether the model and the trained agent predict real biology. The Systema perturbation benchmark illustrates why evaluation must distinguish perturbation-specific prediction from systematic effects that can inflate apparent performance.

The proposed learning cycle is therefore: train against a versioned simulator, evaluate on unseen tasks and independent experimental data, use discrepancies to improve the biological model, and repeat. Each training run uses a fixed environment and grader so its rewards remain interpretable. Simulator skill, numerical correctness, and experimental validity are measured separately.

Explore the simulator through chat

Ask what can be changed, search for a hormone or organ, and inspect a control’s current value. Chat explores the full Physim model through the same API your code can use.

Use the model picker beneath your question to choose an answering model. Astra is the default; search the featured models or the full catalog of available models with tool support. You can switch between questions, and each reply identifies the model that produced it. Every answering model uses the selected simulator’s tools.

A fully specified task runs immediately. If you leave important choices open, the assistant picks sensible settings and presents a Run/Edit proposal. Review the interpretation, time window and controls, then run it or change the settings. Saying “choose whatever” authorizes those defaults and skips approval.

Physim simulations default to one hour (60 simulated minutes) with adaptive integration when no duration is given, in chat and through the API. Explicitly requested shorter or longer windows are honored within the service limits. An hour is an observation window, not a claim that the system has reached a steady state.

Specify the intervention, amount, time horizon and quantities to measure. The assistant submits a native simulation and shows a run card that updates through queued, running, completed or failed states. Accepted results include the numerical and source-verification checks.

Expand “View evidence” to see each API method, path, request body and response. Completed run cards offer a Harbor trajectory and a separate simulation-data JSON download. The assistant can explain those measurements or continue from a completed run.

Compare male and female profiles

The default model is the male hormone-feedback profile, male-hpg-feedback-v1, in both chat and the API. Its experimental validation status stays attached to results. Ask for a female profile, another reference, or a comparison when needed; ovarian questions use the female profile. Both models include shared hormones such as FSH and LH.

Each profile has its own initialized checkpoint, model version and available controls. Female results identify the cycle phase. Profile metadata also identifies reference calibrations and modeling limitations.

GET /api/physim/model/profiles
GET /api/physim/model/search?profile=male&q=FSH
GET /api/physim/model/search?profile=female&q=FSH

POST /api/physim/runs/batch
Authorization: Bearer <your-personal-key>
Idempotency-Key: reference-comparison-1
Content-Type: application/json

{
  "runs": [
    {
      "label": "Male reference",
      "baseline_profile": "male",
      "duration_min": 1,
      "observation_times_min": [0, 1],
      "readouts": ["FSH-Circulating.[Conc(IU/L)]"]
    },
    {
      "label": "Female follicular reference",
      "baseline_profile": "female",
      "duration_min": 1,
      "observation_times_min": [0, 1],
      "readouts": ["FSH-Circulating.[Conc(IU/L)]"]
    }
  ]
}

This checks two unperturbed references. To measure an intervention, include a matched control and a perturbed run for each profile: four runs total. Compare intervention minus control within each profile. Batch admission is atomic; unavailable profiles or insufficient capacity submit no new branches.

Profiled runs use adaptive integration. The initial step is set by step_size_min; subsequent steps are chosen by the native solver. Requested observation times are reached directly, without interpolation. Omit observation_times_min for eleven shared points, or request only zero and the final time for an endpoint question.

Discover controls and run a simulation

The model registry exposes thousands of parameters and named readouts; the exact set depends on the selected profile. Search and inspect exact names before choosing an intervention. Metadata distinguishes parameters, differential states, algebraic states and derived readouts; units are supplied where known.

GET /api/physim/model
GET /api/physim/model/search?q=insulin&kind=parameter
GET /api/physim/model/variable?name=InsulinPump.Setting

POST /api/physim/runs
Authorization: Bearer <your-personal-key>
Idempotency-Key: insulin-example-1
Content-Type: application/json

{
  "label": "Insulin infusion integration check",
  "duration_min": 0.002,
  "parameter_set": {
    "InsulinPump.Switch": 1,
    "InsulinPump.Setting": 1
  },
  "readouts": ["InsulinPool.[Insulin]"]
}

GET /api/physim/runs/{id}
GET /api/physim/runs/{id}/results

This example is a short integration check, not a long-horizon physiological study. Change the horizon and readouts for your question. The worker queues native jobs; only a completed, verified job has results.

A run accepts parameter_set, state_set, state_add, and scheduled kicks with time_min, set and add. Set start_run_id to continue from one of your completed runs. Read /model for grid and job limits.

Algebraic states are recomputed by the solver; change the driving parameter to sustain a change. Derived readouts are computed from the verified trajectory and may be null when their defining ratio is undefined. Unknown units are marked as model-native units. For a causal effect, compare with a matched control using the same starting state, observation times and horizon.

Query the API

Create a personal key in API keys once key access is activated. Send it as a Bearer token. The portal handles the private backend credentials; your code does not need a Google IAM token.

Use your portal’s URL with the prefix /api/physim. This deployment uses https://symbolic.life/api/physim. Local development continues to use http://localhost:3000/api/physim.

curl "$PORTAL_URL/api/physim/problems?depth=14" \
  -H "Authorization: Bearer $PHYSIM_KEY"

curl "$PORTAL_URL/api/physim/episodes" \
  -H "Authorization: Bearer $PHYSIM_KEY" \
  -H "Idempotency-Key: my-first-episode" \
  -H "Content-Type: application/json" \
  -d '{"task_id":"pressure_intact_gfr_ml_min_36"}'

Keep the returned id exactly as provided. Episodes belong to your account and can be used through either chat or the API. Every POST requires an Idempotency-Key; retry an uncertain request with the same key and body.

Select a model through the API

List available answering models with GET /api/models, using the same personal key. Pass an exact returned model ID to POST /api/chat. Omitting model uses the server default.

POST /api/chat
Authorization: Bearer <your-personal-key>
Content-Type: application/json

{
  "requestId": "model-example-1",
  "model": "openai/gpt-6-astra",
  "messages": [{"role": "user", "text": "Show me the insulin controls."}]
}

This messages-based request is stateless. Saved conversations use conversationId, requestId, text, revision and model. Keep the question and model unchanged when retrying a saved request ID.

// POST /api/physim/episodes/{id}/actions
{"tool":"observe","arguments":{"time_s":2.4}}

// POST /api/physim/episodes/{id}/submit
{
  "answer": { "delta": 3.4 },
  "reasoning": "Your explanation of the predicted response."
}

The delta above is an example submission, not a reference answer. The passed field is the authoritative grading decision. Tool choice and explanatory prose are not graded.

Recorded verification tasks

The separate task catalog contains 60 questions from one recorded pressure experiment. Its 15 readouts are a benchmark subset, not the simulator’s capability limit. These episode endpoints replay saved observations and grade predictions; fresh work uses the native run endpoints above.

A missing control must be established by searching the full registry. The API does not invent variables or silently substitute a different hormone or physiological intervention.

Your results

Choose “Download Harbor trajectory” in a conversation, or “Harbor trajectory (.json)” on a completed run. This downloads trajectory.json in Harbor’s Agent Trajectory Interchange Format (ATIF-v1.7): ordered user messages, assistant replies, tool calls and their matching observations, with model identifiers and provenance.

The run-card download also includes that run’s current specification, verified measurements, units, profile/checkpoint identity and numerical verification under extra.physim.run_snapshot. These are export-time evidence; they are kept separate from observations the agent actually received. “Simulation data (.json)” downloads only the native run result.

Use GET /api/conversations/{id}/trajectory with your session or personal API key. Add ?run={run-id} to include a run referenced by that conversation. Exports enforce conversation and run ownership. Interrupted conversations retain their recorded evidence and status. Missing historical call arguments are reconstructed from saved requests and marked; unrecorded reasoning, model-round grouping, system prompts, token counts and costs are not invented.

An ATIF trajectory is a completed interaction record. A runnable Harbor task is a separate package containing an instruction, environment and verifier; this download does not claim to supply that package or a benchmark reward.

A trace is one JSON object per line, using the physim.trace.v1 schema. It records the task, episode state, observations, submission and verifier result. Your chat transcript, selected models, replies and tool evidence are saved to your account and can be reopened across devices.

The simulator and reference data remain hosted by Syntensor. The recorded verifier endpoint and its original customer tokens continue to work separately; personal portal keys are used with the portal URL above.