Hugging Face Spaces: Run a Demo and Keep the Setup

Hugging Face Spaces are hosted apps and demos whose code lives in Git repositories, folders with a history of saved changes. To make a useful experiment, try the app, inspect its repository, and save the exact setup alongside the result. The Spaces overview↗ (opens in a new tab) explains that a new commit rebuilds and restarts the Space. fenbs can keep your findings and next step outside the demo, so another AI session can continue the work.

How do you start with a Space?

1. Open the Space you want to investigate and read the instructions supplied with that app before entering an example.
2. Choose a small, non-sensitive input whose useful result you can describe in advance. Keep a copy of that input.
3. Run the app and save the output you actually received, including any visible error or incomplete result.
4. Inspect the repository files and record the Space address, the saved code version you inspected, and any setup information supplied by its author.
5. If you want your own version, follow the current Spaces overview for adapting the source. Check your access and the requirements before starting compute.

These steps establish what happened before you change anything. For example, a designer testing a public image demo could use an invented product description and judge whether the output follows its requested layout. The point is to keep one inspectable example, rather than collecting attractive outputs with no record of their inputs.

A hosted Space is a different starting point from running a model on your own computer. If your requirement is local execution, use the separate guide to hosting AI locally. Do not assume that success in a hosted app proves your laptop can run its underlying model.

Which files explain the experiment?

The repository is where you look for evidence about how the app was assembled. Read the supplied explanation and inspect the files it points to. Record which model, data, settings, and dependencies you can establish from those files; mark anything you cannot establish as unknown. A familiar app title is not enough to identify the exact experiment.

Keep source information separate from what you observed. An author may describe an intended behavior that your test does not reproduce. Write both down: what the instructions say should happen, and what happened with your saved input. That distinction makes a later failure easier to investigate without accusing either the code or your memory of being wrong.

• Source: the original Space address and the repository version you inspected.
• Setup: the files and documented requirements relevant to your run, with sensitive values removed.
• Input: the exact example, including any choices you made in the app.
• Output: the result, its date, and any error that prevented completion.
• Judgment: what passed, what failed, and what still needs a person to check.

If the demo relies on data you need to identify separately, continue with recording a Hugging Face dataset. A link to a demo should not become a substitute for knowing which data supported your conclusion.

Where can you keep notes inside the repository?

Hugging Face documents Files > Add file↗ (opens in a new tab) for creating or uploading a file and saving it with a change message. With the appropriate write access, you can use a Markdown file for experiment notes. This is a way to use repository storage; it is not a separate automatic memory feature.

Give the note a clear purpose. State the question, the starting version, the input, the result, and the next check. A short record that tells someone how to repeat one experiment is more useful than a long diary mixing setup attempts, unrelated prompts, and conclusions that were later rejected.

Remember that saving a new commit rebuilds and restarts a Space. Plan repository edits around any experiment already running. Do not keep the only copy of your evidence on the default runtime disk: the Spaces overview describes that disk as non-persistent.

Who can see the app and your notes?

Space visibility applies to the work you keep there. Public Spaces expose their source. Protected Spaces hide the source while leaving the running app accessible. Private Spaces restrict both. Review the visibility explanation in the overview before deciding whether a repository file is an appropriate home for your notes.

The community tab↗ (opens in a new tab) holds discussions and pull requests. Use it for an appropriate contribution or reproducible report, not as a private notebook. Hugging Face also warns that hiding a discussion comment is irreversible, so review what you are about to publish before posting it.

Write useful evidence without credentials, personal information, or confidential input. For shared work, save a safe summary and a pointer to the approved source. Keeping the result in the fenbs work record lets your next assistant find the conclusion without treating a public discussion as your private history.

How do you tell whether the demo worked?

Decide the pass condition before your second run. For a text demo, that could mean covering three requested points without adding an unsupported claim. For a transformation demo, compare the output with the unchanged input and check the property you wanted to preserve. Use checks that match your task rather than a general impression of quality.

Change one meaningful condition at a time. If you change the input, code, and model together, an improved result will not tell you which change helped. Keep a rejected attempt when it explains a real limit, including the reason you rejected it. Our AI model evaluation guide covers designing these checks; the model comparison guide covers choosing between candidates.

If you need an API call rather than an interactive app, read about Hugging Face Inference Providers. Trying a Space and configuring a hosted-model request answer different questions, even when your research involves the same model name.

How to keep your Space findings with fenbs

1. Create a free account.
2. Save the Space link, the input you tried, and the safe setup details you will need again.
3. Write what worked, what failed, and which result you trust. Keep guesses clearly marked.
4. Before you stop, write the next small check. Pick up from that point on any device or with another connected AI.

fenbs does not run or host the Space, and it does not automatically import its files or output. It fits when you want to preserve the work around the experiment. A repository file may be enough for notes that belong with the code; fenbs helps when the same findings need to travel between people and AI apps.

Keep exploring models through the AI models topic hub, but give each experiment a clear stopping point. A saved result and a specific next step are easier to reuse than another open tab.