Cursor Product & Architecture
Know the thing you're supporting cold
What Cursor is, under the hood
After this you can explain Cursor's architecture well enough to predict where things break
Cursor is a fork of VS Code with an AI layer grafted on top and almost every confusing support ticket makes sense the moment you remember which half you're looking at.
When a user reports that their extension stopped working, their settings vanished after a profile switch or the editor can't find their Python interpreter, you are usually staring at inherited VS Code behavior. When a user reports a wrong answer, a stalled agent or a model error, you're in the part Anysphere built. Splitting tickets along that seam is the first move that makes you fast.
The two halves you triage between
The extension system and marketplace, the settings.json model, profiles and settings sync.
Language servers (LSP), the integrated terminal, file watchers and the workspace/folder model.
Most platform-specific quirks: file paths on Windows, permissions on macOS, file-watcher limits on Linux.
Tab autocomplete, Chat and Agent mode.
The model router and the context/retrieval pipeline that feeds them.
Codebase indexing/embeddings, Rules, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. integration and privacy-mode data handling.
If an issue would also happen in stock VS Code, the fix usually already exists in VS Code's docs and community: extension conflicts, corrupt user settings, a broken interpreter path.
A quick way to isolate: ask the user to reproduce in a clean profile or with extensions disabled. If it persists, you've narrowed it to Cursor's own layer.
Who builds it and why that changes the job
Cursor is made by Anysphere, founded in 2022 by a group of MIT graduates. The stated mission is to automate coding, the company has grown extraordinarily fast on both revenue and valuation and the product ships changes weekly. That pace is the part that matters for support.
A memorized fix can rot in a week because a model swapped, a default changed or a feature shipped. The durable skill is reasoning from how the system is wired, not from a script. Interviewers in User Operations screen for exactly this.
The core surfaces, named
- The editor
- The VS Code-derived shell: files, extensions, terminal, LSP. The host everything else runs in.
- Tab / autocomplete
- Inline next-edit prediction as you type. Cursor's signature low-latency surface.
- Chat (Ask)
- Conversational Q&A over your code, read-only by default. Understand before you touch.
- Agent
- Multi-step, multi-file edits with tool use. States intent, proposes a diff you review.
- Model + context layer
- The router and retrieval pipeline that decide which model runs and what it sees.
Five surfaces. Most tickets land on one of them and naming it is half the triage.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Top layers rest on the VS Code shell at the bottom; tickets ride down to whichever layer actually broke.
One more architectural fact earns credibility in the technical round: Cursor does not only relay foundation models. For some tasks where third-party latency or quality fall short, Anysphere trains and serves its own models. Tab in particular runs on custom prediction models built for speed.
The workspace defines what the AI can see
The folder you open is the workspace and it sets the entire domain the AI can reason over. A user who opens only their frontend repo and asks "what happens when I click this button" gets back only the frontend piece. The same question against a workspace that holds the frontend, the backend and its docs traces the click all the way through to where the data persists. Knowing this turns a lot of "the AI can't see X" tickets into a one-line answer about scope.
Tactic to recommend for end-to-end debugging: make one empty parent folder, git clone each related repo into it, then open the parent as the workspace. Cursor now adds context across repositories instead of seeing one in isolation.
If you have your backend docs and your front-end repos all in one workspace, what you're doing is enhancing Cursor's ability to add context between those different repositories.
Don't tell a user "that's a VS Code problem, not ours" and close the ticket. The lineage is your diagnostic tool, not a deflection.
Cursor's job is to resolve the user's problem regardless of which half it lives in. Use the fork to find the fix faster, then own the resolution.
Takeaway. Cursor is VS Code (extensions, settings, LSP, files) plus an Anysphere AI layer (Tab, Chat, Agent, context, indexing, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.); split every ticket along that seam first and the fix gets shorter.
Self-check
QA user says: "After I switched profiles, all my keybindings and theme reset and now my Python linter doesn't run." Which half of the architecture is this and what does that tell you about the fix?
Tab, Chat and Agent mode
After this you can describe each core feature, its happy path and its common failure modes
Three surfaces, three latency budgets, three completely different failure shapes - and users describe all of them as "the AI is dumb."
Your value in a Tab/Chat/Agent ticket is converting that vague complaint into a surface and a reproducible scenario. A latency gripe about Tab and a runaway Agent edit have nothing in common except the user's frustration. Name the surface first.
Ultra-low-latency next-edit prediction as you type, often multi-line and cross-file.
Happy path: sub-second, anticipates the edit you're already making.
Complaints cluster on latency and quality: slow suggestions, irrelevant completions or Tab going quiet.
Conversational Q&A grounded in your code, no edits applied unless you act.
Happy path: accurate answers about the open codebase.
Failures trace to context: it can't see the file the user means or indexing is stale.
Multi-step, multi-file edits with tool use: reads code, runs commands, proposes a diff.
Happy path: a scoped task lands with a reviewable diff.
Failures: stale context, wrong model, rate limits, tool/permission errors, off-target edits.
The failure-mode mapwhat to suspect, by symptom
- Symptom
- "Completions are slow / laggy"
- Likely surface
- Tab
- First thing to check
- Network round-trip, region, large file, conflicting extension hijacking the keybinding
- Symptom
- "Tab stopped suggesting"
- Likely surface
- Tab
- First thing to check
- File type/language, Tab disabled in settings, quota/plan limits
- Symptom
- "It gives wrong or generic answers"
- Likely surface
- Chat / Agent
- First thing to check
- Indexing state and whether the right context was attached
- Symptom
- "The agent edited the wrong files"
- Likely surface
- Agent
- First thing to check
- Scope of the prompt, context provided, model selected
- Symptom
- "Model error / request failed"
- Likely surface
- Chat / Agent
- First thing to check
- Rate limits, model availability, network/proxy, auth token
- Symptom
- "It won't run my command / read my file"
- Likely surface
- Agent
- First thing to check
- Tool permissions and what the user approved
| Symptom | Likely surface | First thing to check |
|---|---|---|
| "Completions are slow / laggy" | Tab | Network round-trip, region, large file, conflicting extension hijacking the keybinding |
| "Tab stopped suggesting" | Tab | File type/language, Tab disabled in settings, quota/plan limits |
| "It gives wrong or generic answers" | Chat / Agent | Indexing state and whether the right context was attached |
| "The agent edited the wrong files" | Agent | Scope of the prompt, context provided, model selected |
| "Model error / request failed" | Chat / Agent | Rate limits, model availability, network/proxy, auth token |
| "It won't run my command / read my file" | Agent | Tool permissions and what the user approved |
Most tickets resolve to one row. Confirm the symptom, then check the named cause.
Mode and model both change behavior and cost
Two settings change the answer a user gets before context even enters the picture: which mode they're in and which model they picked. Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. won't edit; Agent mode will plan and act. A fast small model and a top-tier reasoning model behave differently on the same prompt and they cost differently against the user's request budget.
- Mode (Ask vs Agent). Ask answers and explains; Agent plans, runs tools and proposes edits. A user expecting edits in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. will report that "nothing happens."
- Model choice. A lightweight model is fast but weaker on hard reasoning; a latest-generation model is stronger but slower and heavier on usage. "It got worse" is sometimes just a model switch.
- Cost coupling. Heavier models and longer agent runs consume more of the request/usage allowance, which loops back to billing tickets you'll see in a later section.
Plan with a smart model, execute with a fast one
Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. harnesses the agent to write a detailed Markdown of exactly what it will do instead of editing files immediately. The pattern worth coaching users toward: plan with a state-of-the-art reasoning model (an Opus 4.x or GPT-5.x) where the big context window and processing power craft a plan the agent then adheres to, then switch to a fast in-house model like ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. to execute it. The thinking is already done up front, so what you're optimizing for is speed.
If a user complains that Agent runs feel slow on big tasks, point them at this split before anything else.
"Plan with a frontier model so the agent writes out exactly what it'll do, then switch the model to ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. to execute. Composer has enough context and juice to run the plan well, and because all the thinking is done up front, you're just buying speed."
The single most common question support fields is which model to pick. The honest answer is to let the user determine it for themselves: Best-of-N runs the same prompt with the same inputs across several models in parallel so you can compare the outputs side by side.
You can even run one model twice (2X it) to see the variance from the same prompt - that variance tends to surprise people. There's an upfront cost to running a prompt redundantly, but it's far cheaper than going down a rabbit hole with the wrong model and redoing the whole task.
Interactive widget. Tab through its controls; the result updates in the panel below as you change them.
Plan with a thinker, execute with a fast model.
Plan and reason with a frontier model (Opus 4.x / GPT-5.x), execute with a fast in-house Composer model, and let Auto route when you're unsure. Best-of-N settles ties empirically.
In the technical screen you'll get a vague complaint on purpose. Don't theorize. Drive to a repro: "Which mode were you in, which model, what was the exact prompt and what did you expect versus see?"
Narrate the surface you've isolated as you go. Interviewers are grading whether you turn "the AI is dumb" into a single reproducible scenario, not whether you guess the root cause on the first try.
"Totally hear you that the suggestions felt off. Let's pin it down together - were you in Ask or Agent and which model was selected? If you can paste the exact prompt and the diff it produced, I can reproduce it on my end and see where the context went sideways."
Takeaway. Tab fails on latency and quality, Chat fails on context, Agent fails on scope, model, limits and permissions; coach the user from "the AI is dumb" to one reproducible scenario with mode + model + prompt + expected-vs-actual.
Self-check
Context, indexing, rules & MCP
After this you can trace how context gets into the model and where the pipeline fails
Almost every "bad answer" ticket is a context failure wearing a model-quality costume.
The model only sees what the pipeline hands it. When retrieval misses the relevant file, when indexing is stale or when a rule quietly rewrites the instructions, the output looks confidently wrong and the user blames intelligence. Your job is to walk the pipeline and find where the right information dropped out.
The context pipeline, end to end
- 1User intent. The prompt, the current mode and the model selected. Ambiguous intent produces vague context.
- 2Context selection. Implicit (open file, selection, recent files, linter errors) plus explicit
@-references:@files,@folders,@docsand MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. tools. - 3Retrieval / indexing. Codebase embeddings retrieve semantically relevant files. If indexing failed or is partial, retrieval pulls the wrong slice or nothing.
- 4Rules. Project and user rules are injected to steer behavior. A bad rule reshapes every answer silently.
- 5Model. The assembled context plus the prompt go to the selected model, which produces the output the user sees.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Walk it left to right and place the failure on a step. The two gates - indexing and rules - are what to check before blaming the model.
Failed or partial indexing is one of the most common root causes of "it doesn't know my codebase." Check it before you suspect the model.
Have the user confirm the index built (and finished) and that the repo isn't excluded by .gitignore/.cursorignore or too large to fully index. A re-index resolves a surprising share of "bad answer" tickets.
What indexing actually stores (the privacy-ticket answer)
A large share of enterprise tickets are really "what happens to our code?" in disguise. Knowing the exact storage mechanic lets you answer with precision instead of hand-waving, which is what earns trust with a security-conscious admin.
- Chunk + embed
- On first open Cursor chunks the repo into functions/pieces and generates vector embeddings. The embeddings are hashed and stored.
- Raw code is ephemeral
- The actual source is held only ephemerally during indexing, then deleted. The only long-term store is the vector database, not your code.
- Retrieval at prompt time
- Semantic search over those embeddings pulls the most relevant chunks into context when the user prompts.
- .cursorignore
- A file (distinct from .gitignore) naming paths Cursor must never index or view: the control surface for keeping sensitive code out of indexing and agent reach.
"We don't keep your codebase long-term: embeddings live in a vector DB, the raw code is deleted after indexing." That sentence resolves most privacy tickets.
Tools that rely on grep (substring search) stall on a large repo: on a 2M-line codebase, substring search is slow and degrades. Because Cursor indexes the whole repo into a vector DB, it matches what the user semantically means and stays fast, demoed on Grafana at ~2M+ lines and 30,000 files.
This is why "it can't find anything in our huge monorepo" is usually an indexing-not-built problem, not a model problem. A fully-built index is what makes large-repo retrieval work at all.
When a team asks how to point Cursor at a smaller subset of a giant C++ tree, reframe first: thousands of source files isn't large by Cursor's standards, since it indexes very large monorepos performantly. Fundamentally you're just opening a folder, so it's about what you populate in it.
Two real levers: .cursorignore to exclude paths from indexing, or a team rule to steer the agent toward a subset. Cursor's own pattern is pulling their website out into a sub-repository people can iterate on for docs. Note that indexing scope and access scope are separate axes - don't conflate them.
Cursor doesn't shove every file, tool and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. output into the window. Since v2.4 the agent reads from files/tools/MCP and pulls in only what it deems relevant, a filesystem approach that preserves accuracy as context grows.
Combined with caching, this harness behavior reduces agent tokens by around 47%, even on other vendors' models. Useful context for billing tickets where a user expects every request to be maximally expensive.
Each context source adds its own failure surface
- Context source
- Codebase index
- What it adds
- Semantic retrieval over the whole repo
- How it fails
- Failed/partial build, ignored paths, repo too large, stale after big changes
- Context source
- @-files / @-folders
- What it adds
- Exact files the user names
- How it fails
- User attached the wrong path or the file is huge and crowds the window
- Context source
- @-docs / @-web
- What it adds
- External reference material
- How it fails
- Doc not indexed, link unreachable, outdated source
- Context source
- Rules
- What it adds
- Standing instructions that steer the model
- How it fails
- Conflicting or overly broad rules producing surprising outputs
- Context source
- MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers
- What it adds
- External tools and data the model can call
- How it fails
- Server down, auth expired, schema mismatch, timeout
| Context source | What it adds | How it fails |
|---|---|---|
| Codebase index | Semantic retrieval over the whole repo | Failed/partial build, ignored paths, repo too large, stale after big changes |
| @-files / @-folders | Exact files the user names | User attached the wrong path or the file is huge and crowds the window |
| @-docs / @-web | External reference material | Doc not indexed, link unreachable, outdated source |
| Rules | Standing instructions that steer the model | Conflicting or overly broad rules producing surprising outputs |
| MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers | External tools and data the model can call | Server down, auth expired, schema mismatch, timeout |
More context power means more places to look when something goes wrong.
Rules and MCP, specifically
Rules are standing instructions (project-level or user-level) that get injected into the model's context. They're powerful and easy to forget. A user who set a rule weeks ago like "always respond in terse pseudocode" will later report that "the agent won't write real code," and the cause is sitting in their own rules file.
MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. (Model Context Protocol) lets Cursor connect to external servers that expose tools and data - a database, an issue tracker, a docs source. Each connection is a small integration with its own auth and uptime. When an MCP-backed action fails, treat it like any integration: is the server reachable, is the token valid, does the response match the expected schema.
Looking at just the code helps, but the additional sources of context are what really unlock a team. Three platforms do most of the work: ticketing/management (Jira, Intercom), a knowledge base (Notion, docs) and customer context (Salesforce or your CRM).
Cursor's own support stack is concrete: Datadog MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. to pull logs directly in for debugging, Notion MCP for their docs (used heavily) and Linear for bug reports.
If you're just looking at the code that can be helpful in and of itself but providing these additional sources of context is what really unlocks a team.
A user asks how to keep accumulated context - past answers, historical tickets - available to the agent. Cursor's team does not store this in a code repository. They use a third-party vendor that holds all the tickets and historical interaction data (enabling deep-research tools) and pull it into Cursor via MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs..
The forward-looking version worth mentioning: if you did store knowledge as Markdown somewhere Cursor can read, that directly enhances the in-IDE agent. It's a powerful option, not a requirement. As one engineer put it, "it's more stored in an external source and then brought in via MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.."
Hooks: deterministic code in the agent loop
LLMs are nondeterministic by design, so you can't rely on the model to decide to protect secrets or log usage. Hooks let you configure a piece of code that always runs in the agent loop, deterministically, instead of trusting the model to do it. Two real uses: filtering agent responses by scanning for secrets, and augmenting your own analytics to track usage at the team level. When a support or security workflow must be guaranteed rather than likely, hooks are the surface.
This is our way to basically allow you to hook into that loop and be able to run something that will always consistently run versus relying on the LLM to decide that it should.
Privacy mode and data-handling settings change what context leaves the machine and what gets stored. In a privacy-restricted or enterprise-locked setup, certain retrieval or training-data behavior is intentionally limited.
Before you chase a "why doesn't it see my code" ticket as a bug, confirm whether privacy or data controls are constraining the pipeline by design. This is constant in enterprise troubleshooting.
When given a "bad output" scenario, say the pipeline out loud: intent → context selection → retrieval/index → rules → model → output and place the failure on it.
That sentence signals you root-cause along a system, not by trial and error. It's the single most impactful thing you can demonstrate in the technical round for this role.
cursor.com/docs has an Ask AI feature that semantic-searches the documentation and returns a detailed answer - ask it "give me an overview of rules, skills, and sub-agents" and it pulls straight from the Customizing section.
It's a good self-serve deflection for the rules/skills/MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. questions in this section. Hand it to a user who wants to go deeper rather than retyping the docs into a ticket.
Takeaway. Output quality is set upstream of the model: walk intent → context → index → rules → model → output, check indexing and rules before blaming the model and remember privacy mode can constrain the pipeline by design.
Self-check
QAn enterprise developer reports that Cursor "ignores half my codebase" and only references the file that's open. List the pipeline stages you'd check, in order and name the two you'd suspect first.
Accounts, billing & enterprise
After this you can handle the non-editor issues that dominate enterprise tickets
A large share of "Cursor is broken" tickets never touch the editor - they're billing confusion, an SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. misconfig or a corporate proxy quietly dropping requests.
These tickets are where a support engineer earns trust with enterprise buyers, because they're the ones an admin escalates loudly. The skill is telling a confused user from a broken product, then routing each to the right place: config questions to docs and the admin, real defects to Engineering.
Plans, usage and the billing tickets that aren't bugs
- Tier
- Individual / Free
- Roughly who it's for
- Trying it out, light use
- Why behavior differs
- Tighter request/usage limits; fewer admin controls
- Tier
- Pro
- Roughly who it's for
- A serious individual developer
- Why behavior differs
- Higher limits, full model access within the usage allowance
- Tier
- Team / Business
- Roughly who it's for
- Small-to-mid teams
- Why behavior differs
- Seat management, centralized billing, shared admin
- Tier
- Enterprise
- Roughly who it's for
- Large orgs with security needs
- Why behavior differs
- SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SAMLAn enterprise standard that powers single sign-on., admin policy, privacy/data controls, deployment options
| Tier | Roughly who it's for | Why behavior differs |
|---|---|---|
| Individual / Free | Trying it out, light use | Tighter request/usage limits; fewer admin controls |
| Pro | A serious individual developer | Higher limits, full model access within the usage allowance |
| Team / Business | Small-to-mid teams | Seat management, centralized billing, shared admin |
| Enterprise | Large orgs with security needs | SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SAMLAn enterprise standard that powers single sign-on., admin policy, privacy/data controls, deployment options |
When two users see different behavior, the tier difference is often the whole story.
Many billing tickets are quota or pricing confusion, not defects. A user hits a request limit or a heavier model burns the allowance faster than expected and reports it as the product "cutting them off." The fix is explaining limits and model pricing clearly, not a code change.
- "It stopped working mid-task"
- Often a request/usage limit reached, not an outage. Check plan and usage.
- "My bill is higher than expected"
- Heavier models and long agent runs cost more per request. Walk through model pricing.
- "A teammate has features I don't"
- Different tier or seat assignment. Check seat management and plan.
- "I upgraded but nothing changed"
- Sign-out/sign-in to refresh entitlements, confirm the seat applied to the right account.
Route these to clear explanation + docs, not to Engineering.
The request math behind "why did one chat cost 30 requests?"
The most confusing billing ticket on legacy request-based plans is a single chat that burned a surprising number of requests. The answer is a concrete mapping, not a bug, and being able to walk it through calmly is what closes the ticket.
- Non-max-mode models
- Usually consume roughly one or two requests per use. This is what users expect.
- Max-mode models
- Map their underlying API cost back to a request count. That's how a single chat can consume ~30 requests.
- A request ≈ 8 cents
- On legacy request-based plans a request roughly equals ~8¢, so a 30-request Max-mode chat reflects ~$2.40 of model API cost, not an overcharge.
- Tokens map to dollars
- Each model has distinct input/output/cached rates; heavier models and longer agent runs cost more. Cloud-agent pricing is usage-based and draws from the team's pooled usage.
Walk the user through the mapping: Max mode trades a bigger context window for a higher request count. It's pricing working as designed.
"That 30-request chat isn't a glitch. You were on a Max-mode model, which maps its API cost back to requests, and on the legacy plan a request is about 8 cents. So a heavy Max-mode chat lands around 30 requests. If you don't need the larger context, switching to a standard model keeps it at one or two requests per turn."
Auth, SSO and admin
Enterprise auth is its own category. SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SAMLAn enterprise standard that powers single sign-on. sits between the user and the product, so a failed login is frequently an identity-provider configuration issue, not a Cursor bug. Admin and team management (who has a seat, what policy applies, which data controls are enabled) explains a lot of "why can't I do X" tickets.
- SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SAMLAn enterprise standard that powers single sign-on.. Login loops or "access denied" often trace to the IdP config: wrong assertion mapping, an unprovisioned user or a domain not verified. Confirm with the admin before assuming a defect.
- Admin / team management. Seat assignment, role/policy and enabled data controls govern what a user can do. Many capability complaints are policy, working as configured.
- Privacy / data controls. Enterprise policy can disable indexing of certain content or restrict what's sent. Verify the policy before treating restricted behavior as broken.
A specific, non-obvious gotcha that generates real tickets: cloud agents and automations respect the same privacy mode as the user's account (code not used for training), but they do not work with legacy privacy mode.
The reason is mechanical: the cloud VM must store the codebase for the duration of the agent run, which legacy privacy mode forbids. A user on legacy privacy mode who reports "cloud agents won't start" isn't hitting a bug. They need to switch off legacy privacy mode. Confirm which mode is set before escalating.
Network realities in regulated environments
Cursor's AI features need to reach Anysphere's services. In corporate networks that path runs through a proxy or firewall and air-gapped or heavily regulated environments may block it entirely. When AI features fail but the editor works, suspect the network before the product.
- Network condition
- Corporate proxy
- Typical symptom
- Requests time out or fail with TLS errors
- Where to point
- Proxy allowlist and proxy settings in the editor/OS
- Network condition
- Firewall / allowlist
- Typical symptom
- AI features dead, editor fine
- Where to point
- Required Cursor/Anysphere endpoints not allowlisted
- Network condition
- Air-gapped / regulated
- Typical symptom
- No outbound AI calls possible
- Where to point
- Deployment options and admin discussion; not a client bug
| Network condition | Typical symptom | Where to point |
|---|---|---|
| Corporate proxy | Requests time out or fail with TLS errors | Proxy allowlist and proxy settings in the editor/OS |
| Firewall / allowlist | AI features dead, editor fine | Required Cursor/Anysphere endpoints not allowlisted |
| Air-gapped / regulated | No outbound AI calls possible | Deployment options and admin discussion; not a client bug |
Editor works but AI doesn't is the classic network-not-product signature.
In the cross-functional round, show you triage the type of issue, not just the issue: "This is a config question, so I route it to the admin and our docs; this one reproduces on a clean network, so it's a real bug and I write the repro for Eng."
Demonstrating that you protect Engineering's time by filtering confusion from defects is exactly the support-scaling instinct Cursor hires for.
"Good news - the editor itself is healthy, the AI calls are being blocked before they leave your network. That points at the proxy or firewall rather than Cursor. Can you confirm with your IT admin that our endpoints are allowlisted? I'll send the exact list so the change is quick."
Takeaway. Many enterprise tickets are confused, not broken: bill/quota confusion → explain + docs, SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./seat/policy → admin, proxy/firewall → IT allowlist; reserve Engineering escalation for issues that reproduce on a clean config.
Self-check
QAn enterprise admin reports: "Half our developers can use Chat and Agent, the other half just get errors. Same version, same company." What's your hypothesis order?
Cursor vs the field
After this you can hold an informed point of view on competitors for the product round
The product round is partly a lie detector: interviewers can tell within minutes whether you actually use Cursor and have formed real opinions, including where a competitor is genuinely better.
Fanboying reads as fake and fails the truth-seeking value Anysphere screens for. The strong candidate names Cursor's real edge, concedes where a rival wins and ties each difference back to the support questions it would create.
The field you should know
- Tool
- Cursor
- Shape
- AI-native editor (VS Code fork)
- Where it's strong
- Editor-first feel, Tab prediction, capable Agent, custom models
- Tool
- GitHub Copilot
- Shape
- Plugin into existing editors + GitHub
- Where it's strong
- Ubiquity, IDE neutrality, deep GitHub/enterprise footprint
- Tool
- Windsurf (Codeium)
- Shape
- AI-native editor / agent-assisted IDE
- Where it's strong
- Direct editor competitor with its own agent flow
- Tool
- Claude Code
- Shape
- Terminal / CLI-native agent
- Where it's strong
- Command-line and scripting workflows, agent-assisted from the shell
- Tool
- Sourcegraph Cody
- Shape
- Code search + AI across large codebases
- Where it's strong
- Enterprise-scale code intelligence and search
| Tool | Shape | Where it's strong |
|---|---|---|
| Cursor | AI-native editor (VS Code fork) | Editor-first feel, Tab prediction, capable Agent, custom models |
| GitHub Copilot | Plugin into existing editors + GitHub | Ubiquity, IDE neutrality, deep GitHub/enterprise footprint |
| Windsurf (Codeium) | AI-native editor / agent-assisted IDE | Direct editor competitor with its own agent flow |
| Claude Code | Terminal / CLI-native agent | Command-line and scripting workflows, agent-assisted from the shell |
| Sourcegraph Cody | Code search + AI across large codebases | Enterprise-scale code intelligence and search |
Know the shape of each, not just the name. Shape predicts the workflow and the complaint.
Where Cursor wins and where it doesn't
The editor-first experience: AI woven into the editing loop rather than bolted on.
Tab's next-edit prediction and a genuinely capable Agent.
Custom models tuned for speed and specific tasks, plus model neutrality: Claude, OpenAI/Codex, Gemini, Grok or ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan., switched as new SOTA ships (with Claude Code you'd effectively only have Claude).
The proprietary harness (caching + dynamic context discoveryThe agent pulling only the relevant parts of files, tools and MCP servers into context as needed, instead of loading everything up front.) cuts agent tokens ~47% even on other vendors' models, so the same model can perform better here than elsewhere. It's why "Cursor is just a wrapper" is wrong.
Copilot's reach: if a team is locked to a specific IDE or deep in GitHub, that ubiquity is real.
Claude Code wins for terminal-native, scriptable workflows away from an editor.
Switching to a forked editor is a real adoption cost some teams won't pay.
The top support misconception in enterprise security reviews: people hear "self-hosted" (private workersCloud-agent machines that run inside your own network so they can reach internal systems; the model inference still calls external providers., in beta) and assume model inference runs in their network too. It doesn't.
Self-hosted runs the cloud-agent container/VM inside the customer's network so it can reach on-prem source control and internal MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers. But the agent still calls out to the model providers (e.g. Anthropic's API for an Opus model), exactly like the desktop. It's for assets that can never touch the internet and stringent-compliance orgs, not fully on-prem AI. Correcting this early saves a doomed escalation.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Same question, two takes. The strong one is first-hand, concedes a real competitor win and lands back on the support queue.
Each difference becomes a ticket. Being a forked editor means extension-compat and migration questions. Custom models and Tab mean latency and model-error tickets that a pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance.-based tool simply doesn't generate.
Saying "this differentiator creates this class of support question" proves you connect product to the actual job, which is rarer and more convincing than reciting feature lists.
Don't bluff comparisons you haven't lived. "I haven't used Cody deeply, but here's what I'd expect from its code-search angle" beats a confident, wrong claim.
Calibrated honesty is the point. Overclaiming on a competitor is the fastest way to fail the values screen.
Before the loop, do real work in Cursor and at least one competitor on the same task and write down two things each does better. First-hand specifics ("Tab caught a cross-file rename Copilot missed; Claude Code was smoother for a one-off shell script") read as genuine.
Then close the loop to the role: name which of those differences would land on your support queue and how you'd handle it.
"I use Cursor daily and the Agent plus Tab combination is what keeps me in it. Copilot still wins on raw ubiquity and for pure terminal work I reach for Claude Code. The fork model is Cursor's biggest strength and its biggest source of support tickets - extension and migration questions - which is honestly part of why this role interests me."
Takeaway. Have a first-hand, calibrated take: name Cursor's edge (editor-first, Tab, Agent, custom models), concede where Copilot/Claude Code/Cody genuinely win and tie each difference to the support tickets it would create.