Claude Opus 5.5 Review: Benchmarks, Price, and a Real App Build

Kristoffer · September 24, 2026 · 18 min read

Anthropic released Claude Opus 5.5 yesterday, and one line in the launch thread explains why it matters: it performs at the level of Claude Fable 5.1, Anthropic's most powerful model, for most tasks, and it costs 40% less to run than Opus 5.

That is flagship-level intelligence at a lower price, generating output faster. On the published benchmarks it also beats OpenAI's new GPT-6 Astra on most tests.

Benchmarks are numbers on a chart, so this post does two things. First, it breaks down exactly what changed in Opus 5.5, where it wins and where it still loses. Then it puts the model to work: I handed it an app idea that is making over $16,000 a month and had it build my own version inside Claude Code, without writing a single line of code.

Every prompt is included in full so you can run the same build yourself.

What's actually new in Claude Opus 5.5

Until this release you had to choose. Fable 5.1 was Anthropic's most capable model. Opus 5 was cheaper, but a step behind on the really hard builds. Opus 5.5 is Anthropic's attempt to remove that choice.

The launch tweet reads: "Introducing Claude Opus 5.5, the first model in our new Claude 5.5 family. It performs at the level of Claude Fable 5.1 for most tasks, and costs 40% less to run than Opus 5." It passed 21 million views within a day.

Anthropic also says the model was tested by outside evaluators before release, and that it scored the strongest result they have ever seen on their most comprehensive alignment test.

Here are the five things that matter.

1. Benchmarks

Anthropic calls Opus 5.5 a major step up from Opus 5, leading on agentic coding, computer use and knowledge work. All figures below are read from the official launch thread.

The Terminal-Bench result is the headline. The cheaper model now beats Anthropic's own flagship by more than ten points, and it beats Astra by more than eight. FrontierCode is close. GDPval is not close at all.

2. Where it still loses

GPT-6 Astra still wins on AutomationBench, which tests business workflow automation: 41.4 versus 40.0, which is effectively a tie. Astra clearly wins on Terminal-Bench-Science, which tests scientific research tasks: 64.6 versus 58.7.

One fairness note from the small print: the Terminal-Bench comparison runs Opus 5.5 on xhigh effort against Astra on high effort, which is the highest score OpenAI has reported.

3. Price

Tokens are the small chunks of text the model reads and writes, and they are what you get billed for. On paper that is a 20% cut. Anthropic says Opus 5.5 also needs less computing power per task, which is how it reaches 40% cheaper than Opus 5 on typical workloads at the default settings.

4. Speed and effort levels

Opus 5.5 generates output more than 30% faster than Opus 5.

It also ships with five effort levels: low, medium, high, xhigh and max. Effort controls how long the model thinks before it acts. The interesting claim is that at the default effort setting it delivers frontier results for a fraction of the cost per task, often beating other models running at their highest settings.

That claim is exactly what the build below tests.

5. Easier to work with

Anthropic says Opus 5.5 communicates more naturally: it puts the most important information up front and follows the writing rules you give it. On top of that, the five-hour usage limits on the Pro, Max and Team plans are going up.

So on paper this is the best value model on the market right now. But I don't trust paper. I trust apps.

The app we're cloning: AbMaxx

AbMaxx is an AI fitness app. You take a photo of your stomach, the AI rates your abs, and it builds you a personal plan to get a six pack.

The numbers, captured from trustmrr.com and the App Store on September 23, 2026:

• $54,896 in revenue in the last 30 days, up 28% on the period before
• $16,339 in monthly recurring revenue from over 4,100 active subscriptions
• $129,161 in total revenue since it was founded in March 2026
• A 4.7 star rating from 1,300 App Store ratings
• Listed for sale by the founder with a $1 million asking price

The founder's own message says it all: "We're the #1 app for abs and there's basically no competition in this space."

The product is simple. Snap a photo, get an abs score and an explanation of what is holding you back. Then a personal abs plan with easy, medium and hard daily routines, a focus on your weak zones, an AI rep counter, a nutrition tracker, a progress tab and a leaderboard.

Why this idea works

Every viral app I have cloned follows three criteria, and AbMaxx hits all of them.

1. It solves a common, frustrating problem. Millions of people train their abs for months and still cannot see them, with no idea what they are doing wrong. One photo tells them exactly what is holding them back.
2. It keeps things simple. The core functionality fits in three words: scan your abs. Take one photo, the app does the rest.
3. It's naturally shareable. When an abs score jumps from 62 to 81, that is the screenshot people post to their story or send to the gym group chat. The leaderboard makes people invite friends just to beat them. That is organic marketing built into the product, and it is why AbMaxx grows on TikTok and Instagram.

I found the idea on trustmrr.com, a directory that shows the real, verified revenue of startups going viral right now, straight from their subscription provider. These apps are usually built by one or two people. To beat them, you only have to build a slightly better app.

Our version is called Shredly: an AI abs coach. You upload a photo of your midsection, it scores your abs, finds your weak zones, and builds a personal workout and nutrition plan around them.

Setting up Opus 5.5 in Claude Code

Claude Code is Anthropic's official coding agent, which makes it the best place to test their own model.

1. Create a completely empty folder called Shredly.
2. Open it in the terminal and run claude, then trust the folder.
3. Type /model and select Opus 5.5 with the 1 million token context window.
4. Leave the effort on medium, the default.

The 1 million token context window means the model can hold an entire large project in its head at once.

Leaving effort on medium is deliberate. The whole claim of this release is that you get frontier results at the default setting. If the app comes out broken, I am not blaming the effort setting. I am blaming the model.

Prompt 1: the build prompt

The biggest mistake beginners make is opening an AI tool and typing "build me an abs app." Before generating a single screen you need a proper spec: every feature, every screen, and what "finished" actually means. Skip it and your app will break.

For an app like this the scan is everything, so the prompt spells out exactly what the AI should measure, what it should say, and what happens when someone uploads a bad photo.

Build a complete, mobile-first responsive web app called "Shredly," an AI abs coach. The user uploads a photo of their midsection, the app scores their abs with AI, finds their weak zones, and builds a personal workout and nutrition plan around them. Use React, TypeScript, Vite, and Tailwind CSS, plus a small local server route for AI calls. The app must run locally with npm install and npm run dev. The only required setting is an ANTHROPIC_API_KEY in a .env.local file - include an .env.example. Never expose the API key to the browser. If no key is set, the app must still run using a clearly labeled demo scan. Use realistic seeded demo data, persist user data in localStorage, and store photos on the device in IndexedDB.

The product must feel like one coherent app, not a collection of unrelated demo pages.

Required product areas:

1. Onboarding - A polished first-run flow. Ask for the user's goal (see my abs for the first time, get more defined abs, or lose belly fat), age with a confirmation that they are 18 or older, sex, height, weight, activity level, training experience, available equipment (none, dumbbells, or full gym), and minutes per day they can train. Use these answers to calculate a daily calorie and protein target and explain the reasoning in one sentence. End onboarding by sending the user into their first scan. Onboarding must be skippable and repeatable from settings.

2. AI Abs Scan - A guided photo flow with clear tips: good lighting, front-facing, relaxed stomach, same pose every time. Let the user upload or take a photo. Compress the image, then send it to the Claude API with vision through the server route. Keep the model name in one config value, defaulting to claude-opus-5-5. Require a strict JSON response and validate it before showing anything: an overall abs score from 0 to 100, sub-scores for definition, symmetry, upper abs, lower abs, and obliques, an estimated body-fat range, the top three weak zones, a short encouraging summary, and three specific recommendations. If the photo is not a midsection, is too dark or blurry, or shows more than one person, show a friendly retake message instead of a score. All wording must be encouraging and never body-shaming. Make it clear that scores are estimates, not medical advice. Show the result with a satisfying score reveal and a shareable result card that shows the score and improvement but never the photo.

3. Home - Latest abs score and change since the first scan. Today's workout with a start button. Calories and protein logged today versus target. Current streak. Days until the next weekly rescan.

4. Workout Plan - Generate a personal plan from the weak zones, equipment, experience, and minutes per day. Daily routines with Easy, Medium, and Hard levels, and rest days. An exercise library with clear written instructions and the target zone for each exercise. A guided workout mode with a timer per exercise, rest timer, next-up preview, and set completion. The plan must adapt after every rescan to focus on the new weakest zones.

5. Nutrition - Log meals with calories and protein. Quick-add from saved meals. Daily progress rings against the targets. A 7-day history.

6. Progress - Abs score history chart, sub-score trends, a before-and-after photo compare slider, and a reminder to rescan weekly. Photos stay private on the device.

7. Leaderboard - A weekly leaderboard ranked by points from completed workouts, streak days, and score improvement, so beginners can compete with people who already have abs. Use clearly labeled demo users. Show the user's rank. Never show photos on the leaderboard.

8. Settings - Light, dark, and system theme. Metric and imperial units applied everywhere instantly. Edit profile and targets. Restart onboarding. Reset demo data. Export all data as JSON. Delete all photos.

Design requirements: Premium consumer fitness product design, not a generic admin dashboard. It must feel motivating, energetic, and clean, and make people want to open it every day. Mobile-first, because people use this on their phone at the gym, with a bottom navigation bar, while still working on tablet and desktop. The score reveal should feel like a moment. Workout mode must be readable from a phone on the floor: huge timers and large tap targets. Strong hierarchy, excellent spacing, thoughtful empty states, subtle motion, clear feedback, and consistent components. Use accessible contrast and keyboard-friendly controls. Avoid excessive gradients, random glassmorphism, or unnecessary visual clutter. Create a distinctive visual identity for Shredly.

Engineering requirements: Use reusable components and clean project organization. No broken buttons or placeholder interactions for required features. Validate every AI response against a schema and handle failures, timeouts, and malformed responses gracefully. Handle invalid form input, oversized images, and empty states. Avoid console errors. Ensure the app survives refreshes. Include a README with setup instructions, an architecture summary, and a checklist of implemented features.

Work autonomously. First inspect the empty project, create a concise implementation plan, then build the full app. Test the app yourself before declaring completion. Do not stop after creating a mockup or partial prototype. Continue until the required functionality is implemented and the project runs successfully.

The first thing Opus 5.5 does is not write files. It checks the empty folder and the tools installed on the machine. Then it loads its own guide to the Claude API and reads up on exactly what this app needs: how to send images to Claude, how to force a strict JSON answer, and how to handle errors, timeouts and refusals. That was the part I was most worried about.

First build: 37 minutes on medium effort

The whole build took 37 minutes at the default effort. Opus 5.5 reported all eight product areas built, a clean build, and that it had tested everything itself in a browser at phone size.

It listed bugs it found and fixed on its own, like unreadable dark cards on the workout tab and workout controls cut off on phone-sized screens. It was also honest about the one thing it could not test: a real AI scan, because there was no API key on the machine, so scans fell back to the clearly labeled demo scan.

What worked

• Welcome and onboarding. The welcome screen reads "Your abs, scored. Your plan, built." Onboarding asks one question per screen with a progress bar on top: goal, name and age with an 18+ checkbox, height, weight, activity level, training experience, equipment and minutes per day.
• Targets that use your answers. With a full gym and 45 minutes a day, it gave me 2,450 calories and 170 grams of protein and explained why: I burn about 2,990 calories a day, so an 18% deficit reveals abs without draining workouts, and the protein protects muscle.
• The bad-photo test. I uploaded a photo of a kitchen instead of a stomach. The response: "This looks like a lovely kitchen, but we need a photo of your midsection to assess your abs!" and underneath, "No score was recorded - nothing lost." No fake score.
• The real scan. A real torso photo scored 18 out of 100 with the message "Day One. Every six-pack starts right here." Below that: an estimated body fat of 22 to 26 percent, symmetry the strongest sub-score at 62, lower abs the weakest at 12, three weak zones (conditioning, deep core and lower abs) each explained in plain English, and three specific recommendations.
• Workout plan. Built around those three weak zones and using real gym exercises because I said full gym: rower sprints, Pallof presses, ab wheel rollouts and hanging leg raises, switchable between Easy, Medium and Hard.
• Home, nutrition, progress, leaderboard. The home page shows score, today's workout, calories and protein, streak, next rescan and league rank. Nutrition has progress rings, quick-add meals and a friendly empty state. Progress shows "Your chart appears after your second scan. Baseline: 18." The leaderboard labels every other user as Demo and put me at rank 13.
• Settings. Profile, targets, JSON export, photo deletion, and a footer reading "AI scans enabled · claude-opus-5-5 via your local Claude Code login." Light mode switched instantly.

What didn't

For a first build on medium effort this is very impressive, but the first version is functional rather than stunning. It looks like a lot of AI-generated apps look: the same dark rounded cards stacked on every page.

For a fitness app that is a real problem. Design builds trust in the first three seconds, and people only pay weekly for a fitness app if it feels premium the moment they open it.

Connect the Mobbin MCP to Claude Code

Instead of telling the model to vaguely "make it look better," give it real references. Mobbin is a curated library of the world's best interfaces from real successful apps, and because it has an MCP, Opus 5.5 can search it directly from inside Claude Code. An MCP is a plug that lets the AI use an outside tool on its own.

Add it with one command:

claude mcp add mobbin --scope user --transport http https://api.mobbin.com/mcp

Restart Claude Code, then check it is installed:

/mcp

Select Mobbin, choose authenticate, and a browser window asks you to connect Claude Code to your Mobbin account. Click continue and you are done.

Prompt 2: research and redesign with Mobbin

Use the Mobbin MCP to research strong, modern product interfaces relevant to Shredly.

Study multiple real examples across: fitness and workout apps, body scan and progress photo flows, score and result reveal screens, fitness onboarding flows, guided workout players with timers, exercise libraries, nutrition and calorie trackers, progress charts and before-and-after comparisons, streaks and leaderboards, and settings and theme customization.

Do not copy one product screen-for-screen. Extract the strongest recurring design patterns and use them to improve Shredly as an original product.

First, create a file called design-research.md containing: 1. The products or flows you examined. 2. The useful patterns you identified. 3. Patterns you intentionally rejected and why. 4. A complete Shredly design system: visual direction, colors, typography, how scores and numbers are displayed, spacing scale, corner radii, shadows, icon style, motion principles, chart style, form style, empty states, mobile behavior, and accessibility rules. 5. A page-by-page redesign plan for the existing app.

Then implement the redesign across the entire Shredly project.

Requirements: Preserve and test all existing functionality. Do not reduce the number of features. Make the interface feel like a premium, motivating consumer fitness product rather than a generic dashboard. Create a distinctive identity that fits the name Shredly. Improve onboarding, the scan flow and score reveal, the home page, the workout plan and guided workout mode, nutrition, progress, the leaderboard, settings, empty states, and mobile responsiveness. Make sure both light and dark mode are equally polished. Use subtle motion where it improves clarity. Do not declare completion until the redesign is consistent across every major screen and the project runs without console errors.

Before changing anything, Opus 5.5 read through every page of the existing app. This is a strong test because the model has to research, make real design decisions, and refactor a big project without breaking what already works.

Redesign results: 43 minutes

The redesign took 43 minutes. The design-research file lists 25 patterns it kept and 10 it rejected, with reasons. It rejected a neon-lime accent as "a category cliché," and red-to-green health gauges because "they read as shaming under a body photo."

It named the new design Ember & Carbon: carbon black in dark mode, warm chalk in light mode, and one single ember-orange accent. It took the six-pack grid from the logo and reused it in the scanning animation, the empty states and the weak-zone map.

One honest note in its report: the Chrome extension kept failing, so it tested the redesign with a headless browser it scripted itself.

The difference is night and day:

• The home page opens with a one-line coach tip ("Today's session hits your conditioning"), the score on its own dark card with a "Day One" badge, one big orange start button, calories left for the day, and the streak as a row of dots for the week.
• The sidebar shows score and streak on every page.
• The workout plan ranks weak zones with conditioning marked as the priority, and a week strip shows rest days.
• The scan page has an illustrated guide showing exactly how to frame the photo, from chest to hips.
• The nutrition ring shows calories left in the middle.
• The league has a podium for the top three, with your own row pinned to the bottom.
• Theme settings are little preview cards.

Light mode is where AI redesigns usually fall apart. This one holds: the background turns warm off-white and the score card stays dark, so it still pops. It now looks like an app you would pay for.

Prompt 3: the quality audit

This is a step very few people teach. Most startups have a QA team whose only job is to go through the app before launch and make sure it does not break. For Shredly it matters even more: people are trusting you with photos of their body, and nothing destroys your work faster than a score that makes no sense or a scan that crashes.

So I asked Opus 5.5 to be its own QA team.

Perform a final product, functionality, responsiveness, and code-quality audit of Shredly. Use the original build requirements and design-research.md as the source of truth.

Test and verify: onboarding, skip, restart, and the calorie and protein calculations; the scan flow including large photos, iPhone HEIC photos, photos that are not a midsection, dark or blurry photos, a missing API key, API failures, timeouts, and malformed AI responses; score consistency, so the same photo gives the same or nearly the same score every time; that every AI message and result is encouraging and never body-shaming; workout plan generation and adaptation after a rescan; the Easy, Medium, and Hard levels; guided workout timers, including when the phone screen locks or the app goes to the background; the AI Rep Counter and every edge case; nutrition logging and daily totals; progress charts and the before-and-after compare slider; streak calculations across midnight in the user's own time zone; leaderboard points; metric and imperial units applied everywhere; light, dark, and system themes; JSON export; photo storage limits and deleting photos; desktop, tablet, small phone, and large phone layouts; keyboard accessibility and visible focus states; empty states and validation; refresh behavior; console errors, broken routes, broken buttons, overflow, and visual inconsistencies.

Fix every issue you find. Do not remove a required feature to avoid fixing it. Do not replace real interactions with placeholders.

After the audit: 1. Run the relevant build and validation commands. 2. Create audit-report.md listing what you tested, what was broken, what you fixed, and any honest remaining limitations. 3. Update the README.

Do not declare completion until the production build succeeds.

Audit results: 22 bugs in 1 hour 11 minutes

The audit ran for 1 hour and 11 minutes. It found and fixed 22 bugs, the production build succeeds, every check passes and there are no console errors. It wrote 64 automated tests where the project had none, and checked every page at 8 screen sizes from a tiny phone to a full desktop.

One fix was exactly what I was worried about: the same photo could get a different score each time. Now every photo gets its own fingerprint, so uploading the same photo again returns the same result, and the scoring prompt uses a stricter, repeatable rubric so similar photos land within about 3 points.

It also found the invisible bugs, the ones that make someone delete your app in the first week without telling you why:

• The skip button let people jump past the 18-or-older confirmation.
• Photos taken on an iPhone failed to upload in Chrome, Edge and Firefox because of the HEIC format.
• Locking your phone in the middle of a workout broke the timer.
• Leaving the app open overnight never rolled over to the new day, so streaks, totals and today's workout went stale.

It added a tone guard so the AI can never say something like "trims belly fat." It now says "trims your waistline" instead.

And it was honest about limits: consistency across different photos is a target, not a guarantee, because a vision model cannot promise that.

Prompt 4: prepare Shredly for public release

At this point Shredly works, but it is not ready for real users. All data and photos live on one device, so clearing the browser wipes the whole history. There is no account system, so you cannot scan on your phone and check progress on your laptop. The leaderboard is full of demo users. And there is no way to make money from it, which is the whole point.

This prompt has nine sections and dozens of requirements on purpose. This is where the 1 million token context window matters: the model has to hold the whole project in its head and not quietly forget instruction number forty.

Prepare Shredly for real public release. The current app is a local prototype with seeded demo data, localStorage, and photos stored on the device. Convert it into a production-ready application while preserving the existing design and functionality.

Use Supabase for authentication, the database, and photo storage. Create the required database schema, migrations, row-level security policies, storage policies, an .env.example file, and setup documentation.

1. Authentication - Secure email and password sign up, login, logout, forgotten password, password reset, and email verification. Protect all private routes. Every user must only ever access their own data and photos.

2. Real data only - New accounts start completely clean with no demo scans, workouts, meals, or leaderboard users. Keep demo data available only through a clearly labeled demo mode. Show onboarding only for new accounts, save the answers to the user's profile, and create their real targets. Add loading states, success and error notifications, duplicate-submission protection, and graceful handling of offline, failed-request, and expired-session states.

3. Database and photos - Move profiles, targets, scans, scores, workout plans, workout logs, rep counts, meals, streaks, and leaderboard points into the database, and make sure everything syncs across devices. Store scan photos in a private storage bucket that only the owner can access, using short-lived signed links.

4. AI scan in production - Move the Claude API call into a Supabase Edge Function and store the Anthropic API key as a server secret. Limit scans per user per day to protect API costs. Keep the strict response validation and friendly retake messages.

5. Premium subscription - Add Stripe Checkout in test mode with a weekly plan at $4.99 and a yearly plan at $29.99, stored in one editable config. Free users can complete onboarding and see their overall abs score from one scan. Show a clean paywall after the score reveal. Premium unlocks the full breakdown, the workout plan, the AI Rep Counter, and weekly rescans. Use a Stripe webhook to update premium status, and add a customer portal to manage or cancel the subscription.

6. Real leaderboard - Rank real users by weekly points. Users choose a display name and can opt out of the leaderboard in settings. Never show photos or body data on the leaderboard.

7. Legal and trust pages - Privacy Policy, Terms of Service, Contact or Support, and Account and Data Deletion pages. Explain clearly how photos are stored and used. Add a clear note that Shredly gives fitness estimates, not medical advice, and that users should talk to a doctor before starting a new diet or exercise program. Require users to confirm they are 18 or older. Use clearly marked editable placeholders for company details. Do not invent legal or company details.

8. Security - Never expose secret keys in client code. Validate every upload's file type and size. Validate and sanitize all user input. Remove debug logs. Make account deletion remove all related user data and every stored photo. Test with two separate accounts and confirm neither can access the other's data or photos, even with a direct link.

9. Publishing - Make Shredly installable as a Progressive Web App with a manifest, icons, and theme colors. Add page titles, social metadata, a custom 404 page, and a PUBLICATION_CHECKLIST.md listing what I still need to configure. Prepare the project for deployment on Vercel.

Be honest about anything that still needs manual setup. Do not stop after writing a plan. Implement the changes, run the project checks, and confirm the production build succeeds.

The first thing it did was check which tools the machine had: Supabase, Docker, Deno, Stripe and Vercel, so it knew what it could actually test.

Production results: 47 minutes and 119 passing tests

The production pass finished in 47 minutes with 119 tests passing. One test has two separate accounts try to get into each other's data and photos, including going straight to a photo's file link, and neither can.

It was honest that payments and real AI scans had not actually run, because nothing was connected yet. Instead it produced a publication checklist of what I still need to do myself:

1. Create the Supabase project and push the database.
2. Deploy the server functions with the Anthropic and Stripe keys as secrets.
3. Set up the Stripe webhook and customer portal.
4. Add the environment settings in Vercel.
5. Fill in company details. It did not invent any.
6. Have a lawyer review how body photos are handled.
7. Do a final test with two real accounts.

Testing the new version as a brand-new user

Running locally, the welcome page now carries a clear note that Shredly is for adults 18 and over and gives fitness estimates, not medical advice, with links to the privacy policy, terms, support and account deletion.

Onboarding ends with "Kristoffer, you're ready to shred." The first scan reveals a score counting up to 19 out of 100 and says I am 6 points from the next level.

Because Supabase and Stripe were not connected, there was no sign-up and no paywall in this local run, and the leaderboard still showed the labeled demo users. That is expected: without Supabase it runs as the local prototype.

The guided workout mode has a timer per exercise, a rest timer between sets and a big "set done" button. After tapping through, "Workout complete!" shows 24 sets done, 80 points earned and the first streak day. Leaderboard points went from 0 to 95. Logging a chicken salad at 500 calories and 25 grams of protein updated calories left instantly.

Does Opus 5.5 change everything?

We started with an empty folder. Now there is a full AI fitness app: an AI abs scanner, personal workout plans, guided workouts, nutrition tracking and a weekly league, with the code for accounts, cloud sync, payments and legal pages already written and tested. What is left is the checklist, and it is live.

That is the same idea making AbMaxx over $16,000 a month, and we did not write a single line of code.

For people who build apps with AI, I think it does change things. You get Fable-level results for most tasks, faster, for 40% less than Opus 5. And on the default effort setting it built something I would be comfortable putting in front of real users.

Frequently asked questions

Is Claude Opus 5.5 better than Claude Fable 5.1?

For most tasks Anthropic says it performs at Fable 5.1's level, and on Terminal-Bench 4.0 and OSWorld it scores higher. Fable 5.1 remains the top model for the hardest work, but Opus 5.5 is cheaper and faster.

How much cheaper is Opus 5.5 than Opus 5?

The list price is $4 per million input tokens and $20 per million output tokens, a 20% cut from Opus 5's $5 and $25. Because it needs less compute per task, Anthropic says typical workloads at default settings come out about 40% cheaper.

Which effort level should I use in Claude Code?

Start with medium, the default. Every build in this post ran on medium and produced a launch-ready app. Raise the effort only if a specific task comes back broken.

Do I need an API key to run Shredly?

Locally, no. Without an ANTHROPIC_API_KEY the app runs with a clearly labeled demo scan. In production the key lives in a Supabase Edge Function secret and is never exposed to the browser.

If you want the complete system I use to go from an app idea to a built MVP, publish it, market it and grow it, it is all inside BuildWithAI. You get lifetime access when you start a paid Lovable plan through our partner link, with no separate community fee.