feat: add MiniMax as an alternative LLM provider (M3 default)

[octo-patch]

Summary

Add MiniMax as an alternative LLM provider to bolt.new, with MiniMax-M3 as the default model. Users can switch from Anthropic (Claude) to MiniMax by setting DEFAULT_LLM_PROVIDER=minimax and MINIMAX_API_KEY in .env.local.

Changes

• Add getMiniMaxModel to app/lib/.server/llm/model.ts using @ai-sdk/openai with the OpenAI-compatible endpoint https://api.minimax.io/v1
• Add LLMProvider type and getModel(provider, ...) to dispatch by provider
• Add getMiniMaxAPIKey, getLLMProvider, getProviderAPIKey helpers in app/lib/.server/llm/api-key.ts
• Extend worker-configuration.d.ts with MINIMAX_API_KEY and DEFAULT_LLM_PROVIDER env bindings
• Update CONTRIBUTING.md to document the new provider and how to configure it
• Add unit tests (model.spec.ts, api-key.spec.ts) and an opt-in E2E test (minimax.e2e.spec.ts, skipped without MINIMAX_API_KEY)

Model Configuration

The MiniMax provider supports:

Model	Role
MiniMax-M3	Default — 512K context, up to 128K output, image input support
MiniMax-M2.7	Previous-generation alternative
MiniMax-M2.7-highspeed	Previous-generation low-latency alternative

Anthropic remains the default provider; nothing changes for existing users unless they opt in to MiniMax.

Why MiniMax-M3?

MiniMax-M3 is the latest model in the MiniMax family:

• 512K context window
• Up to 128K max output tokens
• Image input support on both OpenAI-compatible and Anthropic-compatible endpoints

See pricing: https://platform.minimax.io/docs/guides/pricing-paygo

Testing

• pnpm test — all unit tests pass (22 tests)
• E2E test (minimax.e2e.spec.ts) verified end-to-end against the MiniMax API with MINIMAX_API_KEY set: basic chat with M3, streaming with M3, and the MiniMax-M2.7-highspeed alternative
• Existing Anthropic flow unaffected — defaults to Claude when DEFAULT_LLM_PROVIDER is unset

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[ivanm696]

Skip to content
bolt-new-local
Repository navigation
Code
Issues
Settings
Settings: ivanm696/bolt-new-local
Access
Code and automation
Security and quality
Integrations
Rulesets
/
Protect
Active
Ruleset created
Ruleset Name
*
Protect
Enforcement status
Bypass list
Exempt roles, teams, agents, apps, and users from this ruleset by adding them to the bypass list.
MaintainRole
Always allow
Select bypass mode
Cloudflare Workers and Pages
Cloudflare Workers and PagesApp • cloudflare
Always allow
Select bypass mode
Target branches
Which branches should be matched?
Branch targeting criteria
All branches
Applies to 1 target:
main
.
Rules
Which rules should be applied?
Branch rules

Restrict creations
Only allow users with bypass permission to create matching refs.

Restrict updates
Only allow users with bypass permission to update matching refs.

Restrict deletions
Only allow users with bypass permissions to delete matching refs.

Require linear history
Prevent merge commits from being pushed to matching refs.

Require deployments to succeed
Choose which environments must be successfully deployed to before refs can be pushed into a ref that matches this rule.

Require signed commits
Commits pushed to matching refs must have verified signatures.

Require a pull request before merging
Require all commits be made to a non-target branch and submitted via a pull request before they can be merged.
Required approvals
The number of approving reviews that are required before a pull request can be merged.

Dismiss stale pull request approvals when new commits are pushed
New, reviewable commits pushed will dismiss previous pull request review approvals.

Require review from specific teams
A collection of reviewers and associated file patterns. Each reviewer has a list of file patterns which determine the files that reviewer is required to review.

Require review from Code Owners
Require an approving review in pull requests that modify files that have a designated code owner.

Require approval of the most recent reviewable push
Whether the most recent reviewable push must be approved by someone other than the person who pushed it.

Require conversation resolution before merging
All conversations on code must be resolved before a pull request can be merged.
Allowed merge methods
When merging pull requests, you can allow any combination of merge commits, squashing, or rebasing. At least one option must be enabled.

Require status checks to pass
Choose which status checks must pass before the ref is updated. When enabled, commits must first be pushed to another ref where the checks pass.

Block force pushes
Prevent users with push access from force pushing to refs.

Require code scanning results
Choose which tools must provide code scanning results before the reference is updated. When configured, code scanning must be enabled and have results for both the commit and the reference being updated.

Require code quality results
Choose which severity levels of code quality results should block pull request merges. When configured, a code quality analysis must be done on the pull request before the changes can be merged.

Automatically request Copilot code review
Request Copilot code review for new pull requests automatically if the author has access to Copilot code review and their premium requests quota has not reached the limit.
Footer
© 2026 GitHub, Inc.
Footer navigation
Terms
Privacy
Security
Status
Community
Docs
Contact
Manage cookies
Do not share my personal information
List updated, Focused item: Maintain, selected, 3 of 28