Samouczek Muse Spark 1.3: praktyczny przewodnik dla deweloperów

Meta wypuściła Muse Spark 1.3 2 września 2026 r., a instrukcja aktualizacji mieści się w jednym wierszu: zmień ID modelu. Oznacza to te same endpointy, to samo SDK i te same ceny.

Według Met y ta jednolinijkowa zmiana daje model, który kończy to samo zadanie przy mniej więcej 20% mniejszej liczbie wywołań narzędzi i 25% mniejszej liczbie tokenów niż Muse Spark 1.2. Te liczby pochodzą z porównań przeprowadzonych przez inżynierów Meta, na zadaniach, których nie nazwali, bez opisu metodologii.

To dokładnie ten rodzaj deklaracji, który chcę sprawdzić, zanim go powtórzę. 

Zainstalowałem więc Muse Code, celowo popsułem prawdziwy projekt open source i uruchomiłem te same trzy zadania na obu modelach.

Żeby iść dalej z tym tutorialem Muse Code, będziesz potrzebować konta deweloperskiego Meta, terminala, w którym czujesz się swobodnie, oraz macOS lub Linuxa dla agenta Muse Code. Użytkownicy Windows wciąż mają pecha w obecnej becie.

W pigułce

• Muse Spark 1.3 to flagowy multimodalny model rozumowania Meta, wydany 2 września 2026 r., z kontekstem 1M tokenów.
• Muse Code domyślnie uruchamia muse-spark-1.3-contributor, co oznacza, że Meta trenuje na twoim kodzie, chyba że to zmienisz. Trening jest opt-out, nie opt-in.
• W 6 uruchomieniach na 3 zadaniach 1.3 była tańsza w 2 i o 38% droższa w trzecim, co dało łącznie 12% wzrost kosztu.
• Liczba ukończeń modelu spadła o 23% i 32% w 2 zadaniach, gdzie 1.3 wygrała, co pokrywa się z deklaracją Meta o wywołaniach narzędzi. Niekeszowane wejście spadło we wszystkich 3, ale nigdy o 25%.
• Poziom rozumowania ultra istnieje w CLI i selektorze w sesji, ale backend go odrzuca z nazwanym feature gate.

Czym jest Muse Spark 1.3?

Muse Spark 1.3 to flagowy multimodalny model rozumowania Meta, wydany przez Meta Superintelligence Labs 2 września 2026 r., zbudowany do długich sesji agencyjnych i kodowania w dużych repozytoriach. Mieści 1 048 576 tokenów kontekstu i przyjmuje tekst, obrazy, wideo i pliki.

Sześć zmian względem Muse Spark 1.2:

• Wydajność. Około 20% mniej wywołań narzędzi i 25% mniej tokenów w wewnętrznych porównaniach Meta.
• Współpraca. Zadaje pytania doprecyzowujące przy niejasnych poleceniach i pyta przed działaniami o dużych konsekwencjach.
• Wielozadaniowość w jednym wątku, więc wiadomość wysłana w trakcie dołącza do zadania, o które ci chodziło.
• Lepsze wykonywanie długich instrukcji, z mniejszą liczbą pominiętych ograniczeń w pracy wieloetapowej.
• Lepsza kalibracja przy działaniach nieodwracalnych.
• Czystszy styl kodowania. Mniej niepotrzebnych tur, mniej rozwlekłości.

To wszystko wygląda dobrze, ale opublikowana przez Metę karta wyników uruchamia Muse Spark 1.3 na max reasoning wobec Muse Spark 1.2 na xhigh, a max nadal był zablokowany na starcie. 

Artificial Analysis oceniło wariant xhigh dostarczany na premierę na 61 w Intelligence Index, a max na 62. Różnica o jeden punkt.

Matt Crabtree omówił już pełne tabele benchmarków, rozbicie cen i porównanie z GPT-5.6 Sol i Claude Opus 5 w swojej analizie wydania Muse Spark 1.3. Nie będę tego powtarzać. Poniżej zobaczysz, co się dzieje, gdy zainstalujesz to narzędzie i sprawisz, że działa.

Jak uzyskać dostęp do Muse Spark 1.3

Są trzy drogi, a właściwa zależy od tego, co budujesz. Wybierz z tabeli, potem przejdź do odpowiedniej sekcji.

Muse Code, agent terminalowy

Muse Code to terminalowy agent do kodowania od Meta, w becie na macOS i Linux. To uprząż uruchamiająca Muse Spark, wersjonują się niezależnie, więc muse --version nic nie mówi o tym, z którym modelem rozmawiasz. Trzymaj to rozdzielone w głowie.

curl -fsSL https://dev.meta.ai/install.sh | bash

To pobiera 230 MB binarkę i wrzuca ją do ~/.local/bin/muse, co nie zawsze jest na PATH. 

Potem sprawdź, co masz:

muse --version

4 września 2026 r. dostałem Muse Code 1.0.2 (1.0.2-R2040.1). 

Dość dziwne jak na betę, bo narzędzia zewnętrzne dokumentowały Muse Code jako 0.2.1 jeszcze kilka tygodni wcześniej. Przypnij wersję do daty, w której ją dostałeś.

Zrzut ekranu: autor. Instalacja Muse Code jednolinijkowym skryptem, potem potwierdzenie wersji 1.0.2 na macOS.

Teraz uruchom muse. Za pierwszym razem wydrukował Not logged in. Run muse again to log in. i wyszedł. Więc uruchamiasz go dwa razy, co jest drobiazgiem, który sprawia, że myślisz, iż instalacja się zepsuła.

Drugie uruchomienie startuje przepływ urządzenia OAuth. Drukuje URL logowania zawierający krótki kod, pokazuje ten sam kod osobno i prosi cię o potwierdzenie zgodności przed zatwierdzeniem w przeglądarce.

Sign in at this page:
  https://auth.meta.com/oauth/device/?code=XXXX-XXXX
confirm this code matches:
  XXXX-XXXX

Waiting for approval…

Powinieneś zobaczyć taki widok: 

Zrzut ekranu: autor. Przepływ logowania do Meta Model API, potwierdzenie danych konta przed wydaniem poświadczeń. 

Po stronie przeglądarki potwierdzasz imię i nazwisko, akceptujesz warunki i podajesz kartę. Przeczytaj panel cen na tym ekranie płatności zamiast klikać dalej — za chwilę będzie jasne dlaczego.

Domyślny poziom trenuje na twoim kodzie

W terminalu nagłówek sesji mówi, co uruchamiasz:

Muse Code 1.0.2
You are logged in.
Model set to muse-spark-1.3-contributor
└ Discounted tokens: your content, including inter-session messages, may be
  used for product improvement.

Przeczytaj nazwę modelu jeszcze raz. Wariant contributor, ustawiony jako domyślny, przy świeżej instalacji, bez pytania kogokolwiek.

Meta tego nie ukrywa. Ujawnienie siedzi pod nazwą modelu, ekran płatności oznacza contributor jako DEFAULT, a pasek statusu trzyma muse-spark-1.3-contributor na widoku podczas pracy. 

Ale ciężar jest odwrócony względem tego, czego oczekuje większość deweloperów.

Jeśli otworzysz Muse Code wewnątrz repo klienta i zaczniesz pracę, już wysłałeś ten kod do endpointu kwalifikującego się do treningu. Sprawdź pasek statusu przed pierwszą prośbą, nie po.

Zrzut ekranu: autor. Pierwsza sesja Muse Code, z domyślnym modelem ustawionym na muse-spark-1.3-contributor i informacją o ulepszaniu produktu poniżej.

Pasek statusu pokazuje też wysiłek rozumowania, u mnie high. Nie xhigh, wariant benchmarkowany przez Artificial Analysis. Warto o tym pamiętać, porównując swoje wyniki z opublikowanymi liczbami.

Wybór i zmiana poziomów

Uruchom /model, a dostaniesz interaktywny selektor z czterema opcjami i ich stawkami. Te liczby zgadzają się z ekranem płatności Meta:

Contributor jest około 12 razy tańszy na wejściu i 21 razy tańszy na wyjściu.

To, co kupuje ten rabat, to twoja własność intelektualna (IP). Sformułowanie Meta brzmi: „twoje treści, w tym wiadomości między sesjami, mogą być użyte do ulepszania produktu”, co obejmuje więcej niż tylko kod, który przekazujesz.

Oba warianty Muse Spark 1.2 wciąż są w selektorze w identycznych cenach, co ma znaczenie dla porównania później: skoro stawki nie zmieniają się między generacjami, porównanie tokenów jest porównaniem kosztów bez normalizacji.

Zrzut ekranu: autor. Selektor /model pokazujący cztery warianty Muse Spark z cenami za cache, wejście i wyjście.

Aby zrezygnować, strzałką w górę wybierz muse-spark-1.3 i wciśnij enter. Linia „Discounted tokens” znika z nagłówka.

Do pracy dla klienta jest mocniejsza opcja, której nie widać w terminalu. Meta mówi, że zaczęła przyjmować wnioski o zerową retencję danych, obsługiwane przez sprzedaż, nie przełącznik. 

Retencja i trening to osobne kwestie i umowy agencyjne zwykle wymagają odpowiedzi na obie.

Limitowanie działa inaczej między poziomami, choć źródła nie zgadzają się jak. Blog deweloperski Meta opisuje poziom contributor jako limitowany tokenami w ruchomym 5-godzinnym oknie zamiast liczbą żądań. Relacje prasowe przy premierze 1.2 mówiły o limicie 60 żądań na minutę, co jest zupełnie innym mechanizmem. Nie trafiłem na żaden z limitów w ~90 ukończeniach modelu w jedno popołudnie.

Meta Model API i OpenRouter

Meta Model API jest kompatybilne z OpenAI SDK, więc migracja oznacza zmianę ID modelu i zachowanie kodu klienta. ID modeli to muse-spark-1.3 i muse-spark-1.3-contributor.

OpenRouter ma to pod slugiem meta/muse-spark-1.3. To kosztuje: OpenRouter zmierzył przepustowość ok. 81 tokenów/s wobec 182 zanotowanych przez Artificial Analysis przy połączeniu bezpośrednim, z dostępnością ok. 92% przez pierwsze trzy dni. Meta jest jedynym dostawcą, więc nie ma zapasowego.

Twoja pierwsza sesja z Muse Spark 1.3

Wszystko poniżej działa na python-humanize/humanize, przypiętym do commita 823ad6096. To 1676 linii źródeł w 6 modułach, testy uruchamiają się poniżej sekundy, a domena nie wymaga tłumaczenia. Nic tu nie modyfikuje repo. 

To pytania tylko do odczytu, żeby zobaczyć, jak agent eksploruje bazę kodu, zanim dam mu cokolwiek do pisania.

Dwa prompty, żeby wyczuć, jak czyta kod, zacznijmy od pierwszego: 

Map the dependency graph of this project and tell me which module has the most inbound imports.

Uruchomił dwa polecenia, wypisał strukturę projektu, a potem napisał parser AST zamiast grepować import. Odpowiedź: i18n z 4 przychodzącymi importami, rozbite jako i18n 4, number 2 oraz filesize, lists, time i _version po 1.

Sprawdziłem własnym skryptem i dostałem inne liczby, co wyglądało jak wpadka. Mój skrypt był błędny. Liczył tylko importy względne (from ._version import ...) i pomijał formę bezwzględną (from humanize.i18n import ...), której używa większość tego pakietu. Model obsłużył obie.

Drugi prompt warto uruchomić, bo da się go ocenić:

List every public function in src/humanize, grouped by module, with a count per module.

Odpowiedział 20 łącznie: filesize 1, i18n 5, lists 1, number 8, time 5. Wszystko poprawnie. Dodał też, bez pytania, że i18n.get_translation jest publiczne z nazwy, ale nieobecne w i18n.__all__, które eksportuje tylko pozostałe cztery. Też poprawnie.

Ta sesja kosztowała $0.01 w 8 turach.

Poziom rozumowania, o którym Meta nie mówi

muse --help dokumentuje to:

--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|ultra
    (default: high)

Selektor /effort w sesji oferuje sześć z tych siedmiu, pomijając none. 

Zrzut ekranu: autor. Selektor /effort z sześcioma poziomami rozumowania do wyboru, z high jako bieżącym.

Oba listują poziom ultra, który nie pojawia się w żadnym ogłoszeniu Meta. Publiczne stanowisko Meta jest takie, że max reasoning „pojawi się wkrótce po zakończeniu dodatkowych testów bezpieczeństwa”.

Więc o to poprosiłem:

muse exec --model muse-spark-1.3-contributor --reasoning-effort ultra 'Reply with exactly: ok'

tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

Jest nazwany feature gate, ultra_reasoning_effort, i jest zamknięty. Zdolność jest zbudowana, a przełącznik jest wyłączony po stronie serwera. To bardziej precyzyjny obraz niż „oczekuje na testy bezpieczeństwa”, i przyszedł w ostrzeżeniu zawierającym słowo „tbh”.

Dwa praktyczne punkty. Klient reklamuje poziom, którego backend nie obsłuży, zarówno w CLI, jak i selektorze. I cicho degraduje do xhigh jedną linią stderr, co w skrypcie lub logu CI przewija się niezauważone. Uwierzysz, że uruchamiasz konfigurację, której nie było.

Potem spróbowałem wartości, której nie ma w dokumentacji:

muse exec --model muse-spark-1.3-contributor --reasoning-effort max 'Reply with exactly: ok'

Bez ostrzeżenia. Poszło i zwróciło ok. Więc nieudokumentowana wartość przechodzi walidację bez komentarza, podczas gdy udokumentowana jest blokowana, i nie możesz z wyjścia poznać, jaki poziom wysiłku faktycznie obsłużył twoje żądanie.

Zrzut ekranu: autor. Żądanie ultra zwraca zamknięty feature gate i cichą degradację do xhigh, podczas gdy nieudokumentowane max przechodzi bez komentarza.

Jeśli zależy ci na poziomie rozumowania, ustaw go jawnie i czytaj stderr. Nie zakładaj, że flaga, którą podałeś, to flaga, która została użyta.

Czy deklaracja wydajności Muse Spark 1.3 się broni?

Oto test. Weź jedno repo open source, odwróć prawdziwy commit z poprawką błędu, żeby testy naprawdę padały, potem uruchom trzy zadania kodowe na obu modelach z tymi samymi promptami i flagami.

To osobne od eksploracyjnej sesji powyżej. Każde z nich pisze kod.

Odwrócenie źródłowej części commita 823ad6096 przy zachowaniu jego testów zostawia 6 padających testów i to stan początkowy:

git checkout 823ad6096e1e5ba82ea876ce761fc2efebd76157
git show 823ad6096 -- src/humanize/filesize.py | git apply -R -
python -m pytest tests/test_filesize.py -q

Każdy bieg używał tego samego kształtu polecenia, zmieniając tylko ID modelu i prompt:

muse exec \
  --model muse-spark-1.3-contributor \
  --reasoning-effort high \
  --no-parallel-tool-calls \
  --approval-mode never \
  'PROMPT GOES HERE'

Zadanie 1, naprawa błędu. 

Sukces jest tu binarny: 6 testów przechodzi, albo nie. 

The test suite tests/test_filesize.py is failing. 
Fix the source code in src/humanize/ so that all tests pass. 
Do not modify any file in tests/.

Zadanie 2, mała funkcja.

Na tyle otwarte, że dwa modele mogą się nie zgodzić co do zakresu, co faktycznie miało znaczenie.

Add a function called natural_list_with_limit to src/humanize/lists.py. 
It formats a list but truncates after a given number of items, appending "and N more". 
Export it from the package and add tests.

Zadanie 3, refaktoryzacja.

Najcięższe z trzech, dotyka kilku plików.

src/humanize/number.py is 571 lines. 
Split it into two modules along a sensible boundary, 
update all imports across the package, and make sure the full test suite still passes.

Trzy zadania biegły sekwencyjnie bez resetu między nimi, więc 2 i 3 budowały na tym, co model wyprodukował wcześniej. Oba modele przeszły tę samą ścieżkę.

Liczby tokenów pochodzą z logów sesji w ~/.local/share/muse/sessions/, liczone raz na ukończenie modelu. Wszystkie sześć biegów przeszło testy.

I delty, gdzie wartość ujemna oznacza, że 1.3 zużyła mniej:

Uczciwa interpretacja wyniku

Dwa z trzech zadań wyszły taniej, z 23% i 32% mniejszą liczbą ukończeń. To dokładnie pokrywa deklarację Meta o wywołaniach narzędzi. Refaktoryzacja poszła w drugą stronę: o 70% więcej ukończeń i o 38% wyższy koszt.

Łącznie w trzech zadaniach 1.3 kosztowała o 12% więcej niż 1.2. Więc deklaracja wydajności jest prawdziwa, ale zależna od zadania, a pojedynczy headline całkowicie to zaciera.

Wejście bez cache spadło w każdym zadaniu o 19%, 22% i 5%. Nigdy o 25%. 

Meta nie mówi, które tokeny liczyła, a odpowiedź bardzo się zmienia w zależności od tego, czy masz na myśli wejście, wyjście, bez cache czy łącznie.

Współczynniki trafień cache wyniosły 88% do 97% i rosły z długością zadania. Raportowanie surowej liczby tokenów wejściowych bez rozdzielenia cache od non-cache byłoby niemal bez sensu, bo 4,18M wejścia przy refaktoryzacji to w rzeczywistości 109k nowego kontekstu plus 4,07M ponownych odczytów rozliczanych po pięćdziesiątej stawce.

Dlaczego refaktoryzacja to nie czysta strata

Zobacz, co 1.3 faktycznie zrobiła w tym zadaniu, zanim nazwiesz to niewydajnym.

Zweryfikowała programowo, że każdy przeniesiony blok jest bajtowo identyczny z oryginałem. 

Uruchomiła --doctest-modules na obu nowych plikach. Przetestowała rozwiązywanie importów z tymczasowego katalogu w /tmp. Potem zaznaczyła dwie rzeczy, o które nikt nie prosił: że funkcja humanize.scientific cieniuję nowy submoduł, oraz że doctest naturaldelta pada identycznie na czystym drzewie, więc awaria nie wynika ze zmiany.

Muse Spark 1.2 zduplikowała funkcję pomocniczą, by ominąć cykliczny import i poszła dalej. 1.3 zaimportowała ją i wyjaśniła, czemu cyklu nie ma.

Nie da się oddzielić „spaliła więcej tokenów” od „zrobiła dokładniejszą robotę” przy tym projekcie. Uczciwe stwierdzenie jest takie, że 1.3 wydała więcej i dostarczyła więcej, a to, czy to plus, zależy od tego, czy chciałeś tej dodatkowej rygorystyki.

Zadanie z funkcją pokazuje odwrotny wzorzec i jest najczystszą ilustracją deklaracji Meta o „mniejszej rozwlekłości”. Muse Spark 1.2 wymyśliła aliasy parametrów max_items, n i max_len, których nikt nie prosił, i napisała 28 testów. 

Muse Spark 1.3 napisała jedną sygnaturę z sensowną domyślną wartością i 20 testów, o 54% mniej tokenów wyjściowych.

Czego nie mogłem kontrolować

Cztery rzeczy i bez nich artykuł byłby nieuczciwy.

1. Muse Code zaktualizował się z 1.0.2 do 1.0.3 w trakcie, więc uprząż nie była identyczna we wszystkich sześciu biegach. 
2. Zadania 2 i 3 startowały z własnego wcześniejszego outputu każdego modelu, a nie z bajtowo identycznego drzewa, bo sekwencja biegnie bez resetów.
3. Każda komórka to pojedyncza próba, więc zwykła wariancja między biegami nie jest zmierzona. 
4. I całość uruchomiłem na poziomie contributor, czyli ten sam model, ale inne warunki dotyczące danych.

Żadne z tego nie unieważnia kierunku wyników. Oznacza jednak, że 12% różnicy łącznej to słabszy sygnał niż trzy zgodne biegi na komórkę.

Najlepsze praktyki i rozwiązywanie problemów w Muse Spark 1.3

Kilka rzeczy, które chciałbym wiedzieć pierwszego dnia.

Promptowanie pod zachowania współpracy

Muse Spark 1.3 zadaje pytania doprecyzowujące przy niejednoznacznych promptach, więc nadmiernie wyspecyfikowany prompt wyłącza funkcję, za którą płacisz. Kontrintuicyjne, jeśli spędziłeś dwa lata ucząc się ładować wszystkie instrukcje z góry.

Zakres nadal ma znaczenie. „Podziel number.py” zostawia modelowi zgadywanie granicy, aktualizacji importów i definicji done. Wersja, której faktycznie użyłem, precyzuje wszystkie trzy:

src/humanize/number.py is 571 lines. Split it into two modules along a sensible boundary, update all imports across the package, and make sure the full test suite still passes.

Jeszcze jedna rzecz. Mój prompt do refaktoryzacji mówił number.py is 571 lines. Ma 567. Oba modele poprawiły mnie bez pytania, a 1.3 w pierwszym zdaniu. Moja liczba pochodziła z pomiaru tipa repo zamiast przypiętego commita.

Trzymanie kosztów w ryzach

Umieść stabilną część promptu na początku, żeby była keszowalna. Przy 88–97% trafień cache twoje zachowanie cache’owania wpływa na rachunek znacznie bardziej niż wybór modelu.

Trzy zadania kosztowały łącznie $0.034 na contributor. Ta sama praca na standard kosztowałaby $0.91, 27x więcej. Tak wygląda decyzja o poziomie w pieniądzach: trzy centy kontra dziewięćdziesiąt.

Jeśli idziesz przez OpenRouter, wyszukiwanie w sieci jest rozliczane osobno po $2.50 za 1000 wywołań.

Kiedy Muse Spark 1.3 to zły wybór

• Brak ujawnionych śladów rozumowania. Widzisz, co zdecydował, nie dlaczego, co utrudnia debug złej refaktoryzacji.
• Max reasoning jest zablokowany, więc konfiguracja za każdą nagłówkową liczbą benchmarkową jest poza stołem.
• Zamknięte wagi. Bez self-hostingu, bez fine-tuningu. Roadmapa Meta wspomina „wydanie otwartych wag Muse Spark” bez wersji, daty ani licencji.
• Jeden dostawca. Gdy endpoint Meta degraduje, nie ma dokąd routować.

Typowe problemy i rozwiązania

• muse: command not found po czystej instalacji. Skrypt instaluje do ~/.local/bin/muse, co nie zawsze jest na PATH w każdej powłoce.
• Not logged in. Run muse again to log in. Dokładnie to znaczy. Pierwszy muse wychodzi, drugi startuje logowanie.
• Jesteś na poziomie contributor i go nie wybierałeś. To domyślne. Sprawdź pasek statusu i uruchom /model przed otwarciem czegokolwiek zastrzeżonego.
• ultra rozumowanie po cichu staje się xhigh. Bramka jest zamknięta. Czytaj stderr zamiast ufać podanej fladze.
• Muse Code aktualizuje się w trakcie sesji. U mnie było 1.0.2 do 1.0.3 między biegami. Jeśli cokolwiek mierzysz, przypnij i zapisz wersję.

Jedna rzecz, której nie odtworzyłem

Krążyły doniesienia, że użytkownicy z UE wciąż dostawali Muse Spark 1.1 po wydaniu 1.3. Ja uruchamiałem to wszystko z Holandii i cały czas miałem 1.3. Te raporty dotyczyły Meta.ai, asystenta konsumenckiego, i nie wydają się dotyczyć Muse Code ani Model API. Dwa różne rollouty.

Na koniec

Deklaracja wydajności Meta utrzymała się w dwóch z moich trzech zadań i odwróciła w trzecim, co dało łącznie 12% wzrost kosztu. Część o wywołaniach narzędzi wygląda solidnie przy 23% i 32% redukcji tam, gdzie 1.3 wygrała. Część o tokenach zależy całkowicie od tego, które tokeny liczysz.

Jeśli już jesteś na Meta Model API lub w Muse Code, podmiana ID modelu zajmuje minutę i prawdopodobnie wyjdziesz na plus w rutynowej pracy. Jeśli wybierasz świeżo dla agentów produkcyjnych, zablokowany wariant max i brak śladów rozumowania to konkretne powody, by poczekać kilka tygodni.

Rzecz, na którą faktycznie bym zareagował, to nie liczba wydajności. To, że Muse Code domyślnie stawia cię na poziomie kwalifikującym do treningu oraz że udokumentowany poziom rozumowania cicho degraduje, gdy o niego prosisz. Obie to jedna linijka do sprawdzenia i łatwo je przeoczyć.

Przeprowadź porównanie na własnym workloadzie. Moje trzy zadania to nie twoje trzy, a rozrzut między nimi był większy niż różnica między modelami.

Po pełny obraz benchmarków zajrzyj do analizy Matta Muse Spark 1.3. Żeby zbudować umiejętności samodzielnej oceny takich modeli, zacznij od naszego skill tracku AI Agent Fundamentals.