SF Compute

Today, San Francisco Compute (SFC) announces SF Autoresearch, a platform as a service (PaaS) built for autoresearch and agent-driven experimentation. Give your agent compute, an objective, and a way to measure progress. It can run experiments, compare results, and choose what to try next. Start from your terminal, connect your own agent, or request access to our managed research agents.

Install the CLI on macOS or Linux, then sign in to your Autoresearch account. On Windows, use Windows Subsystem for Linux (WSL).

curl -fsSL https://autoresearch.sfcompute.com/cli.sh | bash
export PATH="$HOME/.local/bin:$PATH"
autor login

Create an H100 node and check its GPU:

autor node create --name first-experiment --chip h100 --wait
autor run first-experiment -- nvidia-smi

The --wait flag waits for capacity. nvidia-smi reports the GPU your code can use. When you finish, stop compute billing and keep the node’s files:

autor node stop first-experiment

Connect the coding agents installed on your machine through the Model Context Protocol (MCP), which lets agents call Autoresearch tools:

autor mcp install

Then give your agent a task:

Run my benchmark on an H100. Record the baseline, try three changes,
and compare their results. Stop the node when you finish.

Our fully managed research agents can work for days while you’re away. Give a researcher your source code, an objective, and a budget. Define the checks that a result must pass, then let it run experiments and evaluate the evidence.

Use a managed researcher directly, or have your own agent delegate a research task to one. Managed research is in private preview; talk to us for access.

You can also use the research harness through MCP and keep experiment selection in your own agent. The harness handles execution and records the results. Your agent decides what to test next.

Autoresearch buys compute through SFC’s order book, a physically settled market where customers buy and resell GPU capacity. SFC operates every cluster it sells capacity on. That gives you a path from one experiment to thousands of GPUs without a long-term capacity commitment. Scale independent experiments and batch jobs across the fleet as capacity becomes available.

SFC’s upcoming deployments will expand that supply. The same market connects Autoresearch to capacity from the new clusters coming online, so your experiments can grow with the fleet.

Autoresearch schedules work through a queue that gives each customer an initial share of priority access. A team submitting a large batch shouldn’t prevent you from testing one idea.

The queue favors customers with less compute already in use. Your first node gets priority ahead of paid queue tiers. That keeps room for experimentation while larger campaigns make progress. You can inspect your position while you wait; priority doesn’t reserve capacity or remove the queue.

Queue priorityFive queues move from right to left toward dispatch. The top lane, for first experiments, advances faster than the four lanes below it. This illustrates scheduling priority, not GPU execution speed.

Autoresearch includes tools for measuring performance, so your agent can investigate why a change helped. Lock GPU clocks to reduce timing variation and enable NVIDIA Nsight Compute (ncu) counters when you create a profiling node:

autor node create --name profile --chip 8xh100 \
  --clock-lock --profiling --wait

Copy your Linux GPU benchmark from ./your_benchmark with execute permission, then collect its hardware counters:

autor cp ./your_benchmark profile:~/your_benchmark --executable
autor run profile -- ncu --set full ./your_benchmark

Inspect memory throughput and kernel duration to see where execution time goes. Profiling requires a whole eight-GPU machine because shared counters could expose another workload. Clock locking reduces variation, but power and thermal limits can still throttle the GPU. Read the profiling documentation for the supported configuration.

Stop the profiling node when you finish:

autor node stop profile

Metrics, logs, and traces are built into the platform. Infrastructure telemetry gives you a starting point; send your application’s measurements and spans to connect them to the run. Your agent can inspect:

  • Metrics to compare performance and resource use across experiments
  • Logs to read command output and diagnose failures
  • Traces to follow timing across operations
  • Samples to compare generated outputs as training progresses

Run a sweep to test several configurations, then compare their measurements and samples. Group related work into a mission so you and your agent can follow the campaign together. The experiment documentation covers sweeps and how to record samples.

Autoresearch’s sandboxes capture full disk and memory state, including running processes. That lets reinforcement learning (RL) experiments branch from a prepared environment instead of repeating setup for every attempt.

A rollout is one sequence of actions and observations in an environment. Fork a snapshot for each rollout, let the agent act, and score the result. Snapshot a useful intermediate state to explore several possible continuations from the same point.

Sandbox forksOne snapshot forks into three isolated rollouts. The middle rollout is selected and forks into three more continuations.

The sandbox system is built for this repeated fork, execute, and score loop, with published timings of 50 ms per fork and 150 ms per snapshot. Forks share their starting state while keeping each experiment’s changes isolated. The sandbox documentation describes snapshot and fork operations, including their limits.

Long research runs need checkpoints and health checks because a running process can still stop making useful progress. Save consistent training state, and define checks that detect stalled or invalid work.

For batch jobs, write state to $GMN_CHECKPOINT_DIR and declare a checkpoint through the job’s metadata service. Wait until checkpointed_at advances before treating the capture as committed. A resumed attempt receives the saved files; your code must load them and continue. Follow the checkpoint workflow to test restoration before a long run.

Autoresearch’s volume write-ahead log (WAL) continuously replicates changed disk blocks to object storage. It keeps a recoverable copy outside the machine running your experiment. Replication runs asynchronously, so the durable copy can lag behind live writes.

The worker captures and commits each batch through this sequence:

  1. Track which 2 MiB blocks have changed.
  2. Read each block once, then compute its fingerprint from those captured bytes.
  3. Reuse blocks already stored for that volume, and encrypt and upload the missing blocks.
  4. Commit the mapping between disk offsets and stored blocks after the upload completes.
  5. Advance the recoverable timestamp after the complete set of pending blocks has committed.

Reading each block once matters because your experiment can keep writing during capture. The worker hashes and encrypts the same captured bytes. A concurrent write cannot produce stored content that disagrees with its fingerprint.

The node’s durable_as_of field identifies the recoverable point. It records the capture time, not the later time when an upload finishes. A partial upload doesn’t advance it. If writes outpace uploads, the timestamp shows the gap instead of claiming that unsent data is safe.

WAL recoveryChanged disk blocks upload and commit to durable storage. The host fails. A replacement restores the committed blocks; later uncommitted writes are not preserved.

For a node with WAL recovery enabled, a host failure can park the node against this durable copy. On its next start, the platform reconstructs the volume from stored blocks, downloading in parallel and verifying each block after decryption. A planned stop also attempts a final capture to preserve the remaining writes.

The volume WAL preserves disk contents. Your training code still needs to save consistent model and optimizer checkpoints and load them after a restart. Disk recovery does not restore a GPU process’s live memory, and writes after the durable point may need to be repeated. Sandbox memory snapshots serve the separate rollout use case described above.

Health checks complete the loop by detecting work that needs attention. Configure them to record a failure, stop the run, or reschedule it. Together, durable records and committed checkpoints give recovery a known point to continue from.

Autoresearch includes native storage compatible with the Amazon Simple Storage Service (S3) interface. Keep datasets and results on the platform, or connect to storage where your data already lives.

Use the built-in integrations to bring code and models into an experiment:

  • S3-compatible storage for datasets, checkpoints, and outputs
  • Hugging Face for model weights and datasets
  • Civitai for image-generation models and adapters
  • GitHub for source repositories

Configure connections once, then let your agent refer to them by name. The platform handles the credentials for those transfers. The connection documentation explains how to scope access to each data source.

Autoresearch combines retention policies with single sign-on (SSO) and isolated workspaces. Choose what workload data the platform retains, and connect your organization’s identity provider for team access.

You can create a separate workspace for each agent, scaling that pattern to millions of isolated workspaces. Give each workspace its own access and spending boundaries so independent experiments don’t share a single unrestricted account.

As an organization admin, create a workspace and issue its agent a token that expires in 24 hours:

autor api post /org/workspaces/agent-001/tokens \
  -d '{"ttl_hours":24,"cap_usd":100}'

This creates agent-001 if it doesn’t exist and sets a $100 monthly spend cap on the new workspace. If the workspace already exists, its cap stays unchanged. The response returns a token scoped to that workspace.

Pass the returned token to the agent as the GMN_TOKEN environment variable. In the agent’s environment:

autor whoami
autor node create --name experiment --chip h100 --wait
autor run experiment -- nvidia-smi
autor node stop experiment

Repeat with a new workspace slug for each agent. Each token can access only its assigned workspace, so agents can reuse node names without sharing access to each other’s experiments.

Retention controls let you choose which optional captures to store and how long to keep them. Billing and audit records have separate retention requirements. Review the retention settings before starting work with sensitive data.

Start using SF Autoresearch to run your first experiment or connect your agent. For managed research agents that work for days, contact us for preview access.

Subscribe to updates

Point Mugu, CA