feat: Add Mercury 2 (Inception Labs) as primary model in fallback chain#29
feat: Add Mercury 2 (Inception Labs) as primary model in fallback chain#29
Conversation
- Adds mercury-coder as first target when INCEPTION_API_KEY is set - Uses openai-compatible provider with base_url https://api.inceptionlabs.ai/v1 - Falls back to existing Groq -> SambaNova -> Cerebras -> OpenRouter chain - Mercury target is conditionally included so it's safe to deploy without the key
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🤖 Augment PR SummarySummary: Introduces Inception Labs Mercury Coder as the first target in the Portkey fallback chain (when Changes:
Technical Notes: Mercury is configured as an OpenAI-compatible provider via 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| const { data, error } = await supabase | ||
| .from("profiles") | ||
| .select("credits") | ||
| .select("*") |
There was a problem hiding this comment.
syncTokensWithDB now does .select("*") but only uses data.credits; this increases payload and can expose extra profile fields to the client unnecessarily. Consider selecting only the columns actually needed (e.g., credits).
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| console.error("Error updating tokens in DB:", error); | ||
| // ONLY allow decrements (usage), never allow increments | ||
| // If local tokens are less than DB credits, sync the lower value | ||
| if (localTokens < currentCredits) { |
There was a problem hiding this comment.
The localTokens < currentCredits branch treats any DB increase as “usage” and deducts the delta; if credits are refreshed server-side (daily reset/subscription) while the client is stale, this can unintentionally burn the newly granted credits. This comparison-based deduction seems unsafe without tracking a last-synced baseline.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| case 'free': | ||
| return 30; | ||
| case 'pro': | ||
| return 100; |
There was a problem hiding this comment.
getBaseCreditsForTier returns 100/1000 for pro/ultra, but the database reset_daily_credits logic elsewhere appears to use different tier amounts in some migrations; a mismatch here can cause repeated/incorrect refresh decisions. It’d be good to ensure these tier constants are consistent with the DB refresh function.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| if (shouldRefresh) { | ||
| try { | ||
| // Call the secure RPC function instead of direct update | ||
| const { data, error: rpcError } = await supabase.rpc('reset_daily_credits'); |
There was a problem hiding this comment.
checkAndRefreshCredits calls reset_daily_credits() as a per-user fallback, but that function is defined as a global daily reset (updates many/all users). Calling it from the browser for one user looks abusable and could unintentionally refresh credits for other accounts.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| type: string = 'adjustment', | ||
| description?: string | ||
| ) { | ||
| const supabase = AuthService.createClient(); |
There was a problem hiding this comment.
CreditsService.addCredits uses AuthService.createClient() (browser anon/user client) to call add_user_credits; if that RPC is executable by authenticated, this becomes a direct credit-granting vector. Also, the default type='adjustment' may be rejected by the DB function if it enforces an allowlist.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
|
|
||
| -- If credits are being updated directly (not through our functions) | ||
| IF OLD.credits IS DISTINCT FROM NEW.credits AND | ||
| pg_trigger_depth() <= 1 -- Only check for direct updates, not those triggered by our stored procedures |
There was a problem hiding this comment.
The trigger’s pg_trigger_depth() <= 1 check won’t distinguish a “direct UPDATE” from an UPDATE performed inside a stored procedure (both fire the trigger at depth 1). As written, non-service-role updates to credits from SECURITY DEFINER functions can still be reverted unintentionally.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| pg_trigger_depth() <= 1 -- Only check for direct updates, not those triggered by our stored procedures | ||
| THEN | ||
| -- Reset to old value if someone tries to bypass RLS | ||
| NEW.credits := OLD.credits; |
There was a problem hiding this comment.
In prevent_direct_credits_update, NEW.credits is overwritten with OLD.credits before the audit log entry is written, so the log will lose the attempted new value (it will record old→old). Same issue exists in the subscription_tier logging branch.
Severity: low
Other Locations
nextjs-web-app/backups/fix-rls-policies.sql:183
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| -- ============================================ | ||
|
|
||
| -- Revoke all permissions and reapply correctly | ||
| REVOKE ALL ON public.profiles FROM authenticated; |
There was a problem hiding this comment.
This script revokes all privileges on public.profiles from authenticated and only grants SELECT, but it also creates an UPDATE RLS policy for user profile updates. Without re-granting UPDATE on allowed columns, authenticated users won’t be able to update even non-sensitive profile fields.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
1 participant
Summary
Adds Mercury Coder by Inception Labs as the first target in the Portkey fallback chain, before the existing Groq → SambaNova → Cerebras → OpenRouter providers.
Changes
openai-compatible provider type withbase_url: https://api.inceptionlabs.ai/v1mercury-coderINCEPTION_API_KEYis set in envDeployment
Add to Vercel environment variables:
No breaking changes — safe to deploy without the key.