GlideGlide is a lightweight VS Code extension for low-latency AI code completion using GPT-5.6 Luna through the OpenAI Responses API. Glide is intended primarily for isolated, restricted, enterprise, and government development environments where developers need Copilot-style inline code completion but cannot depend on a vendor-hosted IDE service. The initial goal is deliberately narrow:
Glide is not initially intended to be a coding agent, chat assistant, repository management system, or replacement for tools such as Codex, Cline, Zoo Code, or VS Code Agent Mode. Those tools solve a different problem. Glide focuses on one thing and should do it well: predictive code completion. Current ImplementationGlide now has an installable V1 foundation with:
The initial code intentionally excludes chat, agents, sidebars, repository indexing, embeddings, and cross-file context. The Luna completion research compares published infilling and IDE research with this implementation. The completion action plan tracks the resulting fixes and experiments for work across development sessions. The live Luna evaluations found faster compact and full-fragment prompts without a supported quality improvement. Glide retains P0, its insertion-only protocol, a 96-token limit, and a 175 ms automatic debounce. A bounded same-file study did not support enabling selected context by default. The release-candidate report records automated evidence and the remaining five-session human usability gate. Install and ConfigureInstall the generated VSIX from VS Code's Extensions: Install from VSIX... command, then run: Version 0.1.5 preserves the existing Marketplace extension ID Glide defaults to To choose an existing key file, run Glide: Select API Key File from the Command Palette and select the file. It should contain the key itself on the first non-empty line, without quotes or Run Glide: Clear API Key File to forget the selected path and restore the default location without deleting a file or saved key. The default is Key files may be symbolic links to IT-managed secrets. On macOS and Linux, the resolved target must have private permissions, such as For example, create a private file once: Or replace Glide excludes common credential files such as SSH keys, While a request is active, the status icon spins and the model label stays stable. Authentication failures pause automatic requests. Updating settings or credentials, a successful Glide: Test Connection, or a successful explicitly invoked completion restores automatic requests. Network failures and timeouts use a bounded cooldown. DevelopGlide uses Node.js 24 LTS for development and supports VS Code 1.82 or newer. The extension bundle targets the Node 16.14 syntax level used by the minimum editor; integration tests run against VS Code 1.82 and current stable. The packaged extension is written to Why Glide ExistsModern AI coding products generally fall into two categories. The first category includes commercial products such as GitHub Copilot, Cursor, and Windsurf. These products provide excellent inline completion experiences, but their completion engines generally depend on vendor-operated infrastructure and cannot simply be pointed at an arbitrary private model endpoint. The second category includes open-source tools such as Tabby and Continue. These provide significantly more deployment flexibility and have contributed important ideas around code context, fill-in-the-middle completion, local models, model routing, and repository awareness. However, our requirements are unusually specific. We already have access to GPT-5.6 Luna Fast through a controlled API endpoint. Luna is fast, inexpensive relative to larger reasoning models, and capable enough to be a strong candidate for frequent code completion requests. Rather than inserting several generic abstraction layers between VS Code and Luna solely to obtain inline completion, Glide will explore whether a purpose-built Luna-oriented completion engine can provide a simpler and better-controlled solution. The intended architecture is therefore: V1 talks directly to the configured OpenAI Responses endpoint. Gateway integrations are outside the V1 product boundary. Design PrinciplesInvisible by defaultAutocomplete should not interrupt the developer's thought process. Glide should primarily exist as ghost text inside the editor. The developer should not have to interact with a chat window, sidebar, panel, or agent to receive suggestions. The main interaction should be: Latency matters more than maximum intelligenceAutocomplete is fundamentally different from agentic coding. A powerful answer arriving several seconds later is usually useless as an inline completion. Glide should optimize aggressively for:
GPT-5.6 Luna Fast should initially use the lowest practical reasoning effort for the normal autocomplete path. Larger reasoning models belong in agents and deliberate coding workflows, not on the critical path of every keystroke. Context quality over context quantityGlide should not send the entire repository with every completion request. The initial context strategy should prioritize:
Additional context should only be introduced when it measurably improves completion quality. Model-specific optimization is acceptableGlide does not need to support every LLM provider or every historical completion format. The initial implementation should be optimized around Luna Fast and OpenAI-compatible APIs. A clean provider abstraction is desirable, but generic provider compatibility must not compromise latency or implementation simplicity. Isolated-environment friendlyGlide must be usable in environments where arbitrary outbound Internet access is prohibited. The extension should not require:
The only model-related network destination is the configured completion endpoint. Redirects are rejected so credentials and source context are never replayed to another origin. Telemetry must be off by default. No source code should be transmitted anywhere except the configured completion endpoint. Relationship to Existing ToolsGlide should learn from existing autocomplete systems without attempting to duplicate them wholesale. TabbyTabby is an important architectural reference because it treats code completion as a dedicated system rather than merely sending chat prompts from an editor. Useful concepts to study include:
Glide does not initially require Tabby's server architecture because inference will occur remotely through Luna Fast. ContinueContinue is another useful reference, especially for:
Glide should adopt proven ideas where useful while remaining substantially smaller and more specialized. GitHub CopilotCopilot represents the user-experience benchmark. Glide should aspire to the same basic feeling:
Glide does not initially attempt to reproduce Copilot's entire feature set, including agent functionality or advanced next-edit prediction. Codex, Cline, Zoo Code, and other agentsThese tools are complementary to Glide. A likely developer environment is: Autocomplete and agentic coding should remain separate concerns unless future evidence suggests otherwise. Product NamingThe extension is named Glide. The name represents the desired user experience: the developer continues moving naturally while code appears smoothly ahead of them. The internal completion engine may use the name Impulse. Example internal component names may include: This lets the product name describe the experience while the engine name describes the event-driven completion mechanism. Initial User ExperienceGlide should not have a dedicated sidebar in the first release. The primary interfaces should be: Inline ghost textSuggestions appear directly in the editor and are accepted using the normal VS Code Tab workflow. Status barA small status indicator should provide visibility without consuming editor space. Example: The status item should allow quick access to enable or disable completion. Command PaletteInitial commands should include: VS Code SettingsConfiguration should use normal VS Code extension settings. Example configuration concepts: Secrets should preferably use VS Code SecretStorage, environment variables, platform credential storage, or another secure mechanism rather than plaintext settings. First MilestoneThe first milestone is a working installable VSIX. It should support:
The first languages to test heavily should be:
The architecture should remain language-independent where possible. Completion Request LifecycleA normal request should approximately follow this process: Glide should be willing to make no suggestion. Silence is better than a distracting or obviously wrong completion. Prompting StrategyLuna is a general-purpose model rather than a traditional dedicated FIM completion model. Glide therefore needs to carefully structure completion requests. A conceptual request may look like: The exact prompt should be treated as an implementation detail and tuned experimentally. Prompt quality should be evaluated through benchmarks rather than intuition alone. Cancellation and DebouncingAutocomplete requests become obsolete extremely quickly. If the user continues typing after a request begins, Glide should immediately invalidate or cancel the old request when possible. Requests should not be generated on every keystroke. The debounce algorithm should initially be simple and configurable. Future versions may make debounce timing adaptive based on:
Completion CleanupRaw model output should never automatically become visible ghost text. Glide should normalize and validate results first. Potential processing includes:
This processing layer is expected to be one of the most important parts of completion quality. Local StatisticsGlide should measure its usefulness without collecting source code. Local statistics may include: Metrics should remain local unless a future explicit opt-in system is designed. Source code, prompts, file contents, filenames, repository names, and completion contents should not be included in analytics by default. Testing PhilosophyGlide should be evaluated in three ways. Deterministic benchmarkCreate completion cases by removing code from existing source files. Each case contains: Candidate completion strategies can then be compared repeatedly. Useful measurements include:
Real-world usageDevelopers should use Glide during normal work. The most meaningful signals are acceptance rate and how much useful typing the system eliminates. A/B comparisonGlide should periodically be compared against tools such as Copilot, Tabby, or Continue when those tools are available. The benchmark is not merely whether Glide produces technically correct code. The real target is:
Future CapabilitiesFeatures intentionally deferred from the first milestone include:
These should only be added when testing demonstrates a meaningful benefit. Development ModelThe Go-first evaluation corpus also covers TypeScript, Python, YAML, and JSON. See the benchmark guide for offline checks and explicitly budgeted live runs, and the action plan for current priorities and per-task model recommendations. Glide should be developed primarily using GPT-5.6 Sol with a higher reasoning setting for architecture, code review, debugging, and analysis of reference implementations. GPT-5.6 Luna Fast is the initial runtime completion model. This distinction is intentional: The system should be designed so that the runtime model can be replaced later without renaming or fundamentally redesigning Glide. Success CriteriaThe first meaningful release of Glide is successful when:
The final criterion is the most important. An autocomplete system that developers disable has failed regardless of benchmark scores. |