Wybór modelu w Cursorze

Wybór modelu w Cursorze to decyzja, który model wykonuje dane zadanie agenta. Zasada, której trzyma się ten serwis: zacznij od jednego mocnego modelu domyślnego, przed zmianą modelu dostrój jego wariant wysiłku, a model zmień dopiero wtedy, gdy mały benchmark zadań z repozytorium zespołu, sprawdzany jego własnymi testami, pokaże, że inny model zalicza więcej zadań taniej.

Jesteś w połowie funkcji. Plan agenta wygląda dobrze, lista modeli jest dłuższa, niż dałoby się kiedykolwiek porównać, a kolega przysięga na inny model. Wybierasz z przyzwyczajenia, agent kręci się w kółko na tym samym czerwonym teście, a miesięczny limit znika w trzecim tygodniu.

Ta strona jest dla deweloperów, którzy wybierają model do zadania w Cursorze, i dla tech leadów, którzy ustalają domyślny model zespołu i chcą go uzasadnić liczbami, a nie preferencjami. Zakłada, że masz za sobą podstawową konfigurację.

Modele w Cursorze, stan na 2026-10-12

Lista modeli Cursora zmienia się niezależnie od dostawców modeli. Według strony Cursora z modelami i cenami (stan na 2026-10-12) pula Cursor Models to Grok 4.7, Grok 4.6, Grok 4.5 i Composer 2.5, a Cursor nazywa Grok 4.7 swoim flagowym modelem. W sekcji Other Models oferuje między innymi Claude Opus 5.5, Claude Fable 5.1, Claude Sonnet 5.5, Claude Haiku 5.5, GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.6 Luna, Gemini 3.8 Flash, Gemini 3.1 Pro i Muse Spark 1.3, a starsze modele, między innymi Opus 5, Sonnet 5, Fable 5, GPT-5.5 i GPT-5.4, domyślnie ukrywa. Na liście Cursora nie ma 2026-10-12 żadnego modelu GPT-6, a Cursor nie wskazuje jednego modelu domyślnego. Rozstrzygające jest to, co pokazuje twój selektor modeli i Cursor.models.list(). Ceny i okna kontekstu modeli dostawców są w jednym miejscu serwisu: w przeglądzie modeli.

• Claude Fable 5.1 jest domyślnie wyłączony przy włączonym Privacy Mode lub w planie Enterprise, bo Anthropic przechowuje jego dane wejściowe i wyjściowe. Wymaga zgody administratora (strona Cursora o prywatności i zarządzaniu danymi).
• Auto działa na Cursor Router, który Cursor opisuje jako „the model routing system behind Auto”. Cursor Router ma tryby Cost, Balance i Intelligence i według Cursora jest dostępny tylko w planach Teams i Enterprise. Każdy tryb Auto rozlicza się po cenie katalogowej modelu, do którego trafia żądanie, a modele zewnętrzne mają dodatkowo Cursor Token Rate. Stawkę i ceny planów podaje zarządzanie tokenami w Cursorze.
• Max Mode jest dostępny tylko w starszych planach opartych na żądaniach (pomoc Cursora).

Co daje ci stała procedura wyboru modelu

• Cztery pytania, które w kilka sekund przypisują zadanie do klasy modelu.
• Skrypt wypisujący każdy model dostępny na twoim koncie razem z wariantami wysiłku, żebyś wiedział, z czego dziś wybierasz.
• Skrypt benchmarku, który uruchamia to samo zadanie na kilku modelach w osobnych worktree Gita i raportuje wynik testów, rozmiar diffu, tokeny i koszt.
• Trzy prompty do skopiowania: plan na mocnym modelu, implementacja na tańszym i druga opinia, gdy agent utknie.
• Tabelę awarii na dzień, w którym twój ulubiony model zniknie z selektora.

Która klasa modelu pasuje do którego zadania?

Najpierw wybierz klasę, potem model. Klasa zależy od tego, jak trudno zrobić zadanie dobrze i jak tanio da się wychwycić błąd, a nie od rozmiaru zadania.

Rodzaj zadania	Klasa modelu	Modele dostawców w tej klasie (sprawdź, czy są w twoim selektorze)
Zmiana przekraczająca granice modułów, architektura, kod wrażliwy na bezpieczeństwo, błąd o niejasnej przyczynie	Model rozumujący z czołówki: twój domyślny	Claude Opus 5.5, który Anthropic wskazuje jako model, od którego należy zacząć w większości zastosowań
Model domyślny na wyższym wariancie wysiłku nadal oblewa twój benchmark	Najwyższa półka, wybierana świadomie do jednego zadania	Claude Fable 5.1, który Anthropic poleca, gdy ewaluacje Claude Opus 5.5 na wyższym wysiłku nadal nie wystarczają
Dobrze opisana rutynowa zmiana, którą potwierdza test	Model codzienny, tańszy	Claude Sonnet 5.5 albo tańsze modele, które selektor opisuje jako szybkie
Dużo drobnej pracy: zmiany nazw, objaśnienia, rozdzielanie pracy na subagentów	Szybki, tani model	Claude Haiku 5.5, Gemini 3.8 Flash
Model domyślny powtarza ten sam błąd	Inna rodzina modeli, w nowym czacie	Grok 4.7, w Cursorze od tygodnia 2026-09-21 (notatki o wydaniach Cursora w sieci, sprawdzone 2026-10-12)

Tabela wymienia modele dostawców, a nie katalog Cursora. To, czy model jest w twoim selektorze, zależy od planu i od daty, więc potwierdź to skryptem z następnej sekcji. Ceny wszystkich powyższych modeli są w przeglądzie modeli.

Cztery pytania, które wskażą klasę dla każdego zadania:

1. Czy test wychwyci złą odpowiedź w ciągu kilku minut? Jeśli nie, użyj modelu domyślnego: subtelny błąd kosztuje więcej niż model.
2. Czy zadanie obejmuje więcej niż jeden moduł albo zmienia publiczny interfejs? Użyj modelu domyślnego i zaplanuj, zanim zaczniesz implementację.
3. Czy to wzorzec, który już robiłeś, z testem, który go potwierdza? Użyj klasy codziennej albo szybkiej.
4. Czy obecny model dwa razy oblał tę samą kontrolę? Zamiast trzeciej próby otwórz nowy czat z inną rodziną modeli.

Zmienić model w Cursorze czy najpierw jego wysiłek?

Zmiana modelu kasuje wszystko, co wiesz o zachowaniu agenta w twoim repozytorium. Zmiana wariantu wysiłku tego samego modelu tego nie robi i często wystarcza. W tabeli Anthropic z premiery Opus 5.5 (22 września 2026) Opus 5.5 na domyślnym wysiłku medium uzyskał 52,5% w CursorBench 4.0, wobec 51,8% dla Fable 5.1 na wysiłku max. Anthropic sam zastrzega: „at these levels of capability we’ve found that benchmark margins have become a less reliable guide to real-world differences. In our own use, the gap between Opus 5.5 and Claude Fable 5.1 is narrower than these scores suggest” (przy tym poziomie możliwości różnice w benchmarkach coraz słabiej oddają różnice w realnej pracy; we własnym użyciu Anthropic widzi mniejszą różnicę między Opus 5.5 a Claude Fable 5.1, niż sugerują te wyniki). Dlatego ostatnim krokiem poniżej jest twój własny benchmark.

1. Wypisz, co udostępnia twoje konto. Zainstaluj Cursor SDK jako zależność deweloperską (wymaga Node.js 22.13 lub nowszego) i wyeksportuj klucz API z menedżera sekretów. W terminalu:

   npm install --save-dev @cursor/sdk@1.0.32 tsx
   export CURSOR_API_KEY="$(op read 'op://Dev/cursor-api-key/credential')"

   Druga linia czyta klucz przez CLI 1Password; użyj menedżera sekretów, którego używa twój zespół. Nigdy nie wklejaj klucza do wiersza poleceń ani do pliku. Potem zapisz ten skrypt:

   bench/list-models.mts

   // Run from the repository root: npx tsx bench/list-models.mts
   import { Cursor } from '@cursor/sdk';
   
   const models = await Cursor.models.list();
   for (const m of models) {
     const aliases = m.aliases?.length ? `  (aliases: ${m.aliases.join(', ')})` : '';
     console.log(`${m.id}  ${m.displayName}${aliases}`);
     for (const v of m.variants ?? []) {
       const params = v.params.map((p) => `${p.id}=${p.value}`).join(' ');
       console.log(`    ${v.displayName}${v.isDefault ? ' (default)' : ''}  ${params}`);
     }
   }

   W @cursor/sdk 1.0.32 każdy model ma id, displayName, opcjonalne aliases i opcjonalne variants; każdy wariant to zestaw params, a jeden z nich jest oznaczony isDefault. W wariantach pojawiają się ustawienia wysiłku lub myślenia. SDK nie ma wpisanych na sztywno identyfikatorów modeli, więc ta lista jest jedynym wiarygodnym źródłem. Zarówno @cursor/sdk w npm, jak i cursor-sdk w PyPI mają 2026-10-07 wersję 1.0.37 (sprawdzone 2026-10-12); przypięta wyżej wersja i te nazwy pól pochodzą z 1.0.32.

2. Zacommituj listę. Uruchom npx tsx bench/list-models.mts > bench/models.txt i dodaj plik do repozytorium. Przy kolejnym uruchomieniu git diff bench/models.txt pokaże dokładnie, które modele lub warianty się pojawiły, zmieniły albo zniknęły.

3. Wybierz model domyślny. Weź najmocniejszy model rozumujący, jaki obejmuje twój plan, i wybierz go w selektorze modeli. W większości zespołów to klasa z czołówki z tabeli powyżej. Zostaw go na tydzień prawdziwej pracy, zanim go ocenisz.

4. Dostrój wysiłek, zanim zmienisz model. Jeśli model ma warianty, przy rutynowej pracy zostań na domyślnym. Gdy trudne zadanie się nie udaje, najpierw uruchom je ponownie na wyższym wariancie tego samego modelu. Zejdź o wariant niżej, gdy agent rozwleka proste zmiany.

5. Zmieniaj model tylko na podstawie dowodów. Inny model zostaje twoim domyślnym albo wyborem dla danej klasy zadań dopiero wtedy, gdy wygra benchmark z następnej sekcji.

Automatyczny routing sprawia, że pomiarów nie da się powtórzyć

W planach Teams i Enterprise Auto działa na Cursor Router, a wybrany przez niego model jest domyślnie ukryty (administrator może zdecydować o jego wyświetlaniu), więc model może się zmieniać między zapytaniami (dokumentacja Cursor Router, sprawdzone 2026-10-12). Przy każdym pomiarze i porównaniu przypnij konkretny model. Auto używaj tylko do pracy, przy której nie musisz wiedzieć, który model napisał kod.

Jak udowodnić zmianę modelu benchmarkiem na własnych testach?

Publiczne benchmarki mierzą cudze repozytoria. Przed zmianą uruchom od trzech do pięciu zadań z ostatniego sprintu, każde z poleceniem, które dowodzi, że zadanie jest skończone. Każde zadanie zapisz jako plik Markdown w bench/, tak jak napisałbyś prompt dla agenta, i podaj jego polecenie akceptacyjne, na przykład npm ci && npm test -- rate-limit.

Ten skrypt daje każdemu modelowi osobny worktree Gita z tego samego commita, więc modele nie widzą ani nie nadpisują nawzajem swojej pracy:

bench/compare.mts

// Run from the repository root:
// npx tsx bench/compare.mts bench/task-01.md "npm ci && npm test -- rate-limit" MODEL_A "MODEL_B?PARAM=VALUE"
import { execSync } from 'node:child_process';
import { readFileSync } from 'node:fs';
import { basename, resolve } from 'node:path';
import { Agent } from '@cursor/sdk';

const [taskFile, check, ...specs] = process.argv.slice(2);
const task = readFileSync(taskFile, 'utf8');

for (const spec of specs) {
  const [id, query = ''] = spec.split('?');
  const params = [...new URLSearchParams(query)].map(([pid, value]) => ({ id: pid, value }));
  const dir = resolve('..', `bench-${basename(taskFile, '.md')}-${spec.replace(/[^a-z0-9.-]/gi, '_')}`);
  execSync(`git worktree add --detach "${dir}" HEAD`, { stdio: 'inherit' });

  const agent = await Agent.create({
    apiKey: process.env.CURSOR_API_KEY,
    model: { id, params },
    local: { cwd: dir, settingSources: ['project'] },
  });
  const result = await (await agent.send(task)).wait();
  const { cost } = await agent.getUsage();
  agent.close();

  let passed = true;
  try {
    execSync(check, { cwd: dir, stdio: 'inherit' });
  } catch {
    passed = false;
  }
  execSync('git add -A', { cwd: dir });
  const diff = execSync('git diff --cached --shortstat', { cwd: dir, encoding: 'utf8' }).trim();

  console.log(JSON.stringify({
    task: taskFile, model: spec, agentId: agent.agentId, status: result.status, passed, diff,
    ...result.usage, rawCostCents: cost?.rawCostCents ?? null,
  }));
}

MODEL_A i MODEL_B to identyfikatory z bench/models.txt. Żeby przetestować wariant, dopisz jego parametry po znaku zapytania, skopiowane z tego samego pliku. Lokalny agent edytuje pliki i uruchamia polecenia w każdym worktree, więc benchmark uruchamiaj na maszynie bez produkcyjnych poświadczeń w środowisku. Każde zadanie i każdy model dostaje osobny katalog worktree, więc możesz uruchomić wszystkie zadania przed sprzątaniem; na koniec usuń worktree poleceniem git worktree remove. Zanim ponownie uruchomisz to samo zadanie na tym samym modelu, usuń worktree tej pary (git worktree remove <katalog>); inaczej git worktree add zakończy się błędem i przebieg się zatrzyma. Koszt raportowany jest z opóźnieniem; jeśli rawCostCents ma wartość null, wywołaj później Agent.getUsage(agentId) z zapisanym agentId, jak opisuje zarządzanie tokenami w Cursorze. rawCostCents to koszt modelu bez rabatów, właściwy do porównywania modeli (przy rozliczeniu za żądania wynosi 0); cost.chargedCents to kwota faktycznie naliczona w twoim planie.

Oceniaj wyniki według jednej zasady: koszt zaliczonego zadania, a nie cena za token. Model, który oblał polecenie akceptacyjne, dostaje za to zadanie zero, niezależnie od tego, jak tani był.

Zmień model domyślny, gdy kandydat…	Zostań przy obecnym, gdy…
Zalicza co najmniej tyle samo zadań	Obecny zalicza więcej zadań, nawet drożej
Kosztuje mniej za zaliczone zadanie	Kandydat jest tańszy tylko dlatego, że zrobił mniej (mniejszy diff, który oblewa testy)
Daje diff o rozmiarze zbliżonym do planu	Diff kandydata dotyka plików spoza zadania

O własnych zadaniach decyduje deweloper. Model domyślny zespołu zatwierdza tech lead i commituje wynik benchmarku obok bench/models.txt, żeby następna osoba mogła powtórzyć te same zadania, gdy zmieni się selektor. O rozbudowie zestawu ewaluacyjnego piszemy w tekście o benchmarkach agentów i własnych ewaluacjach.

Planuj na jednym modelu, implementuj na drugim

Najtańszy niezawodny wzorzec: decyzje zostaw mocnemu modelowi, a pisanie kodu tańszemu. Plan Mode w Cursorze tworzy szczegółowy plan implementacji, zanim powstanie jakikolwiek kod, więc tańszy model dostaje dokładny scenariusz do wykonania. Wybierz model domyślny, przełącz agenta na Plan Mode i wklej pierwszy prompt. Więcej o trybach znajdziesz w szczegółowym omówieniu trybów agenta.

Prompt do skopiowania: plan na modelu domyślnym

Plan the change described in docs/specs/rate-limit.md. Do not edit any files.
List every file you will touch, the tests you will add or change, and for each
step the command that proves it is done (for example `npm test -- rate-limit`).
Mark every point where the spec is ambiguous and ask me instead of assuming.
Stop after the plan.

Przeczytaj i zatwierdź plan. Przełączenie trybu zaczyna nowe okno kontekstu (pomoc Cursora, sprawdzone 2026-10-12), więc czat implementacyjny nie dziedziczy rozmowy planistycznej: najpierw zapisz plan do pliku. Potem wybierz w selektorze model codzienny, wróć do trybu Agent, dołącz plik z planem przez @ i wyślij prompt implementacyjny, żeby tańszy model zaczynał od planu i niczego więcej.

Prompt do skopiowania: implementacja zatwierdzonego planu tańszym modelem

Implement the approved plan one step at a time.
After each step, run that step's check command and show the last 20 lines of output.
Do not touch any file that is not in the plan.
If a check fails twice, stop and report the failure and your best diagnosis
instead of widening the change.

Ten sam podział działa z kodu: w @cursor/sdk 1.0.32 metoda agent.send() przyjmuje mode: 'plan' dla pojedynczej wiadomości oraz model, który od tej wiadomości zostaje modelem agenta, więc skrypt może planować na jednym modelu i przełączyć się na drugi do implementacji w tej samej rozmowie. Szczegóły są w przewodniku po Cursor SDK.

Gdy model implementujący dwa razy oblewa tę samą kontrolę, nie ponawiaj próby. Otwórz nowy czat z inną rodziną modeli, żeby wcześniejsza błędna diagnoza nie siedziała w jego kontekście:

Prompt do skopiowania: druga opinia od innej rodziny modeli

An earlier attempt keeps failing `npm test -- checkout` with the same assertion error.
Read the failing test and src/checkout/total.ts from scratch; assume any earlier
diagnosis is wrong. State the root cause in two sentences and quote the line that
causes it. Then propose the smallest fix and the test case that would have caught it.
Do not edit files until I confirm.

Skąd wiesz, że wynik jest poprawny, niezależnie od modelu?

Model zmienia to, jak często agent trafia, a nie to, jak sprawdzasz wynik. Utrzymuj te same bramki dla każdego modelu, żeby tańszy model nie obniżał poprzeczki:

• Polecenie akceptacyjne dla każdego zadania. Każdy krok planu je wskazuje, a prompt implementacyjny każe agentowi je uruchomić. Czytasz wynik polecenia, a nie cały diff.
• Sprawdzanie typów i linter w tym samym przebiegu. Dodaj je do polecenia kontrolnego (npm run typecheck && npm run lint && npm test -- rate-limit), żeby model pomijający typy oblewał to widocznie.
• Kontrola zakresu. Porównaj git diff --stat z listą plików z planu. Pliki spoza planu to pierwszy sygnał, że model rozszerza zadanie.
• Review w pull requeście. Bugbot przegląda pull requesty pod kątem błędów, problemów z bezpieczeństwem i jakością kodu; skonfigurujesz go według strony o Bugbocie w Cursorze. Recenzent czyta plan, wynik kontroli i uwagi z review.
• Wycofanie zmian. Pracuj na gałęzi albo w worktree, żeby nieudany przebieg dzieliło od cofnięcia jedno git worktree remove. Cofanie w samym IDE opisuje strona o checkpointach i gałęziach.

Co idzie nie tak przy wyborze modelu w Cursorze

Objaw	Prawdopodobna przyczyna	Co zrobić
Modelu, którego używałeś wczoraj, nie ma w selektorze	Zmieniła się pula modeli Cursora	Uruchom ponownie bench/list-models.mts, przeczytaj git diff bench/models.txt i przed przyjęciem zamiennika powtórz benchmark
Wyniki pogorszyły się przy tej samej nazwie modelu	Nowy wariant albo nowy wariant domyślny	Sprawdź znacznik (default) na liście, przypnij wariant, który wygrał benchmark, i powtórz jedno zadanie dla potwierdzenia
Tańszy model zalicza benchmark, ale zawodzi w prawdziwej pracy	Zadania w benchmarku były za łatwe	Dodaj do bench/ najtrudniejsze zadanie z ostatniego sprintu i porównaj jeszcze raz
Limit kończy się przed końcem miesiąca	Model z czołówki wykonuje rutynową pracę	Przenieś rutynowe zadania do klasy codziennej i zmierz oszczędność według zarządzania tokenami w Cursorze
Odpowiedzi stają się chaotyczne tuż po zmianie modelu w trakcie czatu	Nowy model dziedziczy długą historię zbudowaną przez inny	Zapisz plan do pliku i otwórz nowy czat, który dołącza tylko plan
Dwa przebiegi tego samego benchmarku dają różne wyniki	Auto wybrał różne modele	Przy każdym mierzonym przebiegu przypnij konkretny model i wariant
Agent kręci się w kółko na tym samym błędzie	Czat niesie błędną diagnozę	Użyj promptu z drugą opinią w nowym czacie z inną rodziną modeli

Gdy pojawia się nowy model, postępuj według 48-godzinnej procedury oceny nowego modelu, zamiast przełączać się pod wpływem entuzjazmu z dnia premiery.

Dokąd dalej po wyborze modelu

Następny krok w Szybkim starcie to reguły, dzięki którym każdy model trzyma się twoich konwencji. Użytkownicy Claude Code i Codeksa podejmują tę samą decyzję we własnych ustawieniach.

Reguły projektu w Cursorze Skonfiguruj reguły, żeby każdy model generował kod zgodny z konwencjami zespołu.

Przegląd modeli Aktualne nazwy modeli, ceny i okna kontekstu w jednym miejscu.

Zarządzanie tokenami w Cursorze Zmierz tokeny i koszt zadania i ogranicz kontekst, za który płaci każdy model.

Ewaluacje agentów kodujących Rozbuduj pięciozadaniowy benchmark w zestaw ewaluacji, któremu ufa cały zespół.

Model i wysiłek w Claude Code Ta sama zasada: najpierw model domyślny, potem wysiłek, ustawiana w plikach ustawień Claude Code.

Ustawienia modelu w Codeksie Wybierz i przypnij model oraz poziom wysiłku w konfiguracji Codeksa.