Vibecode Cursor
track this build5 phases, 15 steps, beginner friendly0%KINDA · weekend project
⌨️ featured in the best vibe coding tools
You can assemble VS Code plus open-source agents, but Cursor's moat is editor-native agent UX, model routing, cloud agents, context handling, and rapid product iteration.
the project pack5 files · written for this build, step by step
You are building a lean indie version of Cursor. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Cursor · indie build VS Code or VSCodium running Cline with your own provider keys, a project rules file that survives across sessions, a deny list that keeps the agent away from secrets, a local model for the cheap tasks, and a weekly cost report so the bill is a number you chose rather than one you discover. Estimated effort: **weekend**. Work `BUILD_PLAN.md` top to bottom · every phase ends in a check that has to pass before the next one starts. ## Stack | Part | Choice | Why | | --- | --- | --- | | Editor | VS Code, or VSCodium if you want the telemetry-free build | the extension surface is the same and the whole point is that the editor is replaceable | | Agent | Cline, Apache 2.0, installed from the extension marketplace | actively maintained, brings your own key, and every file write and terminal command passes an approval gate | | Frontier model | Claude or another provider through your own API key | you pay per token at cost instead of paying for a seat and a credit allowance you cannot see | | Local model | Ollama running a small coding model | the cheap tasks stop costing anything and keep working with no network | | Cost control | Provider usage endpoints polled into a small local table | a subscription hides spend behind a monthly number; keys make it visible, but only if you look | ## Before you start Have every one of these ready. The plan assumes them from step one. - [ ] **VS Code or VSCodium** · free - Why: Hosts the agent extension. Everything else assumes it. - Get it: code.visualstudio.com for VS Code, or vscodium.com for a build with Microsoft telemetry and branding removed. Either works. - Verify: The editor opens your project folder and the extension marketplace is reachable - [ ] **The Cline extension** · free and Apache 2.0; you pay your model provider, not the extension - Why: It is the agent. Continue, which older guides recommend, was acquired by Cursor and its repository has been archived and read-only since June 2026. - Get it: Search for Cline in the editor's extension marketplace and install it. Open its sidebar to confirm it loaded. - Verify: The Cline sidebar opens and asks for a provider - [ ] **An API key from a model provider** · pay per token, typically a few cents per small task and more for long agent runs; set the provider spend limit on day one - Why: Without it the agent has nothing to think with. This is also the line item that replaces the subscription. - Get it: Create an account with your chosen provider, add a payment method, and create an API key in their console. Set a spending limit in the provider dashboard at the same time, before you make a single request. - Verify: A first small task completes and the provider dashboard shows the usage - [ ] **Ollama with a small coding model** (optional) · free, but it uses your own memory and battery - Why: Phase 4 only. It is what makes routine tasks free and offline. - Get it: Download from ollama.com, then pull a coding model sized for your memory. A seven billion parameter model wants roughly eight gigabytes free. - Verify: ollama list shows the model and curl http://localhost:11434/api/tags responds - [ ] **A secret scanner such as gitleaks** (optional) · free - Why: Product phase only. It is the machine that catches the key you were about to commit. - Get it: brew install gitleaks, or download a release binary from its GitHub project, then wire it into a pre-commit hook. - Verify: A deliberate commit containing a fake key is blocked ## Quick start ```sh ollama pull qwen2.5-coder:7b ollama list ``` Then copy `.env.example` to `.env` and fill in the values it documents. ## Honest limits This build deliberately does not replace: - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. - native composer/agent UX - model routing/credits - cloud agents - editor polish - extensions compatibility - team features If one of those is essential to you, that is the reason to keep paying for Cursor, and the README should say so rather than pretend. ===== BRIEF.md ===== # Build brief · Cursor The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me an agentic coding setup in an editor you control, with your own model keys and your own spending limits to replace Cursor. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. ### Rule zero Do not write an editor and do not write an agent loop. Both already exist, both are harder than they look, and neither is what you are actually missing. Assemble a real editor with a real open-source agent extension, then spend your effort on the parts that are genuinely yours: which model runs which task, what the agent is allowed to touch, and what it costs you per week. One note on the landscape, checked in September 2026: Continue was acquired by Cursor and its repository is archived and read-only, with the last release in June 2026. Do not build on it. Cline is the actively maintained open-source agent extension and is what this build uses. ### Stack (fixed, do not substitute) - Editor: VS Code, or VSCodium if you want the telemetry-free build · the extension surface is the same and the whole point is that the editor is replaceable - Agent: Cline, Apache 2.0, installed from the extension marketplace · actively maintained, brings your own key, and every file write and terminal command passes an approval gate - Frontier model: Claude or another provider through your own API key · you pay per token at cost instead of paying for a seat and a credit allowance you cannot see - Local model: Ollama running a small coding model · the cheap tasks stop costing anything and keep working with no network - Cost control: Provider usage endpoints polled into a small local table · a subscription hides spend behind a monthly number; keys make it visible, but only if you look ### Data model (create this before Phase 1) - .clinerules · the project rules the agent reads every session, committed to the repository - .clineignore · paths the agent must never read, starting with .env and any credential directory - runs(id, started_at, task, provider, model, input_tokens, output_tokens, cost_usd) · your own record, because provider dashboards aggregate and you want per-task - budget(month, cap_usd, spent_usd) · the number you refuse to exceed - Keep the two dotfiles in the repository and the two tables local; the rules are shared, the spending is yours. ### Phase 1 · Editor, agent and the first real task Build: Install VS Code or VSCodium and the Cline extension. Add one provider key. Give it a small real task in a scratch repository: add a function and a test, then run the test. Watch the approval prompts and do not turn them off. Trap: The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. Done when: The agent creates a file, edits it, runs the test suite and reports the result, and each write and command asked first. Revoking the API key makes the agent fail with a clear authentication error rather than silently doing nothing. Do not build yet: No local model, no rules file, no cost tracking. One working agent task. ### Phase 2 · Project rules that survive the session Build: Write .clinerules and commit it. Put in the things you correct twice: the test command, the package manager, the formatting rules, which directories are generated, and the house conventions a newcomer would get wrong. Keep it short enough to stay true. Trap: A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. Done when: A fresh session in the repository follows a convention you never mentioned in the prompt, and you can point at the line in the rules file that caused it. Deliberately removing that line makes the behaviour go away. Do not build yet: No cost tracking and no local model yet. ### Phase 3 · A deny list the agent cannot talk its way past Build: Write .clineignore covering .env and every variant, credential directories, key files, node_modules, build output and anything large and generated. Then verify by asking the agent directly for the contents of an ignored file and confirming it cannot produce it. Trap: An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. Done when: Asking the agent to print the contents of .env does not produce them through the file tools. Asking it to cat the same file produces an approval prompt you can refuse, and refusing it leaves the secret unread. A grep of the repository finds no live credential in the first place. Do not build yet: No local model or cost reporting yet. ### Phase 4 · Local model for the cheap work Build: Install Ollama, pull a small coding model, and add it as a second provider in the extension. Decide which tasks route to it: commit messages, renames, docstrings, simple refactors. Keep the frontier model for anything needing real reasoning. Trap: A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. Done when: A commit message task completes with the network disconnected. The same task against the frontier model is not billed, verified in the run table from Phase 5 or in the provider dashboard. Switching providers takes one action in the extension and does not require reconfiguring the project. Do not build yet: No cost reporting yet, which is the next phase. ### Phase 5 · Knowing what it costs Build: Record every run locally with tokens and estimated cost, and pull the provider's own usage figures on a schedule to reconcile. Set a monthly cap and a threshold that warns you before you reach it. Compare the total against the subscription you left behind. Trap: Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. Done when: A weekly report shows spend per day and per model, and its total is within a small margin of the provider dashboard for the same window. Crossing the warning threshold produces a visible alert. You can state, with a number, whether this setup costs more or less than the subscription it replaced. Do not build yet: Team configuration is the product phase. ### Phase 6 · Sharing the setup without sharing the keys Build: Commit the rules file, the ignore file and a setup document. Keep every key out of the repository and out of the shell history. Add a pre-commit secret scan so the mistake is caught by a machine rather than in review. Trap: A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is. Done when: A fresh clone plus the setup document gets a colleague to a working agent without anyone sending a key over chat. A deliberate test commit containing a fake key is blocked by the pre-commit hook. A scan of the full git history finds no credential. Do not build yet: Nothing after this. ### Out of scope (and why) - The editor itself. Cursor's tab completion, its inline diff presentation and the way its agent surfaces work are the product, and reproducing that experience is a company, not a weekend. - Model routing that Cursor does for you. You are now the router, which is why the routing rule has to be written down. - Cloud agents that run without your machine on. That is infrastructure with a bill attached. - Anything proprietary about how Cursor indexes a repository, which is a real engineering asset and not something a configuration file replaces. ### README must contain - Which editor and which extension, with the note that Continue is archived as of June 2026 and should not be adopted - Where keys are stored and the explicit rule that they never enter the repository - The task routing rule between the local and frontier models - The monthly cost cap and where the weekly report comes from - What the ignore list does and does not prevent, including the terminal caveat ===== AGENTS.md ===== # Agent instructions · Cursor indie build - Read `README.md` and `BUILD_PLAN.md` before writing code. The stack is fixed: VS Code, or VSCodium if you want the telemetry-free build, Cline, Apache 2.0, installed from the extension marketplace, Claude or another provider through your own API key, Ollama running a small coding model, Provider usage endpoints polled into a small local table. Do not substitute. - Work one phase at a time, in order. Do not start a phase until every "Done when" item of the previous one passes. - Prefer the fewest moving parts that satisfy the step. No frameworks, services or dependencies the plan does not name. - Secrets live in `.env`, never in source or logs. Keep `.env.example` current when a variable is introduced. - Do not invent cryptography, security guarantees, APIs or compliance claims. - Add a focused test for every destructive, security-sensitive or data-loss path the plan names. - Run the project checks before declaring a phase complete, and record any deliberate shortcut in the README under "Tradeoffs". ## Known traps - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. ===== BUILD_PLAN.md ===== # Build plan · Cursor VS Code or VSCodium running Cline with your own provider keys, a project rules file that survives across sessions, a deny list that keeps the agent away from secrets, a local model for the cheap tasks, and a weekly cost report so the bill is a number you chose rather than one you discover. Phases are in dependency order. Each ends in a "Done when" list; treat an unticked item as a blocker, not a note. ## Phase 1 · Editor, agent and the first real task An agent edits a file and runs a test in your repository, and you approved every action it took. ### Steps 1. Install the editor and the extension VS Code from code.visualstudio.com, or VSCodium from vscodium.com for a build without Microsoft telemetry. Install Cline from the extension marketplace inside the editor. 2. Add one provider key Paste the key into the extension settings. It is stored by the editor's secret storage rather than in your repository, which is where it must stay. 3. Run a real task and watch every prompt Ask for a small function plus a test in a scratch repository, then ask it to run the tests. Read what each approval prompt is actually asking before you click it. ### Done when - [ ] The agent writes a file and runs the test suite in your repository - [ ] Every file write and terminal command presented an approval prompt - [ ] The key is not present anywhere in the repository, checked with a grep - [ ] Revoking the key produces a clear authentication error ### Watch out - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. ## Phase 2 · Project rules that survive the session The agent starts every session knowing your conventions, so you stop repeating them. ### Steps 1. Write the rules file from real corrections Go through your last few sessions and write down what you had to say twice. That list is the rules file. Inventing rules you have not needed wastes tokens on every request. Files: `.clinerules` 2. State the commands explicitly The exact test command, the exact build command, and the package manager. An agent guessing between npm and pnpm wastes a minute and a half of your attention every time. Files: `.clinerules` 3. Prove a rule fires and prove it stops Pick one rule, run a task that would violate it, then delete the rule and run the same task. If nothing changes, the rule was decoration. ### Done when - [ ] A fresh session follows a convention that was never in the prompt - [ ] Removing the responsible line changes the behaviour - [ ] The rules file is committed and reviewed like code - [ ] The file is short enough that you have read all of it recently ### Watch out - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. ## Phase 3 · A deny list the agent cannot talk its way past Secrets and generated noise are outside the agent's reach, by configuration rather than by hope. ### Steps 1. Write the ignore file Start from your .gitignore and add credential paths, then add large generated directories so indexing stays fast and cheap. Files: `.clineignore` 2. Test the boundary honestly Ask for an ignored file two ways: through the file tools and through a terminal command. Record what each does. Knowing the real boundary is the deliverable of this phase. 3. Move real secrets out of the tree Use a secret manager, your operating system keychain, or a file outside the repository referenced by an absolute path. Test credentials in the working tree are fine; live ones are not. ### Done when - [ ] The agent cannot read an ignored file through the file tools - [ ] A terminal read of the same file raises an approval prompt that can be refused - [ ] No live credential exists anywhere in the working tree - [ ] Indexing skips generated directories, measured by how long a fresh index takes ### Watch out - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. ## Phase 4 · Local model for the cheap work Routine tasks stop costing money and keep working without a network. ### Steps 1. Install Ollama and pull a coding model Pick a model sized for your machine's memory. A model that swaps is slower than the network you were trying to avoid. ```sh ollama pull qwen2.5-coder:7b ollama list ``` 2. Add it as a second provider Configure the extension with the local endpoint, usually http://localhost:11434. Confirm it answers before trusting it with a task. ```sh curl http://localhost:11434/api/tags ``` 3. Write down the routing rule Two lines in the README naming which task types go local. A rule you did not write down is not a rule. Files: `README.md` ### Done when - [ ] A routine task completes with networking disabled - [ ] The local run produces no provider charge - [ ] Switching between local and frontier is one action - [ ] The routing rule is written down and matches what you actually do ### Watch out - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. ## Phase 5 · Knowing what it costs Weekly spend is a number you set, not one you find out about at the end of the month. ### Steps 1. Log runs locally A small script or extension hook writing one row per task with model, tokens and estimated cost. Files: `scripts/log_run.py` 2. Reconcile against the provider Fetch the provider's usage for the same window and compare. Investigate a gap rather than adjusting your estimate to hide it. Files: `scripts/reconcile.py` 3. Set a cap and an alert A monthly cap you actually intend to honour, and a warning at a fraction of it. Providers also offer their own spend limits; set those too, as a backstop. ### Done when - [ ] The weekly total is within a small margin of the provider dashboard - [ ] Crossing the warning threshold produces a visible alert - [ ] Per-model breakdown shows the local model contributing no cost - [ ] You can state the monthly figure and compare it to the subscription ### Watch out - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. ## Not in this build - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. ## After v1, if you want it - A shared rules file per repository so conventions travel with the project - Routing longer agent runs to a cheaper model and comparing the diff quality - A monthly review comparing your actual spend to the seat price you left ===== .env.example ===== # Copy to .env and fill in. Never commit .env; this file documents it. # Optional · secret. Your provider console. Prefer the editor's secret storage over an environment variable, and never a committed file. ANTHROPIC_API_KEY=sk-ant-... # Optional. Where the local model server listens. The default is fine unless you moved it. OLLAMA_HOST=http://localhost:11434 # Required. The cap you choose. Mirror it as a hard spend limit in the provider dashboard so a runaway loop cannot outrun your own alert. AGENT_MONTHLY_CAP_USD=40 # Required. Where per-task cost rows are written. Local only; it contains your usage patterns. RUN_LOG_PATH=~/.local/share/agent/runs.sqlite
You are building a lean indie version of Cursor. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Cursor · indie build VS Code or VSCodium running Cline with your own provider keys, a project rules file that survives across sessions, a deny list that keeps the agent away from secrets, a local model for the cheap tasks, and a weekly cost report so the bill is a number you chose rather than one you discover. Estimated effort: **weekend**. Work `BUILD_PLAN.md` top to bottom · every phase ends in a check that has to pass before the next one starts. ## Stack | Part | Choice | Why | | --- | --- | --- | | Editor | VS Code, or VSCodium if you want the telemetry-free build | the extension surface is the same and the whole point is that the editor is replaceable | | Agent | Cline, Apache 2.0, installed from the extension marketplace | actively maintained, brings your own key, and every file write and terminal command passes an approval gate | | Frontier model | Claude or another provider through your own API key | you pay per token at cost instead of paying for a seat and a credit allowance you cannot see | | Local model | Ollama running a small coding model | the cheap tasks stop costing anything and keep working with no network | | Cost control | Provider usage endpoints polled into a small local table | a subscription hides spend behind a monthly number; keys make it visible, but only if you look | ## Before you start Have every one of these ready. The plan assumes them from step one. - [ ] **VS Code or VSCodium** · free - Why: Hosts the agent extension. Everything else assumes it. - Get it: code.visualstudio.com for VS Code, or vscodium.com for a build with Microsoft telemetry and branding removed. Either works. - Verify: The editor opens your project folder and the extension marketplace is reachable - [ ] **The Cline extension** · free and Apache 2.0; you pay your model provider, not the extension - Why: It is the agent. Continue, which older guides recommend, was acquired by Cursor and its repository has been archived and read-only since June 2026. - Get it: Search for Cline in the editor's extension marketplace and install it. Open its sidebar to confirm it loaded. - Verify: The Cline sidebar opens and asks for a provider - [ ] **An API key from a model provider** · pay per token, typically a few cents per small task and more for long agent runs; set the provider spend limit on day one - Why: Without it the agent has nothing to think with. This is also the line item that replaces the subscription. - Get it: Create an account with your chosen provider, add a payment method, and create an API key in their console. Set a spending limit in the provider dashboard at the same time, before you make a single request. - Verify: A first small task completes and the provider dashboard shows the usage - [ ] **Ollama with a small coding model** (optional) · free, but it uses your own memory and battery - Why: Phase 4 only. It is what makes routine tasks free and offline. - Get it: Download from ollama.com, then pull a coding model sized for your memory. A seven billion parameter model wants roughly eight gigabytes free. - Verify: ollama list shows the model and curl http://localhost:11434/api/tags responds - [ ] **A secret scanner such as gitleaks** (optional) · free - Why: Product phase only. It is the machine that catches the key you were about to commit. - Get it: brew install gitleaks, or download a release binary from its GitHub project, then wire it into a pre-commit hook. - Verify: A deliberate commit containing a fake key is blocked ## Quick start ```sh ollama pull qwen2.5-coder:7b ollama list ``` Then copy `.env.example` to `.env` and fill in the values it documents. ## Honest limits This build deliberately does not replace: - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. - native composer/agent UX - model routing/credits - cloud agents - editor polish - extensions compatibility - team features If one of those is essential to you, that is the reason to keep paying for Cursor, and the README should say so rather than pretend. ===== BRIEF.md ===== # Build brief · Cursor The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me an agentic coding setup in an editor you control, with your own model keys and your own spending limits to replace Cursor. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. ### Rule zero Do not write an editor and do not write an agent loop. Both already exist, both are harder than they look, and neither is what you are actually missing. Assemble a real editor with a real open-source agent extension, then spend your effort on the parts that are genuinely yours: which model runs which task, what the agent is allowed to touch, and what it costs you per week. One note on the landscape, checked in September 2026: Continue was acquired by Cursor and its repository is archived and read-only, with the last release in June 2026. Do not build on it. Cline is the actively maintained open-source agent extension and is what this build uses. ### Stack (fixed, do not substitute) - Editor: VS Code, or VSCodium if you want the telemetry-free build · the extension surface is the same and the whole point is that the editor is replaceable - Agent: Cline, Apache 2.0, installed from the extension marketplace · actively maintained, brings your own key, and every file write and terminal command passes an approval gate - Frontier model: Claude or another provider through your own API key · you pay per token at cost instead of paying for a seat and a credit allowance you cannot see - Local model: Ollama running a small coding model · the cheap tasks stop costing anything and keep working with no network - Cost control: Provider usage endpoints polled into a small local table · a subscription hides spend behind a monthly number; keys make it visible, but only if you look ### Data model (create this before Phase 1) - .clinerules · the project rules the agent reads every session, committed to the repository - .clineignore · paths the agent must never read, starting with .env and any credential directory - runs(id, started_at, task, provider, model, input_tokens, output_tokens, cost_usd) · your own record, because provider dashboards aggregate and you want per-task - budget(month, cap_usd, spent_usd) · the number you refuse to exceed - Keep the two dotfiles in the repository and the two tables local; the rules are shared, the spending is yours. ### Phase 1 · Editor, agent and the first real task Build: Install VS Code or VSCodium and the Cline extension. Add one provider key. Give it a small real task in a scratch repository: add a function and a test, then run the test. Watch the approval prompts and do not turn them off. Trap: The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. Done when: The agent creates a file, edits it, runs the test suite and reports the result, and each write and command asked first. Revoking the API key makes the agent fail with a clear authentication error rather than silently doing nothing. Do not build yet: No local model, no rules file, no cost tracking. One working agent task. ### Phase 2 · Project rules that survive the session Build: Write .clinerules and commit it. Put in the things you correct twice: the test command, the package manager, the formatting rules, which directories are generated, and the house conventions a newcomer would get wrong. Keep it short enough to stay true. Trap: A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. Done when: A fresh session in the repository follows a convention you never mentioned in the prompt, and you can point at the line in the rules file that caused it. Deliberately removing that line makes the behaviour go away. Do not build yet: No cost tracking and no local model yet. ### Phase 3 · A deny list the agent cannot talk its way past Build: Write .clineignore covering .env and every variant, credential directories, key files, node_modules, build output and anything large and generated. Then verify by asking the agent directly for the contents of an ignored file and confirming it cannot produce it. Trap: An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. Done when: Asking the agent to print the contents of .env does not produce them through the file tools. Asking it to cat the same file produces an approval prompt you can refuse, and refusing it leaves the secret unread. A grep of the repository finds no live credential in the first place. Do not build yet: No local model or cost reporting yet. ### Phase 4 · Local model for the cheap work Build: Install Ollama, pull a small coding model, and add it as a second provider in the extension. Decide which tasks route to it: commit messages, renames, docstrings, simple refactors. Keep the frontier model for anything needing real reasoning. Trap: A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. Done when: A commit message task completes with the network disconnected. The same task against the frontier model is not billed, verified in the run table from Phase 5 or in the provider dashboard. Switching providers takes one action in the extension and does not require reconfiguring the project. Do not build yet: No cost reporting yet, which is the next phase. ### Phase 5 · Knowing what it costs Build: Record every run locally with tokens and estimated cost, and pull the provider's own usage figures on a schedule to reconcile. Set a monthly cap and a threshold that warns you before you reach it. Compare the total against the subscription you left behind. Trap: Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. Done when: A weekly report shows spend per day and per model, and its total is within a small margin of the provider dashboard for the same window. Crossing the warning threshold produces a visible alert. You can state, with a number, whether this setup costs more or less than the subscription it replaced. Do not build yet: Team configuration is the product phase. ### Phase 6 · Sharing the setup without sharing the keys Build: Commit the rules file, the ignore file and a setup document. Keep every key out of the repository and out of the shell history. Add a pre-commit secret scan so the mistake is caught by a machine rather than in review. Trap: A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is. Done when: A fresh clone plus the setup document gets a colleague to a working agent without anyone sending a key over chat. A deliberate test commit containing a fake key is blocked by the pre-commit hook. A scan of the full git history finds no credential. Do not build yet: Nothing after this. ### Out of scope (and why) - The editor itself. Cursor's tab completion, its inline diff presentation and the way its agent surfaces work are the product, and reproducing that experience is a company, not a weekend. - Model routing that Cursor does for you. You are now the router, which is why the routing rule has to be written down. - Cloud agents that run without your machine on. That is infrastructure with a bill attached. - Anything proprietary about how Cursor indexes a repository, which is a real engineering asset and not something a configuration file replaces. ### README must contain - Which editor and which extension, with the note that Continue is archived as of June 2026 and should not be adopted - Where keys are stored and the explicit rule that they never enter the repository - The task routing rule between the local and frontier models - The monthly cost cap and where the weekly report comes from - What the ignore list does and does not prevent, including the terminal caveat ===== AGENTS.md ===== # Agent instructions · Cursor indie build - Read `README.md` and `BUILD_PLAN.md` before writing code. The stack is fixed: VS Code, or VSCodium if you want the telemetry-free build, Cline, Apache 2.0, installed from the extension marketplace, Claude or another provider through your own API key, Ollama running a small coding model, Provider usage endpoints polled into a small local table. Do not substitute. - Work one phase at a time, in order. Do not start a phase until every "Done when" item of the previous one passes. - Prefer the fewest moving parts that satisfy the step. No frameworks, services or dependencies the plan does not name. - Secrets live in `.env`, never in source or logs. Keep `.env.example` current when a variable is introduced. - Do not invent cryptography, security guarantees, APIs or compliance claims. - Add a focused test for every destructive, security-sensitive or data-loss path the plan names. - Run the project checks before declaring a phase complete, and record any deliberate shortcut in the README under "Tradeoffs". ## Known traps - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. ===== BUILD_PLAN.md ===== # Build plan · Cursor VS Code or VSCodium running Cline with your own provider keys, a project rules file that survives across sessions, a deny list that keeps the agent away from secrets, a local model for the cheap tasks, and a weekly cost report so the bill is a number you chose rather than one you discover. Phases are in dependency order. Each ends in a "Done when" list; treat an unticked item as a blocker, not a note. ## Phase 1 · Editor, agent and the first real task An agent edits a file and runs a test in your repository, and you approved every action it took. ### Steps 1. Install the editor and the extension VS Code from code.visualstudio.com, or VSCodium from vscodium.com for a build without Microsoft telemetry. Install Cline from the extension marketplace inside the editor. 2. Add one provider key Paste the key into the extension settings. It is stored by the editor's secret storage rather than in your repository, which is where it must stay. 3. Run a real task and watch every prompt Ask for a small function plus a test in a scratch repository, then ask it to run the tests. Read what each approval prompt is actually asking before you click it. ### Done when - [ ] The agent writes a file and runs the test suite in your repository - [ ] Every file write and terminal command presented an approval prompt - [ ] The key is not present anywhere in the repository, checked with a grep - [ ] Revoking the key produces a clear authentication error ### Watch out - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. ## Phase 2 · Project rules that survive the session The agent starts every session knowing your conventions, so you stop repeating them. ### Steps 1. Write the rules file from real corrections Go through your last few sessions and write down what you had to say twice. That list is the rules file. Inventing rules you have not needed wastes tokens on every request. Files: `.clinerules` 2. State the commands explicitly The exact test command, the exact build command, and the package manager. An agent guessing between npm and pnpm wastes a minute and a half of your attention every time. Files: `.clinerules` 3. Prove a rule fires and prove it stops Pick one rule, run a task that would violate it, then delete the rule and run the same task. If nothing changes, the rule was decoration. ### Done when - [ ] A fresh session follows a convention that was never in the prompt - [ ] Removing the responsible line changes the behaviour - [ ] The rules file is committed and reviewed like code - [ ] The file is short enough that you have read all of it recently ### Watch out - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. ## Phase 3 · A deny list the agent cannot talk its way past Secrets and generated noise are outside the agent's reach, by configuration rather than by hope. ### Steps 1. Write the ignore file Start from your .gitignore and add credential paths, then add large generated directories so indexing stays fast and cheap. Files: `.clineignore` 2. Test the boundary honestly Ask for an ignored file two ways: through the file tools and through a terminal command. Record what each does. Knowing the real boundary is the deliverable of this phase. 3. Move real secrets out of the tree Use a secret manager, your operating system keychain, or a file outside the repository referenced by an absolute path. Test credentials in the working tree are fine; live ones are not. ### Done when - [ ] The agent cannot read an ignored file through the file tools - [ ] A terminal read of the same file raises an approval prompt that can be refused - [ ] No live credential exists anywhere in the working tree - [ ] Indexing skips generated directories, measured by how long a fresh index takes ### Watch out - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. ## Phase 4 · Local model for the cheap work Routine tasks stop costing money and keep working without a network. ### Steps 1. Install Ollama and pull a coding model Pick a model sized for your machine's memory. A model that swaps is slower than the network you were trying to avoid. ```sh ollama pull qwen2.5-coder:7b ollama list ``` 2. Add it as a second provider Configure the extension with the local endpoint, usually http://localhost:11434. Confirm it answers before trusting it with a task. ```sh curl http://localhost:11434/api/tags ``` 3. Write down the routing rule Two lines in the README naming which task types go local. A rule you did not write down is not a rule. Files: `README.md` ### Done when - [ ] A routine task completes with networking disabled - [ ] The local run produces no provider charge - [ ] Switching between local and frontier is one action - [ ] The routing rule is written down and matches what you actually do ### Watch out - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. ## Phase 5 · Knowing what it costs Weekly spend is a number you set, not one you find out about at the end of the month. ### Steps 1. Log runs locally A small script or extension hook writing one row per task with model, tokens and estimated cost. Files: `scripts/log_run.py` 2. Reconcile against the provider Fetch the provider's usage for the same window and compare. Investigate a gap rather than adjusting your estimate to hide it. Files: `scripts/reconcile.py` 3. Set a cap and an alert A monthly cap you actually intend to honour, and a warning at a fraction of it. Providers also offer their own spend limits; set those too, as a backstop. ### Done when - [ ] The weekly total is within a small margin of the provider dashboard - [ ] Crossing the warning threshold produces a visible alert - [ ] Per-model breakdown shows the local model contributing no cost - [ ] You can state the monthly figure and compare it to the subscription ### Watch out - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. ## Not in this build - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. ## After v1, if you want it - A shared rules file per repository so conventions travel with the project - Routing longer agent runs to a cheaper model and comparing the diff quality - A monthly review comparing your actual spend to the seat price you left ===== .env.example ===== # Copy to .env and fill in. Never commit .env; this file documents it. # Optional · secret. Your provider console. Prefer the editor's secret storage over an environment variable, and never a committed file. ANTHROPIC_API_KEY=sk-ant-... # Optional. Where the local model server listens. The default is fine unless you moved it. OLLAMA_HOST=http://localhost:11434 # Required. The cap you choose. Mirror it as a hard spend limit in the provider dashboard so a runaway loop cannot outrun your own alert. AGENT_MONTHLY_CAP_USD=40 # Required. Where per-task cost rows are written. Local only; it contains your usage patterns. RUN_LOG_PATH=~/.local/share/agent/runs.sqlite
You are building a production product version of Cursor. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Cursor · product brief ## Problem You can assemble VS Code plus open-source agents, but Cursor's moat is editor-native agent UX, model routing, cloud agents, context handling, and rapid product iteration. ## Product outcome A setup a colleague can adopt from a document and a clone, where keys never enter the repository, the agent cannot casually read secrets, routine work runs locally for nothing, and the monthly cost is a number that was decided rather than discovered. ## Target user A builder who needs a maintainable product foundation, not a one-off demo. ## Required capabilities - VS Code-compatible editor - LLM API - repo indexer - terminal/tool permissions - optional remote agent runtime ## Explicit non-goals for v1 - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. - native composer/agent UX - model routing/credits - cloud agents - editor polish - extensions compatibility - team features ## Success criteria - A full git history scan finds no credential - The pre-commit secret hook is proved to fire on a fake key - The ignore list is tested through both file tools and a terminal read - The weekly cost report reconciles with the provider dashboard - The setup document has been followed by someone else, start to finish ===== BRIEF.md ===== # Build brief · Cursor The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me an agentic coding setup in an editor you control, with your own model keys and your own spending limits to replace Cursor. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. ### Rule zero Do not write an editor and do not write an agent loop. Both already exist, both are harder than they look, and neither is what you are actually missing. Assemble a real editor with a real open-source agent extension, then spend your effort on the parts that are genuinely yours: which model runs which task, what the agent is allowed to touch, and what it costs you per week. One note on the landscape, checked in September 2026: Continue was acquired by Cursor and its repository is archived and read-only, with the last release in June 2026. Do not build on it. Cline is the actively maintained open-source agent extension and is what this build uses. ### Stack (fixed, do not substitute) - Editor: VS Code, or VSCodium if you want the telemetry-free build · the extension surface is the same and the whole point is that the editor is replaceable - Agent: Cline, Apache 2.0, installed from the extension marketplace · actively maintained, brings your own key, and every file write and terminal command passes an approval gate - Frontier model: Claude or another provider through your own API key · you pay per token at cost instead of paying for a seat and a credit allowance you cannot see - Local model: Ollama running a small coding model · the cheap tasks stop costing anything and keep working with no network - Cost control: Provider usage endpoints polled into a small local table · a subscription hides spend behind a monthly number; keys make it visible, but only if you look ### Data model (create this before Phase 1) - .clinerules · the project rules the agent reads every session, committed to the repository - .clineignore · paths the agent must never read, starting with .env and any credential directory - runs(id, started_at, task, provider, model, input_tokens, output_tokens, cost_usd) · your own record, because provider dashboards aggregate and you want per-task - budget(month, cap_usd, spent_usd) · the number you refuse to exceed - Keep the two dotfiles in the repository and the two tables local; the rules are shared, the spending is yours. ### Phase 1 · Editor, agent and the first real task Build: Install VS Code or VSCodium and the Cline extension. Add one provider key. Give it a small real task in a scratch repository: add a function and a test, then run the test. Watch the approval prompts and do not turn them off. Trap: The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. Done when: The agent creates a file, edits it, runs the test suite and reports the result, and each write and command asked first. Revoking the API key makes the agent fail with a clear authentication error rather than silently doing nothing. Do not build yet: No local model, no rules file, no cost tracking. One working agent task. ### Phase 2 · Project rules that survive the session Build: Write .clinerules and commit it. Put in the things you correct twice: the test command, the package manager, the formatting rules, which directories are generated, and the house conventions a newcomer would get wrong. Keep it short enough to stay true. Trap: A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. Done when: A fresh session in the repository follows a convention you never mentioned in the prompt, and you can point at the line in the rules file that caused it. Deliberately removing that line makes the behaviour go away. Do not build yet: No cost tracking and no local model yet. ### Phase 3 · A deny list the agent cannot talk its way past Build: Write .clineignore covering .env and every variant, credential directories, key files, node_modules, build output and anything large and generated. Then verify by asking the agent directly for the contents of an ignored file and confirming it cannot produce it. Trap: An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. Done when: Asking the agent to print the contents of .env does not produce them through the file tools. Asking it to cat the same file produces an approval prompt you can refuse, and refusing it leaves the secret unread. A grep of the repository finds no live credential in the first place. Do not build yet: No local model or cost reporting yet. ### Phase 4 · Local model for the cheap work Build: Install Ollama, pull a small coding model, and add it as a second provider in the extension. Decide which tasks route to it: commit messages, renames, docstrings, simple refactors. Keep the frontier model for anything needing real reasoning. Trap: A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. Done when: A commit message task completes with the network disconnected. The same task against the frontier model is not billed, verified in the run table from Phase 5 or in the provider dashboard. Switching providers takes one action in the extension and does not require reconfiguring the project. Do not build yet: No cost reporting yet, which is the next phase. ### Phase 5 · Knowing what it costs Build: Record every run locally with tokens and estimated cost, and pull the provider's own usage figures on a schedule to reconcile. Set a monthly cap and a threshold that warns you before you reach it. Compare the total against the subscription you left behind. Trap: Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. Done when: A weekly report shows spend per day and per model, and its total is within a small margin of the provider dashboard for the same window. Crossing the warning threshold produces a visible alert. You can state, with a number, whether this setup costs more or less than the subscription it replaced. Do not build yet: Team configuration is the product phase. ### Phase 6 · Sharing the setup without sharing the keys Build: Commit the rules file, the ignore file and a setup document. Keep every key out of the repository and out of the shell history. Add a pre-commit secret scan so the mistake is caught by a machine rather than in review. Trap: A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is. Done when: A fresh clone plus the setup document gets a colleague to a working agent without anyone sending a key over chat. A deliberate test commit containing a fake key is blocked by the pre-commit hook. A scan of the full git history finds no credential. Do not build yet: Nothing after this. ### Out of scope (and why) - The editor itself. Cursor's tab completion, its inline diff presentation and the way its agent surfaces work are the product, and reproducing that experience is a company, not a weekend. - Model routing that Cursor does for you. You are now the router, which is why the routing rule has to be written down. - Cloud agents that run without your machine on. That is infrastructure with a bill attached. - Anything proprietary about how Cursor indexes a repository, which is a real engineering asset and not something a configuration file replaces. ### README must contain - Which editor and which extension, with the note that Continue is archived as of June 2026 and should not be adopted - Where keys are stored and the explicit rule that they never enter the repository - The task routing rule between the local and frontier models - The monthly cost cap and where the weekly report comes from - What the ignore list does and does not prevent, including the terminal caveat ===== ARCHITECTURE.md ===== # Architecture · Cursor ## Stack | Part | Choice | Why | | --- | --- | --- | | Editor | VS Code, or VSCodium if you want the telemetry-free build | the extension surface is the same and the whole point is that the editor is replaceable | | Agent | Cline, Apache 2.0, installed from the extension marketplace | actively maintained, brings your own key, and every file write and terminal command passes an approval gate | | Frontier model | Claude or another provider through your own API key | you pay per token at cost instead of paying for a seat and a credit allowance you cannot see | | Local model | Ollama running a small coding model | the cheap tasks stop costing anything and keep working with no network | | Cost control | Provider usage endpoints polled into a small local table | a subscription hides spend behind a monthly number; keys make it visible, but only if you look | ## Modules Each module has one owner concern and a documented way to replace it. | Module | Owns | How to replace it | | --- | --- | --- | | Editor | The interface, extensions and secret storage. | VS Code and VSCodium are interchangeable here, and Cline also runs in several other hosts. Nothing in this build depends on which you chose. | | Agent | The plan and act loop, tool calls and approval gates. | If Cline is ever archived the way Continue was, the rules file and ignore file are the assets that carry over. Keep project intent in those files rather than in the extension's own settings. | | Providers | Which model answers which task. | Keys are per provider and the extension holds several at once, so swapping is a settings change, not a migration. | | Boundaries | The ignore list and the approval policy. | This is the part you should never loosen for convenience. Revisit it when the agent gains capabilities, not when it gets annoying. | | Cost | Run logging, reconciliation and the cap. | The reconcile script is provider specific and will need rewriting per provider. The runs table shape does not change. | ## Configuration Every runtime setting is an environment variable documented in `.env.example`, validated at startup, with a safe local default wherever one exists. - `ANTHROPIC_API_KEY` · optional, secret · Your provider console. Prefer the editor's secret storage over an environment variable, and never a committed file. - `OLLAMA_HOST` · optional · Where the local model server listens. The default is fine unless you moved it. - `AGENT_MONTHLY_CAP_USD` · required · The cap you choose. Mirror it as a hard spend limit in the provider dashboard so a runaway loop cannot outrun your own alert. - `RUN_LOG_PATH` · required · Where per-task cost rows are written. Local only; it contains your usage patterns. ## Production baseline - Security: least privilege, input validation at every boundary, secret redaction in logs, rate limits on abuse-prone paths, no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore procedures that have been exercised. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, timeouts. - Observability: structured logs with request or operation ids, an error-tracking hook, and health and readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, one end-to-end test of the critical path. ## Decision records For each dependency in the stack table, keep a short note: why it was chosen, its failure mode, and how it is replaced. Do not add infrastructure until a requirement in `PRODUCT.md` justifies it. ===== AGENTS.md ===== # Agent instructions · Cursor product build - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. The stack is fixed: VS Code, or VSCodium if you want the telemetry-free build, Cline, Apache 2.0, installed from the extension marketplace, Claude or another provider through your own API key, Ollama running a small coding model, Provider usage endpoints polled into a small local table. - Implement milestone by milestone from `MILESTONES.md`; keep each change reviewable and leave the application runnable at every commit. - Treat authentication, payments, encryption, imports, webhooks and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a check pass. - Put every external service behind an interface with a deterministic fake for tests. - Add migrations and rollback or recovery notes for every persistent data change. - Log useful operational context without credentials, tokens, passwords or personal data. - Update documentation and run every check before completing a milestone. ## Known traps - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. - A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is. ===== MILESTONES.md ===== # Delivery milestones · Cursor Estimated effort: **weekend** for the indie phases; the production-only milestones add the trust and operability layer. ## M1 · Editor, agent and the first real task An agent edits a file and runs a test in your repository, and you approved every action it took. ### Steps 1. Install the editor and the extension VS Code from code.visualstudio.com, or VSCodium from vscodium.com for a build without Microsoft telemetry. Install Cline from the extension marketplace inside the editor. 2. Add one provider key Paste the key into the extension settings. It is stored by the editor's secret storage rather than in your repository, which is where it must stay. 3. Run a real task and watch every prompt Ask for a small function plus a test in a scratch repository, then ask it to run the tests. Read what each approval prompt is actually asking before you click it. ### Done when - [ ] The agent writes a file and runs the test suite in your repository - [ ] Every file write and terminal command presented an approval prompt - [ ] The key is not present anywhere in the repository, checked with a grep - [ ] Revoking the key produces a clear authentication error ### Watch out - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. ## M2 · Project rules that survive the session The agent starts every session knowing your conventions, so you stop repeating them. ### Steps 1. Write the rules file from real corrections Go through your last few sessions and write down what you had to say twice. That list is the rules file. Inventing rules you have not needed wastes tokens on every request. Files: `.clinerules` 2. State the commands explicitly The exact test command, the exact build command, and the package manager. An agent guessing between npm and pnpm wastes a minute and a half of your attention every time. Files: `.clinerules` 3. Prove a rule fires and prove it stops Pick one rule, run a task that would violate it, then delete the rule and run the same task. If nothing changes, the rule was decoration. ### Done when - [ ] A fresh session follows a convention that was never in the prompt - [ ] Removing the responsible line changes the behaviour - [ ] The rules file is committed and reviewed like code - [ ] The file is short enough that you have read all of it recently ### Watch out - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. ## M3 · A deny list the agent cannot talk its way past Secrets and generated noise are outside the agent's reach, by configuration rather than by hope. ### Steps 1. Write the ignore file Start from your .gitignore and add credential paths, then add large generated directories so indexing stays fast and cheap. Files: `.clineignore` 2. Test the boundary honestly Ask for an ignored file two ways: through the file tools and through a terminal command. Record what each does. Knowing the real boundary is the deliverable of this phase. 3. Move real secrets out of the tree Use a secret manager, your operating system keychain, or a file outside the repository referenced by an absolute path. Test credentials in the working tree are fine; live ones are not. ### Done when - [ ] The agent cannot read an ignored file through the file tools - [ ] A terminal read of the same file raises an approval prompt that can be refused - [ ] No live credential exists anywhere in the working tree - [ ] Indexing skips generated directories, measured by how long a fresh index takes ### Watch out - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. ## M4 · Local model for the cheap work Routine tasks stop costing money and keep working without a network. ### Steps 1. Install Ollama and pull a coding model Pick a model sized for your machine's memory. A model that swaps is slower than the network you were trying to avoid. ```sh ollama pull qwen2.5-coder:7b ollama list ``` 2. Add it as a second provider Configure the extension with the local endpoint, usually http://localhost:11434. Confirm it answers before trusting it with a task. ```sh curl http://localhost:11434/api/tags ``` 3. Write down the routing rule Two lines in the README naming which task types go local. A rule you did not write down is not a rule. Files: `README.md` ### Done when - [ ] A routine task completes with networking disabled - [ ] The local run produces no provider charge - [ ] Switching between local and frontier is one action - [ ] The routing rule is written down and matches what you actually do ### Watch out - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. ## M5 · Knowing what it costs Weekly spend is a number you set, not one you find out about at the end of the month. ### Steps 1. Log runs locally A small script or extension hook writing one row per task with model, tokens and estimated cost. Files: `scripts/log_run.py` 2. Reconcile against the provider Fetch the provider's usage for the same window and compare. Investigate a gap rather than adjusting your estimate to hide it. Files: `scripts/reconcile.py` 3. Set a cap and an alert A monthly cap you actually intend to honour, and a warning at a fraction of it. Providers also offer their own spend limits; set those too, as a backstop. ### Done when - [ ] The weekly total is within a small margin of the provider dashboard - [ ] Crossing the warning threshold produces a visible alert - [ ] Per-model breakdown shows the local model contributing no cost - [ ] You can state the monthly figure and compare it to the subscription ### Watch out - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. ## M6 · Sharing the setup without sharing the keys (production only) A colleague can adopt this in an afternoon, and nobody's key ends up in the repository. ### Steps 1. Write the setup document Editor, extension, which provider, where to get a key, and the routing rule. Half a page, not a wiki. Files: `docs/agent-setup.md` 2. Add a secret scanner to pre-commit gitleaks or a similar tool run as a hook. Test it with a fake key to be sure it actually fires. Files: `.githooks/pre-commit` ```sh gitleaks protect --staged ``` 3. Scan the existing history Run the scanner over the whole history, not just the working tree. If it finds something, rotate that credential today and treat removal as secondary. ```sh gitleaks detect --source . ``` ### Done when - [ ] A fresh clone and the setup document produce a working agent - [ ] A test commit with a fake key is blocked by the hook - [ ] A full history scan finds no credential - [ ] The rules and ignore files are reviewed in pull requests like any other code ### Watch out - A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is. ===== OPERATIONS.md ===== # Operations · Cursor ## Backup The rules and ignore files are in the repository and backed up with it. The run log is local and worth keeping only for the cost history; losing it costs you a chart, not your work. ## Restore A fresh machine needs the editor, the extension, one key and a clone. That is the whole restore, and it is worth timing once so the setup document is honest. Do a restore drill before the first real user, and write the date here when it passes. ## Monitoring The weekly cost report is the monitoring. Reconcile against the provider rather than trusting local arithmetic, and treat a gap as a signal rather than rounding. ## Incident checklist If a key leaks, rotate it at the provider immediately, then clean the history. If the agent makes a destructive change, git is the undo; work on a branch and commit often enough that this is true. 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified backup when needed. 5. Document the root cause, the remediation and the regression test. ## Release gate - [ ] A full git history scan finds no credential - [ ] The pre-commit secret hook is proved to fire on a fake key - [ ] The ignore list is tested through both file tools and a terminal read - [ ] The weekly cost report reconciles with the provider dashboard - [ ] The setup document has been followed by someone else, start to finish ## Launch constraint Do not market omitted Cursor capabilities as implemented. The non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered. ===== .env.example ===== # Copy to .env and fill in. Never commit .env; this file documents it. # Optional · secret. Your provider console. Prefer the editor's secret storage over an environment variable, and never a committed file. ANTHROPIC_API_KEY=sk-ant-... # Optional. Where the local model server listens. The default is fine unless you moved it. OLLAMA_HOST=http://localhost:11434 # Required. The cap you choose. Mirror it as a hard spend limit in the provider dashboard so a runaway loop cannot outrun your own alert. AGENT_MONTHLY_CAP_USD=40 # Required. Where per-task cost rows are written. Local only; it contains your usage patterns. RUN_LOG_PATH=~/.local/share/agent/runs.sqlite
README.md
# Cursor · indie build VS Code or VSCodium running Cline with your own provider keys, a project rules file that survives across sessions, a deny list that keeps the agent away from secrets, a local model for the cheap tasks, and a weekly cost report so the bill is a number you chose rather than one you discover. Estimated effort: **weekend**. Work `BUILD_PLAN.md` top to bottom · every phase ends in a check that has to pass before the next one starts. ## Stack | Part | Choice | Why | | --- | --- | --- | | Editor | VS Code, or VSCodium if you want the telemetry-free build | the extension surface is the same and the whole point is that the editor is replaceable | | Agent | Cline, Apache 2.0, installed from the extension marketplace | actively maintained, brings your own key, and every file write and terminal command passes an approval gate | | Frontier model | Claude or another provider through your own API key | you pay per token at cost instead of paying for a seat and a credit allowance you cannot see | | Local model | Ollama running a small coding model | the cheap tasks stop costing anything and keep working with no network | | Cost control | Provider usage endpoints polled into a small local table | a subscription hides spend behind a monthly number; keys make it visible, but only if you look | ## Before you start Have every one of these ready. The plan assumes them from step one. - [ ] **VS Code or VSCodium** · free - Why: Hosts the agent extension. Everything else assumes it. - Get it: code.visualstudio.com for VS Code, or vscodium.com for a build with Microsoft telemetry and branding removed. Either works. - Verify: The editor opens your project folder and the extension marketplace is reachable - [ ] **The Cline extension** · free and Apache 2.0; you pay your model provider, not the extension - Why: It is the agent. Continue, which older guides recommend, was acquired by Cursor and its repository has been archived and read-only since June 2026. - Get it: Search for Cline in the editor's extension marketplace and install it. Open its sidebar to confirm it loaded. - Verify: The Cline sidebar opens and asks for a provider - [ ] **An API key from a model provider** · pay per token, typically a few cents per small task and more for long agent runs; set the provider spend limit on day one - Why: Without it the agent has nothing to think with. This is also the line item that replaces the subscription. - Get it: Create an account with your chosen provider, add a payment method, and create an API key in their console. Set a spending limit in the provider dashboard at the same time, before you make a single request. - Verify: A first small task completes and the provider dashboard shows the usage - [ ] **Ollama with a small coding model** (optional) · free, but it uses your own memory and battery - Why: Phase 4 only. It is what makes routine tasks free and offline. - Get it: Download from ollama.com, then pull a coding model sized for your memory. A seven billion parameter model wants roughly eight gigabytes free. - Verify: ollama list shows the model and curl http://localhost:11434/api/tags responds - [ ] **A secret scanner such as gitleaks** (optional) · free - Why: Product phase only. It is the machine that catches the key you were about to commit. - Get it: brew install gitleaks, or download a release binary from its GitHub project, then wire it into a pre-commit hook. - Verify: A deliberate commit containing a fake key is blocked ## Quick start ```sh ollama pull qwen2.5-coder:7b ollama list ``` Then copy `.env.example` to `.env` and fill in the values it documents. ## Honest limits This build deliberately does not replace: - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. - native composer/agent UX - model routing/credits - cloud agents - editor polish - extensions compatibility - team features If one of those is essential to you, that is the reason to keep paying for Cursor, and the README should say so rather than pretend.
BRIEF.md
# Build brief · Cursor The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me an agentic coding setup in an editor you control, with your own model keys and your own spending limits to replace Cursor. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. ### Rule zero Do not write an editor and do not write an agent loop. Both already exist, both are harder than they look, and neither is what you are actually missing. Assemble a real editor with a real open-source agent extension, then spend your effort on the parts that are genuinely yours: which model runs which task, what the agent is allowed to touch, and what it costs you per week. One note on the landscape, checked in September 2026: Continue was acquired by Cursor and its repository is archived and read-only, with the last release in June 2026. Do not build on it. Cline is the actively maintained open-source agent extension and is what this build uses. ### Stack (fixed, do not substitute) - Editor: VS Code, or VSCodium if you want the telemetry-free build · the extension surface is the same and the whole point is that the editor is replaceable - Agent: Cline, Apache 2.0, installed from the extension marketplace · actively maintained, brings your own key, and every file write and terminal command passes an approval gate - Frontier model: Claude or another provider through your own API key · you pay per token at cost instead of paying for a seat and a credit allowance you cannot see - Local model: Ollama running a small coding model · the cheap tasks stop costing anything and keep working with no network - Cost control: Provider usage endpoints polled into a small local table · a subscription hides spend behind a monthly number; keys make it visible, but only if you look ### Data model (create this before Phase 1) - .clinerules · the project rules the agent reads every session, committed to the repository - .clineignore · paths the agent must never read, starting with .env and any credential directory - runs(id, started_at, task, provider, model, input_tokens, output_tokens, cost_usd) · your own record, because provider dashboards aggregate and you want per-task - budget(month, cap_usd, spent_usd) · the number you refuse to exceed - Keep the two dotfiles in the repository and the two tables local; the rules are shared, the spending is yours. ### Phase 1 · Editor, agent and the first real task Build: Install VS Code or VSCodium and the Cline extension. Add one provider key. Give it a small real task in a scratch repository: add a function and a test, then run the test. Watch the approval prompts and do not turn them off. Trap: The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. Done when: The agent creates a file, edits it, runs the test suite and reports the result, and each write and command asked first. Revoking the API key makes the agent fail with a clear authentication error rather than silently doing nothing. Do not build yet: No local model, no rules file, no cost tracking. One working agent task. ### Phase 2 · Project rules that survive the session Build: Write .clinerules and commit it. Put in the things you correct twice: the test command, the package manager, the formatting rules, which directories are generated, and the house conventions a newcomer would get wrong. Keep it short enough to stay true. Trap: A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. Done when: A fresh session in the repository follows a convention you never mentioned in the prompt, and you can point at the line in the rules file that caused it. Deliberately removing that line makes the behaviour go away. Do not build yet: No cost tracking and no local model yet. ### Phase 3 · A deny list the agent cannot talk its way past Build: Write .clineignore covering .env and every variant, credential directories, key files, node_modules, build output and anything large and generated. Then verify by asking the agent directly for the contents of an ignored file and confirming it cannot produce it. Trap: An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. Done when: Asking the agent to print the contents of .env does not produce them through the file tools. Asking it to cat the same file produces an approval prompt you can refuse, and refusing it leaves the secret unread. A grep of the repository finds no live credential in the first place. Do not build yet: No local model or cost reporting yet. ### Phase 4 · Local model for the cheap work Build: Install Ollama, pull a small coding model, and add it as a second provider in the extension. Decide which tasks route to it: commit messages, renames, docstrings, simple refactors. Keep the frontier model for anything needing real reasoning. Trap: A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. Done when: A commit message task completes with the network disconnected. The same task against the frontier model is not billed, verified in the run table from Phase 5 or in the provider dashboard. Switching providers takes one action in the extension and does not require reconfiguring the project. Do not build yet: No cost reporting yet, which is the next phase. ### Phase 5 · Knowing what it costs Build: Record every run locally with tokens and estimated cost, and pull the provider's own usage figures on a schedule to reconcile. Set a monthly cap and a threshold that warns you before you reach it. Compare the total against the subscription you left behind. Trap: Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. Done when: A weekly report shows spend per day and per model, and its total is within a small margin of the provider dashboard for the same window. Crossing the warning threshold produces a visible alert. You can state, with a number, whether this setup costs more or less than the subscription it replaced. Do not build yet: Team configuration is the product phase. ### Phase 6 · Sharing the setup without sharing the keys Build: Commit the rules file, the ignore file and a setup document. Keep every key out of the repository and out of the shell history. Add a pre-commit secret scan so the mistake is caught by a machine rather than in review. Trap: A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is. Done when: A fresh clone plus the setup document gets a colleague to a working agent without anyone sending a key over chat. A deliberate test commit containing a fake key is blocked by the pre-commit hook. A scan of the full git history finds no credential. Do not build yet: Nothing after this. ### Out of scope (and why) - The editor itself. Cursor's tab completion, its inline diff presentation and the way its agent surfaces work are the product, and reproducing that experience is a company, not a weekend. - Model routing that Cursor does for you. You are now the router, which is why the routing rule has to be written down. - Cloud agents that run without your machine on. That is infrastructure with a bill attached. - Anything proprietary about how Cursor indexes a repository, which is a real engineering asset and not something a configuration file replaces. ### README must contain - Which editor and which extension, with the note that Continue is archived as of June 2026 and should not be adopted - Where keys are stored and the explicit rule that they never enter the repository - The task routing rule between the local and frontier models - The monthly cost cap and where the weekly report comes from - What the ignore list does and does not prevent, including the terminal caveat
AGENTS.md
# Agent instructions · Cursor indie build - Read `README.md` and `BUILD_PLAN.md` before writing code. The stack is fixed: VS Code, or VSCodium if you want the telemetry-free build, Cline, Apache 2.0, installed from the extension marketplace, Claude or another provider through your own API key, Ollama running a small coding model, Provider usage endpoints polled into a small local table. Do not substitute. - Work one phase at a time, in order. Do not start a phase until every "Done when" item of the previous one passes. - Prefer the fewest moving parts that satisfy the step. No frameworks, services or dependencies the plan does not name. - Secrets live in `.env`, never in source or logs. Keep `.env.example` current when a variable is introduced. - Do not invent cryptography, security guarantees, APIs or compliance claims. - Add a focused test for every destructive, security-sensitive or data-loss path the plan names. - Run the project checks before declaring a phase complete, and record any deliberate shortcut in the README under "Tradeoffs". ## Known traps - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic.
BUILD_PLAN.md
# Build plan · Cursor VS Code or VSCodium running Cline with your own provider keys, a project rules file that survives across sessions, a deny list that keeps the agent away from secrets, a local model for the cheap tasks, and a weekly cost report so the bill is a number you chose rather than one you discover. Phases are in dependency order. Each ends in a "Done when" list; treat an unticked item as a blocker, not a note. ## Phase 1 · Editor, agent and the first real task An agent edits a file and runs a test in your repository, and you approved every action it took. ### Steps 1. Install the editor and the extension VS Code from code.visualstudio.com, or VSCodium from vscodium.com for a build without Microsoft telemetry. Install Cline from the extension marketplace inside the editor. 2. Add one provider key Paste the key into the extension settings. It is stored by the editor's secret storage rather than in your repository, which is where it must stay. 3. Run a real task and watch every prompt Ask for a small function plus a test in a scratch repository, then ask it to run the tests. Read what each approval prompt is actually asking before you click it. ### Done when - [ ] The agent writes a file and runs the test suite in your repository - [ ] Every file write and terminal command presented an approval prompt - [ ] The key is not present anywhere in the repository, checked with a grep - [ ] Revoking the key produces a clear authentication error ### Watch out - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. ## Phase 2 · Project rules that survive the session The agent starts every session knowing your conventions, so you stop repeating them. ### Steps 1. Write the rules file from real corrections Go through your last few sessions and write down what you had to say twice. That list is the rules file. Inventing rules you have not needed wastes tokens on every request. Files: `.clinerules` 2. State the commands explicitly The exact test command, the exact build command, and the package manager. An agent guessing between npm and pnpm wastes a minute and a half of your attention every time. Files: `.clinerules` 3. Prove a rule fires and prove it stops Pick one rule, run a task that would violate it, then delete the rule and run the same task. If nothing changes, the rule was decoration. ### Done when - [ ] A fresh session follows a convention that was never in the prompt - [ ] Removing the responsible line changes the behaviour - [ ] The rules file is committed and reviewed like code - [ ] The file is short enough that you have read all of it recently ### Watch out - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. ## Phase 3 · A deny list the agent cannot talk its way past Secrets and generated noise are outside the agent's reach, by configuration rather than by hope. ### Steps 1. Write the ignore file Start from your .gitignore and add credential paths, then add large generated directories so indexing stays fast and cheap. Files: `.clineignore` 2. Test the boundary honestly Ask for an ignored file two ways: through the file tools and through a terminal command. Record what each does. Knowing the real boundary is the deliverable of this phase. 3. Move real secrets out of the tree Use a secret manager, your operating system keychain, or a file outside the repository referenced by an absolute path. Test credentials in the working tree are fine; live ones are not. ### Done when - [ ] The agent cannot read an ignored file through the file tools - [ ] A terminal read of the same file raises an approval prompt that can be refused - [ ] No live credential exists anywhere in the working tree - [ ] Indexing skips generated directories, measured by how long a fresh index takes ### Watch out - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. ## Phase 4 · Local model for the cheap work Routine tasks stop costing money and keep working without a network. ### Steps 1. Install Ollama and pull a coding model Pick a model sized for your machine's memory. A model that swaps is slower than the network you were trying to avoid. ```sh ollama pull qwen2.5-coder:7b ollama list ``` 2. Add it as a second provider Configure the extension with the local endpoint, usually http://localhost:11434. Confirm it answers before trusting it with a task. ```sh curl http://localhost:11434/api/tags ``` 3. Write down the routing rule Two lines in the README naming which task types go local. A rule you did not write down is not a rule. Files: `README.md` ### Done when - [ ] A routine task completes with networking disabled - [ ] The local run produces no provider charge - [ ] Switching between local and frontier is one action - [ ] The routing rule is written down and matches what you actually do ### Watch out - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. ## Phase 5 · Knowing what it costs Weekly spend is a number you set, not one you find out about at the end of the month. ### Steps 1. Log runs locally A small script or extension hook writing one row per task with model, tokens and estimated cost. Files: `scripts/log_run.py` 2. Reconcile against the provider Fetch the provider's usage for the same window and compare. Investigate a gap rather than adjusting your estimate to hide it. Files: `scripts/reconcile.py` 3. Set a cap and an alert A monthly cap you actually intend to honour, and a warning at a fraction of it. Providers also offer their own spend limits; set those too, as a backstop. ### Done when - [ ] The weekly total is within a small margin of the provider dashboard - [ ] Crossing the warning threshold produces a visible alert - [ ] Per-model breakdown shows the local model contributing no cost - [ ] You can state the monthly figure and compare it to the subscription ### Watch out - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. ## Not in this build - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. ## After v1, if you want it - A shared rules file per repository so conventions travel with the project - Routing longer agent runs to a cheaper model and comparing the diff quality - A monthly review comparing your actual spend to the seat price you left
.env.example
# Copy to .env and fill in. Never commit .env; this file documents it. # Optional · secret. Your provider console. Prefer the editor's secret storage over an environment variable, and never a committed file. ANTHROPIC_API_KEY=sk-ant-... # Optional. Where the local model server listens. The default is fine unless you moved it. OLLAMA_HOST=http://localhost:11434 # Required. The cap you choose. Mirror it as a hard spend limit in the provider dashboard so a runaway loop cannot outrun your own alert. AGENT_MONTHLY_CAP_USD=40 # Required. Where per-task cost rows are written. Local only; it contains your usage patterns. RUN_LOG_PATH=~/.local/share/agent/runs.sqlite
PRODUCT.md
# Cursor · product brief ## Problem You can assemble VS Code plus open-source agents, but Cursor's moat is editor-native agent UX, model routing, cloud agents, context handling, and rapid product iteration. ## Product outcome A setup a colleague can adopt from a document and a clone, where keys never enter the repository, the agent cannot casually read secrets, routine work runs locally for nothing, and the monthly cost is a number that was decided rather than discovered. ## Target user A builder who needs a maintainable product foundation, not a one-off demo. ## Required capabilities - VS Code-compatible editor - LLM API - repo indexer - terminal/tool permissions - optional remote agent runtime ## Explicit non-goals for v1 - Cursor's own editor experience, which is the thing most people are actually paying for. - Managed model routing and the credit allowance behind it. - Cloud agents that keep working when your laptop is closed. - Whatever Cursor's repository indexing does that a local index does not. - native composer/agent UX - model routing/credits - cloud agents - editor polish - extensions compatibility - team features ## Success criteria - A full git history scan finds no credential - The pre-commit secret hook is proved to fire on a fake key - The ignore list is tested through both file tools and a terminal read - The weekly cost report reconciles with the provider dashboard - The setup document has been followed by someone else, start to finish
BRIEF.md
# Build brief · Cursor The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me an agentic coding setup in an editor you control, with your own model keys and your own spending limits to replace Cursor. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. ### Rule zero Do not write an editor and do not write an agent loop. Both already exist, both are harder than they look, and neither is what you are actually missing. Assemble a real editor with a real open-source agent extension, then spend your effort on the parts that are genuinely yours: which model runs which task, what the agent is allowed to touch, and what it costs you per week. One note on the landscape, checked in September 2026: Continue was acquired by Cursor and its repository is archived and read-only, with the last release in June 2026. Do not build on it. Cline is the actively maintained open-source agent extension and is what this build uses. ### Stack (fixed, do not substitute) - Editor: VS Code, or VSCodium if you want the telemetry-free build · the extension surface is the same and the whole point is that the editor is replaceable - Agent: Cline, Apache 2.0, installed from the extension marketplace · actively maintained, brings your own key, and every file write and terminal command passes an approval gate - Frontier model: Claude or another provider through your own API key · you pay per token at cost instead of paying for a seat and a credit allowance you cannot see - Local model: Ollama running a small coding model · the cheap tasks stop costing anything and keep working with no network - Cost control: Provider usage endpoints polled into a small local table · a subscription hides spend behind a monthly number; keys make it visible, but only if you look ### Data model (create this before Phase 1) - .clinerules · the project rules the agent reads every session, committed to the repository - .clineignore · paths the agent must never read, starting with .env and any credential directory - runs(id, started_at, task, provider, model, input_tokens, output_tokens, cost_usd) · your own record, because provider dashboards aggregate and you want per-task - budget(month, cap_usd, spent_usd) · the number you refuse to exceed - Keep the two dotfiles in the repository and the two tables local; the rules are shared, the spending is yours. ### Phase 1 · Editor, agent and the first real task Build: Install VS Code or VSCodium and the Cline extension. Add one provider key. Give it a small real task in a scratch repository: add a function and a test, then run the test. Watch the approval prompts and do not turn them off. Trap: The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. Done when: The agent creates a file, edits it, runs the test suite and reports the result, and each write and command asked first. Revoking the API key makes the agent fail with a clear authentication error rather than silently doing nothing. Do not build yet: No local model, no rules file, no cost tracking. One working agent task. ### Phase 2 · Project rules that survive the session Build: Write .clinerules and commit it. Put in the things you correct twice: the test command, the package manager, the formatting rules, which directories are generated, and the house conventions a newcomer would get wrong. Keep it short enough to stay true. Trap: A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. Done when: A fresh session in the repository follows a convention you never mentioned in the prompt, and you can point at the line in the rules file that caused it. Deliberately removing that line makes the behaviour go away. Do not build yet: No cost tracking and no local model yet. ### Phase 3 · A deny list the agent cannot talk its way past Build: Write .clineignore covering .env and every variant, credential directories, key files, node_modules, build output and anything large and generated. Then verify by asking the agent directly for the contents of an ignored file and confirming it cannot produce it. Trap: An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. Done when: Asking the agent to print the contents of .env does not produce them through the file tools. Asking it to cat the same file produces an approval prompt you can refuse, and refusing it leaves the secret unread. A grep of the repository finds no live credential in the first place. Do not build yet: No local model or cost reporting yet. ### Phase 4 · Local model for the cheap work Build: Install Ollama, pull a small coding model, and add it as a second provider in the extension. Decide which tasks route to it: commit messages, renames, docstrings, simple refactors. Keep the frontier model for anything needing real reasoning. Trap: A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. Done when: A commit message task completes with the network disconnected. The same task against the frontier model is not billed, verified in the run table from Phase 5 or in the provider dashboard. Switching providers takes one action in the extension and does not require reconfiguring the project. Do not build yet: No cost reporting yet, which is the next phase. ### Phase 5 · Knowing what it costs Build: Record every run locally with tokens and estimated cost, and pull the provider's own usage figures on a schedule to reconcile. Set a monthly cap and a threshold that warns you before you reach it. Compare the total against the subscription you left behind. Trap: Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. Done when: A weekly report shows spend per day and per model, and its total is within a small margin of the provider dashboard for the same window. Crossing the warning threshold produces a visible alert. You can state, with a number, whether this setup costs more or less than the subscription it replaced. Do not build yet: Team configuration is the product phase. ### Phase 6 · Sharing the setup without sharing the keys Build: Commit the rules file, the ignore file and a setup document. Keep every key out of the repository and out of the shell history. Add a pre-commit secret scan so the mistake is caught by a machine rather than in review. Trap: A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is. Done when: A fresh clone plus the setup document gets a colleague to a working agent without anyone sending a key over chat. A deliberate test commit containing a fake key is blocked by the pre-commit hook. A scan of the full git history finds no credential. Do not build yet: Nothing after this. ### Out of scope (and why) - The editor itself. Cursor's tab completion, its inline diff presentation and the way its agent surfaces work are the product, and reproducing that experience is a company, not a weekend. - Model routing that Cursor does for you. You are now the router, which is why the routing rule has to be written down. - Cloud agents that run without your machine on. That is infrastructure with a bill attached. - Anything proprietary about how Cursor indexes a repository, which is a real engineering asset and not something a configuration file replaces. ### README must contain - Which editor and which extension, with the note that Continue is archived as of June 2026 and should not be adopted - Where keys are stored and the explicit rule that they never enter the repository - The task routing rule between the local and frontier models - The monthly cost cap and where the weekly report comes from - What the ignore list does and does not prevent, including the terminal caveat
ARCHITECTURE.md
# Architecture · Cursor ## Stack | Part | Choice | Why | | --- | --- | --- | | Editor | VS Code, or VSCodium if you want the telemetry-free build | the extension surface is the same and the whole point is that the editor is replaceable | | Agent | Cline, Apache 2.0, installed from the extension marketplace | actively maintained, brings your own key, and every file write and terminal command passes an approval gate | | Frontier model | Claude or another provider through your own API key | you pay per token at cost instead of paying for a seat and a credit allowance you cannot see | | Local model | Ollama running a small coding model | the cheap tasks stop costing anything and keep working with no network | | Cost control | Provider usage endpoints polled into a small local table | a subscription hides spend behind a monthly number; keys make it visible, but only if you look | ## Modules Each module has one owner concern and a documented way to replace it. | Module | Owns | How to replace it | | --- | --- | --- | | Editor | The interface, extensions and secret storage. | VS Code and VSCodium are interchangeable here, and Cline also runs in several other hosts. Nothing in this build depends on which you chose. | | Agent | The plan and act loop, tool calls and approval gates. | If Cline is ever archived the way Continue was, the rules file and ignore file are the assets that carry over. Keep project intent in those files rather than in the extension's own settings. | | Providers | Which model answers which task. | Keys are per provider and the extension holds several at once, so swapping is a settings change, not a migration. | | Boundaries | The ignore list and the approval policy. | This is the part you should never loosen for convenience. Revisit it when the agent gains capabilities, not when it gets annoying. | | Cost | Run logging, reconciliation and the cap. | The reconcile script is provider specific and will need rewriting per provider. The runs table shape does not change. | ## Configuration Every runtime setting is an environment variable documented in `.env.example`, validated at startup, with a safe local default wherever one exists. - `ANTHROPIC_API_KEY` · optional, secret · Your provider console. Prefer the editor's secret storage over an environment variable, and never a committed file. - `OLLAMA_HOST` · optional · Where the local model server listens. The default is fine unless you moved it. - `AGENT_MONTHLY_CAP_USD` · required · The cap you choose. Mirror it as a hard spend limit in the provider dashboard so a runaway loop cannot outrun your own alert. - `RUN_LOG_PATH` · required · Where per-task cost rows are written. Local only; it contains your usage patterns. ## Production baseline - Security: least privilege, input validation at every boundary, secret redaction in logs, rate limits on abuse-prone paths, no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore procedures that have been exercised. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, timeouts. - Observability: structured logs with request or operation ids, an error-tracking hook, and health and readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, one end-to-end test of the critical path. ## Decision records For each dependency in the stack table, keep a short note: why it was chosen, its failure mode, and how it is replaced. Do not add infrastructure until a requirement in `PRODUCT.md` justifies it.
AGENTS.md
# Agent instructions · Cursor product build - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. The stack is fixed: VS Code, or VSCodium if you want the telemetry-free build, Cline, Apache 2.0, installed from the extension marketplace, Claude or another provider through your own API key, Ollama running a small coding model, Provider usage endpoints polled into a small local table. - Implement milestone by milestone from `MILESTONES.md`; keep each change reviewable and leave the application runnable at every commit. - Treat authentication, payments, encryption, imports, webhooks and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a check pass. - Put every external service behind an interface with a deterministic fake for tests. - Add migrations and rollback or recovery notes for every persistent data change. - Log useful operational context without credentials, tokens, passwords or personal data. - Update documentation and run every check before completing a milestone. ## Known traps - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. - A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is.
MILESTONES.md
# Delivery milestones · Cursor Estimated effort: **weekend** for the indie phases; the production-only milestones add the trust and operability layer. ## M1 · Editor, agent and the first real task An agent edits a file and runs a test in your repository, and you approved every action it took. ### Steps 1. Install the editor and the extension VS Code from code.visualstudio.com, or VSCodium from vscodium.com for a build without Microsoft telemetry. Install Cline from the extension marketplace inside the editor. 2. Add one provider key Paste the key into the extension settings. It is stored by the editor's secret storage rather than in your repository, which is where it must stay. 3. Run a real task and watch every prompt Ask for a small function plus a test in a scratch repository, then ask it to run the tests. Read what each approval prompt is actually asking before you click it. ### Done when - [ ] The agent writes a file and runs the test suite in your repository - [ ] Every file write and terminal command presented an approval prompt - [ ] The key is not present anywhere in the repository, checked with a grep - [ ] Revoking the key produces a clear authentication error ### Watch out - The first instinct after ten approval prompts is to enable auto-approve for everything. Auto-approving terminal commands hands a program that reads the internet the ability to run anything as you. Approve reads freely if you like, but keep writes and commands behind a prompt until Phase 3 gives you a deny list worth trusting. ## M2 · Project rules that survive the session The agent starts every session knowing your conventions, so you stop repeating them. ### Steps 1. Write the rules file from real corrections Go through your last few sessions and write down what you had to say twice. That list is the rules file. Inventing rules you have not needed wastes tokens on every request. Files: `.clinerules` 2. State the commands explicitly The exact test command, the exact build command, and the package manager. An agent guessing between npm and pnpm wastes a minute and a half of your attention every time. Files: `.clinerules` 3. Prove a rule fires and prove it stops Pick one rule, run a task that would violate it, then delete the rule and run the same task. If nothing changes, the rule was decoration. ### Done when - [ ] A fresh session follows a convention that was never in the prompt - [ ] Removing the responsible line changes the behaviour - [ ] The rules file is committed and reviewed like code - [ ] The file is short enough that you have read all of it recently ### Watch out - A rules file that grows to four hundred lines stops being read carefully and starts being expensive on every single request, because it is prepended to the context each time. Prune it when a rule stops being violated. ## M3 · A deny list the agent cannot talk its way past Secrets and generated noise are outside the agent's reach, by configuration rather than by hope. ### Steps 1. Write the ignore file Start from your .gitignore and add credential paths, then add large generated directories so indexing stays fast and cheap. Files: `.clineignore` 2. Test the boundary honestly Ask for an ignored file two ways: through the file tools and through a terminal command. Record what each does. Knowing the real boundary is the deliverable of this phase. 3. Move real secrets out of the tree Use a secret manager, your operating system keychain, or a file outside the repository referenced by an absolute path. Test credentials in the working tree are fine; live ones are not. ### Done when - [ ] The agent cannot read an ignored file through the file tools - [ ] A terminal read of the same file raises an approval prompt that can be refused - [ ] No live credential exists anywhere in the working tree - [ ] Indexing skips generated directories, measured by how long a fresh index takes ### Watch out - An agent with terminal access can read an ignored file with cat even when the extension will not open it for indexing. The ignore list reduces accidental exposure, it does not contain a determined tool call. That is exactly why terminal approval stays on, and why real credentials should not sit in the working tree of a repository you point an agent at. ## M4 · Local model for the cheap work Routine tasks stop costing money and keep working without a network. ### Steps 1. Install Ollama and pull a coding model Pick a model sized for your machine's memory. A model that swaps is slower than the network you were trying to avoid. ```sh ollama pull qwen2.5-coder:7b ollama list ``` 2. Add it as a second provider Configure the extension with the local endpoint, usually http://localhost:11434. Confirm it answers before trusting it with a task. ```sh curl http://localhost:11434/api/tags ``` 3. Write down the routing rule Two lines in the README naming which task types go local. A rule you did not write down is not a rule. Files: `README.md` ### Done when - [ ] A routine task completes with networking disabled - [ ] The local run produces no provider charge - [ ] Switching between local and frontier is one action - [ ] The routing rule is written down and matches what you actually do ### Watch out - A small local model will confidently do a bad job of a task that needs judgement, and the failure is quiet rather than loud. Route by task type deliberately and write the routing down, rather than choosing per request and drifting toward whichever is on screen. ## M5 · Knowing what it costs Weekly spend is a number you set, not one you find out about at the end of the month. ### Steps 1. Log runs locally A small script or extension hook writing one row per task with model, tokens and estimated cost. Files: `scripts/log_run.py` 2. Reconcile against the provider Fetch the provider's usage for the same window and compare. Investigate a gap rather than adjusting your estimate to hide it. Files: `scripts/reconcile.py` 3. Set a cap and an alert A monthly cap you actually intend to honour, and a warning at a fraction of it. Providers also offer their own spend limits; set those too, as a backstop. ### Done when - [ ] The weekly total is within a small margin of the provider dashboard - [ ] Crossing the warning threshold produces a visible alert - [ ] Per-model breakdown shows the local model contributing no cost - [ ] You can state the monthly figure and compare it to the subscription ### Watch out - Estimating cost from your own token counts alone drifts, because cached input, reasoning tokens and tool overhead are priced differently and change. Reconcile against the provider's usage endpoint rather than trusting your own arithmetic. ## M6 · Sharing the setup without sharing the keys (production only) A colleague can adopt this in an afternoon, and nobody's key ends up in the repository. ### Steps 1. Write the setup document Editor, extension, which provider, where to get a key, and the routing rule. Half a page, not a wiki. Files: `docs/agent-setup.md` 2. Add a secret scanner to pre-commit gitleaks or a similar tool run as a hook. Test it with a fake key to be sure it actually fires. Files: `.githooks/pre-commit` ```sh gitleaks protect --staged ``` 3. Scan the existing history Run the scanner over the whole history, not just the working tree. If it finds something, rotate that credential today and treat removal as secondary. ```sh gitleaks detect --source . ``` ### Done when - [ ] A fresh clone and the setup document produce a working agent - [ ] A test commit with a fake key is blocked by the hook - [ ] A full history scan finds no credential - [ ] The rules and ignore files are reviewed in pull requests like any other code ### Watch out - A key pasted into a settings file that is committed once stays in the git history after you delete it. Rotate the key rather than only removing the file, because the history is public the moment the repository is.
OPERATIONS.md
# Operations · Cursor ## Backup The rules and ignore files are in the repository and backed up with it. The run log is local and worth keeping only for the cost history; losing it costs you a chart, not your work. ## Restore A fresh machine needs the editor, the extension, one key and a clone. That is the whole restore, and it is worth timing once so the setup document is honest. Do a restore drill before the first real user, and write the date here when it passes. ## Monitoring The weekly cost report is the monitoring. Reconcile against the provider rather than trusting local arithmetic, and treat a gap as a signal rather than rounding. ## Incident checklist If a key leaks, rotate it at the provider immediately, then clean the history. If the agent makes a destructive change, git is the undo; work on a branch and commit often enough that this is true. 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified backup when needed. 5. Document the root cause, the remediation and the regression test. ## Release gate - [ ] A full git history scan finds no credential - [ ] The pre-commit secret hook is proved to fire on a fake key - [ ] The ignore list is tested through both file tools and a terminal read - [ ] The weekly cost report reconciles with the provider dashboard - [ ] The setup document has been followed by someone else, start to finish ## Launch constraint Do not market omitted Cursor capabilities as implemented. The non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
.env.example
# Copy to .env and fill in. Never commit .env; this file documents it. # Optional · secret. Your provider console. Prefer the editor's secret storage over an environment variable, and never a committed file. ANTHROPIC_API_KEY=sk-ant-... # Optional. Where the local model server listens. The default is fine unless you moved it. OLLAMA_HOST=http://localhost:11434 # Required. The cap you choose. Mirror it as a hard spend limit in the provider dashboard so a runaway loop cannot outrun your own alert. AGENT_MONTHLY_CAP_USD=40 # Required. Where per-task cost rows are written. Local only; it contains your usage patterns. RUN_LOG_PATH=~/.local/share/agent/runs.sqlite
$ choose a build depth, inspect the files, then open the complete pack in your agent
They pay for speed: the agent is already in the editor with defaults that work.
xnative composer/agent UX
xmodel routing/credits
xcloud agents
xeditor polish
xextensions compatibility
xteam features
share on X ↗"I just replaced Cursor ($20/mo) with one prompt"
Don't feel like building it? These folks already made it free.
OpenCodeA fast local coding agent with no loyalty to any model vendor.open source↗
ZedA fast open editor with agents built in, not a VS Code costume.open source↗
ClineA code agent in your editor; the model bill is still yours.open source↗all 5 free alternatives to Cursor →· no votes, no pay-to-list · just what's real
Cursor pricing
| plan | monthly | annual (per mo) | what you get |
|---|---|---|---|
| hobby | $0 | $0 | Limited Agent, Chat and Tab usage with Auto; the current numeric request cap is not published. |
| start (india) | $6.81 | — | India-only entry plan; exact Agent and model-usage caps were not published on the public page. |
| pro | $20 | $16 | $20/month of included third-party 'Other Models' usage; extended Agent limits. |
| pro+ | $60 | $48 | $70/month of included Other Models usage and 3× Pro Agent limits. |
| ultra | $200 | $160 | $400/month of included Other Models usage and 20× Pro Agent limits. |
| teams standard | $40/user | $32/user | 1 paid editor seat; Standard team Agent allowance; SAML/OIDC SSO and centralized billing. |
| teams premium | $120/user | $96/user | 1 paid editor seat; 5× Teams Standard Agent allowance. |
| enterprise | custom | — | Custom seats and pooled usage; numeric limits and price are not public. |
free tierHobby is free, but Cursor publishes no numeric request allowance; it only says Agent, Chat and Tab usage is limited.
billingmonthly + annual for self-serve plans; Start is monthly-only in India; taxes excluded
hidden costsUsage is split into included pools that reset monthly without rollover; on-demand third-party model usage is billed in arrears at model/API rates. Cursor Router Cost mode is $1.25/M input tokens, $6/M output and $0.25/M cache read; Bugbot is separately usage-billed.
verified 2026-08-11 · source ↗
Is Cursor free?
The free Hobby plan includes limited agent requests; no credit card needed. Paid is Pro at $20/mo (checked 2026-08-07).
Vibecode Cursor
Kinda. The core of Cursor is buildable in a weekend with the prompt on this page, but there are real gaps: native composer/agent UX, model routing/credits. Read the honest list above before committing.
How much does Cursor cost?
Cursor costs about $20/month (Pro, checked 2026-08-07), which is $240 per year.
What do I lose by replacing Cursor?
Honestly: native composer/agent UX; model routing/credits; cloud agents; editor polish; extensions compatibility; team features. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Cursor?
Yes: OpenCode (A fast local coding agent with no loyalty to any model vendor.) Zed (A fast open editor with agents built in, not a VS Code costume.) Cline (A code agent in your editor; the model bill is still yours.) All 5 curated free alternatives are at vibecodeit.com/cursor/alternatives. The prompt is for when you want it exactly your way.