FastAPI 0.140: What Actually Changed

FastAPI’s 0.140 series is a maintenance release, and that’s worth understanding

FastAPI 0.140 doesn’t add a headline feature – no new decorator, no new response type. Instead, the entire 0.140.x series through July 2026 focuses on something less flashy but genuinely useful if you run FastAPI in production: reducing the memory FastAPI itself uses to process requests, independent of your own application code. If you’ve ever profiled a FastAPI service and found a chunk of memory going to framework internals rather than your handlers, FastAPI 0.140 is squarely aimed at that.

What’s actually changed under the hood

• Dependency-parameter flattening refactor – FastAPI used to flatten your entire dependency tree to work out request parameters and OpenAPI schema. 0.140.6 stops flattening dependencies purely for request-parameter resolution, improving both memory use and OpenAPI accuracy for deeply nested dependencies.
• Targeted request-body derivation – 0.140.5 changed how request-body fields are pulled from your dependency graph, walking only the parts of the tree that actually contain body parameters instead of flattening everything.
• Dropped the retained flat dependency tree – 0.140.2 removed a cached “flat” version of the dependency tree that APIRoute used to hold onto for the lifetime of the app, along with adding an internal memory benchmark test so future regressions get caught automatically.

None of this changes your application code. The point is that a FastAPI app with a large, deeply-nested set of dependencies (common once you’re past a handful of endpoints and using dependency injection properly) now carries noticeably less framework-level memory overhead per route.

The bug fix worth knowing about specifically

FastAPI 0.140.13 (28 July 2026) fixed a real, user-facing bug: status_code was being ignored on Server-Sent Events and JSON Lines streaming responses. If you’re building an SSE endpoint for live updates or a JSON Lines endpoint for streaming large result sets, and you’d set a non-default status code on the response, it was silently reverting to 200 before this fix. Anyone streaming responses with a custom status code should update past 0.140.13 specifically, not just to the latest 0.140.x.

A quick before/after for the streaming fix

from fastapi.responses import StreamingResponse

@app.get("/events")
async def events():
    return StreamingResponse(
        event_generator(),
        media_type="text/event-stream",
        status_code=202,  # now actually respected as of 0.140.13
    )

Should you upgrade now?

1. If you use SSE or JSON Lines streaming with non-default status codes, upgrade to at least 0.140.13 – this is a correctness fix, not just an optimisation
2. If you run a large FastAPI service with many nested dependencies, the memory refactors are worth pulling in even without a specific bug to fix – it’s a straightforward version bump with no breaking API changes
3. If your app is small and dependency-light, the memory savings will be marginal – there’s no urgency, but there’s also no reason not to stay current

One documentation change worth noticing

FastAPI’s own docs have quietly shifted their default examples toward uv rather than pip/venv for installing dependencies and running the dev server. It’s not a framework change, but if you’ve been meaning to try uv for a FastAPI project, the official docs are now a genuinely good place to see it used idiomatically rather than bolted on.

The bigger pattern

FastAPI’s 0.140 series is a reminder that not every release needs a new feature to be worth tracking. A framework that’s mature enough to spend a full release cycle purely on memory efficiency and a real streaming bug fix – rather than chasing new API surface – is a framework that’s settled into production-grade maintenance mode. For anyone running FastAPI at any real scale, that’s the more useful signal than a shiny new decorator would have been.