Chat
The chat panel is the single place you talk to Lume. What changes between a question and a task is not the panel but what the model does with your message: ask "why does this request return 500?" and it reads the code and answers, say "fix the 500 on this endpoint" and the agent takes its tools, edits files, runs commands, and comes back with diffs for you to accept or reject. Same box, same thread, different amount of authority.
About chat
Chat is a conversation with your project in scope, not a general-purpose assistant window that happens to sit next to your editor.
Use cases
- Understanding code you did not write. Ask what a module does, where a value comes from, or why two things are coupled. The agent reads the actual files rather than guessing from names.
- Working out an approach before committing to it. Describe the change you are considering and ask what it would touch. Nothing is edited until you ask for edits.
- Handing over a task. State the goal and let the agent plan, edit, run and verify. You review the result as diffs.
- Debugging. Paste an error, point at the file, and let the agent reproduce it in the terminal.
What the model can see
A turn is assembled from several sources, and knowing which is which is the difference between a good answer and a confident wrong one.
| Source | How it gets there |
|---|---|
Files you attach with # | Injected into your message verbatim, as if the agent had just read the file |
| Images you attach | Pasted with Ctrl+V or picked with the attach button; available only when the selected model can read images |
| Your codebase index | Searched by the agent when it needs to find code you did not point at |
| Files the agent opens itself | It reads what it needs while working, and you see each read in the conversation |
| Earlier turns in this thread | Carried forward, and compacted automatically when the thread grows past the model's context window |
Start a conversation
-
Open the chat panel.
-
Type your message. Describe the outcome you want, not the steps you imagine it will take.
-
Attach the files that matter with
#(see below). -
Send.
The agent's work appears in the thread as it happens — each file it reads, each command it wants to run, each edit it proposes.
-
Review the diffs. Accept the ones you want and reject the rest.
Note: Commands are governed by the auto-run mode you have configured, not by the conversation. By default the agent asks before running anything, and a red list of destructive commands always asks regardless of the mode.
Attach context
Three characters open pickers in the composer, and each one attaches something different.
| Token | What it attaches |
|---|---|
# | A file from your workspace. Its contents are put into the message directly, so the agent does not spend a turn reading it. |
@ | An agent. Picks which agent handles this message instead of the default one. |
/ | A command. Runs one of your saved commands rather than sending free text. |
You can also attach images: paste a screenshot with Ctrl+V anywhere in the composer, or use the attach button. The attach button and the paste are both gated on the selected model — if the current model cannot read images, Lume refuses the attachment rather than silently dropping it.
Note: A file attached with # is injected up to 2000 lines. Past that it is truncated, which is the same ceiling the agent's own file reads use — a mention can never put more into a turn than reading the file would have. For anything larger, point at the specific region instead of the whole file.
Switch models
The model selector sits under the composer and applies to the next message, so you can start a thread on a cheap model and move to a stronger one when the work gets harder. Each model's card shows what it is available for, what it costs, and its capabilities including the size of its context window. Models that support a larger window than their default expose a Max Mode toggle on that card.
You can also add your own provider and use your own key, in which case the requests leave your account balance out of it entirely.
Manage threads
Threads are scoped to the workspace they were created in: open a different project and you get that project's conversations, not a single global pile. The history view lists them so you can return to an earlier thread, and starting a new thread is the right move whenever the subject changes — a long thread that wanders costs more and answers worse, because everything before your question is still being carried.
Best practices
- Say what "done" looks like. A passing test, a page that renders, a build that completes — the agent can verify its own work when it knows what to verify against.
- Point at files with
#rather than describing them. It is faster, it is exact, and it saves the agent a search. - Start a new thread when the subject changes. Context carried forward is context you are paying for.
- Read the diffs. The agent is fast and it is not infallible; the review step is the point of the review step.
- Ask for a plan first on anything large. "How would you approach this, and what would it touch?" costs one cheap turn and prevents a wrong expensive one.
Example
You are looking at a failing test and you do not know the code well.
- Attach the test and the module it exercises:
#tests/test_invoices.pyand#billing/invoices.py. - Ask: "This test fails with a rounding mismatch on the VAT total. Find the cause and fix it so the test passes. Do not change the test."
- The agent reads both files, runs the test to see the failure itself, proposes an edit to the rounding in
invoices.py, then runs the test again to confirm it passes. - You review the diff, accept it, and commit it from the source control panel.
The constraint in step 2 — "do not change the test" — is doing real work. Without it, making the test pass by editing the test is a legitimate reading of the instruction.