Three names, two licences, and a package version two majors above its newest tag
Build your own Cowork, AI Scientist and other SoTA Agents just by editing config files. Support anthropic skills. An infinite-horizon agent framework designed for long-running, complex tasks.
At a glance
- What is it?
- infiAgent, also called MLA, is a config-driven multi-agent framework built for tasks that run for days, with crash-safe file persistence, an Agent Skills library, and a deployment list that fails over between model providers while protecting prompt caches. What the repository documents is a project that has handed its desktop app and marketplace to other repositories, a version scheme where the package is 3.12.24 and the newest tag is V2.0.0, a licence field that says GPL-3.0 while the packaging script declares MIT, and a requirements file that lists its core dependencies twice with different constraints.
- Who is it for?
- infiAgent is worth a look if your agent work is long enough that context growth and provider rate limits are the failure modes rather than model quality, since the framework treats both as engineering problems: a context builder that keeps running for days, an experience store with cross-process locks and optimistic revision checks, and a failover list that stays on one provider so the provider's cache survives. Two things to settle first.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 83 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Four names for one project and two licences
The repository is `infiAgent`, the page heading reads MLA V3, and the first paragraph expands MLA as Multi-Level Agent. The distribution on PyPI is `infiagent`. Those are four labels for the same code, and the documentation mixes them freely: a release note refers to the InfiAgent backend runtime, the level-0 tool suite and the SDK entry point, while the configuration files are still called `llm_config.yaml` and the workspace directory the page tells you to mount is `~/.mla_v3`.
The licence is stated in two places and they do not agree. The repository's licence metadata says GPL-3.0, and `setup.py` declares `license="MIT"`. Nothing in between settles it: `pyproject.toml` contains only a build-system table requiring `setuptools>=69,<75` and `wheel`, with no project table at all, so every packaging field including the licence comes from the setup script. That split is why two answers can both be traceable to the tree.
The package is 3.12.24 and the newest tag is V2.0.0
Three releases are visible. MAC_OS_V1.1.0 on 2026-03-08, described in Chinese as a fully modular agent desktop. v1.4.1 on 2026-03-25, described as fixing some hanging problems and optimising performance. V2.0.0 on 2026-03-30, described as adding history task truncation, history task query, and a thinking on and off switch. The names mix English and Chinese, and one of them is a platform name rather than a version of the runtime.
Meanwhile the installable package is a different line:
pip install infiagent==3.12.24`setup.py` carries the same `version="3.12.24"`. So the tag series stops at V2.0.0 while the published package is on a 3.x line, and the two are not on the same numbering. The last recorded push to the repository is 2026-07-11, months after the newest tag. The page also carries a standing instruction to refer to the fixed issues and re-pull the image and the code if you took them before the latest update date.
The desktop app and the marketplace left the repository
A July 2026 note reframes what this repository is. It now tracks the InfiAgent backend runtime, and the note is explicit that the desktop app, the marketplace, and other application layers have moved out to other repositories, with RUNTIME.md describing the build. What stayed behind is the part a runtime needs: the agent execution loop, the context builder, the tool executor, the built-in level-0 tool suite, the LLM client with multi-provider failover, the concurrency-safe experience store, the SDK entry point, and the full test suite.
The tree still shows the older shape underneath. Alongside `infiagent/` there are `core/`, `services/`, `tool_server_lite/`, `utils/`, `config/`, `skills/`, `tests/`, `docs/`, `assets/`, `start.py`, `setup.py`, and a `MANIFEST.in`, so the source layout predates the split in places even though the packaging now points PyPI at the runtime.
CheapClaw is the pattern the note points at for what moved out: it ships as an SDK-based application layer that keeps custom bots, multi-bot collaboration workflows, IM integrations, and Skills while inheriting the runtime model, including a multi-agent system behind a single bot and task-scoped context isolation so two tasks under one bot keep separate contexts.
Failover is arranged to protect the provider prompt cache
The multi-provider mechanism is a `deployments` list on a model entry inside `llm_config.yaml`, holding several API keys and/or platforms that serve the same logical model. The default behaviour is deliberately sticky: healthy traffic stays on the primary deployment, and the stated reason is preserving provider-side prompt caching. Failover is not the normal path, it is the exception path.
Three conditions push a deployment into cooldown and hand over to the next one: rate limits, timeouts, and auth failures. One of those has an extra rule, because auth errors no longer abort retries when an alternate deployment is available. The classic single-key configuration is stated to remain fully compatible, so the list is an addition rather than a replacement.
That combination, a sticky primary plus automatic cooldown, is the part worth thinking about if you rely on cached prefixes. Traffic that stays healthy gets the cache; traffic that fails over pays for a cold prefix on the new deployment, and nothing on the page describes how the cache state is tracked after a handover.
Concurrency control is built out of ordinary files
The long-horizon work is a filesystem discipline. All runtime persistence, covering the execution stack, task state, and experience files, uses atomic writes: a temp file in the same directory, then fsync, then rename, so a power loss cannot leave half-written state. Corrupted legacy state files are quarantined automatically with a clean recovery path, and interrupted tool calls replay idempotently on resume, which is what makes the advertised breakpoint continuation more than a restart.
The experience store adds the parts a database would have given. Cross-process file locks cover the full read-modify-write, entries get uuid-based ids, and files carry revisions checked optimistically through `expected_revision` and `expected_updated_at`. Task and global writes are transactional with rollback, and only entries with `status=active` are injected into agent context.
The persistent memory claim follows from the same design: memory is file-directory based, so launching agents in the same workspace directory makes them remember historical tasks across sessions with no external database. One caveat, since a later note adds a local SQLite index of historical task records and a `task_history_search` tool enabled by default, so there are now two stores, files for experience and SQLite for task history.
Five model slots per sub-agent, plus an editor that stops you writing YAML
Model assignment is per sub-agent and per slot. A sub-agent can set `execution_model`, `thinking_model`, `compressor_model`, `image_generation_model`, and `read_figure_model` independently, which lets one agent loop split execution, thinking, compression, and image understanding across different models. Model-level `tool_choice` options live in `llm_config.example.yaml`, and the concrete example given is the Level 3 `alpha_agent` definition in the default OpenCowork configuration.
Configuration has been moving away from hand-written files. The SDK now accepts structured model profiles directly instead of requiring every integration to write `llm_config.yaml`, and both the mac desktop app and the Docker Web UI expose a source-based editor: set a default `base_url` and `api_key` once, then add shared or per-slot models, where each row either reuses the default source or switches to a custom URL and key. Raw YAML and JSON are still there, described as advanced fallbacks, so the hand-written path remains available for the cases the editor does not cover.
The Docker web UI changed port and ships multi-user accounts
The March 2026 Web UI note is a migration with a security shape. The `chenglinhku/mlav3:latest` image runs the SDK-based Web UI with a new `webui` startup command on port `4242`, users register from the login page, and a bootstrap admin account manages users inside the Web UI. The old standalone config page flow on port `9641` is explicitly no longer required, and the updated command mounts `~/.mla_v3` to `/root/mla_v3` and publishes `4242`.
Two details are worth holding onto. The image is published under a personal account rather than the organisation, so the container you pull is not namespaced to this repository. And a published port now fronts a registration page plus an admin account, which means the access control on that port is whatever the first visitor chooses.
The same note also changes the shape of the application: registration and account management live inside the Web UI, so user management is part of the container's job rather than something you configure outside it.
The core dependency block appears twice with different extras
`requirements.txt` is written in two passes over largely the same list. The first pass names `litellm==1.82.6`, `pyyaml>=6.0`, `tiktoken>=0.5.0`, `virtualenv>=20.0.0`, then the tool server group, then `mcp` guarded by `python_version >= "3.10"`, `PyMuPDF`, `playwright`, `docx2pdf`, and `pytest>=7.0.0`. The second pass repeats the core group and the tool server group, then adds `python-pptx>=0.6.21` and restates `pyyaml` as `>=6.0.0`, while dropping `mcp`, `PyMuPDF`, `docx2pdf`, and `pytest`.
`setup.py` resolves the duplication by normalising each line, dropping anything that starts with `pytest`, and skipping any requirement already seen, so the first occurrence of a name wins. The effect is that everything in both passes gets installed except `pytest`, which is stripped deliberately, and `python-pptx` is added by the second pass without conflict.
Two pins carry comments worth reading. `litellm==1.82.6` is pinned exactly to stay consistent with the version bundled in the desktop backend, and `crawl4ai` is noted as installing playwright on its own. The package also installs `config/` and `skills/` as data files, which is why the skills library can be dropped into a directory rather than imported.
Editorial conclusion
infiAgent is worth a look if your agent work is long enough that context growth and provider rate limits are the failure modes rather than model quality, since the framework treats both as engineering problems: a context builder that keeps running for days, an experience store with cross-process locks and optimistic revision checks, and a failover list that stays on one provider so the provider's cache survives. Two things to settle first. The project is mid-migration, with the desktop app and marketplace moved out to other repositories, a tag scheme at V2.0.0, and a package version at 3.12.24, so read RUNTIME.md before assuming a feature lives here. And the licence is stated twice in two ways that disagree, GPL-3.0 in the repository metadata and MIT in the packaging script, with the project file holding nothing but a build-system table, so settle that before you build on it.
Frequently asked questions
What is infiAgent, also called MLA V3?
It is a multi-agent framework designed for unlimited runtime, aimed at avoiding tool calling chaos and crashes caused by cumulative task resources and conversation history. Agents are built by writing configuration files, the architecture can be a multi-level hierarchy, as in the Researcher config for long scientific research with paper generation, or a flat single agent with one sub-agent plus Skills, as in OpenCowork.
How do I install infiAgent?
From PyPI with `pip install infiagent==3.12.24`, which is the version carried in `setup.py` as well. The repository ships `requirements.txt` and `setup.py`, with `config/` and `skills/` installed as package data, and `pyproject.toml` holds only a build-system table requiring `setuptools>=69,<75` and `wheel`, so all project metadata lives in the setup script.
Which licence applies to infiAgent?
The repository states two different ones. The licence metadata says GPL-3.0 while `setup.py` declares `license="MIT"`, and nothing in the packaging resolves the conflict because `pyproject.toml` contains no project table. The page also asks users who pulled the code before the latest update date to re-pull it after checking the fixed issues.
Can infiAgent switch between thinking and ReAct modes?
Yes, through a switchable cadence model. You can keep the original ThinkingAgent-style workflow that plans first and then executes a number of steps, or disable thinking and fall back to an explicit ReAct loop where the reflection text is persisted directly inside the message history. Historical task records are indexed into a local SQLite database and a `task_history_search` tool is available by default.
How does infiAgent handle several model providers?
A model entry in `llm_config.yaml` can declare a `deployments` list of API keys and/or platforms serving the same logical model. Healthy traffic stays on the primary deployment to preserve provider-side prompt caching, while rate limits, timeouts, and auth failures put a deployment into cooldown and fail over automatically. Auth errors no longer abort retries when an alternate deployment exists, and the classic single-key configuration remains supported.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/polyuiislab-infiagent)