It’s impossible to see the full name of a read file if it’s too long.
When connecting a device in the Splox App, a “Failed” error pops up for a split second. Then it redirects to the browser, and once the connection is established there, the app successfully connects.
When updating the Splox App, it doesn’t remember its previous installation directory. You have to specify the path manually every time.
Regarding the Coder flow:
4. I didn’t quite catch how file reading works. It seems to read the entire file at once. Does it search for information in chunks, or does it fetch the whole file?
5. For a single fix and reading 6-7 files, the context filled up with ~30,000 tokens. Is this normal?
1. File names being cut off That’s a UI issue — we’ll add truncation with a tooltip so the full path shows on hover. Noted.
2. “Failed” flash when connecting a device That’s expected behavior, not a bug. When you initiate a device connection, the app optimistically shows a connecting state, then hands off to the browser for the auth/approval flow. The “Failed” flash is the app seeing the handoff before the browser completes it — once the browser confirms, the app picks it up. We can smooth out that UX so it doesn’t flash an error state.
3. App not remembering install directory on update Known limitation of the current updater — it doesn’t persist the custom install path between versions. This is on the roadmap to fix properly.
4. How file reading works The agent reads up to 8 KB at a time by default, not the entire file. It reads line-by-line and stops early once it hits the size or line limit. If a file is larger, it uses start_line to paginate through it in subsequent reads. You’ll see a limit_hit field in the response telling the agent there’s more. So large files are read in chunks — the agent just needs to make multiple calls to read all of it.
5. 30k tokens for 6–7 files Yes, that’s in the normal range. Each file read returns the content inline into the context, so 6–7 files × a few KB each, plus the conversation and tool call history, adds up fast.
If a file is larger, it uses start_line to paginate through it in subsequent reads. You’ll see a limit_hit field in the response telling the agent there’s more. So large files are read in chunks — the agent just needs to make multiple calls to read all of it.
At this point, I have a little question. That is, in general, most often he tries to subtract the entire file (in one way or another) entirely, after which he starts working? Is he not trying to find just the right parts without fetching the whole file?
That behavior is driven by your agent’s workflow — specifically how you’ve set up the instructions and tool-calling logic. The agent follows whatever strategy is defined in its system prompt. If you want it to grep first and only read targeted sections, you can instruct it to do that explicitly. Something like:
“Before reading any file, always grep for the relevant function or keyword first. Only read the specific line range, never the full file unless necessary.”
The tools support it (start_line, num_lines, grep) — it’s just a matter of how the agent is instructed to use them.
Understood. And I also forgot to mention: the interface does not show which file has been edited. There’s just an “edit file”, but it doesn’t show which file, which changes.
Good news — we just fixed the file name truncation issue. Now when a file path is too long and gets cut off in the tool pill, you can hover over it to see the full path. The fix applies to all tool types: Edit File, Read File, Write File, and others.
In the Edit file itself, when the path is long, it is still not possible to see which file. However, a block appears in which there is a file name (still no full path) and several lines from the location that was updated, but it does not specify which lines were specifically updated.
Comment “Successfully applied edit to C:/Users/REDACTED : Add a second comment line after the first comment, before the package statement” is it generated automatically by the editing tool or what? That is, is a hallucination possible here (I want to know if I can always trust this?)
In the Read File, I still can’t read the full path of the file, I reloaded the page several times before making a new request to check.
We’re aware of this limitation — a proper diff view showing exactly which lines were changed is already planned and in progress. It’ll replace the current code preview with a before/after diff so you can see precisely what was modified.
The “Successfully applied edit to…” message is generated automatically by the Morph AI model that performs the actual file edit — it’s not something we write or control. So technically yes, a hallucination is possible: Morph could report success even if the edit wasn’t applied perfectly. In practice it’s reliable and the success rate is way more than normal model have (99%), but we’d recommend verifying critical changes rather than trusting the message blindly.