Troubleshooting

Troubleshooting research software is partly about restoring the system and partly about protecting the meaning of the result. A retry may fix a transient job failure; it should not hide that the wrong dataset or checkpoint was used.

Start by locating where the work last made meaningful progress. Read the latest Timeline entry, then open Compute, Code, or the report source that can answer the next concrete question.

A useful diagnostic sequence

Before changing anything, capture four facts:

1. Expected state: What did you expect Silico to be doing or showing?
2. Last good state: Which Timeline entry, job, or report was definitely correct?
3. Current state: Is the work waiting for you, queued for compute, actively running, failed, or complete with an unexpected result?
4. Identity: Which thread (th_…), experiment (exp_…), model checkpoint, dataset, and split are involved?

These facts make most problems much easier to classify. They also keep a debugging attempt from accidentally changing the experiment you meant to inspect.

You cannot sign in or your Lab is missing

1. Confirm that you used the GitHub account that received the invitation.
2. If you are joining an organization, sign in to its Silico deployment once and ask an Admin or Owner to add you under Organization settings → Members.
3. In the desktop app, open Connections, choose Add connection, and select the Lab available to your account.
4. Ask an organization Admin or Owner to confirm your membership if the Lab is still missing.

An experiment will not launch

1. Answer unresolved questions in the thread or plan.
2. Verify the model, checkpoint, data, split, required credentials, compute, and stopping conditions.
3. Open Organization settings → Compute and confirm that at least one option is ready.
4. Open Organization settings → Billing and check the remaining RU balance.
5. Confirm private GitHub, Hugging Face, W&B, or environment-variable access at the correct personal or organization scope.

If an input is unavailable, update the plan rather than quietly substituting another one. A successful launch with the wrong input is harder to detect—and usually more expensive—than a launch that stops clearly.

An experiment appears stuck or blocked

1. Open the experiment from the thread Timeline.
2. Read the latest Timeline entry and answer any decision that needs you.
3. Use Compute to see whether jobs are queued, running, completed, canceled, or failed.
4. Tell the thread's planner what should change. Use Worker only when active execution needs a direct correction.
5. Retry a transient resource failure. Stop and revise the plan when the data, metric, model, or method is wrong.

Valid baselines and partial work may still be useful, even when the full experiment needs to change. Preserve them and record why the remaining work stopped.

A report is missing, incomplete, or surprising

Reports does not appear until the experiment produces one. Metrics and Compute also appear only when relevant.

When a report looks incomplete, stale, or more confident than the evidence:

1. Read the latest Timeline entries and critic review.
2. Check Compute for unfinished or failed jobs.
3. Open Code or a report source link to inspect the implementation and data behind the claim.
4. Compare the report with the Plan, especially the checkpoint, data split, metric, controls, and sample size.
5. Ask for a targeted correction or launch a focused follow-up experiment when new evidence is required.

An attachment or private integration is unavailable

• Connect personal GitHub, W&B, or Hugging Face access under Personal settings → Integrations.
• Use the organization integration only when a shared service account is intended.
• Put other runtime keys under Environment variables at the correct scope.
• Confirm that a connected cluster or filesystem is reachable when a file location is missing.
• Check Sandbox if an external host is blocked by organization network policy.

If access is still failing, share the error and resource name—not the token itself. Never paste a token into a thread, plan, report, repository, or support message.

A shared link does not open

Confirm the full link and its access mode. Organization reports and threads require the reader to sign in to the right organization. Public reports may have been taken down or may still show an older saved version.

A shared thread is read-only. Continuing creates your own thread but does not grant private context or compute.

Usage or compute does not match your expectation

• Organization settings → Billing shows charged usage in RUs.
• An experiment's Compute view shows jobs, accelerators, and runtime.

These totals answer different questions, so they will not necessarily match. For unexpected cost, check sample size, parallelism, accelerator, retries, and stopping conditions. Compare the plan with what Compute says actually ran.

Storage is full

Open Personal settings → Storage and expand from organization to folder, thread, and experiment. Before deletion, confirm the owning research and any report or follow-up that still depends on the files. Cleanup is permanent.

Contact support

For the quickest handoff, choose Report an issue from the in-app help menu. Silico includes diagnostic context such as the current route, app and Lab versions, organization, canonical thread and experiment IDs, and available error or session telemetry. Add a short description of what you expected, what happened, and whether the problem is still reproducible.

The diagnostic context does not replace the report you write, and you should not include credentials or private data in the description. If Report an issue is unavailable on your deployment, email support@goodfire.ai with:

• the organization and Lab
• the canonical thread ID (th_…) and experiment ID (exp_…), when relevant
• the approximate time and timezone
• the latest Timeline state and relevant job status
• exact error text and a screenshot
• what you already tried

Do not include passwords, tokens, environment-variable values, private data, or other secrets.