When Cursor is offline: the local-only features that still work

Published 2026-05-11 by Owner

Cursor is a code editor that happens to have AI features wired into it. The editor part and the AI part have different infrastructure, and understanding the split matters the moment your flight wifi drops mid-session.

The short version: Tab completions, Chat, and Composer all make network calls. Every single one. If the request doesn’t reach Anthropic or OpenAI’s servers (or Cursor’s own model endpoint), nothing AI-related comes back. The editor itself, however, keeps running — and quite a bit of what makes it productive has nothing to do with AI.

This guide maps the split precisely: what goes dark, what stays lit, and how to make the offline half more useful than the default “wait for wifi” response suggests.

What requires the network

All three AI surfaces in Cursor go remote:

Tab — the inline completion that suggests the next line or block — sends your current file context to Cursor’s model endpoint on every trigger. There is no local inference running for Tab. When offline, the tab-complete ghost text simply never appears.

Chat — the sidebar panel where you ask questions about code — routes to Claude or GPT-4 depending on your Cursor plan and the selected model. Offline, messages send and sit unanswered, or return a connection error immediately depending on how hard the request times out.

Composer — the multi-file generation mode — is even more network-dependent than Chat because it often runs multiple model calls in sequence to plan, write, and validate changes. An interrupted Composer session mid-run can leave files in a partially edited state.

@-mentions and context fetching — when Chat or Composer uses @docs, @web, or pulls context from external sources, those requests go out over the network separately from the model call itself. These fail independently from the main inference request.

A subtlety worth knowing: Cursor’s model routing goes through Cursor’s own servers even when you bring your own API key (BYOK). Your key gets used to authenticate to the upstream provider, but the request still passes through Cursor’s infrastructure. That means a Cursor-side infrastructure issue can take down AI features even when Anthropic and OpenAI are fully up.

There is also no graceful degradation. Cursor doesn’t detect “offline” and automatically switch to a local mode. It just fails each request individually. The first time you notice this on a flight is usually when you type and nothing appears in the Tab ghost text slot, or you send a Chat message and see a connection-error badge instead of a response. It’s not subtle once you know the pattern; it’s confusing the first time you encounter it.

A useful diagnostic: if Tab stops working but Chat still responds (or vice versa), the issue is more likely rate-limiting or a partial outage than pure offline. The AI surfaces can fail independently. Full offline kills all of them at once.

What keeps working offline

The non-AI layer is VS Code with a different coat of paint. Everything VS Code does without network access, Cursor does too:

Language Server Protocol (LSP) completions — go-to-definition, find-all-references, hover documentation, rename symbol, parameter hints — these all run locally via the language server for your language. TypeScript’s tsserver, Rust’s rust-analyzer, Python’s Pylance: none of them need a network connection. In practice, LSP completions feel less magical than Tab but cover the mechanical parts of coding just fine.

LSP-driven completions are worth calling out separately from Tab because they operate on a fundamentally different basis. Tab predicts what you were probably about to type based on context. LSP completions know the actual type signatures from your project’s definitions — they’re not predictions, they’re lookups. Offline, the LSP completions survive; the probabilistic predictions from Tab do not.

File operations — creating, renaming, deleting, moving files and folders. The file explorer, split panes, breadcrumbs, minimap.

Search — global text search, regex search, symbol search (Ctrl+T / Cmd+T), fuzzy file open (Ctrl+P / Cmd+P). All local. For a large codebase, the built-in search is often faster than asking Chat where something is defined anyway.

Git integration — staging files, diffing, committing, viewing blame, browsing branch history. Git itself runs locally; only push/fetch/pull need network (to the remote, not to Cursor). The Source Control panel, the inline blame, the timeline view — all of these work.

Terminal — fully local. Any CLI tool you can run in a terminal, you can run in Cursor’s integrated terminal offline. Test runners, build tools, local dev servers, database migrations: none of these care about Cursor’s AI endpoints.

Extensions — any extension that doesn’t itself make external API calls works fine. Linters, formatters (Prettier, ESLint, Rustfmt), debuggers, themes. Check whether an extension makes API calls only if it’s one that explicitly integrates with an external service.

The honest framing: an offline Cursor session is a well-configured VS Code session. That’s meaningfully different from nothing.

Worth naming something most Cursor users don’t discover until offline: the Outline panel (View → Open View → Outline) gives a symbol tree of the current file — all functions, classes, and methods — without any AI involvement. Combined with Ctrl+Shift+O / Cmd+Shift+O (Go to Symbol in File), this is a fast way to navigate a large file that doesn’t require Chat at all. The same applies to Ctrl+T / Cmd+T for workspace-wide symbol search. These are VS Code primitives, always available.

One concrete example of leaning on the local layer: TypeScript’s language server knows every type, every overload, every return value in a project — without any network call. Hovering over a function call gives the full signature. Going to the definition of an interface shows every field. Renaming a symbol renames it in every file. These are operations that people frequently reach for Chat to answer (“what does this return?”) when the answer is already available locally, one hover away. Offline work sharpens the habit of using the LSP layer first.

The BYOK-with-local-model option

There is a path to offline AI completions, but it requires advance setup and has real rough edges.

Cursor supports custom OpenAI-compatible endpoints under Settings → Models → OpenAI API Key → Base URL. Ollama exposes a local inference server at http://localhost:11434/v1 that speaks the OpenAI chat completions API. The combination works:

1. Install Ollama and pull a model: ollama pull qwen2.5-coder:7b (or similar)
2. In Cursor’s model settings, add a custom model pointing at http://localhost:11434/v1 with any non-empty string as the API key (Ollama ignores the key)
3. Select that model in Cursor’s model picker before going offline

What works: Chat, and Composer in single-file mode. What’s rough: Tab completions via this path are hit-or-miss depending on Cursor’s version — Tab uses a different internal path than Chat. As of early 2026 the Ollama-via-custom-endpoint route works reliably for Chat but not consistently for inline Tab.

Model selection also matters more than it might seem. A 7B parameter model on a MacBook Air (M-series) runs at around 30-50 tokens/second, which is fast enough for chat but noticeably slower than Cursor’s hosted Tab completions. A 14B model on the same hardware is half that speed. Code-focused models (Qwen2.5-Coder, DeepSeek-Coder-V2-Lite) outperform general models of the same parameter count on completion quality.

This is an experimental path — Cursor doesn’t officially document or support it, and the custom endpoint setting has moved between Cursor versions. The setting name to look for in current builds is under Cursor Settings → Models, not VS Code’s settings panel.

Quality is also worth calibrating expectations around. A local 7B model on a laptop is meaningfully weaker than Claude 3.5 Sonnet or GPT-4o on complex code tasks. For “explain this error message” or “write a function that parses a date string,” the gap is small. For multi-file refactors or architectural questions, the gap is large. The offline model handles the former well; the latter is where you’ll notice the difference.

The setup cost is front-loaded. If this is valuable to you, spending an hour before a planned offline stretch — pulling a model, confirming the Cursor endpoint setting works, and running a few test Chat messages — is worth doing once rather than figuring out mid-flight.

One more practical point on model selection: the Ollama model library skews toward general-purpose models but has solid code-focused options. For offline coding specifically, qwen2.5-coder at 7B or 14B is consistently recommended in the Cursor community forums as the sweet spot between size and quality. It fits in 8 GB of VRAM or unified memory and handles most common coding tasks at reasonable speed. Larger models (32B+) require more VRAM or dramatically slower inference speeds on most laptops.

The airplane workflow

If offline work is a real scenario — long flights, cabin wifi, spotty conference hotel networks — the setup is worth doing in advance rather than scrambling on the jetway.

Before boarding:

• Pull the Ollama model you want while on a fast connection. Models are 4-8 GB; airport wifi is not the time to find this out. ollama pull qwen2.5-coder:14b takes a few minutes on a home connection and requires nothing else to be running.
• Open the files you’ll need. Cursor’s editor state persists across restarts; the files won’t disappear. If working on a feature branch, have the branch checked out and confirmed clean before the flight.
• If using Cursor’s built-in AI normally, identify any architectural questions you might need answered during the session and ask them before boarding while you still have connectivity. Paste relevant code into Chat and ask “what should I know about this before refactoring it?” The answer lives in the Chat history and is available offline.
• Run any installs, fetches, or test suite downloads beforehand. Offline doesn’t just affect Cursor — it affects npm, pip, cargo, and anything else that fetches from the internet. Running npm install or cargo build for the first time on a flight when dependencies aren’t cached is frustrating.
• Check that your local dev server starts without external dependencies. Some projects call external APIs even in development mode; find out before you’re offline.
• If you rely on documentation sites during coding, consider downloading docs locally or using a tool like Zeal (Linux/Windows) or Dash (macOS) that stores language and library docs offline. This matters more than the Cursor AI layer for most reference tasks.

During the offline session:

Lean on LSP harder than usual. Go-to-definition and find-all-references answer most “what does this call return?” questions without needing Chat. For code structure questions, the terminal plus grep covers a lot of ground. Rubber-duck in a scratch file — writing out the problem in a comment often clarifies the approach without requiring an AI response.

A practical workflow adjustment: do design thinking on paper (or a scratch file) and implementation in Cursor. The AI loop is most valuable when you’re uncertain about the approach; when the approach is clear, the implementation is often mechanical. Offline trips work well for tasks that are well-understood but time-consuming — the kind of work where you know exactly what you’re building and just need the keyboard time.

Use the terminal aggressively. Running tests and watching them fail gives immediate feedback without AI. A tight loop of write code, run tests, read error output, fix — this is an entirely local workflow that doesn’t touch any AI endpoint. For most bug-fixing work, this loop is as fast as using Chat, sometimes faster because there’s no waiting on a model response.

If Ollama is running, Chat with the local model handles factual questions about APIs and syntax reasonably well. It’s weaker on your specific codebase context unless you paste the relevant code directly into the message. Pasting a 50-line function into the Chat prompt and asking “why would this throw a null reference here?” works fine. Asking “how does the auth system work in this codebase?” produces a generic answer about auth systems, not about yours.

Commit frequently during offline sessions. If something breaks and you’d normally ask Chat for help, having a clean git checkpoint to diff against is more useful than a Chat session anyway. Small commits also mean that when you reconnect and review, it’s easy to see what the offline session actually changed.

Reconnection behavior

When network returns, Cursor doesn’t require a restart and doesn’t announce that the connection is restored. You notice it because Tab ghost text reappears, or a Chat message you’d given up on suddenly gets a response. The behavior by surface:

Tab — resumes immediately on the next keystroke that would trigger a completion. No manual action needed. If the language server was doing all the work during the offline period, the Tab predictions layer back on top of whatever LSP completions were appearing.

Chat — a failed or pending message will usually need to be resent. Cursor doesn’t auto-retry timed-out Chat requests. If the connection dropped mid-response, the partial response stays visible in the thread; just ask the follow-up directly. The conversation history is preserved, so context from earlier in the session is still visible to the model.

Composer — a Composer run that failed mid-stream may leave files partially edited. Check the git diff before continuing. Resuming a Composer session after reconnecting by re-running the same prompt doesn’t always produce the same edit set — treat the partial state as a draft and review it before accepting.

One wrinkle to watch for: if Cursor was also syncing anything to its cloud state (settings, snippets, keybindings) during the session, those sync operations will replay on reconnect. This is generally silent but can occasionally cause a brief lag when the editor reconnects.

If you had Ollama running as a Chat fallback during the offline period and switch the model picker back to a cloud model, the conversation history persists but was generated by the local model. The cloud model will have access to that history when you continue the thread — it won’t know the prior responses came from a different model unless you tell it. This is usually fine; just worth knowing if consistency of reasoning matters for the task.

The cleanest reconnection habit: when wifi comes back, run git diff or check the Source Control panel before triggering any new AI requests. This gives a clear view of what the offline session changed versus what the AI will now propose to change. Starting a new Composer prompt without reviewing the offline-session diff is an easy way to end up with conflicting changes.

If Ollama was running as a Chat fallback during the offline period, remember to switch the Cursor model picker back to the cloud model after reconnecting. The local model remains selected until explicitly changed, and it’s easy to forget you’re talking to the local model once the cloud option returns.

One thing that does not happen automatically: Cursor will not retry or replay any AI requests that failed while offline. The assumption is that context may have changed. That’s the right call.

A note on Cursor telemetry and offline: Cursor collects usage data (completions accepted, rejected, chat messages) but these events are buffered and sent when connectivity returns. Going offline doesn’t reset your usage stats or create gaps in Cursor’s telemetry — the data queues locally and replays. This only matters if you monitor your own Cursor usage metrics closely.

The broader takeaway from the offline scenario is that Cursor is more layered than it appears when everything is working. Most users discover the local-only layer only when the network layer fails — which is an inefficient way to learn that LSP hover documentation and full-project symbol search were available all along. Understanding the split in advance means the offline half of a flight is productive rather than frustrating, and means that even online, the faster local features get used for the questions they can already answer.

The split also clarifies what Cursor’s AI layer actually adds. It’s not replacing the editor; it’s layered on top of a fully functional one. Taking that perspective into an offline session makes the experience much less disorienting — and occasionally surfaces the realization that certain tasks don’t need the AI layer at all.