A working session

The screen

The transcript — your messages, the model’s replies, and every tool call it makes, as they happen. A reasoning model’s thinking shows as a dimmed thinking: line; it’s display-only and never saved.
The task panel — the model’s own plan for multi-step work, kept up to date as it goes.
The status line — what’s happening (ready, streaming…), a PLAN badge in plan mode, the context budget (ctx 6.1k/8.2k (74%), turning amber then red as it fills), and — with routing on — the model this conversation is using.
The input box — type and press Enter. While you type a / command, matching commands are suggested.

Before your first message it shows a few example requests and the test command it found for this project.

Keys

Key	What it does
Enter	Send
Tab	Complete a `/command` (Enter on a part that fits one command completes it too; a second Enter runs it)
Alt+Enter	New line in the message (Shift+Enter too, where the terminal tells them apart)
Ctrl+C	Stop the reply in progress; when idle, quit
Ctrl+P	Plan mode on or off (Plan mode)
Ctrl+T	Show the model’s reasoning in full, or fold it again (by default each block of reasoning is one line: how it starts and how many lines follow)
PgUp / PgDn	Scroll the conversation a page; ↑ / ↓ (and, in most terminals, the mouse wheel) scroll it a few lines while the message is one line long
Esc	Back to the newest output after scrolling up
`y` / `n`	In an approval prompt: allow once / deny (Enter and Esc also deny)
`a` / `A`	In an approval prompt: show all of the text / always allow (`A` is Shift+a)
`d`	In an approval prompt: deny and say why — type a short note, Enter sends it to the model with the denial

When you quit (Ctrl+C when idle, or /quit), aivyx-coder prints how to continue the conversation (aivyx-coder --resume) and the files its own file tools changed; commands it ran may have changed others, so git status is the full picture.

A message you send while a reply is still running waits under it as queued > … and goes out when the reply ends, in order. Esc (with an empty box) takes the last one back to edit; Ctrl+C, which stops the reply, also puts queued messages back in the box instead of sending them.

A paste goes into the message box as it is, line breaks included; it is not sent until you press Enter.

While you are scrolled up, the title says how many lines are below and new output doesn’t move what you are reading; sending a message takes you back to the end. Selecting and copying text with the mouse works as usual. /help lists every command. A message that starts with a slash but isn’t a command (/frobnicate) stays in the box with a note instead of going to the model; a path such as /etc/hosts is wrong is sent as usual.

Approving what it does

Reading and searching happen without asking. Anything that changes something — writing, editing, moving or deleting a file, running a command, committing — stops with an approval prompt showing exactly what will happen: a diff for a file change, the full command for a command. A prompt that opens while you are typing doesn’t take those keys as an answer: it waits until you have stopped typing for a moment, and what you typed stays in the message box.

y allows it once.
a shows the whole command or diff when it is longer than the box. It never grants anything.
A (Shift+a) allows it and remembers that exact target for the rest of the session — that file, or that exact command with those arguments. It never blesses a different file or different arguments.
n refuses (so do Esc and Enter); the model is told and can try another way.
d refuses and lets you say why in a line (“use the test database”, “don’t touch the lockfile”); the model gets your note with the refusal instead of having to guess.

A few things never get always allow: edits to files that run code later (your shell start-up files, autostart entries, systemd user units) show an extra warning and must be approved each time, as must changes to your personal AGENTS.md.

Some things are refused outright, with no prompt: your secrets (SSH keys, cloud credentials, .env and key files — the full list is in the security model), and anything inside a .git folder or your global git config.

Commands you trust

The model can run two kinds of command. run_shell runs anything and always asks. run_command runs only commands you’ve named in your config — and those run without asking:

[[permissions.allowed_commands]]
name = "test"
program = "cargo"
args = ["test"]

The model asks for test by name; it can’t change the program or add arguments.

What the model knows about your project

A repository map. Each turn it gets a compact map of the project’s most important files and symbols (Rust, Python, JavaScript and TypeScript), so it knows where to look. [repo_map] sets its size.
AGENTS.md. Instructions in AGENTS.md at the project root, and in your personal one, are included in every turn — see Memory and learning.
Your editor, if you connect one — see Editor integration.

It reads files itself when it needs them.

Long conversations

When the conversation nears the model’s context window ([backend] context_tokens), aivyx-coder makes room: long tool results are trimmed to their start and end first, then the oldest turns are dropped — always with a notice. Set context_tokens to the window your server actually serves; see Local model servers.

Edit formats

How the model writes edits can matter on small models:

native (default) — edits arrive as tool calls.
prompted — the model writes SEARCH/REPLACE blocks as plain text, which some small models get right more often than JSON-escaped code.

Both go through the same approval, diff, deny list and checkpoints. Set [backend] edit_format, or try one for a session with aivyx-coder --edit-format prompted.

When a turn goes wrong

If one reply makes several changes and a later one fails, the earlier changes from that same reply are rolled back automatically, and the model is told. To take back a whole turn yourself, use /undo — see Undo, diff, commit and test.