Hugging Face AI Sheets: build and enrich datasets with open models, no code

What AI Sheets is for, and who it is aimed at

The problem AI Sheets addresses is the gap between a CSV of rows and a model call per row. Doing that by hand means writing a loop, handling retries, keeping a token out of the source, and re-running only the failed rows. AI Sheets puts that loop behind a spreadsheet interface: you load or create a table, and a column becomes a prompt that is applied across the rows. The README describes the tool as being for building, enriching and transforming datasets using AI models with no code, deployable locally or on the Hub.

The audience is fairly specific. It suits a data curator who has a list of records and wants a model to label, rewrite or expand them, and who would rather configure a column than maintain a script. It also suits someone doing LLM evaluation work, which is one of the repository topics, because the same grid can hold prompts and the model outputs side by side. It does not suit anyone who needs a stable, versioned API to call from their own service. This is an application with a browser UI and an Express server, not a library you import.

How a column becomes a model call

The architecture visible in the repository is a Qwik and Qwik City front end built with Vite, plus an Express server adapter under `adapters/express`. The production Dockerfile builds with `pnpm build`, copies `server`, `dist` and `node_modules` into a second stage, and starts the app with `node server/entry.express` on port 3000. The Docker build also installs `sqlite3` and `libsqlite3-dev`, which points to local persistence for the sheets themselves rather than a separate database service.

Inference is routed by environment. By default the app calls the Hugging Face Inference Providers API. If `MODEL_ENDPOINT_URL` is set, inference calls go to that base URL instead, and `MODEL_ENDPOINT_NAME` supplies the model identifier required by the OpenAI API specification. The README is explicit that this only redirects inference: models from the Inference Providers API remain selectable in the column settings. The one exception the README calls out is text-to-image generation, which cannot be customized and always uses the Hugging Face Inference Providers API.

Installing AI Sheets with Docker or pnpm

The fastest path is the hosted Space at `https://huggingface.co/spaces/aisheets/sheets`, which the README offers as the instant option. For a local install, Docker is the shortest route. The README instructs you to get a token from `https://huggingface.co/settings/tokens` and export it, then run the published image. Note that the README's own snippet passes `-e HF_TOKEN=HF_TOKEN` literally, which forwards the shell variable of that name rather than the token value; if your shell variable is named differently, pass the value explicitly.

export HF_TOKEN=your_token_here
docker run -p 3000:3000 \
-e HF_TOKEN=HF_TOKEN \
aisheets/sheets

After that, `http://localhost:3000` serves the app. The container exposes port 3000 and runs the Express entrypoint, so nothing else is needed to reach the UI.

The pnpm route is for working on the source. It clones the repository into a directory named `sheets`, installs with a frozen lockfile, and starts the Vite dev server, which listens on a different port than the Docker image.

git clone https://github.com/huggingface/aisheets.git
cd sheets
export HF_TOKEN=your_token_here
pnpm install --frozen-lockfile
pnpm dev

The README says the dev server is at `http://localhost:5173`. For a production build, `pnpm build` writes to `dist` and `pnpm serve` launches the Express server, which is the same entrypoint the Docker image uses. The `postinstall` script runs `npx playwright install` unless `SKIP_POSTINSTALL` is set, which is why the Dockerfile sets `SKIP_POSTINSTALL=1` during the build stage and installs only Chromium in the production stage.

Pointing AI Sheets at Ollama or another OpenAI-compatible server

Running against your own model server takes two environment variables. The README's Ollama walkthrough starts the server, pulls a model, exports the endpoint and model name, then runs the app. The endpoint URL is the server root, not a path to a completions route.

export OLLAMA_NOHISTORY=1
ollama serve
ollama run llama3
export MODEL_ENDPOINT_URL=http://localhost:11434
export MODEL_ENDPOINT_NAME=llama3
pnpm serve

The requirement is that the endpoint supports the OpenAI API specification, because the model name is a required parameter there. This is the main constraint on the custom path: a server that speaks a different protocol will not work, regardless of how capable the model is. The README also notes that the text-to-image feature ignores this configuration entirely and keeps using the Hugging Face Inference Providers API, so a fully air-gapped setup is not what this configuration produces.

Generating larger datasets outside the browser with HF Jobs

The grid is not the only way to run the pipeline. The repository ships scripts under `scripts/extend_dataset`, and the README shows running them as Hugging Face Jobs with `uv`. One script uses the inference client; the other uses vLLM and requires a GPU flavor, which the README frames as a way to save on inference costs.

hf jobs uv run \
-s HF_TOKEN=$HF_TOKEN \
https://github.com/huggingface/aisheets/raw/refs/heads/main/scripts/extend_dataset/with_inference_client.py \
nvidia/Nemotron-Personas dvilasuero/nemotron-kimi-qa-distilled \
--config https://huggingface.co/datasets/dvilasuero/nemotron-personas-kimi-questions/raw/main/config.yml \
--num-rows 100

The script takes a source dataset, an output dataset, a config URL holding the prompts, and an optional row limit. The vLLM variant adds `--flavor l4x1` and a `--vllm-model` argument. This is the part of the project with the least documentation: the README presents the commands but does not describe the config file schema, so you are reading the referenced config to learn the format.

Where AI Sheets is the wrong tool

The clearest limitation is documented rather than implied: text-to-image generation cannot be pointed at a custom endpoint. If your workflow needs images generated by a model you host, this configuration will not do it, and the README tells you to take that into account before running with custom LLMs.

A second constraint is the authentication model. `HF_TOKEN` is used for authenticated inference calls, and `OAUTH_CLIENT_ID` switches the app to Hugging Face OAuth with default scopes of `openid profile inference-api manage-repos`. That default scope set includes repository management, which is broader than inference alone. Anyone deploying this for other people should read the OAuth setup guide the README links rather than accept the default without thinking about it.

The third is lifecycle. The README does not document rollback, migration or a schema version for stored sheets, and there are no releases retrieved for the repository. The last push was on 2026-05-26, so the code is a few months old rather than dormant, but there is no release cadence to plan upgrades against. If you need a pinned, versioned artifact with a changelog, this project does not currently give you one.

How it compares to scripting the same pipeline

The obvious alternative is writing the pipeline yourself against the Hugging Face Inference Providers API or a local server. The difference is not capability but where the state lives. In a script, the dataset, the prompt and the model choice live in files you version; in AI Sheets they live in a SQLite-backed sheet you edit in a browser. That makes iteration faster and review harder, because a prompt change is a UI action rather than a diff.

The second alternative is a hosted spreadsheet AI add-on. Those typically bind you to one vendor's models. AI Sheets keeps the model choice open, which is the point of the `MODEL_ENDPOINT_URL` and `MODEL_ENDPOINT_NAME` pair, and it can run entirely on your own machine. The trade is operational: you now run a Node server, a SQLite file and a Playwright Chromium install, which the production Dockerfile shows is not a trivial dependency footprint. A script has none of that. If your dataset is generated once a quarter and checked into git, a script is probably the better fit; if you are iterating on prompts across dozens of columns, the grid earns its keep.

Editorial conclusion

Adopt AI Sheets if you want to turn a spreadsheet into a prompt-driven dataset pipeline and you are comfortable holding a Hugging Face token, because the app assumes one for inference and for OAuth. Skip it if your work depends on text-to-image generation through your own model server, since the README states that feature always goes through the Hugging Face Inference Providers API, or if you need a documented rollback story, which the README does not cover. Before committing, verify that `pnpm install --frozen-lockfile` completes on your Node version, that the Node engine range in package.json matches your runtime, and that your custom endpoint answers the OpenAI specification, since `MODEL_ENDPOINT_URL` and `MODEL_ENDPOINT_NAME` are the only knobs the README documents for that path.

Frequently asked questions

Official sources

1. huggingface/aisheets on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README