Two days ago, we published a piece showing how Magic cuts backend build cost by roughly 80 percent in agentic workflows.
That comparison was about platforms.
The same job, built from scratch by a frontier model versus expressed as intent against Magic's runtime.
This article is about the other variable.
The agent itself.
We took the same task management backend and rebuilt it — this time driven by Qoder, Alibaba's agentic coding platform, connected to Magic over MCP.
Same platform. Same natural-language workflow. Different agent, running on Qwen instead of Claude.
The result was the same working backend.
The estimated cost was roughly 3.4 percent of doing the job exclusively with Claude Fable.
That is a saving of about 96.6 percent.
You can watch the entire build below.
What Qoder built
The task was the familiar one.
A SQLite database called task-manager with two tables.
The first table was clients — client information with name, email, phone, address, and timestamps.
The second was tasks — tasks linked to clients through a client_id foreign key, with title, description, status, due date, and timestamps.
Deleting a client cascades to its tasks.
On top of that, a task-manager module with ten REST endpoints, all secured with the guest role.
Full CRUD for clients — list, create, get by ID, update, delete.
Full CRUD for tasks — with the list endpoint joining in the client name for each task.
Every endpoint was produced by Magic's Hyperlambda Generator from natural language descriptions.
No code was written by hand.
Qoder then seeded the database with five example clients and ten tasks spanning pending, in-progress, and completed statuses.
Database creation, schema definition, endpoint generation, role-based access control, and sample data — all of it executed through Magic's MCP tools, by an agent we had never connected to the platform before.
Nothing about the workflow changed
This is the part that matters more than the specific agent.
When we built this backend with Claude, the workflow was: describe what should exist, let the platform's tools do the heavy lifting, verify the result over HTTP.
When we built it with Qoder, the workflow was identical.
Because the integration point is MCP, Magic does not care which agent is on the other end.
The tools are the same tools. The permission boundaries are the same boundaries. The generated endpoints run inside the same runtime, with the same role-based access control, enforced at execution time.
The agent is swappable.
That is not a small architectural detail.
It means the choice of model becomes a pure economics question, made per task, rather than a platform commitment you are locked into.
And the economics turn out to be dramatic.
The economics
Claude Fable 5 is priced at $10 per million input tokens and $50 per million output tokens.
It is a superb model, and for the hardest reasoning work it earns that price.
Qoder takes a different approach.
A Pro plan costs about $20 per month and includes 2,000 credits, with model usage priced in credit multipliers.
And starting Monday, Qoder's off-peak pricing takes effect: the credit multiplier for Qwen3.7-Max drops from 0.5x to 0.1x during off-peak hours, with Qwen3.7-Plus dropping to 0.04x.
Run the backend build through that pricing, and the numbers stop being comparable in any meaningful sense.
Our earlier Fable-driven build of this backend landed at an estimated $0.53.
The same build driven by Qoder on off-peak Qwen3.7-Max lands at roughly $0.02.
That is approximately 3.4 percent of the cost.
A saving of roughly 96.6 percent.
As with our earlier comparison, these figures are calibrated estimates rather than exact metered logs.
But the directional gap is not subtle, and it is the point.
At this price level, the cost of building a hosted, secured, verified backend stops being a line item at all.
It disappears into the rounding error of a $20 monthly subscription.
Why a cheaper model can do this job
The obvious objection deserves a direct answer.
Fable is a stronger model than Qwen3.7-Max.
On raw reasoning benchmarks, that is not close.
So how can the cheaper model produce the same backend?
Because Magic changes what the model is actually asked to do.
When an agent builds a backend from scratch, it needs frontier-level capability.
It must design schemas, scaffold servers, wire routes, implement authentication, reason about role checks, manage dependencies, and debug the inevitable mismatches between all of those layers.
That is genuinely hard work, and weaker models fail at it in expensive ways.
But when an agent builds on Magic, almost none of that work exists.
Hosting is already solved. Authentication is already solved. Role-based access control is already solved. CRUD generation is already solved.
The agent's job shrinks to expressing intent against a platform that already contains the expensive primitives — and verifying the result.
That is a job a mid-tier model does perfectly well.
This is the deeper lesson of the experiment.
The 96.6 percent saving is not really a Qwen-versus-Claude story.
It is a story about where the intelligence lives.
When the platform holds the complexity, you no longer need to rent frontier reasoning to get production backends.
You need a competent agent and a capable runtime.
And competent agents are getting very cheap.
The safety question
There is one more reason this swap is possible, and it is worth stating explicitly.
Handing backend credentials to a cheaper, weaker model sounds like it should be a risk trade-off.
On Magic, it is not.
Every operation the agent performs runs inside the runtime's permission boundaries.
The generated endpoints carry role-based access control enforced at execution time, and the whitelisting system controls what generated code can bind to at all.
A weaker model might need an extra attempt here and there.
What it cannot do is generate its way past its permissions.
The worst a bad generation produces is a failed execution — not an incident.
That is what makes the model choice a pure economics question in the first place.
If safety depended on the model's judgment, you would pay for the best judgment available.
Because safety is a property of the runtime, you are free to pay for the cheapest model that gets the job done.
The honest fine print
The usual caveats apply, and a few new ones.
The cost figures are estimates, calibrated against the same methodology as our earlier comparison, not exact metered counts.
Off-peak pricing means off-peak hours — workloads that must run at peak time see a smaller gap.
This experiment covered the backend and integration slice of work.
We make no claim that Qwen3.7-Max matches Fable on general coding, architecture discussion, or hard debugging — it does not.
And Qoder's credit system means sustained heavy usage eventually buys additional credit packs, which shifts the marginal cost upward.
None of that changes the conclusion.
For the recurring, well-scoped backend work that agentic teams generate constantly, the combination of a cheap agent and a capable platform is now close to free.
Conclusion
Two days ago the argument was that Magic makes backend work roughly 80 percent cheaper than building from scratch.
Today the argument is stronger.
Because Magic speaks MCP, the agent driving it is interchangeable — and that turns model pricing into a market you can shop.
The same task management backend that cost an estimated $0.53 to build with Fable cost roughly $0.02 with Qoder.
Same database. Same ten endpoints. Same role-based security. Same verified result.
At 3.4 percent of the cost.
When the platform owns the hard parts, you stop paying frontier prices for routine backends.
That is not a discount.
It is a different cost structure.