Nowy model na rynku: plan oceny w 48 godzin

Plan oceny nowego modelu w 48 godzin to stała procedura, którą zespół uruchamia po każdej premierze modelu do kodowania: przypięcie bieżącej konfiguracji, ponowne uruchomienie zestawu ewaluacyjnego na kandydacie, porównanie odsetka zaakceptowanych zadań, kosztu zaakceptowanego zadania i czasu, strojenie poziomu rozumowania (effort) przed promptami, a potem wdrożenie pętla po pętli ze spisanymi kryteriami wycofania.

Claude Opus 5.5 wychodzi we wtorek. W środę połowa zespołu już na nim pracuje, bo Claude Code sam się zaktualizował, a inny lider chce GPT-6 Astra, bo zobaczył wykres z premiery. Ta strona jest dla tech leada, który decyduje do czwartku, dla CTO, który zatwierdza, i dla programisty, który uruchamia ewaluacje.

Co daje zespołowi plan na 48 godzin

• Dwudniowy harmonogram z właścicielem każdego kroku i polecenia do przypięcia modelu w Claude Code, Codeksie i Cursorze, żeby premiera dotarła do zespołu dopiero po twojej decyzji.
• Listę kontrolną przeglądu premiery i tabelę decyzyjną, które zamieniają informacje o wydaniu i wyniki ewaluacji w „przechodzimy”, „zostajemy” albo „przechodzimy w części pętli”.
• Kryteria wycofania dla każdej pętli agenta i trzy prompty do skopiowania na dzień premiery.

Ta strona zakłada, że masz już wewnętrzny zestaw ewaluacyjny. Jeśli nie, zbuduj go najpierw według przewodnika o benchmarkach i ewaluacjach, który zakłada pierwszy zestaw około 30 zadań; ten plan używa tych samych zadań i poleceń. Aktualne nazwy modeli, ceny i ustawienia domyślne są w przeglądzie modeli i ta strona ich nie powtarza.

Dlaczego nowy model to praca cykliczna, a nie jednorazowe wydarzenie

W ciągu 22 dni września 2026 czterech dostawców wypuściło siedem modeli, po które mogły sięgnąć zespoły programistyczne, a dwa narzędzia same zmieniły swój model domyślny:

Data premiery	Dostawca	Model	Co zmieniło się w narzędziach
2026-09-01	Anthropic	Claude Fable 5.1	Dostępny w Claude Code od v2.1.257; nigdy domyślny
2026-09-02 (źródło wtórne: The Register)	Google	Gemini 3.8 Flash	Dodany do GitHub Copilot 2026-09-03
2026-09-03 (źródło wtórne: CNBC)	OpenAI	GPT-6 Astra	Domyślny model Codeksa od CLI 0.153.4 z 2026-09-04, przy effort na poziomie low
2026-09-21 (źródło wtórne: MarkTechPost)	SpaceXAI	Grok 4.7	Dodany do GitHub Copilot 2026-09-21; w Cursorze od pierwszego dnia (źródło wtórne: MarkTechPost)
2026-09-22	OpenAI	GPT-6 Sol, GPT-6 Luna	W selektorze modeli Codeksa od CLI 0.156.1 z 2026-09-23
2026-09-22	Anthropic	Claude Opus 5.5	Domyślny w Claude Code od v2.1.280 na kanale latest, przy effort na poziomie medium

Dwa z tych wierszy zmieniły to, na czym działali agenci, choć nikt o tym nie zdecydował. Zmiana modelu to zmiana produkcyjna, a twoje narzędzia potrafią ją wprowadzić za ciebie.

Plan na 48 godzin w skrócie

Okno	Krok	Wynik	Właściciel
Godzina 0–2	Zamrożenie bieżącej konfiguracji i przegląd premiery	Commit z przypięciami; notatki z przeglądu	Właściciel ewaluacji
Godzina 2–12	Ponowne uruchomienie zestawu: wersja bazowa kontra kandydat	Dwa katalogi przebiegów Harbora	Właściciel ewaluacji
Godzina 12–24	Porównanie czterech liczb; strojenie poziomu effort, potem instrukcji	Tabela porównawcza; dostrojony kandydat	Właściciel ewaluacji, jeden programista
Godzina 24–40	Kanarek w jednej pętli agenta	Metryki kanarka zestawione z kryteriami wycofania	Tech lead
Godzina 40–48	Decyzja dla każdej pętli i jej zapis	Zaktualizowany rejestr routingu; plan wycofania	Tech lead zatwierdza; CTO przy zmianie dostawcy

Model operacyjny wyjaśnia, kto odpowiada za zestaw ewaluacyjny w organizacji. 48 godzin to cel, a nie termin: jeśli ewaluacje pokażą remis, odpowiedź brzmi „zostajemy i sprawdzamy ponownie przy następnej premierze”.

Przeprowadź plan krok po kroku

1. Zamroź bieżącą konfigurację (godzina 0). Przypnij model pełnym identyfikatorem, przypnij poziom effort i przypnij wersję narzędzia wszędzie tam, gdzie narzędzie aktualizuje się samo. Aliasy się przesuwają: pomoc Claude Code 2.1.283 opisuje opus, sonnet i fable jako aliasy „for the latest model”, więc konfiguracja z wpisem opus zmieniła model 2026-09-22 bez żadnego commita. Zapisz przypięcia w repozytorium (workflow CI, .claude/settings.json), żeby późniejsze wycofanie było zwykłym git revert.

2. Przejrzyj informacje o wydaniu (godzina 0–2). Czytaj stronę modelu u dostawcy i changelog narzędzia, a nie post premierowy, szukając pięciu rodzajów zmian:

   • Przesunięcia domyślnego poziomu effort. Claude Opus 5.5 ma domyślnie poziom medium w Claude Code i w API, a Opus 5 miał high. Dokumentacja Anthropic o poziomach effort mówi, że żądanie bez effort „runs one level lower than it did on Claude Opus 5”. W Codeksie GPT-6 Astra ma domyślnie low, a GPT-6 Sol i Luna medium.
   • Usunięte lub odrzucane parametry. Na modelach Claude 4.7 i nowszych niedomyślne temperature, top_p lub top_k kończy się błędem 400. Opus 5.5 odrzuca też wyłączenie thinking i wymuszone wywołanie narzędzia. GPT-6 Astra nie ma poziomu none, a przewodnik migracji OpenAI każe usunąć temperature i top_p.
   • Liczenie tokenów. Cennik Anthropic podaje, że modele Claude 4.7 i nowsze używają tokenizera, który dla tego samego tekstu daje około 30% więcej tokenów. Niższa cena za token może więc oznaczać wyższy koszt zadania.
   • Warunki danych i rozliczeń. Claude Fable 5.1 to Covered Model z domyślnym przechowywaniem danych i, zależnie od planu, może być rozliczany z kredytów użycia. Najpierw porównaj je z zasadami dotyczącymi danych.
   • Wycofanie modelu, do którego chcesz wrócić. Codex 0.157.1 wciąż zawiera GPT-5.4 jako wycofany wpis, który automatycznie przenosi sesje na GPT-6 Sol. Zanim zaplanujesz wycofanie, sprawdź w przeglądzie modeli, czy model docelowy pozostaje dostępny.

3. Uruchom zestaw ponownie: wersja bazowa kontra kandydat (godzina 2–12). Te same zadania, ten sam commit instrukcji, ta sama wersja środowiska uruchomieniowego agenta (harness); zmieniasz tylko model, z co najmniej trzema próbami na zadanie. Z konfiguracją Harbora z przewodnika o benchmarkach i ewaluacjach to dwa polecenia na narzędzie, pokazane w zakładkach niżej. Do każdego przebiegu zapisz manifest: identyfikator modelu, poziom effort, claude --version lub codex --version, harbor --version i commit plików CLAUDE.md, AGENTS.md oraz reguł. Prompt go/no-go czyta go z pliku manifest.txt w katalogu każdego przebiegu.

4. Porównaj cztery liczby, a nie jedną (godzina 12–18). Sam odsetek zaliczonych zadań wybierze zły model, jeśli kandydat wygrywa, bo wydaje więcej. Porównaj:

   • Odsetek zaakceptowanych zadań: zadania, w których weryfikator przeszedł i których poprawkę recenzent scaliłby bez zmian, sprawdzone na próbce 10 poprawek przez człowieka albo skalibrowanego sędziego (sprawdzanie przez model pokazuje, jak go skalibrować). Werdykty zapisz jako reviews.csv (zadanie, zaakceptowane tak lub nie) w katalogu każdego przebiegu, żeby prompt go/no-go mógł z nich skorzystać.
   • Koszt zaakceptowanego zadania: wszystkie tokeny lub dolary przebiegu podzielone przez liczbę zaakceptowanych zadań. Wynik Claude Code z --output-format json zawiera total_cost_usd i duration_ms; codex exec --json podaje zużycie tokenów w każdym zdarzeniu turn.completed.
   • Czas: mediana czasu wykonania zadania, która rozstrzyga o pętlach interaktywnych.
   • Zadania, które zmieniły wynik: zadania, które kandydat zalicza po raz pierwszy, i te, które po raz pierwszy oblewa. Sześć zyskanych i cztery stracone to inny bilans niż dwa zyskane.

   Przy 30 zadaniach × 3 próby 95-procentowy przedział dla jednego odsetka zaliczeń to około ±10 punktów, ale porównujesz dwa odsetki, więc przedział dla różnicy wynosi mniej więcej ±14 punktów. Skorelowane próby jednego zadania jeszcze go poszerzają, bo nie dają 90 niezależnych prób. Policz go porównaniem sparowanym po zadaniach, na przykład bootstrapem po zadaniach, a każdą różnicę mieszczącą się w przedziale traktuj jako remis. Remis rozstrzygasz kosztem, czasem albo akceptacją recenzentów.

5. Dostrój poziom effort, zanim ruszysz instrukcje (godzina 18–24). Uruchom kandydata na domyślnym poziomie effort, o poziom wyżej i o poziom niżej; każda zakładka niżej pokazuje polecenie Harbora do tej serii przebiegów. Dokumentacja Claude Code twierdzi, że „Opus 5.5 at medium matches or exceeds Opus 5 at high”; seria przebiegów sprawdza to na twoich zadaniach. Dopiero wtedy przejrzyj instrukcje agenta pod kątem obejść dla starego modelu (drugi prompt poniżej), usuwaj je po jednym i powtarzaj zadania, na które wpływają. Nigdy nie zmieniaj modelu, poziomu effort i instrukcji w jednym przebiegu, bo nie da się wtedy ustalić, która zmiana przesunęła wynik.

6. Uruchom kanarka w jednej pętli (godzina 24–40). Pętla agenta to jedno miejsce, w którym agent działa z własnym wyzwalaczem i recenzentem: sesje interaktywne, zadanie CI z poprawkami, bot recenzujący, pętla zaplanowana, agent w chmurze. Wdrażaj w tej kolejności, od najbardziej nadzorowanej, zaczynając od ochotników w sesjach interaktywnych. Wpisz kryteria wycofania do zgłoszenia wdrożeniowego, zanim przestawisz pierwsze przypięcie.

7. Zdecyduj dla każdej pętli i zapisz decyzję (godzina 40–48). Skorzystaj z tabeli decyzyjnej poniżej; odpowiedź często brzmi „przechodzimy w części pętli”. Zapisz decyzję, dowody i model do wycofania w rejestrze routingu, jak w routingu modeli, a każde zadanie, które kandydat oblał w ciekawy sposób, dodaj do zestawu ewaluacyjnego.

Przypnij i oceń kandydata w Claude Code, Codeksie i Cursorze

Kroki są te same w każdym narzędziu; różni się to, gdzie mieszka przypięcie i co może je przesunąć bez commita. Harbora instalujesz raz poleceniem uv tool install harbor; każdy klucz API ładuj do środowiska z menedżera sekretów i nigdy nie wpisuj go w wierszu poleceń.

Claude Code

Przypnij model bazowy i kanał. W pliku projektu .claude/settings.json ustaw dzisiejszy model pełnym identyfikatorem. W tym przykładzie wersją bazową jest Claude Opus 5, a kandydatem Opus 5.5:

.claude/settings.json

{
  "model": "claude-opus-5"
}

Dla wersji narzędzia ustaw "autoUpdatesChannel": "stable" każdej osobie, która nie powinna dostać zmiany modelu domyślnego w dniu premiery. 2026-09-26 kanał stable był na v2.1.274, która obsługuje Opus 5, ale nie Opus 5.5 (ten wymaga v2.1.280+). Tylko ochotnicy z kanarka przechodzą na kanał latest i zmieniają swoje przypięcie na claude-opus-5-5. Jak trzymać kandydata poza zasięgiem do czasu zatwierdzenia ustawieniami availableModels, enforceAvailableModels i, od v2.1.283 (kanał latest), deniedModels, opisuje polityka zarządzana.

Przypinaj zadania CI w wierszu poleceń, który ma pierwszeństwo przed każdym plikiem ustawień poza polityką zarządzaną. Sesja claude -p startuje w trybie Manual, więc przyznaj tylko edycje i jedno polecenie testowe, którego zadanie potrzebuje. Prompt podaj przed --allowedTools, bo ta flaga przyjmuje listę:

claude -p "Run the failing test in src/billing and fix the cause, not the test." \
  --model claude-opus-5 --effort high --output-format json \
  --permission-mode acceptEdits --allowedTools "Bash(npm test *)"

Uruchom parę ewaluacji w terminalu, zmieniając tylko model:

harbor run -p evals/tasks -a claude-code -m anthropic/claude-opus-5 -k 3 -n 4
harbor run -p evals/tasks -a claude-code -m anthropic/claude-opus-5-5 -k 3 -n 4

Zapisz manifest w katalogu każdego przebiegu utworzonym przez Harbora, z modelem i poziomem effort tego przebiegu:

{ echo "model=claude-opus-5-5"; echo "effort=medium"; claude --version; harbor --version; \
  echo "instructions=$(git rev-parse HEAD)"; } > jobs/JOB_DIR/manifest.txt

Przetestuj kolejne poziomy effort przez opcję agenta reasoning_effort, którą Harbor 0.23.0 przekazuje do Claude Code jako --effort:

harbor run -p evals/tasks -a claude-code -m anthropic/claude-opus-5-5 -k 3 -n 4 \
  --ak reasoning_effort=high

Claude Code v2.1.283 przyjmuje low, medium, high, xhigh i max; w sesji służy do tego /effort.

Codex

Przypnij model i poziom effort w konfiguracji. Codex 0.154.0 sprawił, że nowe sesje „respect server model defaults unless explicitly overridden”, więc dla zalogowanego konta ChatGPT faktyczny model domyślny ustala serwer. Jawne model to jedyne pewne przypięcie:

~/.codex/config.toml

model = "gpt-6-astra"
model_reasoning_effort = "low"

Ten plik leży w katalogu domowym każdego programisty, poza gitem, więc rozprowadź go jako wspólny plik dotfile zespołu, bo inaczej przypięcia się rozjadą. Przypięcie, od którego zależy wycofanie, umieść w workflow CI, w commicie razem z kodem (profil uprawnień :workspace, beta, pozwala zapisać poprawkę):

codex exec --json -m gpt-6-astra -c model_reasoning_effort=low \
  -c default_permissions=':workspace' \
  "Run the failing test in src/billing and fix the cause, not the test."

Kandydata uruchamiaj jedną dodatkową flagą: --profile NAZWA (-p) nakłada $CODEX_HOME/NAZWA.config.toml na ustawienia domyślne:

~/.codex/candidate.config.toml

model = "gpt-6-sol"
model_reasoning_effort = "medium"

codex -p candidate exec --json -c default_permissions=':workspace' \
  "Run the failing test in src/billing and fix the cause, not the test."

W CI przypnij CLI dokładną wersją pakietu, na przykład npm install -g @openai/codex@0.157.1, żeby nowe wydanie nie zmieniło modelu domyślnego w trakcie ewaluacji. Codex 0.157.0 dodał podpowiedzi migracji na GPT-6 Sol lub Luna; odrzucaj je do końca oceny.

Uruchom parę ewaluacji:

harbor run -p evals/tasks -a codex -m openai/gpt-6-astra -k 3 -n 4
harbor run -p evals/tasks -a codex -m openai/gpt-6-sol -k 3 -n 4

Zapisz manifest w katalogu każdego przebiegu:

{ echo "model=gpt-6-sol"; echo "effort=medium"; codex --version; harbor --version; \
  echo "instructions=$(git rev-parse HEAD)"; } > jobs/JOB_DIR/manifest.txt

Przetestuj kolejne poziomy effort tą samą opcją agenta; Harbor 0.23.0 zamienia ją na -c model_reasoning_effort=high w wierszu poleceń codex exec:

harbor run -p evals/tasks -a codex -m openai/gpt-6-sol -k 3 -n 4 \
  --ak reasoning_effort=high

Poziomy effort w Codeksie idą od low do max, plus ultra („Maximum reasoning with automatic task delegation”), którego GPT-6 Luna nie oferuje.

Cursor

Przypnij przez wybór i sprawdź na własnym koncie. Domyślnych modeli, listy modeli ani cen Cursora nie dało się zweryfikować na cursor.com 2026-09-26, więc ta strona nie podaje żadnych. Wybierz model jawnie w selektorze modeli, a nie automatycznie, i wpisz go do reguł zespołu.

Uruchom parę ewaluacji agentem cursor-cli z Harbora, który wymaga CURSOR_API_KEY i uruchamia Cursor CLI w trybie print:

harbor run -p evals/tasks -a cursor-cli -m cursor/BASELINE_MODEL -k 3 -n 4
harbor run -p evals/tasks -a cursor-cli -m cursor/CANDIDATE_MODEL -k 3 -n 4

Zastąp BASELINE_MODEL i CANDIDATE_MODEL identyfikatorami modeli z listy twojego konta Cursor i zapisz manifest.txt w katalogu każdego przebiegu, jak w pozostałych zakładkach. Harness też wpływa na wynik, więc nigdy nie przenoś wyniku z Claude Code ani z Codeksa.

Harbor uruchamia agentów bez zatwierdzeń

Agent Codeksa w Harborze przekazuje --dangerously-bypass-approvals-and-sandbox, a agent Cursora --yolo. Jest to dopuszczalne tylko dlatego, że każda próba działa w jednorazowym kontenerze. W obrazie zadania nie umieszczaj niczego poza migawką repozytorium, a z poświadczeń tylko klucz do modelu. Harbor 0.23.0 nie ma flagi --effort na najwyższym poziomie; poziom effort przekazuj jako opcję agenta (--ak reasoning_effort=…), a to, co przyjmuje twoja wersja, sprawdź poleceniem harbor agent schema <agent>.

Jak podjąć decyzję na podstawie wyników ewaluacji

Odczytaj cztery liczby z kroku 4 według tej tabeli. „Szum” oznacza przedział dla różnicy między dwoma przebiegami: mniej więcej ±14 punktów dla dwóch przebiegów po 30 zadań × 3 próby, a więcej przy skorelowanych próbach.

Co pokazuje ewaluacja	Decyzja	Następny krok
Odsetek zaakceptowanych zadań kandydata wyższy o więcej niż szum, przy podobnym koszcie	Przechodzimy, pętla po pętli	Kanarek najpierw w sesjach interaktywnych
Remis w odsetku zaakceptowanych; kandydat wyraźnie tańszy na zaakceptowane zadanie albo szybszy	Przechodzimy w pętlach, w których liczy się koszt lub czas	Najpierw pętle CI o dużym wolumenie; wersja bazowa zostaje przy długich zadaniach
Kandydat wygrywa tylko na wyższym poziomie effort, który kosztuje więcej na zaakceptowane zadanie	Przechodzimy tylko w pętlach, które tego potrzebują	Zapisz poziom effort dla każdej pętli w rejestrze routingu
Remis we wszystkim	Zostajemy	Zapisz „bez zmian” z identyfikatorami przebiegów; sprawdź przy następnej premierze
Kandydat przegrywa o więcej niż szum albo oblewa klasę zadań, od której zależysz	Zostajemy i trzymamy przypięcie	Dodaj oblane zadania do zestawu

Wykres z premiery nie jest wierszem tej tabeli. Anthropic sam pisze, że „at these levels of capability we’ve found that benchmark margins have become a less reliable guide to real-world differences”, a przewodnik o benchmarkach wyjaśnia, dlaczego publiczny wynik należy do pary model plus harness, a nie do samego modelu.

Kryteria wycofania do spisania przed wdrożeniem

Wpisz progi do zgłoszenia wdrożeniowego, zanim pierwsza pętla się przełączy, żeby nikt nie negocjował ich w trakcie incydentu. Poniższe liczby to punkt startowy dla zespołu, który wykonuje co najmniej 20 zadań agentowych dziennie.

Sygnał w pętli kanarkowej	Próg na start	Działanie
Odsetek zaakceptowanych zadań (weryfikator i akceptacja recenzenta)	Poniżej odsetka bazowego zmierzonego na co najmniej kilkuset historycznych zadaniach o więcej niż własny przedział kanarka: około ±22 punktów przy 20 zadaniach kanarka, ±14 przy 50. Przy mniejszej próbie bazowej użyj przedziału dla różnicy (około ±31 i ±20) i bootstrapu jak w kroku 4	Cofnij przypięcie w tej pętli
Koszt zaakceptowanego zadania	Ponad 25% powyżej wersji bazowej przez trzy dni robocze	Obniż poziom effort o jeden i zmierz ponownie; cofnij, jeśli nadal za wysoko
Mediana czasu zadania w sesjach interaktywnych	Ponad 50% powyżej wersji bazowej	Cofnij pętlę interaktywną; pętle wsadowe zostaw, jeśli spełniają progi
Odsetek poprawek po recenzji w pull requestach agenta	Ponad 10 punktów powyżej wersji bazowej	Przejrzyj próbkę 10 pull requestów; cofnij, jeśli poprawki wynikają z modelu
Niezaliczona bramka bezpieczeństwa, wyciek sekretu lub naruszenie zasad danych związane ze zmianą	Jedno wystąpienie	Cofnij natychmiast i otwórz incydent

Wycofanie to revert commita z przypięciem (.claude/settings.json albo workflow CI; przypięcie w ~/.codex/config.toml rozprowadza się ponownie, a nie cofa), który może zrobić każdy dyżurny inżynier bez zwoływania spotkania. Przewodnik o potoku wycofań opisuje ten sam wzorzec dla kodu, stopniowe wdrażanie (progressive delivery) opisuje mechanikę wdrażania etapami, a śledzenie kosztów agentów to, skąd brać sygnał kosztowy.

Jak udowodnić, że zmiana jest bezpieczna, bez czytania każdego diffa

Nikt nie czyta kodu kandydata linijka po linijce. Dowodami są ewaluacje oceniane weryfikatorem na twoich zadaniach, próbka akceptacji recenzenta z 10 poprawek na konfigurację (jedyne czytanie przez człowieka), niezmienione bramki CI w trakcie kanarka i zapis decyzji z identyfikatorami przebiegów, żeby każdy mógł odtworzyć dowody.

Kto zatwierdza: właściciel ewaluacji publikuje porównanie; tech lead zatwierdza przełączenie każdej pętli i odpowiada za wycofanie; CTO zatwierdza zmianę dostawcy albo zmianę, która dotyka warunków danych, na przykład przejście na Covered Model. Ciągłe ewaluacje uruchamiają ten sam zestaw przy każdej zmianie instrukcji agenta, więc następna premiera zaczyna się od świeżej wersji bazowej.

Prompty do skopiowania na dzień premiery

Prompt do skopiowania: przegląd premiery modelu względem naszej konfiguracji

A new model was released. Read the vendor's model page and the tool changelog
at the URLs at the end of this message, then audit this repository against them.

1. List every change in the release that can affect us, grouped as: default effort,
   removed or rejected API parameters, tool-use behaviour, token accounting,
   data retention or billing terms, and retirement of older models.
2. Search this repository for code and config that each change touches:
   model IDs and aliases (opus, sonnet, fable, gpt-6-*), temperature, top_p, top_k,
   budget_tokens, forced tool_choice, effort settings, model_reasoning_effort,
   and any CI workflow that calls claude -p or codex exec.
3. Output a table: change, file and line affected, risk (breaks / costs more /
   no effect), and the smallest fix. Do not edit any file.
4. Name the model we would roll back to and whether the release notes change
   its availability.

Model page URL:
Changelog URL:

Prompt do skopiowania: obejścia dla starego modelu w instrukcjach agenta

Read CLAUDE.md, AGENTS.md, every file under .claude/, .codex/, .cursor/rules
and .agents/skills in this repository. Find instructions that exist to work
around a weakness of an older model rather than to state a project rule:
repeated warnings, "always re-read the file before editing", step-by-step
scaffolding for routine tasks, forced verbosity or terseness, and rules that
duplicate what a test or linter already enforces.

For each one, report: the file and line, the probable weakness it compensates
for, which eval tasks it could affect, and a proposed removal. Rank by how
much context each one costs. Do not edit anything; I will remove them one at a
time and re-run the affected eval tasks after each removal.

Prompt do skopiowania: go/no-go na podstawie dwóch przebiegów

Compare the two Harbor job directories named below: BASELINE and CANDIDATE.
Each job directory has a manifest.txt with model ID, effort, tool version and
instructions commit; stop and tell me if the manifests differ in anything
other than model or effort.

Report for each job: pass rate, median wall time per task, and total tokens
or cost if the logs contain them. Then list per task: passes out of attempts
in each job, and the tasks that flipped. Estimate a 95% interval on the
difference in pass rate by bootstrapping over tasks (resample tasks, keep
each task's attempts together); do not treat attempts as independent.
If a job directory has a reviews.csv listing reviewer-accepted tasks, report
accepted-task rate and cost per accepted task as well, and apply the table
to those; otherwise say that the decision covers the verifier half only.

Apply this decision table and name one row:
- candidate higher by more than the interval on the difference, at similar cost: switch loop by loop
- tie, candidate clearly cheaper or faster: switch cost- or latency-bound loops
- candidate wins only at a higher effort that costs more: switch only loops that need it
- tie on everything: stay
- candidate lower by more than the interval on the difference: stay and keep the pin

Read the files only; do not re-run anything.

BASELINE: jobs/
CANDIDATE: jobs/

Co idzie nie tak przy ocenie nowego modelu?

• Narzędzie zaktualizowało się przed oceną. Objaw: w dniu premiery sesje już działają na nowym modelu. Jak naprawić: przypnij pełny identyfikator modelu (claude-opus-5) w .claude/settings.json i w CI, co działa na każdej wersji, a w Codeksie ustaw model jawnie. Na następną premierę: przenieś wszystkich spoza kanarka na kanał stable.
• Domyślny poziom effort spadł i nikt tego nie zauważył. Objaw: „nowy model jest leniwszy” przy trudnych zadaniach. Jak naprawić: porównuj przy wyrównanym poziomie effort oraz przy domyślnym poziomie każdego modelu, a w CI ustawiaj effort jawnie.
• Taniej za token, drożej za zadanie. Objaw: faktura rośnie po przejściu na model o niższej cenie. Jak naprawić: porównuj koszt zaakceptowanego zadania, który obejmuje zmianę tokenizera, dodatkowe tury i ponowienia.
• Zestaw ewaluacyjny jest nasycony. Objaw: wersja bazowa i kandydat zaliczają prawie wszystko. Jak naprawić: dodaj świeże trudne zadania i każdy błąd agenta, który przeciekł na produkcję; zestaw, którego nie da się oblać, niczego nie wybierze.
• Przepustowość w tygodniu premiery. Objaw: timeouty i błędy limitów zniekształcają czasy i odsetki zaliczeń. Jak naprawić: powtórz nieudane próby po 24 godzinach, zanim wyciągniesz wnioski, a w zadaniach Claude Code bez interfejsu użyj --fallback-model.
• Model do wycofania zniknął. Objaw: revert przypięcia nie działa, bo stary model został wycofany. Jak naprawić: sprawdź wycofania w kroku 2 i trzymaj w rejestrze routingu drugi zatwierdzony model.

Dokąd dalej po ocenie modelu

Jak czytać benchmarki i budować własne ewaluacje Warunek wstępny: zestaw ewaluacyjny w Harborze, który ten plan uruchamia ponownie.

Przegląd modeli Aktualne nazwy modeli, ceny, ustawienia domyślne i daty wycofania w każdym narzędziu.

Routing modeli Zapisz decyzję dla każdej klasy zadań i pętli razem z dowodami.

Ciągłe ewaluacje Ten sam zestaw uruchamiany przy każdej zmianie instrukcji agenta.

Jak utrzymać zespół na bieżąco Rytm zespołu na premiery dostawców, który nie zamienia się w cotygodniowy alarm.

Modele open-weight Zmierz kandydata z otwartymi wagami na tym samym zestawie.