GPT-6 Astra vs Claude Fable 5.1: Same Prompt, Same App

Kristoffer · September 20, 2026 · 7 min read

I gave GPT-6 Astra and Claude Fable 5.1 the same four prompts and asked them to build the same complete app.

Astra ran inside Codex CLI. Fable ran inside Claude Code. Both started from an empty folder, built IronLog, researched the same interfaces through Mobbin, audited their own work, and converted the local prototype into a Supabase-backed production app.

This post includes every prompt in full, the two Mobbin setup commands, what each model got right and wrong, and the final score. The result was 40/50 for Astra and 44/50 for Fable.

The app: IronLog

IronLog is a strength-training workout tracker inspired by products such as Strong. The promise is simple: log your lifts quickly and see whether you are getting stronger.

Both models had to build:

Prompt 1: build IronLog from scratch

I used a detailed first prompt so the comparison would test model performance instead of luck. Both models knew what to build and what counted as finished, but they still had freedom over architecture and design.

Here is the exact prompt:

Build a complete responsive web app called "IronLog," a strength-training workout tracker. Use React, TypeScript, Vite, and Tailwind CSS unless you have a strong technical reason to choose an equivalent local-first stack. The app must run locally with a simple npm install and npm run dev. Do not require paid APIs, external databases, authentication providers, wearables, or environment variables. Use realistic seeded demo data and persist all user-created or edited data in localStorage.

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

Required product areas:

1. Onboarding - A polished first-run onboarding flow. Ask the user for their name, preferred units (kg or lb), training experience level, training days per week, primary goal (strength, muscle, or general fitness), and available equipment. Use those answers to generate a personalized starting routine. Onboarding must be skippable and repeatable from settings.

2. Home Dashboard - Greeting and current date. The user's next scheduled workout with a one-tap start button. A current training streak. This week's total volume compared with last week. Recent personal records. A weekly training calendar strip showing which days were trained. Useful empty states and realistic demo data.

3. Exercise Library - A library of at least 80 real strength exercises with name, primary muscle group, secondary muscles, equipment type, and a short form cue. Search, filter by muscle group and equipment, and mark favourites. Users can create, edit, and delete their own custom exercises. Each exercise needs a detail view showing its history, best set, estimated one-rep max, and a progress chart.

4. Routines - Create, edit, duplicate, reorder, and delete custom workout routines. Add exercises to a routine with target sets, target rep ranges, and rest times. Support supersets. Show estimated duration and the muscle groups a routine covers. Include a few well-built starter routines such as a push-pull-legs split and a full-body beginner plan.

5. Live Workout Session - This is the most important screen in the app. Starting a routine opens an active session with a running workout timer. For every exercise, show each set with weight, reps, a completed checkbox, and the exact numbers the user hit for that same set last time as a reference. Support warm-up sets, failure sets, and drop sets. Add or remove sets mid-workout. Add an exercise mid-workout. An automatic rest timer starts when a set is completed, with the routine's rest time pre-filled, skip and add-time controls, and a clear visual countdown. Show live session volume and completed set count. Allow the user to finish or discard the workout, and show a workout summary screen afterwards including total volume, duration, and any personal records broken during that session.

6. History - A list and calendar view of every completed workout. Open any past workout to see the full set-by-set breakdown. Edit or delete a past workout. Show streaks and total workouts per month.

7. Progress and Analytics - Total volume over time, workouts per week, volume split by muscle group, per-exercise strength progression charts, estimated one-rep max progression, and a personal records list showing best weight, best estimated one-rep max, and best volume per exercise. All charts must update from actual logged activity.

8. Body Measurements - Log bodyweight and basic measurements over time with dates. Show a bodyweight chart and change over the last 30 and 90 days.

9. Settings - Light, dark, and system theme. Units in kg or lb, applied everywhere in the app instantly. Default rest time. Profile preferences. Reset demo data. Restart onboarding. Export all local app data as JSON. Import previously exported JSON safely.

Design requirements: Premium consumer fitness product design, not a generic enterprise admin dashboard. Responsive on desktop, tablet, and mobile, and the live workout screen must be genuinely usable one-handed on a phone, because that is how it will be used in a gym. 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, giant text, or unnecessary visual clutter. Create a distinctive visual identity for IronLog.

Engineering requirements: Use reusable components and clean project organization. No broken buttons or placeholder interactions for required features. Handle invalid form input and empty states. Avoid console errors. Ensure the app survives refreshes through localStorage, including an in-progress workout session. Include a README with setup instructions, 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.

First-build results

GPT-6 Astra

Astra finished in 46 minutes and 59 seconds. It implemented all nine requested areas, more than 100 exercises, persistent live workouts, analytics and JSON backups. Before handing the app over, it ran the production build, 15 logic tests, and 10 browser and accessibility tests.

Its six-step onboarding created a personalized split around the user's equipment. The live workout supported weight, reps, completion controls, last-time references, an automatic rest timer, live volume and a proper summary with personal records.

Claude Fable 5.1

Fable finished in 34 minutes and 51 seconds, over 12 minutes faster than Astra. It built 106 exercises, seven starter routines, the full live-session flow and all nine requested areas.

It also ran type-checking, a production build and Playwright checks across desktop and phone layouts. Those checks caught a real redirect bug after completing a workout before I opened the app.

Both first builds were legitimate products. The weakness was visual: functional AI-generated apps can still feel generic, so the next stage gave both models the same real design library.

Connect Mobbin to Claude Code and Codex

Mobbin contains real product screens and complete flows. Instead of asking the models to "make it look premium," I gave them the same source material and asked them to research repeated patterns.

Add Mobbin to Claude Code with:

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

Then open Claude Code, run /mcp, select Mobbin and complete browser authorization.

Add it to Codex with:

codex mcp add mobbin --url https://api.mobbin.com/mcp

Complete the browser authorization when Codex opens it.

Prompt 2: research and redesign with Mobbin

The goal was not to copy one product. Each model had to study several relevant products, document what it learned, reject unsuitable patterns, create an original system and then apply it without breaking the app.

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

Study multiple real examples across: workout and strength-training apps, fitness onboarding flows, live activity and timer screens, exercise and content libraries with search and filtering, health and progress analytics, streak and habit mechanics, calendar and history views, and settings and theme customization.

Do not copy one product screen-for-screen. Extract the strongest recurring design patterns and use them to improve IronLog 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 IronLog design system: visual direction, colors, typography, 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 IronLog project.

Requirements: Preserve and test all existing functionality. Do not reduce the number of features. Make the interface feel like a premium consumer fitness product rather than a generic admin dashboard. Create a distinctive identity that fits the name IronLog. Improve onboarding, dashboard hierarchy, the exercise library, routines, the live workout session, history, progress analytics, body measurements, settings, empty states, and mobile responsiveness. The live workout session must be optimized for one-handed phone use with large tap targets, because it is used mid-set in a gym. Use subtle motion and interaction feedback where it improves clarity. Avoid blindly mixing patterns from unrelated apps. Do not declare completion until the redesign is consistent across every major screen and the project runs without console errors.

Redesign results

Astra produced the most striking single screen in the comparison: a high-contrast dark workout interface with an orange accent, large condensed numbers, huge set controls and a rest timer occupying the bottom third of the phone. It genuinely felt designed for somebody holding a phone with one hand in a gym.

But its light mode was weak. Secondary text lost contrast, chart grid lines nearly disappeared, and the orange accent did not translate well to white. The redesign also broke the routine-duration calculation.

Fable chose a calmer deep-charcoal system with muted steel blue and one warm color reserved for personal records. It grouped navigation into "Train" and "Track," kept muscle colors consistent, built a strong light mode and preserved the working features.

Astra created the most dramatic screen. Fable created the more reliable design system.

Prompt 3: complete product and code audit

The third prompt asked each model to become its own QA team. It was not allowed to remove features or hide broken interactions behind placeholders.

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

Test and verify: onboarding, skip, restart, and personalization; exercise library search, filtering, favourites, custom exercise creation, editing, and deletion; routine creation, editing, duplication, reordering, superset behaviour, and deletion; the live workout session including set logging, the last-time reference values, warm-up, failure and drop sets, adding and removing sets mid-workout, adding an exercise mid-workout, the automatic rest timer with skip and add-time, live volume, discarding a workout, finishing a workout, and the summary screen; survival of an in-progress session across a page refresh; history list, calendar, past-workout editing and deletion; personal record detection and the accuracy of estimated one-rep max calculations; progress charts updating from real logged activity; body measurement logging and charts; unit switching between kg and lb applied consistently everywhere including historical data; light, dark, and system themes; JSON export and safe import; desktop, tablet, and mobile layouts, with particular attention to one-handed use of the live workout screen; keyboard accessibility and visible focus states; empty states, validation, loading or transition feedback; refresh behavior; console errors, broken routes, broken buttons, overflow, and obvious 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 with final setup and deployment instructions. 4. Prepare the project for deployment as a static web app, but do not require a specific hosting provider.

Do not declare completion until the production build succeeds.

Audit results: visible bugs versus invisible bugs

Astra opened the app in a browser and drove it. It clicked through onboarding, started a workout, completed sets, refreshed the page and recorded failures with screenshots. In 11 minutes it found and fixed 14 issues, including the refresh bug, frozen routine duration and superset problem.

Fable reported 19 fixes. Its audit focused more heavily on data logic: an incorrect estimated one-rep-max calculation above 12 reps, personal records not being recomputed after editing an old workout, and rounding drift after repeatedly switching between kilograms and pounds.

Astra was better at finding visible interaction failures. Fable was better at finding invisible calculation problems that could corrupt training data over time.

Prompt 4: convert IronLog into a production app

The original apps used demo data and localStorage. The last prompt required accounts, a real database, user isolation, clean first-run states, production settings, legal pages, security checks and deployment documentation.

This was the longest prompt and the real long-horizon test.

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

Use Supabase for authentication and persistent data unless the project already has an equally suitable production backend. Create any required database schema, migrations, policies, environment-variable templates, and setup documentation.

Complete the following work:

1. Authentication and accounts - Add secure email and password account creation. Add login, logout, forgotten-password, and password-reset flows. Add email verification where supported. Keep users signed in securely between sessions. Protect all private application routes. Redirect unauthenticated users to the login or registration flow. Ensure every user can access only their own data. Add loading, success, validation, and error states to every authentication screen.

2. Replace placeholder data - Remove all seeded workouts, routines, personal records, measurements, and analytics from real new-user accounts. New accounts must begin with a clean state. Keep the built-in exercise library available to everyone, but keep demo training history available only through an explicitly labeled demo mode or development-only seed script. Do not show fake progress statistics to real users. Generate analytics only from the authenticated user's actual logged activity.

3. Move data into the production database - Replace localStorage as the primary source of truth for authenticated users. Store profiles, preferences, custom exercises, routines, workout sessions, individual sets, personal records, body measurements, and relevant activity records in the database. Connect every existing create, read, update, delete, filtering, search, and progress feature to the authenticated user's data. Preserve data correctly across refreshes, browsers, devices, and future sessions. An in-progress workout session must survive a refresh and resume correctly on another device. Add appropriate database relationships, indexes, timestamps, validation, and ownership rules. Use row-level security or equivalent authorization so users cannot read or modify another user's information.

4. Improve onboarding - Show onboarding only after a user creates an account and has not completed it previously. Save onboarding answers to the user's profile. Use those answers to generate a real personalized starting routine in the user's own account rather than inserting fake history. Let users skip optional steps. Allow onboarding to be restarted from settings without deleting existing data unless the user explicitly chooses to reset it.

5. Expand settings - Add complete settings sections for: profile name and profile image; email address and password management; units, default rest time, and week-start preferences; time zone; date and number format; notification preferences; rest-timer sound and vibration preferences; light, dark, and system themes; accessibility preferences; exporting the user's data; importing supported data safely; signing out; deleting the account and associated data. Require clear confirmation before destructive actions such as resetting data or deleting an account.

6. Production interface states - Add polished empty states for new users who have no workouts, routines, records, measurements, or analytics yet. Add loading states or skeletons where database requests occur. Add useful success and error notifications. Prevent duplicate submissions. Disable buttons while requests are processing. Handle offline, failed-request, expired-session, and empty-response states gracefully, and make sure a set logged while offline is not silently lost. Replace all development text, placeholder labels, fake testimonials, unfinished links, and temporary content.

7. Legal and trust pages - Create publication-ready pages for: Privacy Policy, Terms of Service, Contact or Support, and Account and Data Deletion. Use clearly marked editable placeholders only for information that must be supplied by the app owner, such as company name, support email, governing jurisdiction, and effective date. Do not invent legal or company details. Add links to these pages in the authentication flow, settings, and website footer where appropriate.

8. Security and reliability - Never expose secret keys in client-side code. Add a complete .env.example containing every required public environment-variable name with no real credentials. Validate and sanitize user-controlled inputs. Review database permissions and authentication redirects. Remove debug logs and development-only controls from the production build. Check for exposed personal information, insecure direct-object access, broken authorization, unsafe imports, and accidental cross-user data access. Add reasonable limits and validation to imported JSON files. Make account deletion remove or appropriately anonymize all related user data.

9. Files required for publication - Create or update all required project and deployment files, including: README.md with local setup, backend setup, database setup, environment variables, development commands, production build commands, and deployment instructions; .env.example; database schema or migration files; optional development-only seed file; production build configuration; hosting configuration where required; .gitignore; package scripts for development, build, preview, linting, and type-checking; favicon and application icons in the required web sizes; manifest.webmanifest; robots.txt; sitemap.xml; social-sharing image placeholder; appropriate page titles, descriptions, Open Graph metadata, and social metadata; a custom 404 page; error-boundary or fatal-error interface; Privacy Policy, Terms, Support, and Data Deletion pages; PUBLICATION_CHECKLIST.md; DEPLOYMENT.md.

10. Progressive Web App readiness - Make IronLog installable as a Progressive Web App where practical. Add the web manifest, app name, icons, theme colors, and standalone display configuration. Ensure the interface works correctly when opened as an installed web app, and make sure the rest timer and live session behave correctly when the screen locks or the app is backgrounded. Do not add unreliable offline behavior that could cause user data conflicts.

11. Quality checks - Test registration, verification, login, logout, password reset, protected routes, onboarding, profile editing, and account deletion. Test every exercise, routine, live session, rest timer, history, personal record, progress, measurement, import, export, theme, unit, and settings feature using authenticated accounts. Test with at least two separate accounts and confirm that neither account can access the other account's data. Test desktop, tablet, and mobile layouts. Run linting, type-checking, tests where available, and the production build. Resolve all critical errors, broken routes, console errors, and production-build failures.

12. Publication checklist - Create PUBLICATION_CHECKLIST.md separating: tasks completed automatically; credentials or configuration the owner must provide; Supabase setup steps; database migration steps; legal details that still require review; domain and DNS setup; email-delivery configuration; analytics or monitoring setup; final security checks; final browser and mobile tests; exact files and folders that must be uploaded or included in deployment; exact build-output directory that should be published.

Do not claim the application is fully ready for production merely because it builds. Be honest about any remaining limitations, credentials, legal review, external configuration, or manual testing still required. Do not stop after writing a plan. Implement the changes, create the required files, run the project checks, and confirm that the production build succeeds.

Final app: GPT-6 Astra

Astra's final version opened on a proper account-creation page and sent a new user directly into onboarding. The resulting account was clean: no fake streak, volume, history or records. Completing a workout correctly populated history, progress and the muscle-split chart.

Its refresh bug was fixed, legal pages were present, and a two-account test confirmed that Row Level Security prevented cross-account access.

But several requested settings were missing: time zone, date and number formatting, accessibility preferences, and rest-timer sound and vibration. More importantly, an active workout did not synchronize correctly across two browsers. Whichever session finished last silently overwrote the other.

Astra's strongest and weakest points

Final app: Claude Fable 5.1

Fable also began with a proper account flow and clean data. Its onboarding first explained that the setup would take roughly 30 seconds and five questions. It then previewed the generated routine and allowed exercise swaps before saving it.

The active workout survived refreshes and synchronized to a second browser at the correct exercise with the correct completed sets. Fable also implemented every requested settings section, including time zone, date format, accessibility, rest-timer sound and vibration.

Its main remaining defect was offline synchronization. Two sets logged offline showed a reassuring local-save badge, but one duplicated when the app came back online.

Fable's strongest and weakest points

Final scores

Category GPT-6 Astra Claude Fable 5.1
Functionality 7/10 9/10
Design and UX 8/10 9/10
Instruction-following 6/10 10/10
Code quality and stability 9/10 9/10
Speed and autonomy 10/10 7/10
Total 40/50 44/50

Claude Fable 5.1 wins by four points.

Astra was faster, cheaper per task and unusually effective at opening the product and testing visible behavior in a real browser. Its dark workout screen was the most impressive single interface in the comparison.

Fable won on staying power. It continued following the 60th requirement as carefully as the first, built the hard synchronization behavior correctly and disclosed weaknesses instead of silently omitting requirements.

Which model should you use?

Choose GPT-6 Astra when speed, cost and rapid browser-driven iteration matter most. It can move extremely quickly and its computer-use testing is a real advantage, but verify long requirement lists manually.

Choose Claude Fable 5.1 when the build has many interdependent requirements and you value completeness over raw speed. It took longer, but it produced the more coherent final product in this test.

The most important lesson is the workflow. A detailed build specification, real interface research, a separate audit and a production-conversion pass produce a far better result than one giant "build my app" instruction.

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.