Token costs used to be something most developers ignored. They simply dismissed them as theoretical. Now, they’re showing up in your Cursor/Claude Code bill, in every pasted error, in that package the AI pulled in without asking, or in that clarification round you didn’t plan for.

Most developers choose a framework based on what they've used before, what the job description asks for, or simply whatever was used on their last project. Very few developers give any consideration to the total cost of using an AI to develop the application, even though token spend is now becoming a real engineering expense for teams using tools like Cursor and Claude Code daily.

That got us wondering: which framework is actually the most economical for AI-assisted development? To find out, we gave Rails, Django, and Laravel the same task, used the same prompts, and tracked every token in an attempt to measure the real vibe coding cost of each.

Here's what we discovered.

What Did the Experiment Look Like?

For this experiment, the task was straightforward: build a simple web app where users could authenticate/register, create and manage posts, comment on posts, and expose the posts through a JSON API endpoint available at /api/posts.

We used Cursor Pro and tested each framework using the same prompt:

Build a web app in [Rails/Django/Laravel] with:
- User authentication (sign up, login, logout)
- A Posts resource with full CRUD (create, list, show, edit, delete)
- Comments on posts (create, delete)
- A JSON API endpoint at GET /api/posts that returns all posts with their comments
 
Use [Rails/Django/Laravel] conventions. Give me all files, migrations, routes, and everything needed to run it locally.

Every framework iteration was executed without manual changes or intervention. Token usage was measured directly from Cursor’s dashboard, counting only input and output tokens. Cached reads were excluded because they heavily depend on project size and could distort the comparison.

The list of tracked items included:

• Total tokens consumed
• Number of prompt iterations to reach a working application
• Number of dependencies/packages installed by the AI
• Memory footprint associated with the application after installation

Rails

Tokens spent: 61,141 tokens (input: 48,527, output: 12,614)

The principle of “convention over configuration” is particularly apparent when AI writes code for you. Rails has a clear, predictable structure. Models are located in app/models, controllers are found in app/controllers, routes are defined in one file, and migrations use standard name conventions.

There’s little architectural uncertainty and even less need for the AI to backtrack or ask follow-up questions. As a result, the application was built on the first try, with zero iterations.

Now let’s take a look at the integrations and tooling that Cursor picked to use in our app. It added bcrypt to the Gemfile for encrypting passwords, solid_queue for background processing, bundler-audit for scanning gem security, and brakeman for scanning static vulnerabilities. None of these were explicitly mentioned in the prompt. It’s just that Rails provides such extensive documentation for the complete ecosystem that the AI tends to automatically reach for default Rails solutions whenever it encounters an implicitly defined issue.

The request was for authentication, but what we got goes a bit further. We ended up with authentication plus the kind of security tools an experienced Rails developer would usually add on day two.

And it works.

Ruby on Rails apps generally load these gems at startup, which is part of why the app takes roughly 80 MB of installed memory, about four times larger than the other two alternatives we’ll look at. But, that memory tax is the trade-off that comes with “convention over configuration”.

Oh, and one more thing worth flagging: if you’re a Rails developer or you already know the foundations, it’s a relatively easy language to debug. For instance, if the solid_queue breaks, you know exactly what it is and why it’s there. However, for someone who isn’t aware of this, every AI-generated code can quickly turn into archaeology (that is, digging through layers just to understand why something exists).

Django (Python)

Tokens spent: 31,301 tokens (input: 20,808, output: 10,493)

Django was the best choice based on all criteria, and by a wide margin. It used less than half the tokens that Rails used during development, produced a working application faster, and had the smallest memory footprint (compared to Laravel), but the biggest surprise was the dependency count.

The only dependencies included in the pip freeze after the development were those that are built into Django: asgiref, sqlparse, and typing_extensions. None of them were written by our AI agent, as all three are Django internals.

AI models have been trained on hundreds of thousands of lines of Python code, which is more than most other languages. You can see it in the quality of their output and how rarely they question themselves.

In addition to fewer clarification rounds (and, therefore, tokens), Django's architecture also reinforces efficiency. Models, views, URLs, and templates all live in predictable locations. This structure gives the AI clear guardrails without forcing it to create a new architecture.

The API endpoint exposed one consistent pattern across all three frameworks. The generated code worked fine in development:

posts = Post.objects.all()
 
for post in posts:
 
comments = post.comments.all()  # fires a query per post

However, in production, this introduces an N+1 problem. This isn’t a big deal when you have 10 posts or so, but it does become a production incident when you hit 10K or more posts.

Laravel (PHP)

Tokens spent: 104,989 tokens (input: ~89,138, output: ~15,851 - combining multiple sessions)

The overall cost of building an application using Laravel compared to Rails or Django was significantly higher. That headline number needs a bit of context, though, rather than being left as a simple data point.

The initial build of the application was completed successfully from a structural point of view, but it still needed some debugging before the app could function properly. That debugging session alone accounted for approximately ~44,000 tokens, which makes up most of the difference in token usage between Laravel, Rails, and Django.

The structure of the error wasn't complex. It was a typical issue AI occasionally runs into with Laravel's layered patterns, especially when attempting to coordinate Eloquent, a service provider, and route model binding at the same time.

The way dependencies were handled was interesting. The Laravel package laravel/breeze was added for authentication scaffolding, which was a reasonable choice but also an opinionated one that the AI made on its own. Another package, laravel/pao, was added as well, which may be an existing package with a hallucinated or incorrect name. It's a good reminder that proper audits should be done before anything reaches production.

The total use of RAM on both frameworks at run time was ~18MB. Although the number of tokens used by Laravel during the build was 3.4x more than the other two, the application isn't heavier at runtime.

It’s also important to note that PHP hosting is the cheapest of the three stacks by a significant margin. If you're already factoring in infrastructure costs alongside token costs, that matters, since spending more during the build phase can sometimes mean cheaper ongoing hosting down the line.

Side-by-Side Results

Here’s the complete token cost comparison across all three frameworks with real numbers:

Django comes out as a clear winner on every metric related to costs: fewer tokens, zero prompt iterations, no dependency sprawl, and lighter memory, similar to Laravel.

What really stood out was the memory difference, as most developers assume Rails and Django are roughly comparable in this regard. However, in practice, Rails consumes around 80 MB of memory (4 times more than Django, which consumes approximately 20 MB) to provide the same feature set.

Laravel's token cost is the other counterintuitive finding. PHP is generally known as a pragmatic, low-overhead choice, and it lived up to that reputation when it came to memory and hosting. However, that was not the case in terms of cost.

The Hidden Cost: What Happens After “It Works”

Tokens tell just one side of the story. They represent only the build cost, not the total cost (in some cases, they are not even the largest expense). It’s equally important to consider what it takes to maintain these applications once they’ve been shipped.

1. Debugging tax: All three apps built by Cursor produced N+1 queries in their API endpoint. When it comes to Django, fixing it only requires one line if you know select_related. If you don't, you're back in Cursor, spending tokens to diagnose something the AI has quietly introduced.
2. Production issues: The AI produces code that works correctly when there are 10 rows of data, but fails when there are 10K of them. Some examples include missing indexes, improperly configured caching, and unprompted packages/libraries with their own failure modes. None of these will be apparent until you deploy your application.
3. Non-developer problem: If you have no framework background and let the AI decide, it will likely reach for Python, where it’s most fluent. But fluency doesn’t help you when the ORM starts misfiring and you don’t know what an ORM is to begin with (it’s an Object-Relational Mapper, in case the acronym wasn’t clear).
4. Multi-agent costs: The numbers discussed in this blog are single-agent sessions. Parallel front-end and back-end agents scale token costs non-linearly. One team reportedly burned €1,000 in just six hours.

The Real Answer

Based on the raw numbers alone, Django was the cheapest framework for AI coding in our experiment. It used half the tokens that Rails used and a third of Laravel's. It also boasted the fastest build speed, with no unexpected dependencies produced.

But when all is said and done, the least expensive framework is actually the one where it's easy to fix things when they break. If you're using Active Record in a Rails app, you’ll likely recover from mistakes the AI made faster than you would if you were to debug unknown Eloquent behavior.

And regardless of how many tokens each framework used to scaffold the app, make sure you’ve set up monitoring before you ship, as AI code does not provide you with a mental model of where things are likely to fail.

The good news is AppSignal has the monitoring you need for Rails, Django (Python), and Laravel (PHP) applications.