Platform Tour

Checklist, Documentation, Code, Data Sources, Memories & Skills, Secrets, and Harumi AI Chat, section by section.

Checklist

The Checklist tab is the project's map: the goal, what is done, what is missing and the Next step, across the whole life of the project. The assistant keeps it up to date and each item has a button that does the thing. See The project checklist.

Documentation

The Documentation tab holds markdown documents for the project — design notes, business rules, or anything you want alongside the code. Documents are plain .md files committed to the same repository as your code.

Click New doc in the sidebar, give it a name (.md is appended if you leave it off), and start writing. Each document has three view modes:

Read-only rendered markdown, including fenced code blocks and math.

Saving a document commits it to the repository, the same as editing a file in the Code tab.

Code

The Code tab is a browser view of the project's git repository: a file tree on the left, and a viewer/editor on the right.

Clone URL — copy it from the top of the Code tab to git clone the project locally, or use the harumi CLI to bind a local directory to the project.
Download .zip — grab a snapshot of the current branch without cloning.
Branches — the New version button creates a new branch to work on changes without touching main. A run isn't locked to main, though: the toolbar's Run options dialog and harumi run --branch can execute any branch directly, and a scheduled run can target one too. Merging a branch back into main (via git) is only needed to make it the default a plain Run click uses. The same dialog lists your tags, named versions such as prod that you can run or schedule by name and manage from each branch's … menu.
New file and Upload files — New file creates an empty file at a path you type; Upload files, in the toolbar's … menu, adds one or more files under the current folder, alongside what's already there. Each lands as a single commit. To start a project from a whole .zip or folder, use the New project dialog instead — see Starting a project.
Editing a file — select a file, switch to Edit, make your change, and click Commit changes. Edits go straight to the branch you're viewing — there's no separate draft/publish state.

Datasets tracked in git vs. uploaded data

Upload files commits to the repository — good for code and small config files, but every collaborator's git pull re-downloads them, and diffs of binary formats (CSV, Parquet) are useless. For anything dataset-shaped, prefer the Data Sources tab's Files section instead: it's not versioned in git, and appears at inputs/ inside every run.

Data Sources

Reached from the project sidebar's Inputs button, this tab has three parts: connecting external databases, a read-only SQL editor, and non-git file uploads.

Data Sources connects a project to an external database so your code can query it directly, without embedding credentials in your repository. Supported types: PostgreSQL, MySQL, SQL Server, and Oracle.

To add one, click Connect new data source and fill in the connection details (host, port, database, username, password). If the database isn't reachable directly, enable Connect through a proxy to route the connection through Harumi's VPN proxy, providing the proxy host/port and mTLS certificates. Click Test connection before saving — Harumi verifies connectivity before persisting the data source.

Once connected, query it two ways:

From your code — the data source is available to your run via its name.
From the SQL Editor in the Data Sources tab — a read-only editor (SELECT/WITH only) for quick exploration.

Files

Files uploaded here aren't tracked in Code (git) — they're stored separately, per project, and appear at inputs/ inside every run's working directory, so main.py can read one with a plain relative path like inputs/model.pkl. Upload by clicking Upload file or by dragging a file onto the section; each file can be downloaded or deleted individually.

A project can hold at most 500 files or 500 MB total. A run refuses to start once uploaded files are over that cap — the UI shows how much of it a project has used, so you can remove files before it becomes a problem.

Memories & Skills

The Memories & Skills shortcut in the project sidebar opens a tab with two kinds of context Harumi AI Chat can draw on for the project — visible and editable by every project member.

Memories

A memory is a short fact or preference the assistant should keep in mind for this project (for example, "Always report revenue in USD"). Type one into the box and click Add.

Each memory has a Retrieval mode:

On demand — only surfaced when the assistant searches memories.
Always — injected into every chat message for this project.

Any memory can be edited or removed from its row afterward.

Skills

A skill is a reusable instruction the assistant loads on demand, stored as a skills/<name>/SKILL.md file in the project's repository. This tab only lists them — click one to open its SKILL.md in the Code tab, where it's actually edited.

New skill creates a folder and starter SKILL.md in the repository under a name you choose, then opens it in the Code tab for editing.

Secrets

Settings → Secrets stores environment variables for your project's code — API keys, credentials, or any other config value you don't want committed to the repository in plain text. Values are encrypted at rest and are never shown again after saving; you can only replace or delete them, not view them.

Click Add secret, provide a name and value, and it becomes available as an environment variable the next time your project runs.

Harumi AI Chat

Chat opens Harumi AI Chat, available as a drawer from any tab or as its own full page. It has two modes:

Agent — full agentic mode. Routes optimization requests to a dedicated solver that builds a model and runs code, and can also answer general questions.
Ask — conversational mode. Searches your project's files and can run code to answer questions, but does not route to the optimization solver.

In either mode, the chat can read and write files in your project's repository and execute code, shown inline as step cards (code execution output, file reads/writes) as it works.

Dashboard

Dashboard is the default tab and shows:

Latest run — widgets declared in the project's dashboard files, rendered from the latest live-branch run's output/output.json.
Recent runs — a list of past runs; click one to open its output.
View latest output — a live terminal showing stdout/stderr while a run is in progress, and the full log once it finishes.
Execution history — every run for the project, with status and timestamps.
Schedule — configure a cron schedule to run the project automatically, including which branch or tag it runs.

Multiple dashboards and versions

Each dashboard/<name>.toml in the repository is its own dashboard (a root dashboard.toml from older projects still works too). Once a project has two or more, a dashboard picker appears above the widgets; each option is named by the file's top-level title, or by its filename. Files in a subfolder of dashboard/ are ignored, so you can keep drafts there.

By default the Dashboard shows the latest run on the live branch (main). The run picker next to it lists every run with its status, branch, and source, grouped by branch. Picking a run from another branch renders it with that branch's dashboard files, so a layout change can be tried on a version before it's merged. Execution history has a Show on dashboard button that does the same for a specific run. Share links only ever show live-branch runs.

Beyond [[widgets]], a dashboard file can declare reusable datasets, define new KPIs as SQL, and add clock-driven playback — see Dashboard datasets, metrics, and the clock.

Before your first run

A project's Dashboard shows real values only once it has a successful run, and shows one of a few states depending on what's happened so far:

No runs yet — nothing has run on this project. Click Run to see something here. Meanwhile every dashboard in the list still opens, drawn with sample data (see Previewing a dashboard before it runs).
Run in progress — the dashboard appears once this run finishes.
This run didn't finish successfully — fix the issue and run again; View output opens the raw log from the failed run.
This run has no dashboard output — the run succeeded, but main.py never wrote output/output.json, so there's nothing for the dashboard's widgets to bind to.

Previewing a dashboard before it runs

A dashboard doesn't have to have run to be looked at. When an agent (or you) adds or changes a dashboard/<name>.toml, open it from the dashboards list and it draws with sample data: made-up values generated from the keys the widgets bind to, so a timeline shows a plausible schedule, a map shows a few stops and a donut shows slices. A banner above the widgets says so.

With no runs at all, a dashboard opens like this on its own.
With a run, switch the Sample data button in the bar under the top of the page on to preview a layout the last run's output doesn't have the keys for yet; pick a run from the run picker to go back to its real values.
Sample data is only for judging layout. Copy and download are hidden on its widgets, and share links never show it.

If a project isn't ready to run

A warning banner above the dashboard means the project is missing something runs and schedules need — most commonly on a project that predates its git repository being provisioned. It lists exactly what's blocking, for example:

Git repository — this project has no repository yet, so there's no code to run. A Set up repository button fixes this in one click.
harumi.toml — add one with a [run] command, from the Code tab or the CLI.
Valid harumi.toml — the file exists but couldn't be read.
Kernel — the kernel named in harumi.toml doesn't exist.

The banner disappears once every check passes.

Run options dialog

Clicking the caret next to Run opens the Run options dialog for a one-off override of a single run, without touching harumi.toml:

Environment — pick a different compute kernel for this run only.
Branch or tag — run a branch other than the project's default, picked from the repo's actual branches, or a tag such as prod.
Command — override the command harumi.toml's [run] section would otherwise run.

Leaving a field untouched uses the project's default for it. These map directly to the CLI's harumi run --kernel, --branch (or --tag), and --command flags (see CLI commands) — anything you can set here, you can also set from a terminal or a CI job.

On this page