How Licuse Selects Context

The workspace is the starting point, not the whole prompt

Licuse keeps source files, local history and checkpoints in the desktop environment. When you ask for AI help, the relevant pieces of the current task can be selected for a model request. The system does not need to attach a complete project inventory to every message; a simple greeting should not carry the same repository evidence as a multi-file bug. That distinction reduces noise and unnecessary transmission, though it does not by itself guarantee a correct answer.

A coding request can require the current file, an error, a test and nearby symbols. The agent may then use file tools to retrieve more. The useful question is whether each added piece helps the next decision. Licuse's approach is built around on-demand inspection rather than a promise that the model has absorbed the entire repository.

Bounded code inspection

The code-lens tool can inspect a target symbol and propose a bounded set of nearby callers and callees. This helps an agent map a local relationship without reading a whole directory. The current implementation limits the number of functions and source characters returned, and it reports uncertainty or skipped material. For JavaScript and TypeScript it uses syntax-aware analysis; other supported sources may use heuristics. A static call relationship does not prove runtime order or identify every dynamic dispatch.

The agent should treat a code-lens result as a lead. It can open the actual source and tests, check current revisions and then decide whether the proposed caller is relevant. Before an edit, a current file read matters because the workspace may have changed after the earlier lens result.

Task episodes as historical clues

Licuse includes a local native EpisodeStore that records task-sized information such as observed files, changed files, actions, commands and outcomes. A later task can search candidates from the same project, then select relevant episodes and file hints. The chooser is constrained to validated IDs and paths; it should not import arbitrary history into the model request. Retrieved material is bounded so older tasks do not crowd out the present problem.

An episode is not an authority over current code. It can tell the agent that a similar bug was investigated before or that a file mattered, but the current branch may differ. The agent should hydrate selected history only when relevant, then re-open source and run present tests. This separates continuity from stale certainty.

The current model path still matters

Local context selection and remote model inference are distinct. In direct BYOK mode, Licuse supports OpenRouter, OpenAI and Anthropic; selected prompts, code excerpts, attachments and tool results can go to the chosen provider. Hosted AI uses Licuse's backend and model router. Local workspace files and episode storage are not an offline inference engine. Read the data-practices page for the mode you use, especially when a repository is sensitive.

A narrow context packet can reduce the amount of code transmitted, but the selected code still reaches the model route. Optional search or fetch tools may introduce more recipients. Review attached material and permission settings rather than assuming that the word local covers every processing step.

What happens when retrieval is unavailable

A local native component may fail to load on an unsupported or broken installation. The EpisodeStore code has a fallback that continues without historical retrieval and warns once, rather than inventing prior memory. That is the safer failure mode: the agent can still use current files and user instructions, but it should not claim to remember an episode it could not access. Current task evidence remains more important than historical convenience.

This distinction also matters in evaluation. Test a new task with no history, then a related follow-up. If follow-up quality improves, inspect whether the correct episode was selected and whether current files were rechecked. If history is wrong or unavailable, the agent should expose that limitation and proceed from fresh evidence.

A user-level review exercise

Give Licuse a bounded repository issue. Before permitting a patch, ask it which files and tests support its hypothesis. Review the code-lens or file-read results if shown. Then make a change to one relevant file and see whether the agent refreshes the source before editing. After the patch, run a targeted test and compare the final diff. This tests context selection, freshness and verification as one workflow.

The desired result is a small, justified change with clear uncertainty where evidence is incomplete. Licuse's context tools help gather and remember clues, but they do not replace a developer's responsibility to inspect the source, approve commands and verify AI output. That is the standard by which any context system should be judged.

Check the request path and cost separately

Selective context can reduce repeated input tokens and limit unrelated code exposure, but it does not determine the model's price or provider policy. A code-lens result may be inexpensive to compute locally and still be followed by a costly remote model call if many excerpts are attached. Inspect the provider usage record and the actual selected context for a representative task. If the agent repeatedly opens the same file after a failed hypothesis, improve the task evidence rather than assuming another retrieval call will solve it. A focused prompt is useful only when it leads to a correct, tested result. This separation helps users evaluate Licuse without confusing local retrieval, remote inference and account billing.