DEV Community: Avenotech Team

Custom LMS Development: Cost, Timeline and When to Build vs Buy (2026)

Avenotech Team — Wed, 21 Oct 2026 03:28:55 +0000

Get three quotes for a custom LMS and you may well get three numbers that look like they belong to different products: $15,000, $90,000 and $300,000. None of the vendors has to be lying. "Custom LMS" means a branded prototype to one team, a working platform with reporting to another, and a multi-tenant system serving dozens of client organizations to a third.

The short answer: a focused custom LMS MVP costs about $40,000 to $70,000 and takes three to four months. A full platform costs $120,000 to $300,000 and takes six to ten. Extending an open-source LMS such as Moodle starts around $15,000.

Whether you should spend any of that depends on who you are, so two hypothetical buyers run through this guide:

The training buyer. A 400-person logistics company that needs drivers and warehouse staff through safety training and onboarding, with proof of completion when an auditor asks.
The product builder. A startup selling certification courses to 30 corporate clients, each of which wants its own branding, its own reports and its own invoice.

Their right answers are opposite, and most LMS cost guides never say which one they're written for.

In short

At 500 learners, five years of a licensed LMS costs $6,000 to $15,000 at 2026 list prices. Buy.
At 25,000 learners, building wins on cash only if the enterprise quote tops about 26 cents per learner per month.
Build when the LMS is your product. Buy when it's plumbing.

Why Do Custom LMS Development Quotes Range From $15K to $500K+?

Because they price different things under the same name. Below about $15,000 you're buying a prototype. The middle of the range buys a production v1 with roles, assessments, reporting and a responsive front end. The top buys multi-tenancy, serious concurrency, deep integrations and the audit trail a regulator will ask for.

Geography widens the spread. The same build costs two to three times more in San Francisco or London than in India or Eastern Europe, which is how identical scope gets priced at $60,000 by one vendor and $180,000 by another. The gap mostly reflects local salaries, so judge a team on its delivery record rather than its postcode.

Quotes also leave out different things, and almost none include content migration, admin training, localization or the iteration after launch. Make every serious proposal spell out scope, exclusions, team and rates before you compare two of them.

How Much Does It Cost to Build an LMS in 2026?

Here's the LMS development cost picture we'd defend for 2026, split into the five scopes buyers actually choose between.

Scope	Typical cost	Timeline	What you get
Extend an open-source LMS	$15,000–$40,000	6–12 weeks	Moodle or Open edX with a custom theme, plugins, SSO and one or two integrations
MVP or pilot	$40,000–$70,000	3–4 months	Course delivery, enrollment, assessments, progress tracking, basic reporting, admin console, SCORM import
Mid-scope platform	$70,000–$120,000	5–6 months	MVP plus custom roles and workflows, learning paths, certification logic, two or three integrations
Full platform	$120,000–$300,000	6–10 months	Virtual classroom, AI personalization, gamification, mobile apps, content authoring, several integrations
Multi-tenant or enterprise	$300,000+	10 months and up	Many organizations on one platform, white-labelling, per-tenant billing, two-way integrations, audit-grade compliance

Market ranges for a senior offshore or global mid-tier team in 2026. A US-only agency will quote above these for the same scope.

Our two buyers land in very different rows. The training buyer's needs fit the first row at most, and possibly no build at all. The product builder starts at the MVP and, once clients ask for their own branding and reports, grows into the mid-scope row within a year.

What moves the number

When we scope an LMS, these decide where in a band the quote lands:

Proprietary logic. Courses, quizzes and certificates are well-trodden ground. Adaptive tests, custom scoring and unusual certification rules are where budgets grow.
Integrations. Typically $5,000 to $25,000 each, depending on the quality of the other side's API. The expensive one is a two-way sync with a legacy system whose documentation is a wiki page and good intentions.
Real-time video. Live classrooms need WebRTC infrastructure and bandwidth that scales with every learner. Recorded video on a CDN is a fraction of the work.
Native mobile. A responsive web application covers most corporate learners. Offline playback on iOS and Android roughly adds a second front end, so a native mobile learning app gets scoped as its own line.
AI features. They bring a cost line almost nobody budgets for: model API usage. Decide early whether AI runs on your API keys or on a vendor's markup.

These ranges assume a team that has built learning platforms before. One learning SCORM sequencing on your budget lands at the top of each band.

The costs that arrive after the quote

Migration from an old LMS is almost always under-scoped (the build steps below explain why), and admin training and translation sit outside most quotes too. Keep 15 to 20% of the build budget for the first 90 days after launch, because version one always meets reality.

Then there's maintenance. A common rule of thumb is 15 to 20% of the build cost every year for hosting, security patches, dependency upgrades and monitoring. Owning the code means owning the upkeep, which is what makes some "expensive" SaaS contracts look reasonable.

Custom LMS vs Off-the-Shelf: A Build vs Buy Framework That Survives the Meeting

Most build-vs-buy content frames the decision as a feature comparison. The question that actually decides it is shorter: is the LMS your product, or is it plumbing?

If the learning platform is how you make money (you sell courses, monetize certifications, white-label for partners, or the learning experience is your moat), forcing that into someone else's SaaS taxes you forever. Per-learner fees grow with your revenue, someone else's roadmap decides your features, and competitors can buy the identical platform. That's the product builder, and for them building a multi-tenant SaaS platform is the business itself rather than an IT purchase.

If the LMS is administrative infrastructure (compliance training, onboarding, standard credentialing), you're in the business of running training programs, not operating software. That's the training buyer, and they should buy. The moment you own the code, you own the upgrades, the security patches, the hosting and every incident.

Two other situations push toward building even when the LMS isn't the product. One is training people outside your company, such as customers, partners or franchisees, who need separate tenants, branding and often per-client billing. The other is a process no licensed tool can handle without permanent workarounds: certifications renewed against a regulator's rules, apprenticeships with on-the-job sign-off, or credentials that mix online modules with observed practice.

Ask in order	If yes	If no
1. Is the LMS what you sell?	Build a custom MVP	Go to question 2
2. Five-year license quote under $70k?	Go to question 3	Go to question 4
3. Fits your workflow as is?	Buy and configure it	Go to question 4
4. Does a hybrid cover it?	Go hybrid	Build, with an owner

A build vs buy decision path for a custom LMS. Use a written quote, not a list price, for question 2; $70,000 is the top of the MVP range above. The hybrid options are described below.

The three real paths in 2026

The first is configurable SaaS, the fastest route to a working platform. Entry prices are modest (TalentLMS starts at $119 a month and has a free tier for 5 users), while enterprise platforms such as Docebo, Absorb and Cornerstone are priced on request. The trade is control, plus costs that grow with your success.

The second is open source or a hybrid. Moodle is the open-source option most buyers already know, with registered sites in 237 countries; Open edX suits engineering teams building at scale, and Totara sits in between. Hybrids come in three shapes:

Extend Moodle or Open edX with your theme, plugins and integrations, which covers more "custom LMS" briefs than people expect.
Build an LTI 1.3 tool instead of an LMS, if what you sell is a simulation, assessment or lab that can launch inside Canvas, Moodle or Blackboard.
Go headless: keep a licensed LMS as the system of record and build your own front end on its API, once you've confirmed the API covers what you need.

All three spare you rebuilding enrollment, gradebooks and course playback. But open source with nobody to maintain it is the most expensive mistake in this category.

The third is a full custom build, with complete control over roadmap, data, UX and architecture. It's justified when your learning workflow is proprietary, commercially differentiating or regulated in ways no platform supports, and only with a permanent owner, either your own engineers or a retained partner.

Build vs Buy in Numbers: License Math at 500 Learners

Most build-vs-buy articles stop at "licensing fees add up." Here's by how much, using list prices published on each vendor's own pricing page in October 2026.

Five-year cost at 500 active learners (2026 list prices)

Option	Five-year cost
MoodleCloud Medium	$6K
TalentLMS Grow	$14K
LearnWorlds Learning Center	$15K
Custom LMS MVP (build only, low end)	$40K

At this size licensing wins, and it isn't close: the custom row shows the build alone, before a single year of maintenance. This is the training buyer's answer. Their 400 staff fit comfortably inside a plan from TalentLMS, MoodleCloud or LearnWorlds, and the money a build would cost buys years of subscription plus someone to run the training. One detail if you rerun the math: TalentLMS counts active users, meaning people who log in that month, so a workforce that trains in bursts can cost less than its headcount suggests.

When Custom LMS Development Pays Off: The Break-Even by Learner Count

The 500-learner chart is the easy case. The decision gets interesting as learner numbers grow, because a license is priced per learner and a custom platform mostly isn't. Above about 1,000 learners, public pricing disappears and every serious vendor is quote-only, so rather than guess what a quote will say, work out the number it has to beat.

The worked example at 25,000 learners

Take an organization with 25,000 learners and two routes it controls. These are illustrative assumptions, not quotes, so swap in your own:

Self-hosted open source: $25,000 to install, theme and harden, plus about $2,000 a month for hosting and part-time administration.
Custom build: a mid-scope platform hardened for that load at about $90,000, plus about $3,000 a month in hosting and 15 to 20% of the build a year in maintenance from year two.

Over three years, open source comes to $25,000 plus 36 months at $2,000. The custom build comes to $90,000 plus 36 months at $3,000 plus two years of maintenance, which lands between $225,000 and $234,000.

About $97K: open source, three years
About $230K: custom build, three years
26¢: per learner per month to break even

The break-even is the license price that costs the same over those three years. Divide the custom total by three and you get $75,000 to $78,000 a year, or about 26 cents per learner per month across 25,000 learners. A quote above that means building costs less in cash; below it, licensing wins and the decision goes back to product versus plumbing. Open source stays lowest in cash, but its monthly figure leaves out the engineering time that plugin upgrades and fixes quietly consume.

How the break-even moves with scale and time

Run the same custom cost against different learner counts and the pattern becomes clear. Because the build is a fixed cost, the license price it has to beat falls as learners grow, and it falls further the longer you keep the platform.

License price per learner per month a custom build has to beat, by learner count

Learners	Over 3 years	Over 5 years
5K	128¢	111¢
10K	64¢	56¢
25K	26¢	22¢
50K	13¢	11¢

Now set those bars against what licenses already cost. Taken at the top of each plan, the published list prices above work out to roughly 12 to 46 cents per learner per month: about 12 cents for LearnWorlds at its 2,000-learner cap, 20 cents for MoodleCloud at 500 users and 46 cents for TalentLMS Grow at 500. Volume pricing normally brings the per-learner rate down at enterprise scale, but no vendor publishes by how much. Read against that range:

Up to about 10,000 learners, a license would need to cost well over list price before building won on cash. Buy, unless the LMS is your product.
Around 25,000 learners, the break-even sits inside the range licenses already charge. This is a genuine toss-up, and the written quote decides it.
From about 50,000 learners, a license has to come in close to the lowest list rate we found, and lower still over five years. At that scale a custom platform is likely to cost less unless the vendor discounts hard, and the gap widens every year you keep it.

One honest caveat cuts both ways: hosting is held at $3,000 a month in every bar. A 5,000-learner platform would cost less to host, which lowers its break-even, and a 50,000-learner one would cost more, which raises it. The direction of the pattern doesn't change.

What the break-even doesn't capture

Three things sit outside the cash comparison, and they're usually what decides it for the product builder.

Growth works differently. A per-learner license grows in step with every learner you add. A custom platform's main cost was paid once, and hosting grows far more slowly than headcount. If you expect to double your learners, the license bill doubles with them.
Margin and ownership. When the LMS is what you sell, a per-learner fee comes out of the margin on every sale, and the roadmap belongs to the vendor. A platform you own can be white-labelled for clients, priced however you choose, and changed when a client asks.
Risk sits on the other side. A build is paid for before the first learner logs in, it can run late, and it needs a permanent owner. Licensing moves those risks to the vendor, which is worth something real.

Two failure modes hide in all of this. The first is the double bill: outgrow a stopgap platform within two years and you pay twice, which is why a product builder whose direction is already clear does better with a focused custom MVP up front. The second is the maintenance vacuum, so decide who runs the platform before launch. Many teams keep a small dedicated offshore team on it after go-live rather than rebuilding that knowledge each time something breaks.

How Long Does It Take to Build an LMS?

Three to four months for an MVP, five to six for a mid-scope platform, and six to ten for a full one. Any timeline you're handed before discovery is a hypothesis, because the things that set it (your HR system, your old LMS vendor, your compliance team) sit outside the development team's control.

A 16-week custom LMS MVP, and what has to be true to leave each phase

Phase	Weeks	What happens	Exit criterion
1. Discovery and design	1 to 5	Map who assigns, completes and checks training. Count the courses and records to move. Prototype the key screens with one of your real courses.	A real admin and a real learner have signed off the prototype
2. Build and integrate	5 to 12	Course player, enrollment, quizzes, reports and SSO, demoed every two weeks. Integrations start against sandboxes early.	A real course plays end to end with completion recorded
3. Test, migrate, pilot	12 to 16	Test your own SCORM packages, audit accessibility, rehearse the migration, then run one group through a full course.	Migrated records reconcile and the pilot finishes cleanly

Integrations start inside the build phase rather than after it, which is what keeps an MVP inside four months.

An enterprise build stretches every phase, with discovery taking four to eight weeks and integration and migration eight to sixteen, which is how large programs pass ten months. At any size, the biggest schedule risk is your existing content rather than the new code. A library built in different authoring tools over a decade always holds courses that misbehave in a new player, and testing a sample in week 2 costs almost nothing, whereas finding them in week 14 usually moves the launch date.

How to Build an LMS: A Step-by-Step Process

Once you've decided to build, this is the order we'd follow. Each step exists because of a specific way LMS projects go wrong.

Write down who assigns, who completes and who gets audited. Who decides a driver needs forklift training, when it's due, who's reminded when it's late, and which report the auditor wants. Then put one of your real courses into the prototype, not placeholder text, to see what your content needs from a player.
Try to break a licensed LMS first. Run your three hardest training scenarios through a free tier or trial. If a licensed product handles all three, you've just saved the cost of a build.
Cut version one to what learners touch on day one. Sort features into must, should, could and won't, and be strict about the last list. Scoping an MVP that proves learners will use it is how you avoid spending the full-platform budget on features nobody asked for.
Settle the decisions that are expensive to undo. SCORM or xAPI, data residency, whose API keys the AI runs on, and above all the multi-tenancy decision if more than one organization will ever use the platform.
Make the first demo a real course, and test the leaver as well as the joiner. Demo working software every two weeks and connect your systems early. Teams check that new hires get enrolled automatically; fewer check that leavers are deactivated, and on per-seat pricing they keep costing you money.
Migrate records with their original dates, then pilot. Completion, certificate issue and expiry dates are what an auditor asks for. If a migration stamps every certificate with the import date, renewals fall due on the wrong day. Rehearse the migration once, then launch to one group before everyone.

The Technical Details That Decide Whether It Works

Two things trip up LMS builds that look fine on paper: the content standards your courses depend on, and the rules that apply if you sell to US schools.

SCORM, xAPI and LTI 1.3

SCORM is still what most course libraries are packaged in, accounting for 92% of registrations on Rustici Software's SCORM Cloud in 2025, according to Rustici's February 2026 analysis. The trap is saved progress. SCORM 1.2 only guarantees 4,096 characters of it, against 64,000 in later SCORM 2004 editions (SCORM run-time reference), so a long course that worked on your old LMS can lose learners' place on a stricter new one. Licensing a proven SCORM engine is usually faster than writing your own player.

Add xAPI, now an IEEE standard, only if you need to track learning outside courses. Build anything that plugs into Canvas or Moodle on LTI 1.3, since 1EdTech retired the security model behind LTI 1.1 in 2021.

Selling to US schools?

Public schools and universities must meet WCAG 2.1 AA under the DOJ's ADA Title II rule, by April 26, 2027 for larger entities and April 26, 2028 for smaller ones, and we build to WCAG 2.2 AA, which covers it. If learners are under 13, the FTC's amended COPPA Rule has applied since April 22, 2026. Projects like these usually grow into rostering and student records, so they're worth scoping as custom education software development rather than as an LMS build.

Where AI Fits in a 2026 LMS Budget

Add AI to version one only if AI is the product. Otherwise, design for it and ship it once the core is stable. Adoption is still early: 37% of US organizations with 100 or more employees used AI in their training in 2025, according to Training Magazine's 2025 Training Industry Report.

The features that hold up are narrow: semantic search across course content, drafts for course authors, and tutoring grounded in approved material. Generative AI features such as tutoring need an evaluation set built from real learner questions before any learner sees them. If you're adding AI to an LMS you already run, our guide to adding AI to an existing platform covers the pattern.

5 Questions to Ask Before You Sign Anything

What's excluded from this quote? Get migration, training, translation, compliance and post-launch support in writing. A vendor who won't list exclusions is telling you where your budget will go.
Who owns the code and the IP? It matters the day you change partners or raise money.
Who maintains it at 2 a.m.? An internal team, a retained partner, or nobody, which many buyers choose by accident.
What's the exit cost? Export formats and contract terms. The platform you can leave is the platform you can negotiate with.
How is AI costed? Per-seat markup, metered usage or your own account. Ask for a projected monthly AI bill in writing, not a demo.

Frequently Asked Questions

How much does it cost to build an LMS?

A custom LMS MVP typically costs $40,000 to $70,000 in 2026, a mid-scope platform $70,000 to $120,000 and a full platform $120,000 to $300,000. Extending Moodle or Open edX costs $15,000 to $40,000. Budget 15 to 20% of the build a year for maintenance.

How long does custom LMS development take?

Three to four months for an MVP, five to six for a mid-scope platform and six to ten for a full platform, with enterprise builds running ten months and up. Integration and data migration are the phases that slip most often.

Is it cheaper to build or buy an LMS?

At 500 learners, buying wins: five years of TalentLMS, MoodleCloud or LearnWorlds costs $6,000 to $15,000 at 2026 list prices. At 25,000 learners, building costs less over three years only if the license quote tops about 26 cents per learner per month.

Is Moodle free to use?

The software is open source and free to download, but running it isn't. Hosted MoodleCloud plans run from $170 a year for 50 users to $2,100 for 750 (MoodleCloud, October 2026), and self-hosting means paying for servers, patching and upgrades yourself.

Can we move our existing SCORM courses into a custom LMS?

Yes. SCORM was built to be portable and made up 92% of registrations on Rustici Software's SCORM Cloud in 2025 (Rustici Software, 2026). Test long courses during discovery; learner history and certificate dates are harder to move than the courses.

The Bottom Line

If you're the training buyer, buy, and spend what a build would cost on good courses and someone to run them.

If you're the product builder, build, but small: a focused MVP that real learners use, on a multi-tenant architecture, with a named owner for the day after launch.

If you're somewhere in between, get a written multi-year license quote at your real learner count this week and set it next to the break-even above. That one comparison settles more of these decisions than any feature list.

Originally published on the Avenotech blog, where we write about software and AI for growing businesses. Prices and figures were checked in October 2026; vendor pricing changes, so confirm current numbers before you decide.

AI Agent Frameworks Compared: LangGraph vs CrewAI vs AutoGen

Avenotech Team — Tue, 13 Oct 2026 03:08:41 +0000

Why is the most-starred framework in this comparison the one you shouldn't start a new project on in 2026?

AutoGen holds roughly 60,400 GitHub stars, more than CrewAI's 57,100 and LangGraph's 39,800. It hasn't shipped a Python release in 320 days. Its last tagged version (python-v0.7.5) shipped on September 30, 2025. The repo hasn't had a commit pushed since April 15, 2026. And yet every "LangGraph vs CrewAI vs AutoGen" post being written right now is still treating it as a live option.

That gap, between stars and production reality, is what this post is actually about. Not a feature matrix. Not a benchmark that can't be audited. The evidence of where each of these frameworks breaks when you run it at scale, who maintains it, and what it actually costs when things go wrong.

Every fact here comes from the GitHub REST API, PyPI release history, official READMEs, vendor migration guides, and public issue trackers, all verified on 2026-08-16. Where evidence is one engineer's account rather than a measurement, it's labeled that way.

Key Takeaways

AutoGen is in maintenance mode per its own README, and the Python package hasn't shipped a stable release in about 320 days. The successor is Microsoft Agent Framework, GA since 2026-04-03. New projects should start there. AG2 is a real option for legacy codebases, and it's a fork, not a rebrand.
Stars lie; installs are closer to the truth. AutoGen leads on stars (about 60K) and trails on monthly PyPI installs (about 1M). LangGraph has fewer stars (about 40K) and runs at about 71M installs, roughly 65x AutoGen. The gap survives every honest caveat.
Treat the star-to-install ratio as a freshness signal in reverse. Stars accumulate at peak hype; installs track present-tense production dependence. A high ratio means a project was once exciting and now isn't load-bearing anywhere.
Verified 2026-08-16 against LangGraph 1.2.11, CrewAI 1.15.16, AutoGen 0.7.5 and Microsoft Agent Framework 1.0. This category moves within weeks, so check those versions on PyPI before you act on any of it.
Don't pick on star counts. Pick on what shipped, what broke, and what's still being maintained.

If you're scoping this for a real system rather than a spike, the framework choice is one input into building a production agent system, and it's rarely the input that decides whether the thing ships.

Which agent framework should you use in 2026?

The short answer, before the evidence.

Pick LangGraph if you need explicit, auditable control flow and durable state, and you can staff the persistence work it brings. Pick CrewAI if you're prototyping multi-agent workflows fast and you accept that delegation is model-mediated. Don't start on AutoGen: as of August 2026 its README carries a maintenance-mode banner directing new users elsewhere. If you're already on AutoGen, your target is Microsoft Agent Framework, GA since April 2026, and the move is a rewrite rather than an upgrade. And if your workflow is three LLM calls in a loop, use no framework at all.

Why that answer isn't the usual one

Every framework here can call a tool and pass a message, so a feature matrix can't separate them. What separates them is what fails at scale: LangGraph breaks on checkpoint growth, CrewAI breaks on prompt-mediated delegation, AutoGen breaks on maintenance. The rest of this post is the evidence for each, with the tracker issues and post-mortems that document them.

The metric that should matter (but doesn't show up in comparison posts)

Stars are a lagging indicator. They record what got bookmarked at peak hype, which for AutoGen was the v0.2 launch era in 2024. Stars accumulate indefinitely and are never removed, even when a project goes quiet. Installs are the opposite: a recurring production cost, paid every time CI runs or an image rebuilds.

The numbers have completely decoupled.

Monthly PyPI installs, last 30 days

Category	Value
LangGraph	71.1M
CrewAI	20.7M
MS Agent Framework	1.6M
AutoGen	1.1M

LangGraph ships roughly 71 million monthly PyPI installs. AutoGen ships about 1.08 million. That's 65x more installs for the framework with fewer stars. CrewAI sits at roughly 20.7 million monthly installs, real production usage by any reading, but a fraction of LangGraph's volume.

A 65x gap in installs against a lead in stars is a strong signal about where the production load actually is. It's not a popularity contest. It's a load map.

GitHub footprint: stars vs forks

Category	Stars	Forks
AutoGen	60K	9K
CrewAI	57K	8K
LangGraph	40K	7K
MS Agent Fw.	13K	2K

Here's the thing that makes it a procurement problem: PyPI counts include CI pipelines and container rebuilds, so they're not user counts. Treat them as a relative signal, not an absolute. And LangGraph benefits from being pulled in transitively by the wider LangChain ecosystem, which inflates its number relative to a standalone install. AutoGen has no such tailwind, and the gap is still enormous. A 65x gap survives both caveats. A 1.2x gap wouldn't.

Release cadence tells the same story from a different angle. Days since the last release, as of 2026-08-16:

AG2: 1 day
CrewAI and MS Agent Framework: 2 days
LangGraph: 5 days
AutoGen: 320 days

One more cadence note before we get to the frameworks. CrewAI shipped 1.15.16 on August 14, 1.15.15 on August 12, 1.15.14 on August 8, and two releases on August 5. That's roughly ten releases in nineteen days. Whether that signals fast fixes or fast churn depends on how much you trust their release process, but either way, lock your version before you start.

The mental models (and why the model matters)

	LangGraph	CrewAI	AutoGen
Best for	Stateful, controllable graphs	Fast multi-agent prototypes	Nothing new in 2026
Latest stable	1.2.11 (2026-08-11)	1.15.16 (2026-08-14)	0.7.5 (2025-09-30)
Monthly PyPI installs	71,095,727	20,672,935	1,082,331
Licence	MIT	MIT	Ambiguous, see below
Orchestration model	Explicit graph, developer-defined edges	Manager agent, prompt-mediated	Group chat, speaker selection
Control flow	Enforced by the graph	Suggested by the prompt	Suggested by the prompt
State	Checkpointed, persistent, JSON-shaped	Task outputs plus optional memory	Agent-held conversation history
Default loop ceiling	1,000 supersteps	20 iterations per agent	String-matched termination
Maintenance status	Active (5 days since release)	Active (2 days since release)	Maintenance mode (320 days)
Our verdict	Default choice for production	Good for speed, verify delegation	Migrate off

Framework comparison as of 2026-08-16. Sources: GitHub REST API, PyPI, official documentation.

LangGraph is a directed graph with a central state object. Agents are nodes. Edges define flow. Conditional edges handle branching. Reducers merge concurrent state updates. You draw the control flow; the LLM executes within it. The mental model is a state machine, and the framework enforces it in code.

Built-in primitives: durable execution (checkpointing, resume from interruption), human-in-the-loop (interrupt the graph, collect input, resume), short-term and long-term memory. It's the most explicit of the three about where control lives.

CrewAI is a role-based team. Every agent carries a role, a goal, a backstory, and tools. A Crew executes tasks sequentially or hierarchically. In hierarchical mode, an auto-generated manager agent delegates and reviews. The runtime provides the hierarchy; the delegation decisions inside it are model-mediated rather than encoded as developer-defined conditional edges. Flows, a newer primitive, are event-driven pipelines that offer more predictable production control: one LLM call per step, no autonomous delegation.

AutoGen, in its current maintained mode, is a conversation-driven multi-agent runtime. Two-agent chats, group chats with an LLM-powered speaker selector, sequential and nested conversations. The successor, Microsoft Agent Framework, has the same patterns but a different architecture. AutoGen itself is not being developed.

AutoGen's licence deserves a flag of its own, because it's a procurement problem rather than a technical one: GitHub detects the repo as CC-BY-4.0, the README describes a dual CC-BY-4.0 and MIT arrangement, and PyPI reports MIT. Your legal team will not enjoy that conversation.

Where LangGraph breaks in production

The failure point isn't the API. It isn't the tooling either.

It's the checkpointer, and specifically, what happens to your Postgres instance when nobody has planned for checkpoint growth.

Tadeo Donegana Braunschweig, an engineer at Tiendanube, published the clearest public account of this in April 2026. At more than 120,000 conversations per week, his team's checkpoint tables grew without bound. The open-source checkpointer ships no native TTL. An average conversation produced roughly 93 rows across four checkpoint tables after just two messages and three tool calls.

Two messages, and your database is ninety-three rows heavier.

In staging, checkpoint_blobs alone hit 56 MB after a single week of traffic. His summary: operational databases should store operational state, not historical exhaust.

This isn't one team's unlucky configuration. On the LangGraphJS tracker, issue #1138, "How do I keep data in Postgres checkpointer database from growing unbounded?", was opened in April 2025 and is still open. LangChain's own documentation suggests running a cron job to delete old checkpoints. That's a clear statement about where lifecycle management lives.

The vendor shipped a fix, and it's worth reading the numbers carefully because they get misquoted. PR #7586 introduced DeltaChannel, which stores a small sentinel value plus replay instructions instead of re-serializing the full accumulated state at every step.

Checkpoint storage for a 500-turn thread

Category	Value
add_messages (default)	221 MB
DeltaChannel, snapshots every 50	10.53 MB
DeltaChannel, no snapshots	1.98 MB

The default reducer writes more than a hundred times what the tightest DeltaChannel configuration does, and the middle row is the setting most teams actually want.

Three caveats before you bank on it. It landed in LangGraph 1.2.0 on 2026-05-12, it's marked beta, and it's opt-in: upgrading does nothing until you actually annotate the channels you want it on. Bloat already written to your tables stays written.

Here's where it gets expensive for teams that didn't budget the operational work. LangGraph's checkpoint packages (checkpoint, checkpoint-postgres, checkpoint-sqlite) version separately from core. If you pin core and float the checkpointers, you've secured the wrong half of the stack. Budget the persistence work before launch, not after

Braunschweig's three fixes generalise. Move checkpoint table creation into Alembic migrations rather than calling LangGraph's setup(), so your schema is version-controlled like everything else. Run recurring TTL deletion, paired with a weekly job that archives history to object storage if you need it for analysis. And checkpoint selectively: persist only the supervisor graph and keep sub-graphs stateless. None of this is exotic work, which is exactly why it gets skipped when an agent prototype gets bolted onto a product that already exists.

The typed-state complaint

Separate from persistence, there's a recurring ergonomics objection about state typing, and it needs stating carefully because the strong version of it is wrong. StateGraph accepts a real schema: TypedDict, a dataclass, or a Pydantic BaseModel if you want recursive validation. LangGraph is not untyped.

The gap is one level up. LangChain's own documentation notes that the higher-level create_agent factory does not support Pydantic state schemas, and the factory is where most teams start. So the typing is available on the API you graduate to, not the one you begin on. One engineer on Hacker News put the frustration this way:

"My experience with langgraph is you spend so much time just fixing stupid runtime type errors because the state of every graph is a stupid JSON blob with very minimal typing, and it's so hard figuring out how data moves through the system."

That's one account. But it's not floating free of evidence, and the evidence points at the same seam. Issue #5891 (TypeError: Type is not msgpack serializable: Send) is a create_react_agent bug, which is exactly the factory path that can't take a Pydantic schema. Issue #740 (InvalidUpdateError on state writing) names the same root cause: state shape discovered at runtime rather than at definition time.

The practical read: LangGraph gives you the tools to keep state contracts honest, and it doesn't force you to use them. The risk isn't missing typing, it's contracts drifting across nodes because nothing made you declare them. Define the schema explicitly at the boundaries that matter, and most of this class of bug disappears.

Where LangGraph is actually strong

Explicit node structure makes execution topology predictable: the graph decides which nodes run and in what order, rather than the model deciding for itself. Token usage is a separate question, and it stays dependent on prompt size, retrieved context, tool outputs, retries and model behaviour. Predictable structure is not a predictable bill, which is why the cost section below argues what it does.

What the structure does buy you is auditability. LangGraph's control flow is enforced in code, not suggested in a prompt, so when a compliance reviewer asks which agent can call which tool under what condition, you can point at an edge instead of a paragraph of instructions.

Where CrewAI breaks in production

Delegation.

Not as a theoretical concern, but as a documented, reproducible failure mode that's been sitting in the issue tracker for over a year.

The 15,759-token incident. Partha Sarkar documented this in detail: a three-agent support crew (triage, technical, billing) running in hierarchical mode received a purely technical query. The manager invoked all three agents, including billing. The billing agent's response then overwrote the correct technical answer. The run consumed 38 seconds and 15,759 tokens to produce roughly 200 tokens of output. Nothing errored.

Root cause: hierarchical mode doesn't enforce conditional branching or true delegation. The manager decides, and when the model's judgment wobbles, the control flow wobbles with it. Look at what the failing workload actually was: routing a support question to the right specialist is ordinary chatbot routing, and it's the case a multi-agent crew is supposed to handle best. His fix was to replace the built-in manager with a custom manager agent carrying explicit step-wise instructions. After that change, technical-only runs took 24 seconds and about 10,000 tokens. You recover roughly a third of the cost by hand-rolling the orchestration the framework was supposed to handle.

Three delegation bugs in eleven months

They all show the same theme. Issue #2606 (April 2025): manager passes dicts while the schema expects strings. Issue #4783 (March 2026): manager executes tasks with its own tools and never delegates, collapsing hierarchical into sequential. Closed as not_planned. Issue #3925 (November 2025): with English task descriptions the manager delegates correctly; with Japanese descriptions the manager answers alone without delegating. Reproducible in both directions.

Sit with what that last one implies. The control flow of a production system changed because the natural language of its task descriptions changed. No framework that enforces orchestration in code can exhibit that behaviour, which makes #3925 the cleanest available proof that CrewAI's hierarchy is a request written into the prompt, not a rule the runtime enforces. If you run CrewAI in a non-English market, make this your regression test before you ship. Comment counts are not an engagement signal on this repo

One methodology note from reading the tracker directly, because it changes how you should read any CrewAI issue thread. CrewAI's highest-comment issues (#4877 at 271 comments, #5802 at 98, #4560 at 97, #5888 at 82) all carry zero reactions, which is an odd shape for genuinely contested threads. Reading #5802 explains it: the issue author repeatedly pitches their own product, and one commenter opens with "Hey! I'm Hermes Agent, an autonomous coding AI agent. I saw this issue and thought I could help." Use reactions and maintainer replies instead. In 2026 that's a general lesson about evaluating open source, not a knock on CrewAI specifically.

The open security issue

Issue #5057, "Memory content injected into system prompt without sanitization enables indirect prompt injection," has been open since March 2026 and was last updated in July. Mechanically, lite_agent.py concatenates retrieved memories straight into the system prompt. Anything written to memory inherits system-level instruction authority. It's rated Medium and cites the OWASP Agentic Security Index. Nearly five months on, it's still open. If you use CrewAI memory with any user-influenced content, apply the recommended mitigation (moving memory out of the system prompt and into user messages) before you ship.

The release cadence as a risk

CrewAI shipped its 1.0.0 rewrite on October 20, 2025, with breaking changes. Since then, the pace has been relentless, roughly a release every two days. That means your pinned version is end-of-life within weeks. It also means bugs get fixed fast. Weigh both.

Where CrewAI is actually strong

For teams that need to ship a multi-agent prototype quickly, CrewAI's higher-level abstractions are genuine. The role/goal/backstory model means you can get a working crew running in hours. The 20.7 million monthly installs reflect real production usage. And if something breaks, there's a good chance a fix is already in the next release.

Where AutoGen breaks (and why "migrate off" is the right starting point)

AutoGen is in maintenance mode. That's the sentence that should end the discussion for anyone starting a new project. But it's worth understanding what that means in practice, because there are teams already running on it who need to know the shape of their exit.

The README carries a maintenance-mode banner verbatim: "AutoGen is now in maintenance mode. It will not receive new features or enhancements and is community managed going forward. New users should start with Microsoft Agent Framework." Last tagged release: python-v0.7.5, September 30, 2025. Last repo push: April 15, 2026. That's roughly ten and a half months without a release, and no archive banner marks the repo, so at a glance the project doesn't look dead. It just is.

Migrating off AutoGen is an architecture review, not a dependency bump. The behaviour that changes underneath you is invisible until a user reports it.

The lineage is worth knowing. Original authors Chi Wang and Qingyun Wu left Microsoft in November 2024 and forked the project to AG2 (ag2ai/ag2), now at v1.0.x under Apache-2.0. Microsoft shipped Microsoft Agent Framework (MAF) 1.0 GA on April 3, 2026, developed by the core AutoGen and Semantic Kernel teams. MAF ships for Python and .NET under MIT, supports A2A and MCP interop, and has stable APIs with an LTS commitment. Official migration guides exist for AutoGen to MAF and Semantic Kernel to MAF.

The migration is a rewrite, and one change is silent

Microsoft's own migration guide reads as a from-scratch guide, not an upgrade guide. AssistantAgent becomes Agent, and the state semantics invert underneath the rename. AssistantAgent maintained conversation history as part of its state. Agent is stateless and does not maintain history between invocations. Nothing errors when you port the code. Your agent doesn't throw an error, it just stops remembering, and you discover it from a customer complaint.

There's a second inversion in the same rename. AssistantAgent is single-turn unless you raise max_tool_iterations. Agent is multi-turn by default. So the migration turns one component from "remembers, but acts once" into "acts many times, but remembers nothing."

Both inversions hide inside a port that looks like a rename (the_silent_migration_bug.py):

# AutoGen: single-turn by default, and the agent holds the history
agent = AssistantAgent(name="support", model_client=client, tools=[lookup])
await agent.run(task="What did I order?")
await agent.run(task="And when does it ship?")   # remembers the first turn

# Agent Framework: the port compiles, runs, and errors on nothing
agent = Agent(name="support", chat_client=client, tools=[lookup])
await agent.run("What did I order?")
await agent.run("And when does it ship?")        # no memory of turn one

# Nothing raised. The agent just answers the second question blind,
# and you find out when a customer complains. Thread state is now
# yours to carry explicitly between invocations.

One more gap to scope before you commit: AutoGen supports local code execution tools, and Microsoft's guide states that this feature is planned for future Agent Framework versions. Today it's a hole.

Termination by string matching

AutoGen terminates when an LLM generates the exact token TERMINATE. Because models are sloppy with exact tokens, they emit terminate, Terminate., Task terminated, or wrap it in markdown. None of those match, so the loop continues and you pay for every turn. Speaker selection fails the same way: if the selector's output doesn't exactly match an agent name, the same agent gets re-selected repeatedly, producing a single-agent infinite loop.

Issue #12 ("force TERMINATE") dates to July 2023. On classic AutoGen, pair max_consecutive_auto_reply with a token ceiling at your gateway before you deploy anything. Note that the knob doesn't carry over to Agent Framework, which is one more reason to treat the migration as a rewrite. And a framework in maintenance mode isn't shipping fixes for any of it.

One honest caveat

AG2 is a real option for teams on classic AutoGen with heavy investment and no appetite for a Microsoft-shaped migration. The original authors maintain it. It's at v1.0.x under Apache-2.0, actively released, with the classic API preserved in a separate ag2-classic repo. It's a smaller ecosystem and a fork rather than a corporate-backed project, so weigh that accordingly.

What multi-agent orchestration actually costs

Roughly 2.3x a sequential baseline, if you pick the most accurate pattern.

Kulkarni and Kulkarni benchmarked multi-agent architectures on SEC filings (arXiv:2603.22651, March 2026). Reflexive self-correcting loops achieved the highest field-level F1 (accuracy per extracted field) at 0.943, at 2.3x the cost of a sequential baseline. Hierarchical supervisor-worker reached F1 0.921 at 1.4x cost, the best cost-accuracy point in the study. A hybrid recovered 89% of the reflexive gains at 1.15x baseline cost.

Relative cost of four orchestration patterns

Category	Value
Sequential	1x
Hybrid	1.15x
Hierarchical	1.4x
Reflexive	2.3x

Those patterns map onto the frameworks directly. CrewAI's hierarchical process is the supervisor-worker row. LangGraph's cyclic graphs are how you build the reflexive loop. AutoGen's group chat is a third shape, less disciplined than either. Practically: if you're paying 2.3x for reflexion across every field in a document, you're overpaying, because the hybrid recovers most of the accuracy for a 15% premium.

None of these three will stop a run on spend

One finding that should shape how you budget this: across LangGraph, CrewAI and Microsoft Agent Framework, every available control knob bounds structure. None bounds money.

Framework	Knob	Default	What it actually bounds
CrewAI	max_iter	20	Iterations per agent
CrewAI	max_retry_limit	2	Retries, and it multiplies spend
CrewAI	respect_context_window	True	Summarizes to stay under context
LangGraph	recursion_limit	1,000	Supersteps per execution
Agent Framework	max_iterations	100	Workflow iterations

Every knob bounds structure. None bounds money. Sources: official CrewAI, LangGraph and Microsoft Agent Framework documentation, retrieved 2026-08-16.

Two problems hide in that table.

Default ceilings differ by 50x and nobody compares them. LangGraph allows 1,000 supersteps. MAF allows 100 workflow iterations. CrewAI allows 20 iterations per agent. CrewAI's looks tightest until you notice it's per-agent, so a five-agent crew's effective ceiling multiplies, and max_retry_limit=2 multiplies it again.

A structural limit also treats a 200-token call and a 200,000-token long-context call as identical events. That's why teams file "we set max_iter, why was the bill still huge?" tickets. You capped the number of steps, but your bill is counting tokens, and the two move independently. Watching it happen isn't an option either: CrewAI's usage metrics are strictly post-hoc, available after kickoff() completes. The bill only shows up once the run has already finished and been paid.

If spend is a hard constraint, put the cap at your gateway or proxy layer, where you can actually count tokens as they're spent.

When to skip the framework entirely

Sometimes the right agent framework is none.

Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027 (press release, June 2025). Cost, unclear business value, and inadequate risk controls are the leading reasons. Cost and risk controls are exactly the two things these frameworks don't give you natively.

Anthropic Engineering's "Building Effective AI Agents" makes the case most directly: the most successful implementations weren't using complex frameworks but simple, composable patterns. If your workflow is a fixed sequence of three LLM calls with a retry, a framework adds an abstraction layer, a dependency tree, and a migration risk for very little. Plenty of production AI features never need orchestration at all, and finding that out early saves the migration you'd otherwise pay for later. Useful test: write the workflow as a plain function first. If that function reads cleanly, you don't need a framework. Once it starts accumulating retries, branches, and shared state, you do, and that's when agent development becomes an architecture problem rather than a library choice.

The verdict

Dimension	Winner	Why
Production reliability	LangGraph	Control flow enforced in code, not prompts
Time to first working crew	CrewAI	Higher-level abstractions; fastest to prototype
Real production usage	LangGraph	71M monthly PyPI installs; LangGraph is load-bearing
Release responsiveness	CrewAI	Ten releases in nineteen days; bugs get fixed fast
Licence clarity	LangGraph / CrewAI (tie)	Both MIT; AutoGen reports three different answers
Cost controls	None	None of the three halts a run on spend
Operational burden	CrewAI	LangGraph's checkpointer needs lifecycle management upfront
Enterprise support path	Microsoft Agent Framework	GA April 2026, stable APIs, LTS commitment
Overall for new projects	LangGraph	Best control-to-risk ratio for production work

Verdict by dimension, as of 2026-08-16.

Choose LangGraph if you need explicit, auditable control flow; you need durable execution or human-in-the-loop steps; your workflow has real branching and shared state; and your team will own the persistence work. Budget that work upfront: checkpoint TTL deletion, selective persistence on the supervisor graph only, and pinning the checkpoint packages separately from core. Its persistence is your problem, not the vendor's.

Choose CrewAI if you're shipping a multi-agent prototype this quarter, you want higher-level abstractions, and you can absorb the operational risk. Pin your version. Write delegation assertions into your test suite. Apply the #5057 memory mitigation before user content touches agent memory. Ten releases in nineteen days means your pinned version is end-of-life within weeks, so plan the upgrade cadence rather than discovering it.

Don't start on AutoGen if you're picking a framework today and have no legacy investment holding you there. If you're already on it, scope the MAF migration as a rewrite, put the stateless Agent behavior at the top of your test plan, and know that local code execution is a feature gap in MAF today. Its termination depends on string-matching a literal token, so pair max_consecutive_auto_reply with a token ceiling until you're off it.

Choose Microsoft Agent Framework if you're a Microsoft shop, you're migrating off AutoGen or Semantic Kernel, or a vendor-backed support path with an LTS commitment is what gets the project approved.

Choose no framework if your workflow is a few deterministic LLM calls and a plain function with retries is still readable. Write the function. Add a retry. Only reach for a framework when the function stops being readable.

The AutoGen lesson isn't that Microsoft abandoned a project. It's that a framework stuck at v0.x was never really a product: it's a research prototype that happened to get famous. Check the maintenance status, the release cadence, and the maintainer's roadmap before you commit. Everything in this post was accurate on 2026-08-16. For this kind of tool, that's not a long shelf life.

Frequently Asked Questions

Is AutoGen deprecated?

Not formally archived, but effectively yes. The README carries a maintenance-mode banner. Last stable Python release: autogen-agentchat 0.7.5 on 2025-09-30, about 320 days before 2026-08-16. The repo remains publicly readable and community-managed. Microsoft recommends Agent Framework for new projects.

What's the difference between AutoGen and AG2?

AG2 is a fork, not a rebrand. Original AutoGen authors Chi Wang and Qingyun Wu left Microsoft in November 2024 and forked the project. AG2 reached v1.0.0 in late July 2026. The classic autogen.* API lives in a separate ag2-classic repo, so 'move to AG2' is a migration. AutoGen stays with Microsoft under a mixed CC-BY-4.0/MIT licence situation; AG2 is Apache-2.0.

Does LangGraph handle its own database cleanup?

No. The open-source Postgres checkpointer ships no native TTL. LangChain's docs recommend a cron job to delete old checkpoints. LangGraph issue #1138 (open since 2025-04-29) reports around 100 rows per graph traversal across three tables with no maintainer resolution. Plan TTL deletion and archival before launch.

Can I cap how much an agent run costs?

Not within LangGraph, CrewAI or Microsoft Agent Framework. All three expose structural limits (recursion_limit at 1000, max_iter at 20 per agent, max_iterations at 100) but none halts execution on spend. CrewAI's usage metrics are post-hoc, available only after kickoff() returns. Enforce budgets at your API gateway or proxy.

Is multi-agent worth the cost over a single agent?

Depends on the accuracy you need. On SEC filings, reflexive loops hit F1 0.943 at 2.3x sequential cost; hierarchical hit 0.921 at 1.4x; a hybrid recovered 89% of the reflexive gains at 1.15x (arXiv:2603.22651, March 2026). Start hybrid. Escalate to reflexive only where accuracy pays for itself.

Should I trust framework star counts?

Treat them as a freshness signal in reverse. Stars accumulate at peak hype. Installs track present-tense production dependence. A high star-to-install ratio means a project was once exciting and now isn't load-bearing anywhere. AutoGen's ratio is the worst of the three by an order of magnitude, and the release cadence (320 days since last release) agrees.

Originally published on the Avenotech blog, where we write about shipping AI and mobile products to production. Figures were verified on August 16, 2026; check current versions before you act on them.