llama-index after the focus shift: 300+ integrations, OpenAI in the starter, a stale README

The starter package hard-depends on OpenAI and NLTK before you choose a provider

There are two ways in, and they cost different amounts. The starter is the llama-index package, which bundles core plus a selection of integrations, and the customized route is llama-index-core on its own with integration packages added from the integrations page. The difference shows up in the starter's own dependency list, which is four entries: llama-index-core>=0.14.25,<0.15.0, llama-index-embeddings-openai>=0.6.0,<0.8, llama-index-llms-openai>=0.7.0,<0.9, and nltk>=3.9.3. So the package described as a general starter arrives already bound to one model provider and to a tokenization library, regardless of what you plan to use. If your application runs on a different LLM or embedding provider, or needs no NLTK at all, the starter still installs all of it and its transitive tree. Choosing core alone avoids that, and moves the decision about which providers you depend on from the maintainers to you, at the cost of assembling the integration set yourself.

Core is 0.14.x while its OpenAI integrations are 0.6.x and 0.7.x

Integration packages version independently of the framework, and the numbering makes the point without needing a comment. Core moves as 0.14.25, 0.14.24, and 0.14.23, while the embeddings package the starter depends on is bounded at >=0.6.0,<0.8 and the LLM package at >=0.7.0,<0.9. The starter also pins core from below at 0.14.25, which is the newest release in the list, and caps it below 0.15.0. Two consequences. First, the integration version number tells you nothing about framework compatibility, so a dependency resolver can satisfy every constraint while still pairing a 0.14 framework with a stale integration, and the upper bounds mean a 0.15 release of core will not be adopted by the starter until that constraint is edited. Second, with over 300 integration packages each carrying its own release line, a reproducible environment is something you assemble and lock yourself, using the uv.lock in the tree as a starting point rather than something the starter package guarantees.

Three Makefile test targets name directories that are not in the tree

The build tooling has outlasted the layout it was written for. Two targets work against directories that exist, running pants against llama-index-core/ and llama-index-integrations/ for the two main suites. Three more do not have a matching directory at the top level: test-finetuning runs pants against llama-index-finetuning/, test-experimental against llama-index-experimental/, and test-packs against llama-index-packs/, while the top level actually holds llama-index-core/, llama-index-integrations/, llama-index-utils/, llama-index-instrumentation/, llama-dev/, docs/, and scripts/. For a contributor this is a small but real trap, because the three targets are advertised in the Makefile help output alongside working ones and nothing in the file marks them as stale.

make test only exercises what changed, and watch-docs watches a path that is absent

Two of the Makefile's own targets are narrower than their names imply. The default test target runs pants with --changed-since=origin/main and --changed-dependents=transitive, which is a fast feedback loop for a local edit rather than a verification of the repository, and it passes on a branch where an untouched package is broken. A full run has to be requested through test-core or test-integrations, or by invoking pants without the changed-since filter. The documentation target has a separate problem: it watches $(GIT_ROOT)/llama_index/, an underscore path, while the source directory in the tree is llama-index-core/ with a hyphen. Whether that watcher sees a change depends on path resolution rather than on anything the file documents. Anyone verifying a change locally should treat both targets as partial.

The import namespace records which package you got, but only by convention

The namespace rule is the one piece of design in the repository that solves a real problem cleanly. Imports that include core belong to the core package, and imports without it belong to an integration, so the shape of the import statement tells you which distribution has to be installed for it to resolve:

# typical pattern
from llama_index.core.xxx import ClassABC  # core submodule xxx
from llama_index.xxx.yyy import (
    SubclassABC,
)  # integration yyy for submodule xxx

# concrete example
from llama_index.core.llms import LLM
from llama_index.llms.openai import OpenAI

The concrete pair is the clearest illustration, since core.llms gives you the abstract LLM and llms.openai gives you a provider implementation of it. What the convention does not do is enforce anything. Two import lines that differ by one path segment resolve to distributions with different version numbers, different release cadences, and different maintenance, and the import statement itself carries no signal about which one you actually have installed. That is a small thing to hold in mind across more than 300 integration packages, and the reason to check the installed set rather than trust the import.

The README disclaims its own currency while the company focus moves to parsing

The most important content in this repository is a note at the top, and it is about direction rather than features. It says the current focus of LlamaIndex is to build the best AI-powered engine for document parsing and extraction, names LlamaParse as the enterprise platform for agentic OCR, parsing, extraction, and indexing, points at LiteParse as the free parser effort, and at ParseBench and ExtractBench as open benchmarks. It adds that the company has evolved since the framework first launched in 2023, and that the primary focus has shifted towards LlamaParse, LiteParse, and the benchmarking work, while the framework is still available as an open toolkit. The consequence for an adopter is that the framework is no longer the company's primary focus. The README also states outright that it is not updated as frequently as the documentation, which is the second thing to check before trusting anything here.

The shipped package is a thin wrapper over four sub-trees and a hundred pinned dev tools

The tree shows how much of the project is not the thing you install. Alongside the top level documentation and governance files, including CHANGELOG.md, CITATION.cff, CODE_OF_CONDUCT.md, RELEASE_HEAD.md, SECURITY.md, and STALE.md, sit llama-index-core/, llama-index-integrations/, llama-index-utils/, and llama-index-instrumentation/ as separate distributions, plus llama-dev/ and scripts/ for internal work. The pyproject for the published package is correspondingly thin, built with hatchling, licensed MIT, requiring Python >=3.10,<4.0, authored by Jerry Liu and maintained by six named people. Its development group is the other half of the story: mypy==1.11.0, ruff==0.11.11, pylint==2.15.10, and pre-commit==3.2.0 are pinned to exact versions while black is allowed to range from 23.7.0 to 26.5.1, and there is a stack of types stubs alongside pytest, pytest-asyncio, and pytest-mock.

Editorial conclusion

Use llama-index-core plus the specific integrations you need if you are starting fresh, and treat the starter package as a convenience that costs you an OpenAI dependency you may not want. Do not adopt it on the assumption that the framework's roadmap follows the framework: the maintainers say their primary focus is LlamaParse, LiteParse, and open parsing benchmarks, and that the open toolkit remains available rather than leading the work. Before pinning a version, check that your integration's release line matches core, since core is held below 0.15.0 while the starter requires OpenAI integrations at >=0.6.0 and >=0.7.0, and before trusting a green build, remember that the default make test only runs what changed since origin/main and three other test targets point at directories this repository no longer contains.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes