FIM Code Completion

FIM (Fill-In-the-Middle) completion reads code context both before and after the cursor, then offers continuation suggestions as gray Ghost Text at the cursor position — with first-token latency under 50ms and zero interruption while you type. Unlike whole-block generation, FIM is designed for "inserting a snippet into existing code".

How It Triggers

• Automatic: a request fires automatically after you pause typing for about 150ms (the debounce interval is adjustable via ide.completion_debounce_ms); continuous typing is never interrupted.
• Manual: invoke completion at the cursor on demand — useful when you want a suggestion immediately.

Every request is tagged with its trigger type (automatic / manual) and carries the current file path and language, so the model returns suggestions that match the syntax and project style. Completion uses the credentials of the currently selected model, returns at most 3 candidates per request, and shows the best one after score-based ranking.

Accept & Reject

Candidate suggestions come in inline and multi-line forms; multi-line suggestions are also accepted in one go with Tab.

Accepted code is no different from hand-typed code and can be undone normally.

How It Works

1. The editor extracts the prefix (text before the cursor) and suffix (text after it), and sends them to the kernel's completion endpoint along with the file path and language.
2. The kernel first checks the project-level cache; on a miss, it calls the model services that declare FIM capability in configured order until it gets candidates.
3. Candidates come back with latency and score information, and the best suggestion is rendered as Ghost Text after the cursor.

When the cursor moves or you keep typing, any in-flight request is aborted immediately to avoid wasted work.

Providers & Models

The FIM engine supports configuring multiple model services as completion providers, each carrying a supports_fim capability flag — only models that declare FIM support are used for completion. A provider configuration includes a name, endpoint URL, model, and the maximum tokens per completion; multiple providers are independent of each other. Requests are tried in configured order: the first provider to succeed returns the result, and failures automatically fall through to the next one.

Provider API keys are resolved server-side by the kernel per vendor configuration — the frontend never holds plaintext keys.

Performance & Caching

Each project has its own local completion cache (.lxz/cache/fim_cache.db):

• Two-tier structure: SQLite persistent storage + an in-memory LRU index, with up to 500 high-frequency records preheated at startup.
• Zero-cost hits: cache-hit completions consume no tokens and return almost instantly.
• Frequency-ranked: the cache tracks usage frequency and recency, so high-frequency completions are retained preferentially.
• Visible usage: every completion request returns latency and token usage, making it easy to observe how different models actually perform; cache-hit results are tagged with source cache.
• Automatic write-back: new results returned by models are written to the cache automatically, so identical contexts hit directly next time.

Beyond automatic completion, Inline Edit also offers Ghost Text continuation suggestions when no code is selected, using exactly the same accept/reject keys.

Completion quality depends directly on the selected model — see Models & Context. Debounce and other parameters are in Configuration, and the full key list is in Keyboard Shortcuts. FIM completion is a basic editor capability and does not consume daily Agent runs.