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
| Flag | What it does |
|---|---|
-p, --path | Search here instead of your home directory (repeatable) |
-n, --limit | How many results to show (default 12) |
--hidden | Include dotfiles and dot-directories |
--no-ai | Use only the built-in parser, even if a model is warm |
--why | Show the filter that was actually run |
--json | Machine-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 MBHow 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 useThe 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-explainAnswers 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:
| Shell | Ghost text | Accepting the fix |
|---|---|---|
| fish | Yes — as you type the first letter | → |
| zsh | Yes — inline on an empty prompt | → |
| bash | No (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 = 30on_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 own — genesi-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.