Muse Spark 1.3 튜토리얼: 실전 개발자 가이드

Meta는 2026년 9월 2일 Muse Spark 1.3을 출시했으며, 업그레이드 방법은 한 줄로 끝납니다: 모델 ID를 바꾸세요. 즉, 동일한 엔드포인트, 동일한 SDK, 동일한 가격을 사용합니다.

Meta에 따르면 그 한 줄 수정으로 얻는 것은 동일한 작업을 완료하는 데 도구 호출은 약 20% 줄고 토큰은 25% 줄어든 모델입니다. 이 수치는 Meta 엔지니어들이 공개하지 않은 작업에서, 방법론 설명 없이 수행한 비교에서 나왔습니다.

바로 이런 류의 주장은, 인용하기 전에 직접 확인해 보고 싶습니다. 

그래서 Muse Code를 설치하고, 실제 오픈 소스 프로젝트를 일부러 깨뜨린 다음, 두 모델에 동일한 세 가지 작업을 돌려 봤습니다.

이 Muse Code 튜토리얼을 따라 하려면 Meta 개발자 계정, 익숙한 터미널, 그리고 Muse Code 에이전트를 위한 macOS 또는 Linux가 필요합니다. 현재 베타에서는 Windows 사용자는 아직 어렵습니다.

핵심 요약

• Muse Spark 1.3은 Meta의 플래그십 멀티모달 추론 모델로, 2026년 9월 2일 출시되었으며 100만 토큰 컨텍스트 윈도를 제공합니다.
• Muse Code는 기본적으로 muse-spark-1.3-contributor로 시작하며, 전환하지 않으면 Meta가 여러분의 코드로 학습한다는 뜻입니다. 학습은 옵트인(opt-in)이 아니라 옵트아웃(opt-out)입니다.
• 3가지 코딩 작업을 6회 실행한 결과, 1.3은 2개 작업에서 더 저렴했고 나머지 하나에서는 38% 더 비쌌으며, 전체적으로는 비용이 12% 증가했습니다.
• 1.3이 우세했던 2개 작업에서는 모델 컴플리션이 각각 23%, 32% 감소해 Meta의 도구 호출 감소 주장과 일치했습니다. 언캐시드 입력은 세 작업 모두 줄었지만 25%까지는 아니었습니다.
• ultra 추론 레벨은 CLI와 세션 내 선택기에는 존재하지만, 백엔드는 명시적 기능 게이트로 이를 거부합니다.

Muse Spark 1.3이란?

Muse Spark 1.3은 Meta Superintelligence Labs가 2026년 9월 2일 출시한 Meta의 플래그십 멀티모달 추론 모델로, 대규모 저장소에서의 장시간 에이전트 세션 및 코딩에 맞춰 설계되었습니다. 1,048,576 토큰 컨텍스트를 보유하며 텍스트, 이미지, 비디오, 파일을 입력으로 받습니다.

Muse Spark 1.2에서 여섯 가지가 바뀌었습니다:

• 효율성. Meta 내부 비교 기준으로 도구 호출 약 20% 감소, 토큰 25% 감소.
• 협업성. 애매한 프롬프트에 대해 명확화 질문을 하고, 중대한 작업 전 확인합니다.
• 한 스레드 내 멀티태스킹으로, 흐름 중간에 보낸 메시지도 의도한 작업에 연결됩니다.
• 장문 지시 따르기가 개선되어, 다단계 작업에서 누락 제약이 줄었습니다.
• 더 나은 보정으로, 되돌릴 수 없는 작업에 신중합니다.
• 더 깔끔한 코딩 스타일. 불필요한 턴과 장황함이 줄었습니다.

모두 좋아 보이지만, Meta가 공개한 스코어카드는 Muse Spark 1.3을 max 추론으로, Muse Spark 1.2는 xhigh로 돌렸고, max는 출시 시점에 여전히 게이트가 걸려 있었습니다. 

Artificial Analysis는 출하된 xhigh 변형을 Intelligence Index 61, max를 62로 평가했습니다. 차이는 1점뿐입니다.

Matt Crabtree가 이미 전체 벤치마크 표, 가격 세부, 그리고 GPT-5.6 Sol과 Claude Opus 5와의 비교를 그의 Muse Spark 1.3 출시 분석에서 다뤘습니다. 여기서는 반복하지 않습니다. 지금부터는 설치하고 실제로 돌리면 어떤 일이 일어나는지입니다.

Muse Spark 1.3에 접근하는 방법

세 가지 경로가 있으며, 올바른 선택은 무엇을 만들고 있는지에 달려 있습니다. 아래 표에서 고르고 해당 섹션으로 이동하세요.

터미널 에이전트, Muse Code

Muse Code는 macOS와 Linux용 베타 단계의 Meta 터미널 코딩 에이전트입니다. Muse Spark를 구동하는 하네스이며, 둘은 독립적으로 버전이 올라가므로 muse --version으로는 어떤 모델과 대화하는지 알 수 없습니다. 머릿속에서 둘을 구분해 두세요.

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

이 명령은 230 MB 바이너리를 받아 ~/.local/bin/muse에 놓습니다. 이 경로는 모든 환경에서 PATH에 잡혀 있지는 않습니다. 

이제 무엇이 설치됐는지 확인합니다:

muse --version

2026년 9월 4일 기준 제 환경에서는 Muse Code 1.0.2 (1.0.2-R2040.1)를 반환했습니다. 

베타가 하기엔 다소 특이한 표기입니다. 몇 주 전까지만 해도 서드파티 도구는 Muse Code를 0.2.1로 문서화했기 때문입니다. 어떤 버전을 받았는지 받은 날짜와 함께 고정해 두세요.

작성자 스크린샷. 원라인 스크립트로 Muse Code를 설치한 뒤, macOS에서 1.0.2 버전을 확인.

이제 muse를 실행합니다. 첫 실행에서는 Not logged in. Run muse again to log in이라고 출력하고 종료했습니다. 그래서 두 번 실행해야 하는데, 이런 작은 점이 설치가 실패했다고 생각하게 만듭니다.

두 번째 실행은 OAuth 디바이스 플로우를 시작합니다. 짧은 코드가 포함된 로그인 URL을 출력하고, 동일 코드를 별도로 표시한 뒤, 브라우저에서 승인하기 전에 일치 여부를 확인하도록 요청합니다.

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

Waiting for approval…

이후 다음과 같은 화면이 보여야 합니다. 

작성자 스크린샷. Meta Model API 로그인 플로우로, 자격 증명 발급 전에 계정 정보를 확인합니다. 

브라우저 측에서는 이름을 확인하고 약관에 동의한 뒤, 결제 카드를 받습니다. 약 30초 뒤에 이유가 분명해지므로, 결제 화면의 가격 안내를 대충 넘기지 말고 꼭 읽어보세요.

기본 티어는 여러분의 코드로 학습합니다

터미널로 돌아오면, 세션 헤더가 현재 실행 중인 구성을 알려 줍니다:

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.

모델 이름을 다시 보세요. 기본값이 contributor 변형이며, 새 설치에서, 아무도 묻지 않았는데도 그렇게 설정되어 있습니다.

Meta가 숨기는 건 아닙니다. 모델 이름 아래에 고지가 있고, 결제 화면에서 contributor가 DEFAULT로 표시되며, 상태 표시줄은 작업 중에도 muse-spark-1.3-contributor를 계속 보여줍니다. 

하지만 이는 대부분의 개발자가 기대하는 바와는 부담이 반대로 걸려 있습니다.

클라이언트 저장소 안에서 Muse Code를 열고 작업을 시작하면, 이미 학습 가능 엔드포인트로 코드를 보낸 셈입니다. 첫 프롬프트 전, 상태 표시줄부터 확인하세요.

작성자 스크린샷. 첫 Muse Code 세션에서 기본 모델은 muse-spark-1.3-contributor로 설정되며, 그 아래에 제품 개선 고지가 표시됩니다.

상태 표시줄에는 추론 노력 수준도 보이며, 제 경우 high였습니다. Artificial Analysis가 벤치마크에 사용한 xhigh가 아닙니다. 공개 수치와 결과를 비교할 때 기억할 가치가 있습니다.

티어 선택과 변경

/model을 실행하면 네 가지 옵션과 요금이 표시되는 인터랙티브 선택기가 나타납니다. 이 수치는 Meta의 결제 화면과 일치합니다:

Contributor는 입력에서 약 12배, 출력에서 약 21배 저렴합니다.

그 할인은 여러분의 지식재산(IP)으로 사는 것입니다. Meta의 문구는 "세션 간 메시지를 포함한 여러분의 콘텐츠가 제품 개선을 위해 사용될 수 있음"이며, 이는 단지 전달한 코드만을 의미하지 않습니다.

Muse Spark 1.2의 두 변형도 동일한 가격으로 여전히 선택기에 남아 있습니다. 이는 이후 비교에서 중요한데, 세대 간 요금이 변하지 않으므로 토큰 비교는 정규화 없이 곧바로 비용 비교가 되기 때문입니다.

작성자 스크린샷. /model 선택기에는 네 가지 Muse Spark 변형이 캐시드, 입력, 출력 요금과 함께 표시됩니다.

옵트아웃하려면, 화살표로 muse-spark-1.3로 올려 엔터를 누르세요. 헤더에서 "Discounted tokens" 문구가 사라집니다.

클라이언트 작업에서는 터미널에 나타나지 않는 더 강력한 옵션이 있습니다. Meta에 따르면 제로 데이터 보존 요청을 받기 시작했으며, 토글이 아니라 영업을 통해 처리된다고 합니다. 

보존과 학습은 별개의 문제이며, 대행 계약에서는 보통 둘 다 답을 요구합니다.

레이트 리밋은 티어마다 다르게 동작하지만, 출처마다 설명이 엇갈립니다. Meta 개발자 블로그는 contributor 티어가 요청 수가 아니라 5시간 롤링 윈도우의 토큰 수로 제한된다고 설명합니다. 반면 1.2 출시 당시 기사에서는 분당 60요청 제한을 보도했는데, 이는 전혀 다른 메커니즘입니다. 저는 오후 내내 약 90개 모델 컴플리션 동안 어느 쿼터도 건드리지 않았습니다.

Meta Model API와 OpenRouter

Meta Model API는 OpenAI SDK와 호환되므로, 마이그레이션은 모델 ID만 바꾸고 클라이언트 코드는 그대로 유지하면 됩니다. 모델 ID는 muse-spark-1.3와 muse-spark-1.3-contributor입니다.

OpenRouter에서는 meta/muse-spark-1.3 슬러그로 제공합니다. 대가가 있습니다. OpenRouter는 초당 약 81토큰 처리량을 측정했고, 직접 연결에 대해 Artificial Analysis가 기록한 182보다 낮았습니다. 가용성은 첫 사흘 동안 약 92%였습니다. Meta 단독 제공이므로 페일오버할 두 번째 제공자가 없습니다.

첫 Muse Spark 1.3 세션

이하 모든 내용은 python-humanize/humanize 저장소를 대상으로, 커밋 823ad6096에 고정하여 실행했습니다. 6개 모듈에 걸쳐 1,676줄 소스이며, 테스트는 1초 이내에 끝나고, 도메인은 추가 설명이 필요 없습니다. 여기서는 저장소를 수정하지 않습니다. 

여기서는 쓰기 작업을 맡기기 전에, 에이전트가 코드베이스를 어떻게 탐색하는지 보기 위한 읽기 전용 질문입니다.

코드 읽기 감을 잡기 위한 두 개의 프롬프트, 첫 번째부터 시작합니다: 

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

두 개의 명령을 실행하고 프로젝트 구조를 나열한 뒤, import를 grep하는 대신 AST 파서를 작성했습니다. 답: i18n가 인바운드 임포트 4개로 최다이며, i18n 4, number 2, 그리고 filesize, lists, time, _version가 각각 1입니다.

제 스크립트로 확인했더니 숫자가 달라서, 문제를 잡은 줄 알았습니다. 제 스크립트가 틀렸습니다. 상대 임포트(from ._version import ...)만 세고, 이 패키지에서 더 많이 쓰는 절대 임포트(from humanize.i18n import ...)를 놓쳤습니다. 모델은 둘 다 처리했습니다.

두 번째 프롬프트는 채점이 가능해 꼭 돌려볼 만합니다:

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

총 20개라고 답했습니다: filesize 1, i18n 5, lists 1, number 8, time 5. 전부 맞았습니다. 거기에 더해, i18n.get_translation이 이름상 퍼블릭이지만 i18n.__all__에는 없어서 나머지 네 개만 내보낸다고, 요청하지 않았는데도 덧붙였습니다. 이것도 맞습니다.

그 세션 비용은 8턴에 $0.01였습니다.

Meta가 말하지 않는 추론 레벨

muse --help 에는 다음이 문서화되어 있습니다:

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

세션 내 /effort 선택기는 일곱 중 여섯을 제공하며, none을 뺍니다. 

작성자 스크린샷. /effort 선택기에는 여섯 가지 선택 가능한 추론 레벨이 나열되며, high가 현재로 표시됩니다.

둘 다 ultra라는 레벨을 나열하지만, Meta 발표 어디에도 등장하지 않습니다. Meta의 공식 입장은 "추가 안전성 테스트를 마치는 대로 곧 max 추론을 제공"하겠다는 것입니다.

그래서 요청해 봤습니다:

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

ultra_reasoning_effort라는 명명된 기능 게이트가 있으며 닫혀 있습니다. 기능은 구현되어 있고, 서버 측 스위치가 꺼져 있습니다. 이는 "안전성 테스트 대기"보다 더 구체적인 그림이며, 경고 메시지 안에 "tbh"라는 단어까지 들어 있습니다.

실용적으로 두 가지 포인트가 있습니다. 클라이언트는 백엔드가 제공하지 않는 레벨을, CLI와 선택기 모두에서 광고합니다. 그리고 xhigh로 조용히 다운그레이드하며, stderr 한 줄만 남깁니다. 스크립트나 CI 로그에서는 그냥 흘러가 보지 못할 수 있습니다. 실제 사용된 구성과 다른 구성을 사용했다고 믿게 됩니다.

그 다음, 문서 어디에도 없는 값을 시도했습니다:

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

경고가 전혀 없습니다. 그대로 실행되어 ok를 반환했습니다. 즉, 문서화된 값은 게이트에 걸리는 반면 문서화되지 않은 값은 아무 말 없이 검증을 통과하며, 실제 어떤 노력 수준이 적용됐는지 출력만으로는 알 수 없습니다.

작성자 스크린샷. ultra 요청은 닫힌 기능 게이트와 xhigh로의 조용한 강등을 반환하는 반면, 문서화되지 않은 max는 아무 코멘트 없이 통과합니다.

어떤 추론 레벨로 실행되는지가 중요하다면, 명시적으로 설정하고 stderr을 읽으세요. 전달한 플래그가 실제 사용된 플래그라고 가정하지 마세요.

Muse Spark 1.3의 효율성 주장은 유효한가?

테스트는 이렇습니다. 하나의 오픈 소스 저장소에서 실제 버그 수정을 되돌려 테스트가 진짜로 실패하는 상태를 만들고, 같은 프롬프트와 같은 플래그로 두 모델에 세 가지 코딩 작업을 실행합니다.

이는 위의 탐색 세션과는 별개입니다. 여기의 모든 작업은 코드를 씁니다.

커밋 823ad6096의 소스 변경 부분만 되돌리고 테스트는 유지하면 테스트 6개가 실패합니다. 그 상태에서 시작합니다:

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

모든 실행은 동일한 커맨드 형태를 사용했고, 모델 ID와 프롬프트만 바꿨습니다:

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

작업 1, 버그 수정. 

여기서 성공은 이진입니다: 6개 테스트가 모두 통과하느냐, 아니냐. 

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/.

작업 2, 작은 기능.

두 모델이 범위를 다르게 해석할 여지가 충분하며, 실제로 이것이 중요했습니다.

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.

작업 3, 리팩터링.

세 개 중 가장 무거우며, 여러 파일을 건드립니다.

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.

세 작업은 리셋 없이 연속으로 실행되어, 작업 2와 3은 이전에 모델이 만든 결과를 기반으로 진행되었습니다. 두 모델 모두 같은 경로를 걸었습니다.

토큰 수치는 ~/.local/share/muse/sessions/의 세션 로그에서 가져왔으며, 모델 컴플리션당 한 번 집계했습니다. 여섯 번 모두 테스트를 통과했습니다.

그리고 델타는 다음과 같습니다. 음수는 1.3이 더 적게 사용했음을 의미합니다:

정직하게 결과 읽기

세 작업 중 두 개는 더 저렴했고, 모델 컴플리션이 각각 23%와 32% 줄었습니다. Meta의 도구 호출 주장과 정확히 맞습니다. 반면 리팩터링은 반대로 갔습니다. 컴플리션 70% 증가, 비용 38% 증가입니다.

세 작업을 합치면, 1.3의 비용은 1.2보다 12% 더 들었습니다. 즉, 효율성 주장은 사실이지만 작업에 따라 다르고, 단일 헤드라인 퍼센트는 이를 완전히 숨깁니다.

언캐시드 입력은 각 작업에서 19%, 22%, 5% 감소했습니다. 25% 감소는 한 번도 없었습니다. 

Meta는 어떤 토큰을 셌는지 말하지 않았고, 입력, 출력, 언캐시드, 전체 중 무엇을 의미하느냐에 따라 답은 크게 달라집니다.

캐시 적중률은 88%에서 97%였고 작업 길이가 늘수록 상승했습니다. 캐시와 언캐시드를 구분하지 않고 원시 입력 토큰만 보고하는 것은 거의 무의미합니다. 리팩터링의 418만 입력은 실제로는 10만 9천의 신규 컨텍스트와, 1/50 요금으로 청구되는 407만의 재읽기이기 때문입니다.

리팩터링이 단순한 손실이 아닌 이유

비효율이라고 결론내리기 전에, 그 작업에서 1.3이 실제로 한 일을 보세요.

옮긴 블록이 원본과 바이트 단위로 동일한지 프로그램적으로 검증했습니다. 

--doctest-modules를 두 새 파일에 대해 실행했습니다. /tmp의 임시 디렉터리에서 임포트 해상도를 테스트했습니다. 그리고 아무도 묻지 않았는데 두 가지를 지적했습니다. humanize.scientific 함수가 새 서브모듈과 이름이 충돌한다는 점, 그리고 naturaldelta doctest가 깨끗한 트리에서도 동일하게 실패하므로, 실패는 변경 때문이 아니라는 점입니다.

Muse Spark 1.2는 순환 임포트를 피하려고 헬퍼 함수를 복제하고 넘어갔습니다. 1.3은 이를 임포트하고 순환이 없음을 설명했습니다.

이 설계에서는 "토큰을 더 썼다"와 "더 철저히 했다"를 분리할 수 없습니다. 정직한 표현은, 1.3은 더 많이 쓰고 더 많이 제공했고, 그것이 이득인지 여부는 추가 엄격함을 원했는지에 달려 있다는 것입니다.

기능 작업은 반대 패턴을 보이며, Meta의 "덜 장황함" 주장을 가장 깔끔히 보여줍니다. Muse Spark 1.2는 아무도 요청하지 않은 max_items, n, max_len 파라미터 별칭을 만들어 28개의 테스트를 작성했습니다. 

Muse Spark 1.3은 합리적인 기본값을 갖춘 하나의 시그니처와 20개의 테스트를 작성했으며, 출력 토큰은 54% 적었습니다.

통제하지 못한 것들

네 가지이며, 이를 밝히지 않으면 글이 정직하지 못합니다.

1. 진행 도중 Muse Code가 1.0.2에서 1.0.3으로 스스로 업데이트되어, 여섯 실행 모두 동일한 하네스는 아니었습니다. 
2. 작업 2와 3은 각 모델의 직전 산출물을 기준으로 시작했지, 바이트 단위로 동일한 트리에서 시작한 것은 아닙니다. 시퀀스가 리셋 없이 진행되기 때문입니다.
3. 모든 셀은 단일 시행이므로, 일반적인 실행 간 분산은 측정되지 않았습니다. 
4. 그리고 전 과정을 contributor 티어에서 돌렸습니다. 같은 모델이지만 데이터 조건은 동일하지 않습니다.

이 어느 것도 결과의 방향성을 무효화하지 않습니다. 다만 12%의 총합 차이는 셀당 세 번 일치하는 실행이 있었을 때보다 신호가 약하다는 뜻입니다.

Mose Spark 1.3 모범 사례와 문제 해결

첫날에 알았으면 좋았을 몇 가지.

협업 행동을 끌어내는 프롬프트

Muse Spark 1.3은 모호한 프롬프트에 명확화 질문을 합니다. 따라서 과도하게 구체화한 프롬프트는 유료 기능을 꺼버리는 셈입니다. 지난 2년간 모든 지시를 앞단에 몰아넣는 법을 배운 분께는 직관에 반합니다.

다만 범위는 여전히 중요합니다. "number.py를 분리해 주세요"는 경계, 임포트 갱신, 완료 기준을 모델이 추측하게 만듭니다. 제가 실제 사용한 버전은 이 세 가지를 모두 명시합니다:

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.

또 알아두면 좋은 점이 하나 있습니다. 제 리팩터링 프롬프트에는 number.py is 571 lines라고 썼습니다. 실제는 567입니다. 두 모델 모두 요청하지 않았는데도 이 점을 바로잡았고, 1.3은 첫 문장에서 지적했습니다. 제 숫자는 고정 커밋이 아니라 저장소 최신을 측정한 결과였습니다.

비용 절감

프롬프트의 변하지 않는 부분을 앞에 두어 캐시 가능성을 유지하세요. 적중률이 88%에서 97%라면, 캐시 동작이 모델 선택보다 요금에 훨씬 큰 영향을 줍니다.

세 작업은 contributor에서 총 $0.034가 들었습니다. 같은 작업을 standard에서 실행하면 $0.91로, 27배 차이입니다. 이는 티어 결정을 돈으로 표현한 것입니다. 3센트 대 90센트.

OpenRouter를 통하면, 웹 검색은 1,000회당 $2.50이 별도 과금됩니다.

Muse Spark 1.3이 맞지 않은 경우

• 추론 추적을 노출하지 않습니다. 무엇을 했는지는 보이지만, 왜 그렇게 했는지는 안 보입니다. 나쁜 리팩터링을 디버깅하기 어려워집니다.
• Max 추론에 게이트가 걸려 있어, 헤드라인 벤치마크가 사용한 구성을 지금은 쓸 수 없습니다.
• 폐쇄 가중치. 자체 호스팅, 파인튜닝 불가. Meta 로드맵에는 버전, 날짜, 라이선스 없이 "Muse Spark 오픈 가중치 릴리스"가 언급됩니다.
• 단일 제공자. Meta 엔드포인트가 저하되면 라우팅할 곳이 없습니다.

흔한 문제와 해결

• muse: command not found — 클린 설치 후. 스크립트는 ~/.local/bin/muse에 설치하며, 이 경로는 모든 셸의 PATH에 잡혀 있지 않습니다.
• Not logged in. Run muse again to log in. 말 그대로입니다. 첫 실행은 종료되고, 두 번째 실행이 로그인 절차를 시작합니다.
• 원치 않았는데 contributor 티어로 되어 있습니다. 기본값입니다. 상태 표시줄을 확인하고, 어떤 자산이든 열기 전에 /model을 실행하세요.
• ultra 추론이 조용히 xhigh로 바뀝니다. 게이트가 닫혀 있습니다. 전달한 플래그를 믿지 말고 stderr을 확인하세요.
• Muse Code가 세션 중간에 업데이트됩니다. 제 경우 실행 사이에 1.0.2에서 1.0.3으로 올라갔습니다. 어떤 측정을 하고 있다면, 버전을 고정하고 기록하세요.

재현되지 않은 한 가지

EU 사용자에게 1.3 출시 후에도 여전히 Muse Spark 1.1이 제공되고 있다는 보고가 있었습니다. 저는 네덜란드에서 전 과정을 실행했으며 내내 1.3을 받았습니다. 해당 보고는 소비자용 어시스턴트 Meta.ai에 관한 것이었고, Muse Code나 Model API에는 적용되지 않는 것으로 보입니다. 서로 다른 롤아웃입니다.

마무리

Meta의 효율성 주장은 제 세 작업 중 두 개에서 성립했고, 세 번째에서는 반대로 나와 전체적으로 12% 비용 증가였습니다. 1.3이 이긴 경우 도구 호출 23%와 32% 감소는 탄탄해 보였습니다. 토큰 측면은 어떤 토큰을 세느냐에 전적으로 달려 있습니다.

이미 Meta Model API나 Muse Code를 쓰고 있다면, 모델 ID 교체에 1분이면 되고, 일상 작업에서는 대체로 이득일 것입니다. 프로덕션 에이전트를 새로 선택하는 상황이라면, 게이트된 max 변형과 부재한 추론 추적은 몇 주 기다릴 만한 구체적 이유입니다.

제가 실제로 행동으로 옮길 부분은 효율성 수치가 아닙니다. Muse Code가 기본으로 학습 가능 티어에 올려둔다는 점, 그리고 문서화된 추론 레벨이 요청 시 조용히 강등된다는 점입니다. 둘 다 한 줄만 확인하면 되지만, 놓치기 쉽습니다.

여러분의 워크로드로 직접 비교해 보세요. 제 세 작업은 여러분의 세 작업이 아니며, 작업 간 편차가 모델 간 차이보다 컸습니다.

전체 벤치마크 그림은 Matt의 Muse Spark 1.3 출시 분석에 표로 정리되어 있습니다. 이런 모델을 스스로 평가하는 역량을 기르고 싶다면, 저희의 AI Agent Fundamentals 스킬 트랙으로 시작하세요.