lobe-chat-agents: The Index Behind LobeChat's Agent Market
🤖 / 🏪 Agent Index - This is the agent index for LobeChat. It accesses index.json from this repository to display a list of available agents for LobeChat to the agent market.
At a glance
- What is it?
- This repository is not a chat app and not an agent runtime. It is the data source LobeChat reads to populate its agent marketplace, and its real product is a review process and a JSON schema.
- Who is it for?
- Adopt this repository if you are a LobeChat user who wants to publish an agent prompt under a shared schema, or if you want to self-host a filtered index of agents for a specific team. Do not adopt it if you need programmatic agent execution, versioned prompt contracts, or a marketplace that does not depend on a single upstream review queue.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the Index Actually Is, and Who It Is For
The README opens with a one-line statement of purpose: LobeChat accesses the Agents Index from this repository to show users the list of available agents. That sentence defines the scope precisely. The repository holds agent definitions, not agent logic. There is no inference code, no tool-calling runtime, and no orchestration layer here. What ships is a set of JSON entries plus the pipeline that turns them into an index file the client fetches.
The audience is narrower than the topic list suggests. The topics include agent, chatgpt, openai, and prompt, which might imply a general prompt library. In practice the entries are LobeChat-shaped: each one carries a name, an author, a creation date, a short description, and a tag list, and the README's own listing format shows exactly those fields. A developer building for a different chat client would be copying a schema built for someone else's renderer. The people who get real value are prompt authors who want distribution inside LobeChat, and LobeChat users who want their own curated subset of the marketplace.
One consequence is easy to miss. Because the index is a data artifact, its quality is editorial, not technical. The repository's value comes from what gets merged, not from what gets compiled.
The Data Flow: From Pull Request to index.json
The mechanism described in the README is a static content pipeline. A contributor forks the repository, copies either agent-template.json or agent-template-full.json, fills in the copy, renames it, moves it into the src directory, and opens a pull request. After merge, the createAt date is populated automatically, per the README's important note. LobeChat then reads index.json from the repository to render the agent list.
Two details in that flow matter more than the rest. First, there are two templates, and the README describes agent-template-full.json as providing a more comprehensive set of parameters for customization. That means the schema has a shallow path and a deep path, and the choice is made by the contributor at submission time, not by the consumer. Second, the src directory is where entries land, but the README's step-by-step instructions also mention making an entry in the agents directory. Those two statements do not agree. Anyone submitting should check the current repository layout rather than trusting either sentence in isolation, because a pull request placed in the wrong directory is a wasted review cycle.
The automatic createAt population is the one piece of generated state in the pipeline. It implies a bot or action runs on merge. The README does not describe that action, so the exact timing and format of the date field cannot be confirmed from this material.
Getting It Running: Submission and Self-Hosting Commands
The submission path has no CLI. It is a fork, a file copy, an edit, and a pull request. The README also offers a Submit Your Agent link as a shortcut, and states that you can submit agents even if you are not the author, though the author is preferred. If your agent is merged and you later want it removed, or you believe the description misrepresents it, the README directs you to open an issue or pull request.
Self-hosting is the other operational path, and the README keeps it short: a Self Hosting section with a single named option, Deploy to Vercel. There is a Local Development section in the table of contents as well. Neither section is reproduced in the material available here, so the exact commands, environment variables, and package manager are not something this review can state. What can be said is that the deployment target named is Vercel, and that the artifact being served is index.json. If you fork the repository to run a private index, the thing you are changing is which entries exist in src, not the serving code.
The practical consequence: this project's setup cost is close to zero for a contributor and non-trivial for a self-hoster, because the self-hoster inherits a build and deploy pipeline that the README does not document in the excerpt provided.
The Review Queue Is the Real Gate, and It Is Opaque
The README states plainly that not all agents will be accepted and that the maintainers will review the agent and make an assessment. That is the honest limitation, and it is worth taking at face value rather than treating as boilerplate. There is no published rubric, no scoring criteria, no appeal process beyond opening an issue or pull request, and no stated turnaround time.
For a prompt author, this means the index is a distribution channel with an editorial gate you cannot inspect in advance. The listing in the README shows a wide range of accepted entries, from a turtle soup host to a nutritional advisor to a Minecraft Java development assistant, so the bar is not obviously narrow in subject matter. What is unclear is how the reviewers treat near-duplicates. The listing already contains an Academic Writing Assistant, an Academic Paper Reading Mentor, and an Academic Paper Review Expert. Three agents in adjacent territory coexisting suggests either a permissive stance or a distinction the public listing does not expose.
A second failure mode is staleness. Entries carry a createAt date that is set once at merge. Nothing in the README describes a re-review, a deprecation path, or a way to flag an agent whose underlying model behaviour has drifted. An index entry is effectively immutable content with a fixed timestamp.
Where This Is the Wrong Tool
If you need agent definitions to be versioned artifacts that your own runtime consumes, this repository is the wrong shape. The schema is built for LobeChat's discover page, the entries are merged by human review on someone else's schedule, and the only automated field mentioned is a creation date. There is no semantic versioning of individual agents, no changelog per entry, and no dependency declaration. A team that wants to pin a prompt to a specific revision and roll it back independently has no mechanism here.
It is also the wrong tool for anyone who wants to run agents. The repository is an index. Executing an agent requires LobeChat itself, which lives in a separate repository. Reading this project's README carefully, the only integration point named is that LobeChat accesses index.json. Everything downstream of that fetch is outside this repository's boundary.
And it is a poor fit for closed or internal prompt sets. The submission flow is a public pull request, and the README's removal path is a public issue. If your agent descriptions contain anything you would not publish, self-hosting a fork is the only option, and the README's self-hosting coverage is one line long.
How It Differs From Curated Prompt Lists
The obvious alternative is a static curated list of prompts, the kind maintained as a README with links and descriptions. The difference is not the content. It is the contract. A curated list is written for humans to read; this repository is written for a client to parse. That distinction drives everything else: the two template files exist so entries conform to a schema, the createAt field is populated automatically so the client can sort or display recency, and the tags are structured so they can be filtered rather than merely searched.
The trade-off runs the other way too. A curated list can describe an agent in a paragraph, link to a gist, and update the wording whenever the maintainer likes. An index entry is constrained by the template's fields, and per the README, changing a description after merge means opening an issue or pull request and waiting. The index gains machine readability and loses editorial flexibility.
A second alternative is to skip the index entirely and distribute a prompt as a file that users import into their own client. That avoids the review queue and the schema, and it also avoids discovery. The index's entire reason to exist is that LobeChat reads it, which is a benefit only if you want LobeChat users to find your agent.
Maintenance, Licensing, and What the MIT Terms Cover
The repository is MIT licensed, which the README surfaces through a license shield. MIT is permissive: it allows use, modification, and redistribution with the licence and copyright notice retained. For a self-hoster forking the index, that is the relevant permission, and it is granted without a separate agreement.
One thing MIT does not do is grant rights to the agent content itself. The licence covers the repository's code and data as distributed, but the prompts and descriptions are contributed by individual authors, listed by handle in the README with dates. Whether a contributor's prompt text carries its own terms is not addressed in the material available here. Anyone repackaging the index for a commercial product should treat that as an open question rather than assume the repository licence settles it. This is not legal advice; it is a gap worth raising with the maintainers directly.
On maintenance cost, the release history is informative. Three releases are shown, v1.40.1, v1.41.0, and v1.42.0, all within a two-day window in June 2025, with the last push to the default branch dated August 2026. That pattern suggests releases are driven by content merges rather than a fixed cadence, which is consistent with an index repository. For a self-hoster, the upgrade cost is therefore the cost of re-syncing entries, not the cost of tracking a moving API. The schema is the only interface that matters, and the README does not describe a schema version field, so a future template change would be discovered by reading the diff.
Editorial conclusion
Adopt this repository if you are a LobeChat user who wants to publish an agent prompt under a shared schema, or if you want to self-host a filtered index of agents for a specific team. Do not adopt it if you need programmatic agent execution, versioned prompt contracts, or a marketplace that does not depend on a single upstream review queue. Before submitting, verify three things in the repository itself: which template file matches your agent's parameter needs, whether your agent's category already has near-duplicates in the index, and how the pull request review handles a rejection, because the README states only that not all agents will be accepted.
Community notes