GenesiGenesiWiki
Features

AI Assist

Find a file by describing it, and have failed commands explained — using the model already running on your machine.

AI Assist is the small, always-there half of local AI in Genesi: the helpers that answer without being opened. Describe a file instead of remembering its name, and get a one-line explanation when a command fails.

They share one rule that shapes everything else about them: they never load a model. They ride whatever is already warm on the Genesi Turbo daemon. Nothing warm means nothing happens, silently — a helper that spins up the GPU to be useful stops being a helper and becomes the reason the machine feels slow.


Find a file by describing it

genesi-find "the contract PDF I saved last month"
genesi-find "aquela foto do churrasco que eu baixei ontem"

You describe the file the way you would to a person. Words from the name help most, but the type ("planilha", "spreadsheet", "foto") and the time ("ontem", "last month", "3 dias") all count.

From the file manager

Right-click any folder in Dolphin and choose Search with AI here — the search is scoped to that folder. There is also a Genesi Find entry in the application menu, and genesi-find-ui from a terminal.

Double-click a result to open it, or use Show in folder to reveal it where it lives.

Options

FlagWhat it does
-p, --pathSearch here instead of your home directory (repeatable)
-n, --limitHow many results to show (default 12)
--hiddenInclude dotfiles and dot-directories
--no-aiUse only the built-in parser, even if a model is warm
--whyShow the filter that was actually run
--jsonMachine-readable output (this is what the window uses)

--why is worth knowing about. It prints the filter the search really used, so when a result surprises you the reason is one flag away:

$ genesi-find --why "aquele pdf do contrato que eu baixei"
  filter: words=contrato exts=pdf days=any dir=download in /home/you  (built-in parser)
  contrato-aluguel-assinado.pdf   ~/Downloads   2d ago · 1.2 MB

How it finds things

The model never touches your disk. It does exactly one job: turn your sentence into a filter — words, extensions, a date range, maybe a standard folder. That filter is then validated (an extension has to look like an extension, a folder has to be one from a fixed list) and executed locally by a plain directory walk.

The model receives your description and nothing else — never a listing of your disk, never the contents of a file, never the results. A model that hallucinated a path would produce a filter with a bad folder name, and the filter would be dropped, because nothing it returns is ever treated as a path.

Heavy directories are skipped (node_modules, .cache, .git, target, Steam, Trash…), and the walk stops at a hard ceiling so one forgotten 200,000-file directory can never turn a search into a hang.

With no model warm

It still searches. The built-in parser understands the same shapes in English and Portuguese — "last month", "mês passado", "photo", "foto", "planilha", "spreadsheet" — and searching by those alone is most of what people want.

The one thing it cannot do is translate: asking in English for a file named in Portuguese needs the model. --why tells you which parser ran.


Explanations when a command fails

When a command exits non-zero, two dim lines appear underneath it:

$ pacman -S ttf-rubik
error: target not found: ttf-rubik
  that package is in the AUR, not the official repositories
  paru -S ttf-rubik   → to use

The second line is the fix, and it is offered as ghost text at the next prompt. Press (or Ctrl+F) and it lands on your command line, ready to edit. It is never executed for you: → types it, you press Enter.

Fixes that delete or overwrite — rm, dd, mkfs, git reset --hard, curl | sh — are printed but never armed on a keypress. A command that can destroy your work should cost more than brushing an arrow key.

What it sees

The command line you typed and its exit code. Not the output, and never the contents of a file. That is a deliberate limit: capturing output would mean either wrapping every command in a pty or re-running it, and re-running is how a helper deletes something twice.

When the output is what matters, pipe it in yourself:

some-command 2>&1 | genesi-explain

Answers are cached under ~/.cache/genesi-ai-assist, so the same typo is never paid for twice.

Per shell

Genesi's default shell is fish, and all three work:

ShellGhost textAccepting the fix
fishYes — as you type the first letter
zshYes — inline on an empty prompt
bashNo (readline cannot draw it), with a printed → to use marker

fish has no API for setting an autosuggestion, so the fix is seeded into fish's own history and fish draws the ghost itself. The trade-off is one history entry for a command that was never run; suggest_fix_history = off declines it, and still works.


Settings

Everything lives in /etc/genesi-ai-assist.conf, overridden per user by ~/.config/genesi-ai-assist.conf. It is read live — no restart.

enabled = on              # master switch for every passive helper
explain_errors = on       # the two lines under a failed command
suggest_fix = on          # offer the fix as ghost text
suggest_fix_history = on  # fish only: seed the fix into fish's history
smart_find = on           # plain-language file search
on_battery = off          # run passive helpers while on battery?
timeout = 4               # seconds to wait for the model
cache_days = 30

on_battery is off by default because a background inference you did not ask for is the rudest possible use of a laptop's remaining charge. It applies to helpers that fire on their owngenesi-find, which you invoke by hand, is not gated on it.

Passive helpers also stand down while a real inference is running and while Studio Mode has the machine, so they never compete with the work you actually asked for.


Privacy

None of this leaves your machine. The model is local, the search is local, and there is no endpoint any of it could report to. See the Privacy Policy for exactly what each feature reads and when.