What is Cursor? How its editor, agents and model choices work together
How Cursor organizes code editing and agent tasks, separating tools, rules and models and distinguishing completion, cross-file edits and review.
Meet this tool
Cursor is software for code editing and collaboration with AI agents. Developers request explanations or edits inside projects, and an agent uses search, file editing and terminal tools. Cursor is not one underlying model: availability and routing depend on product configuration, and rules and tools also affect results. The model label alone does not describe the whole system.
From cursor completion to cross-file tasks
Completion continues content at an editing location and suits developers who know what to write. Cross-file repair requires related implementation, multiple edits and execution feedback. Agent tools connect these operations, while actual program behavior establishes success.
Project rules can live as .mdc files in .cursor/rules and be version-controlled. Rules can be scoped by path patterns, invoked manually or included by relevance. Ordinary .md files there are not automatically project rules. Scope-aware rules are easier to maintain than resending every convention in each conversation.
Agents depend on rules, tools and the selected model
Cursor describes agents through instructions, tools and models. Project rules guide work, tools determine available operations and models process context. Identical models can behave differently with different tools and information, so product experience is not simply a model benchmark score.
Routing can select models, and automatic selection should not be assumed to use one permanent version. Availability depends on accounts and updates. Actual settings and task records are more reliable than old screenshots. This page promises no model access or quota.
Checkpoints help undo edits but do not replace Git
Changes and task records support inspection. Checkpoints can help reverse agent edits but are distinct from Git history. Keep permanent versions, collaboration and recovery in the project’s established version-control process.
Commands and external resources require current authorization. Opening a repository does not authorize arbitrary commits, publication or changes elsewhere. Separate existing user edits from new generated work instead of resetting the entire working tree to undo one mistake.
Choose based on actual development actions
Developers who review while editing may value editor-agent interaction; terminal and automated workflows need corresponding product forms. Compare the same real requirement, scope and error handling rather than equate a convenient interface with higher code quality.
Verify actual patches and task-appropriate checks, including real interface interaction where needed. This page ranks no speed or success rate. If unrelated files change, preserve differences and narrow the patch rather than assume one undo action automatically preserves all prior user work.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.