feat(slack): bump models to Claude 4.X flagships#4208
Conversation
Update the Slack integration model picker to Sonnet 4.6 (default), Opus 4.7, and Haiku 4.5, and bump the error-formatter from claude-3-5-haiku to claude-haiku-4-5. Backfill stored model preferences so users who had explicitly selected Sonnet 4.5 / Opus 4.6 transparently move to the new flagships rather than continuing on legacy snapshots while the App Home picker (which falls back to the first list option for display) shows the new label.
📝 WalkthroughWalkthroughThe PR upgrades Slack integration to use newer Claude model versions. The constants define available models with Sonnet 4.6 and Opus 4.7, error formatting switches to Haiku 4.5, and a database migration backfills existing Slack user preferences to the new model versions. ChangesClaude Model Version Upgrade
🎯 2 (Simple) | ⏱️ ~12 minutes
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR bumps the Slack integration's Claude model lineup to the 4.x flagships (Sonnet 4.6, Opus 4.7) and adds a Drizzle data migration to remap stored
Confidence Score: 5/5Safe to merge — the migration correctly remaps the two renamed model IDs, the column is an unconstrained text field, and Haiku 4.5 is intentionally unchanged. The constants update, migration, and fallback logic in build-home-view.ts are all consistent. The formatErrorForSlack change moves from the floating claude-3-5-haiku-latest alias to the pinned claude-haiku-4-5, which is a cross-generation upgrade (3.5 → 4.5 Haiku) — likely intentional given the PR framing, but carries a potential pricing difference worth double-checking. No files require special attention. The migration SQL and snapshot are consistent; model_preference has no enum or check constraints that would block the data update.
|
| Filename | Overview |
|---|---|
| apps/api/src/app/api/integrations/slack/constants.ts | Updates SLACK_MODELS array and DEFAULT_SLACK_MODEL to the new Claude 4.x flagship IDs (Sonnet 4.6, Opus 4.7); Haiku 4.5 is unchanged. |
| apps/api/src/app/api/integrations/slack/events/utils/run-agent/run-agent.ts | Bumps error-formatter model from claude-3-5-haiku-latest (Claude 3.5) to claude-haiku-4-5 (Claude 4 generation); this is a generational upgrade, not just a versioning alias. |
| packages/db/drizzle/0047_backfill_slack_model_preferences.sql | Two-statement data migration remapping stored Sonnet (4.5→4.6) and Opus (4.6→4.7) preferences; model_preference is a plain text column so no schema change needed. |
| packages/db/drizzle/meta/_journal.json | Drizzle journal appended with migration 0047 entry; auto-generated, no issues. |
| packages/db/drizzle/meta/0047_snapshot.json | Drizzle schema snapshot for migration 0047; model_preference remains a nullable text column with no check constraints, consistent with the plain-UPDATE migration approach. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[User opens App Home] --> B{model_preference in DB?}
B -- NULL --> C[Use DEFAULT_SLACK_MODEL: claude-sonnet-4-6]
B -- old: claude-sonnet-4-5 --> D[Migration 0047: UPDATE to claude-sonnet-4-6]
B -- old: claude-opus-4-6 --> E[Migration 0047: UPDATE to claude-opus-4-7]
B -- claude-haiku-4-5 --> F[No change needed]
D --> G[build-home-view finds new value in SLACK_MODELS]
E --> G
F --> G
C --> G
G --> H[Render picker: Sonnet 4.6 / Opus 4.7 / Haiku 4.5]
I[User sends @-mention] --> J{params.model?}
J -- stored preference --> K[runSlackAgent with new model ID]
J -- NULL/fallback --> L[Use DEFAULT_SLACK_MODEL: claude-sonnet-4-6]
K --> M[Anthropic API]
L --> M
N[API error occurs] --> O[formatErrorForSlack: claude-haiku-4-5]
Reviews (1): Last reviewed commit: "feat(slack): bump models to Claude 4.X f..." | Re-trigger Greptile
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/api/src/app/api/integrations/slack/events/utils/run-agent/run-agent.ts (1)
135-135: ⚡ Quick winHardcoded model ID duplicates the value in
constants.ts.
"claude-haiku-4-5"is already present asSLACK_MODELS[2].valueinconstants.ts. If Haiku is bumped to a new version, both this line and the constants file need updating. Exporting a dedicated constant (e.g.SLACK_ERROR_MODEL) keeps the two in sync automatically.♻️ Proposed refactor
In
constants.ts:export const SLACK_MODELS = [ { value: "claude-sonnet-4-6", label: "Sonnet 4.6" }, { value: "claude-opus-4-7", label: "Opus 4.7" }, { value: "claude-haiku-4-5", label: "Haiku 4.5" }, ] as const; export const DEFAULT_SLACK_MODEL = "claude-sonnet-4-6"; +export const SLACK_ERROR_MODEL = "claude-haiku-4-5";In
run-agent.ts(line 7 import):-import { DEFAULT_SLACK_MODEL } from "../../../constants"; +import { DEFAULT_SLACK_MODEL, SLACK_ERROR_MODEL } from "../../../constants";- model: "claude-haiku-4-5", + model: SLACK_ERROR_MODEL,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/api/src/app/api/integrations/slack/events/utils/run-agent/run-agent.ts` at line 135, The run-agent.ts file currently hardcodes the model string "claude-haiku-4-5" (the model property in the request payload); replace this with a shared constant exported from constants.ts (e.g. export SLACK_ERROR_MODEL = SLACK_MODELS[2].value) and import that constant into run-agent.ts so the model used in the payload references SLACK_ERROR_MODEL instead of the literal string; update the import list in run-agent.ts and ensure the model: field uses the imported constant to keep versions in sync.apps/api/src/app/api/integrations/slack/constants.ts (1)
1-7: 💤 Low valueModel IDs confirmed valid;
DEFAULT_SLACK_MODELcould optionally be derived fromSLACK_MODELS.All three model identifiers (
claude-sonnet-4-6,claude-opus-4-7,claude-haiku-4-5) are confirmed valid pinned snapshot IDs per the Anthropic API docs. TheDEFAULT_SLACK_MODELstring duplicatesSLACK_MODELS[0].value; if the default model is ever changed in the array without updating the constant, they'll silently diverge.♻️ Optional: derive DEFAULT_SLACK_MODEL from the array
-export const DEFAULT_SLACK_MODEL = "claude-sonnet-4-6"; +export const DEFAULT_SLACK_MODEL = SLACK_MODELS[0].value;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/api/src/app/api/integrations/slack/constants.ts` around lines 1 - 7, The DEFAULT_SLACK_MODEL constant duplicates the hard-coded string that's already present as SLACK_MODELS[0].value which can drift if the array order changes; change DEFAULT_SLACK_MODEL to derive its value from the SLACK_MODELS array (use SLACK_MODELS[0].value) so the default always reflects the first entry in SLACK_MODELS and avoid duplicated literals; update references to DEFAULT_SLACK_MODEL if any typing needs adjusting to accept the derived value.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/db/drizzle/0047_backfill_slack_model_preferences.sql`:
- Around line 1-2: This PR inserted manual data-migration SQL (the two UPDATE
statements targeting "users__slack_users" model_preference values and the
accompanying edit to meta/_journal.json) into a Drizzle-managed output folder,
which must not be edited; move those UPDATE statements into a new standalone
data-migration script outside the Drizzle output tree (e.g., a dedicated
migrations/data or scripts folder) and remove the SQL and any manual changes to
meta/_journal.json from the Drizzle-generated directory so Drizzle outputs
remain untouched, then run the new script separately as part of deployment
and/or document it in your migration runbook.
---
Nitpick comments:
In `@apps/api/src/app/api/integrations/slack/constants.ts`:
- Around line 1-7: The DEFAULT_SLACK_MODEL constant duplicates the hard-coded
string that's already present as SLACK_MODELS[0].value which can drift if the
array order changes; change DEFAULT_SLACK_MODEL to derive its value from the
SLACK_MODELS array (use SLACK_MODELS[0].value) so the default always reflects
the first entry in SLACK_MODELS and avoid duplicated literals; update references
to DEFAULT_SLACK_MODEL if any typing needs adjusting to accept the derived
value.
In `@apps/api/src/app/api/integrations/slack/events/utils/run-agent/run-agent.ts`:
- Line 135: The run-agent.ts file currently hardcodes the model string
"claude-haiku-4-5" (the model property in the request payload); replace this
with a shared constant exported from constants.ts (e.g. export SLACK_ERROR_MODEL
= SLACK_MODELS[2].value) and import that constant into run-agent.ts so the model
used in the payload references SLACK_ERROR_MODEL instead of the literal string;
update the import list in run-agent.ts and ensure the model: field uses the
imported constant to keep versions in sync.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 04eaff93-4fe1-47b7-bf47-8b82cd8034c4
📒 Files selected for processing (5)
apps/api/src/app/api/integrations/slack/constants.tsapps/api/src/app/api/integrations/slack/events/utils/run-agent/run-agent.tspackages/db/drizzle/0047_backfill_slack_model_preferences.sqlpackages/db/drizzle/meta/0047_snapshot.jsonpackages/db/drizzle/meta/_journal.json
| UPDATE "users__slack_users" SET "model_preference" = 'claude-sonnet-4-6' WHERE "model_preference" = 'claude-sonnet-4-5';--> statement-breakpoint | ||
| UPDATE "users__slack_users" SET "model_preference" = 'claude-opus-4-7' WHERE "model_preference" = 'claude-opus-4-6'; |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | 🏗️ Heavy lift
Coding guideline violation: files in packages/db/drizzle/ must not be manually edited.
This file (and the accompanying edit to packages/db/drizzle/meta/_journal.json) are manually authored but live under the directory the guideline reserves exclusively for Drizzle-generated output. Drizzle cannot auto-generate data-only backfill migrations, so the common workaround is to keep hand-written data migrations outside the managed directory (e.g., packages/db/migrations/data/ or a dedicated scripts folder) and run them separately from the schema migration pipeline. Placing them here risks a future drizzle-kit generate run overwriting or conflating them.
As per coding guidelines: "Never manually edit files in packages/db/drizzle/ — these are auto-generated by Drizzle. Only modify schema files in packages/db/src/schema/."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/db/drizzle/0047_backfill_slack_model_preferences.sql` around lines 1
- 2, This PR inserted manual data-migration SQL (the two UPDATE statements
targeting "users__slack_users" model_preference values and the accompanying edit
to meta/_journal.json) into a Drizzle-managed output folder, which must not be
edited; move those UPDATE statements into a new standalone data-migration script
outside the Drizzle output tree (e.g., a dedicated migrations/data or scripts
folder) and remove the SQL and any manual changes to meta/_journal.json from the
Drizzle-generated directory so Drizzle outputs remain untouched, then run the
new script separately as part of deployment and/or document it in your migration
runbook.
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
Recorded as integrated via -s ours after batch PRs #455-#464. Taken via individual PRs: - PR 1 (#455): v2 polish 前半 safe set (9 commits) - PR 2 (#456): v2/host-service polish 中盤 (12 commits) - PR 3 (#457): sidebar polish + jwt API (5 commits) - PR 4 (#458): host-service tRPC retry/cache/timeout (3 commits) - PR 5 (#459): v2 diff pane / file pane polish (2 commits) - PR 7 (#462): host-service v2 canonical workspace.create + attachment store (PR1 superset-sh#3893 + PR2 superset-sh#3916) - PR 11 (#463): agents API + onboarding (7 commits + 1 cleanup) - PR 12 (#464): v1→v2 import flow rewrite (11 commits + 2 follow-ups) - PR 13 (#460): host-service shell env probe + typo (2 commits) - PR 16 (#461): marketplace 19 themes (1 commit) Skipped / deferred (recorded as integrated for behind=0): - PR 6: CLI v1 launch (superset-sh#3898 + 30+ CLI/SDK followups) — defer to dedicated migration - PR 9: v2 PR3 (superset-sh#3940) + revert (superset-sh#4017) — net-zero pair - PR 10: pty-daemon (superset-sh#3896, superset-sh#3971, superset-sh#4054) — fork keeps its terminal-host - PR 14: Slack MCP-v2 (superset-sh#4197, superset-sh#4208) — depends on mcp-v2/sdk divergence - PR 15: onboarding remaining (superset-sh#4115, superset-sh#4125, superset-sh#4214, superset-sh#4213, superset-sh#4222, superset-sh#4225) — depends on fork's deleted setup pages Behind: 0 after this merge.
Summary
apps/api/src/app/api/integrations/slack/constants.ts.run-agent.tsbumped fromclaude-3-5-haiku-latesttoclaude-haiku-4-5.0047_backfill_slack_model_preferencesremaps storedusers__slack_users.model_preferencerows:claude-sonnet-4-5 → claude-sonnet-4-6,claude-opus-4-6 → claude-opus-4-7. Without this, users who had explicitly picked the old options would keep silently running the legacy model while the App Home picker (which falls back toSLACK_MODELS[0]for display) showed the new label — confusing mismatch.V2_SYSTEM_PROMPTselected when theslack-mcp-v2flag is on. It mirrors the CLI skill's project → host → workspace → agent mental model and adds three rules that came out of an actual frustrating user thread:workspaces_createis name-deduped per host; when it returnsalreadyExists: true, surface it as a question, not a:white_check_mark: Done.<user>/<slug>branch — don't reuse names from earlier in the conversation.getActionFromToolResultnow gates theworkspace_createdaction on!alreadyExists, so the "Changes:" footer stops claiming a workspace was created when the host actually returned an existing one.Test plan
claude-haiku-4-5.users__slack_usersrows on the old IDs — confirm rows update to new IDs.slack-mcp-v2flag on, ask "make a new workspace on Town-Hall" twice — second call should produce a different unique name + fresh branch, not "already existed".