Skip to content
PrepMint

Cursor

Cursor AI Features

AI-native editing features

50 questions
Easy· 20Medium· 20Hard· 10

Last reviewed

Recommended

Cursor AI Features — Timed Test 4 (10 questions)

TimedEasy10 questions · 10 min
Start test

No account needed. Answers and explanations arrive when you submit.

What this topic tests

The mix every Cursor AI Features set is built to, and the questions published against it so far. Nothing here is hidden before you start.

Cursor AI Features — target difficulty mix and published question count per level
LevelTarget sharePublished
Easy40%20
Medium40%20
Hard20%10
Total50

Cursor AI Features — the theory

Three Ways To Get Code, And When Each Is Wrong

Cursor gives you three distinct ways to have the AI write code, and most wasted time comes from reaching for the wrong one.

Tab is inline autocomplete. It is not a plain completer: it suggests code as you type, based on your recent edits, surrounding code, and linter errors. That means it follows intent you have already demonstrated, which is why it performs badly in an empty file — a new or empty file gives it less to work with. A suggestion is only ever a proposal until you take it, because suggestions appear as grayed-out text ahead of your cursor.

Two behaviours repay knowing. A single suggestion is not limited to the current line — Tab can modify multiple lines, add missing import statements, and suggest coordinated edits across related code. And after you take one, press Tab again. Tab predicts your next editing location and jumps there, including into another file, where a portal window appears at the bottom of the editor.

Inline Edit is the middle option: it lets you make quick, targeted code changes without opening the chat panel, and it is iterative — to refine, add follow-up instructions and press Return again. It acts on your selection, so a change that must span files is the wrong job for it.

Agent is the one that does real work, and the rest of this topic is mostly about it.

What An Agent Actually Is

An agent is not a model. It is instructions, tools and a model together, and Cursor tunes the first two per model — Cursor's agent orchestrates these components for each model we support, tuning instructions and tools specifically for every frontier model. When output is poor, the part you control is usually the instructions, not the model picker.

An agent works until the job is done rather than within a budget: there is no limit on the number of tool calls Agent can make during a task. It does not idle when it asks you something — while waiting for your response, the agent continues reading files, making edits, or running commands — and you do not have to wait for it either. You have two ways to talk to an agent while it works. Queue a message and it waits for the current task to finish.

The most important sentence for a newcomer is about when changes land: Agent's edits are applied as it works. Review them in the diff view and reject anything you don't want. There is no approve-before-write gate on file edits. The safety net is a checkpoint: Agent automatically creates them before making significant changes, capturing the state of all modified files. But it is a local undo and nothing more: checkpoints are stored locally and separate from Git. Only use them for undoing Agent changes; use Git for permanent version control.

The Modes Are Different Permissions, Not Different Tones

Ask mode is a read-only mode for understanding your codebase — the agent answers questions and explores code without making any edits. When the question turns into work, switch back to Agent mode; it will not escalate itself.

Plan Mode researches first: Agent researches your codebase, asks clarifying questions, and generates a reviewable plan you can edit before building. The plan is a document you change, not a preview you accept, and it lives outside the repo — plans are saved by default in your home directory. Plan Mode is not a universal safety upgrade: for quick changes or tasks you've done many times before, jumping straight to Agent mode is fine. When a build goes wrong, the recommended recovery is counter-intuitive and worth trusting — instead of trying to fix it through follow-up prompts, go back to the plan, because this is often faster than fixing an in-progress agent, and produces cleaner results.

Debug Mode trades speed for evidence. Instead of immediately writing code, the agent generates hypotheses, adds log statements, and uses runtime information to pinpoint the exact issue before making a targeted fix. It is not autonomous — Debug Mode asks you to reproduce the bug and provides specific steps — and the cleanup is conditional on finishing: once confirmed, the agent removes all instrumentation.

One cross-cutting fact catches people out: each mode uses its own context, so switching modes starts a fresh context window. Exploring in Ask and then flipping to Agent with "now build what we discussed" reaches an agent that was not there. Rules, by contrast, travel everywhere — project rules, user rules, and team rules apply in Agent, Ask, Plan, and Debug modes.

Running More Than One Agent

A subagent is an isolated worker: each subagent runs in its own context window and returns a result to the main conversation, and crucially the parent agent includes relevant information in the prompt since subagents don't have access to prior conversation history. Isolation is the feature and the price. It is not, however, isolation of authority — subagents inherit all tools from the parent, including MCP tools from configured servers — and nesting is capped: the main agent and its direct subagents can launch subagents, but a subagent launched by another subagent can't launch further ones.

Parallel agents editing one checkout collide, which is what worktrees exist for: they let Agent work in isolated Git checkouts. Each task gets its own files, dependencies, and changes while your main checkout stays untouched. Two warnings come with them. We do not recommend symlinking dependencies into the worktree, and they are not permanent — cleanup runs on an interval and keeps the newest worktrees up to the configured machine-wide maximum count across every workspace on the device.

A side chat is the lightweight option for a question you do not want polluting the main thread. It is seeded invisibly — the parent's conversation history is copied in as reference context for the model. That history does not appear in the side-chat transcript — and it is deliberately not a second agent: by default, side chats focus on reading, searching, and answering.

The Guardrails, And What They Do Not Cover

Cursor is explicit about why the approval prompts exist: AI can behave unexpectedly due to prompt injection, hallucinations, and other issues. Run Modes decide how much runs unattended, and their coverage is narrower than the name suggests — auto-review applies to shell, MCP, and Fetch tool calls, which leaves file edits outside it entirely: agents can modify workspace files without approval, except for configuration files. Changes save immediately to disk.

The review step is a model, and the documentation says so plainly: the classifier can make mistakes. It can allow a call you would have blocked, or block a call you would have allowed. The sandbox has a matching gap — commands that need full system access, like writes outside the workspace or privileged operations, can't be sandboxed, so they go to the classifier instead. The riskiest commands are exactly the ones it cannot contain.

Two defaults are worth keeping. Agents cannot make arbitrary network requests with default settings, and MCP trust is per call, not per connection: after you approve an MCP connection, each tool call still needs individual approval before running.

Finally, if you share a session, know what leaves with it. The full conversation history is shared, including code snippets, tool calls, and their results, and the scrubbing is best-effort: redaction is not guaranteed and can miss secrets.

Where to Go Next

Cursor Basics covers everything this page assumes is already working: installing, migrating, rules, ignore files, skills, configuring MCP and what the usage meter actually counts. AI Agents Basics covers agent architecture in general — the concepts underneath modes, tools and delegation, none of which are Cursor's invention. And Claude Code Workflows shows delegation and subagents worked out in a different tool, which is the fastest way to see which behaviour here is Cursor and which is the shape of the idea.

Sample questions

Three questions from this topic, with the answer and the reasoning shown.

Q1EasyA background subagent finishes an investigation, and an hour later a follow-up question about its findings comes up. What does Cursor make possible?
  • Only starting a fresh subagent, since a completed one is torn down along with everything it had gathered.
  • Resuming that subagent by its agent ID and continuing the conversation with the context it built preserved.Correct
  • Re-issuing the identical prompt, which rebuilds exactly the same context before the follow-up is put to it.
  • Reading back the returned summary alone, because a subagent holds its state in memory and loses it on exit.

Explanation

The principle — Each subagent execution returns an agent ID, and background subagents write their state to disk as they go. A finished subagent is a conversation you can pick up again, rather than a call that has already returned.

Why the key is correct — Passing that ID back resumes the subagent with its context intact, so the follow-up lands on an agent that already knows the paths, the dead ends and the findings.

Why the others are wrong — Starting fresh is possible but wasteful, since completion does not discard the state. Re-issuing the original prompt reproduces neither the exploration nor the saving. And the state is persisted rather than held in memory, so the returned summary is far from all that survives.

Remember this — Keep the agent ID; a completed subagent resumes with its context.

Sources — Cursor's Subagents documentation.

Open this question on its own page

Q2EasyA colleague on a legacy request-based plan switches Max Mode on before asking a question. What does that setting actually change?
  • It substitutes a stronger variant of the model, so the same question comes back with deeper reasoning.
  • It extends the context window past the default, so a single request can hold more material.Correct
  • It widens how much of the project the editor indexes, so searches across the codebase return more results.
  • It lifts the per-message rate limit, so longer runs of requests can be sent with no waiting between them.

Explanation

The principle — Max Mode is available only on legacy request-based plans, and it extends a model's context window beyond the default limit. That is the whole mechanism. It also stays on across conversations once enabled, so it behaves as a default rather than a per-chat choice.

Why the key is correct — A bigger window means more code, more files and more conversation can be in view for one request. Nothing about the model's reasoning changes.

Why the others are wrong — It does not swap in a more capable model, it has no bearing on how much of the project is indexed for search, and it is not a rate limit control.

Remember this — Max Mode is a bigger window, not a better brain — and it stays on until you switch it off.

Sources — Cursor's Max Mode documentation.

Open this question on its own page

Q3EasyA colleague writes every prompt as numbered micro-steps, as though driving a code generator, and wonders why it takes so long. What does a coding agent do with a plain-language goal instead?
  • It expands your goal into a numbered plan and then waits for you to carry out each step in the editor.
  • It returns one best answer as a code block, leaving the file changes and any commands entirely to you.
  • It searches the codebase for comparable code and offers snippets, which you adapt and then apply file by file.
  • It plans the work itself, edits files, runs commands and checks its own results against the goal you described.Correct

Explanation

The principle — A coding agent writes and changes software on its own. You describe a goal in plain language; the agent plans the work, edits files, runs commands and checks its own results.

Why the key is correct — Planning, editing, running and verifying are the agent's job, which is why a useful prompt states the outcome and its constraints. Micro-steps waste the part that plans.

Why the others are wrong — Writing a plan for you to execute describes a hand-off that does not happen; the agent does the work even when the approach is reviewed first. Returning a snippet to paste describes an assistant that answers rather than acts. Codebase search is one tool feeding the next edit, not the deliverable.

Remember this — Give the agent the destination and the constraints; let it choose the route.

Sources — Cursor's coding agents help documentation.

Open this question on its own page

Practise all 50 questions

Every published question in Cursor AI Features, with its answer and explanation.

Frequently asked

What people ask about cursor ai features.

Why are Tab's suggestions poor in a brand-new file?
Tab builds its suggestion from your recent edits, the code around the cursor and linter errors, so an empty file gives it almost nothing to follow. Write a few lines that establish the shape you want and the suggestions sharpen immediately. Once there is a pattern to follow, Tab can span multiple lines and add missing imports.
Does Agent ask before it changes my files?
No. Agent's edits are applied as it works, and you review them afterwards in the diff view, rejecting what you do not want. Checkpoints are created automatically before significant changes, but they are local and separate from Git — commit before a large run rather than relying on them.
I explored a problem in Ask mode, switched to Agent, and it had forgotten everything. Why?
Each mode uses its own context, so switching modes starts a fresh context window. Restate the conclusion, or do the exploration and the work in the same mode. Rules are the exception: project, user and team rules apply in Agent, Ask, Plan and Debug alike.
Agent built the wrong thing from my plan. Should I correct it in chat?
The documentation recommends going back to the plan rather than steering with follow-up prompts, because that is often faster than fixing an in-progress agent and produces cleaner results. Patching a wrong approach conversationally tends to leave a diff nobody can review.
If I turn on sandboxing, is everything the agent runs contained?
No. Commands needing full system access — writes outside the workspace, privileged operations — cannot be sandboxed and are sent to the auto-review classifier instead. The classifier is also not a security boundary; it can allow a call you would have blocked.
What exactly is exposed when I share a transcript?
The full conversation history, including code snippets, tool calls and the results those tool calls returned. Best-effort redaction runs first, but it matches only known secret patterns and can miss custom values or values without a recognisable prefix, so read the transcript yourself before publishing a link.

More Cursor topics

All of Cursor

Related guides

  • How it works · 10 min read

    What Cursor actually looks at when you ask it something

    Indexing says synced, the file is open, and Cursor still answers as if your code does not exist. Follow one request end to end: what gets attached, what gets injected, what the agent decides to search for, what three ignore files remove, and what gets compressed away.

  • How it works · 11 min read

    It followed your example instead of your instruction

    You wrote the rule, then pasted an example under it to help — and the output matched the example. A demonstration is a stronger signal than a description, it shows everything about itself rather than the one property you meant, and nothing warns you when the two disagree.

  • Troubleshooting · 8 min read

    Why Cursor is ignoring your rules file

    A rule that sits in .cursor/rules and does nothing fails silently, and Cursor publishes no way to see which rules were applied. Ten causes with distinct fingerprints: the type you get by leaving fields blank, the .md that is invisible, and the team rule that outranks you.