Skip to content

feat: add Muse Spark 1.3 support - #77

Merged
brentvatne merged 2 commits into
mainfrom
abbo/muse-spark-1.3
Sep 6, 2026
Merged

brentvatne merged 2 commits into
mainfrom
abbo/muse-spark-1.3

Conversation

@Abbondanzo

@Abbondanzo Abbondanzo commented Sep 3, 2026 •

Copy link
Copy Markdown
Collaborator

Muse 1.3 dropped today: https://research.meta.ai/blog/introducing-muse-spark-1-3

Adds Muse Spark 1.3 support through Meta’s public Model API. The CLI registers known 1.3 and Contributor metadata, routes any explicitly configured meta/ through Meta for forward compatibility, and preserves the fixed Responses endpoint and META_API_KEY credential path. Also updates setup guidance, templates, LLP documentation, and tests.

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown

🤖 AI code review

Decision: Ready for human review (with comments)

Overall PR risk: Medium. This change modifies Meta model preflight validation by allowing unknown meta/<model> ids to pass through unchecked. Mistyped model ids now fail at runtime on each pass instead of once at config time, consuming budget identically across passes. The affected surface is limited to configurations explicitly using the Meta provider; the default scaffold is untouched. One warning found: the Meta preflight no longer catches mistyped model ids.

🔗 Review setup:

  • This PR changes code the reviewer prompts cite (src, src/tests, templates, templates/config.jsonc). Check that the guidance quoting it is still correct.

🟡 Warning (1)

  • Meta model preflight no longer catches a mistyped model id — src/core/opencode.ts:308 (correctness) · id:9590f07ca088
    Confidence: High — traced through assertModelsResolvable, fetchProviderModels, and findUnknownModels, and confirmed against the removed test that asserted the old behavior.
    Impact if shipped: Medium — a mistyped meta/... model id is no longer caught before any review pass runs; it now fails once per pass instead of once up front.
    Suggested remediation: Keep unknown meta/ ids out of provider.meta.models (or otherwise mark them so findUnknownModels can still flag a clear typo), and only apply the neutral-metadata fallback for ids that pass a basic well-formed-name check the team is willing to accept as a new family.

    Evidence and reasoning

    The new loop adds every referenced meta/<model> id to provider.meta.models, using {} for any id not in META_MUSE_MODELS. This includes ids that are plain typos, not just future model names.

    assertModelsResolvable (src/core/opencode.ts:621) calls fetchProviderModels, which reads the OpenCode server's own /config/providers list. That list reflects the declared config, not a live check against the real Meta endpoint. Because the typo'd id is now declared as a model key (even with empty metadata), the server reports it as "available", so findUnknownModels (src/core/opencode.ts:508) no longer flags it, and the preflight throw in review.ts (src/core/review.ts:461-480) never fires.

    The doc comment directly above that preflight call states the intended invariant this change breaks: "a model id an engine can't resolve would otherwise fail EVERY pass routed to it identically — N indistinguishable coverage gaps, after spending the run's budget rediscovering the same fixable thing. Throw once, up front, naming the fix" (src/core/review.ts:448-450). With this change, a Meta model typo instead surfaces as a real API rejection on each pass that uses it, producing the exact multiplied, budget-spending failure mode the preflight exists to prevent — only for the Meta provider, not the others.

    The test that previously locked in the old behavior ("Meta provider does not register an unknown Muse id, so preflight can reject it") was deleted and replaced with one that asserts the new, permissive behavior, confirming this is a real behavior change and not a test gap.


This review is advisory — it never blocks a merge and never auto-approves.

@brentvatne
brentvatne merged commit 65ffc81 into main Sep 6, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants