How do their APIs compare?

These two repos aren't comparable in the sense of "which API is better" — they solve completely different problems and "API" means something different in each. Let me lay out the actual comparison:

mlc-ai/mlc-llm: a runtime engine API

MLC LLM exposes an OpenAI-compatible inference API served by MLCEngine, a C++ engine that runs across GPUs/platforms (Vulkan, CUDA, Metal, ROCm, WebGPU, etc.), per the README's platform table. Concretely, this is a programmatic/service API, backed by real request/response types:

• ChatCompletionRequest — mirrors OpenAI's chat completion schema, with fields like messages, temperature, top_p, frequency_penalty, presence_penalty, logprobs, max_tokens, n, seed, stop, stream, tools, etc. [cpp/json_ffi/openai_api_protocol.h:L128-L145]
• Request handling flows through JSONFFIEngine, which parses the JSON request, builds the prompt via CreatePrompt, merges stop strings from the conversation template and request, and constructs a GenerationConfig from request fields falling back to engine defaults. [cpp/json_ffi/json_ffi_engine.cc:L71-L110]
• Internally, the serving engine (cpp/serve/engine.cc) creates RequestStateEntry objects per request (and per parallel generation branch when n > 1), tracked in an estate_->request_states map, with support for aborting individual or all requests. [cpp/serve/engine.cc:L701-L740]
• Streaming responses are modeled by RequestStreamOutputObj, which carries per-group delta token ids, log-probs, finish reasons, and a final usage JSON string. [cpp/serve/data.h:L211-L250]

This is a single, engine-level API surface (OpenAI-compatible), reused consistently across REST, Python, JavaScript, iOS, Android per the README's description of MLCEngine.

public-apis/public-apis: a curated directory of third-party APIs

This repo is not itself an API — it's a Markdown-based, community-curated list of links to thousands of unrelated public APIs (e.g., GitHub, Google Docs, Heroku, IPify, Cloudflare, JSONPlaceholder), each with metadata columns: Auth type, HTTPS support, CORS support, per the entry format. [README.md:L569-L608, README.md:L529-L568]

• Entries follow a strict table format defined in the contributing guide: API name/link, description, Auth (OAuth, apiKey, No, etc.), HTTPS (Yes/No), CORS (Yes/No/Unknown). [CONTRIBUTING.md:L11-L48]
• There's no shared schema or protocol across entries — each linked API has its own independent interface; this repo only standardizes how they're described, not how they behave.
• Tooling like scripts/validate/links.py checks link health (e.g., detecting Cloudflare protection blocking automated validation), which is about maintaining the directory's integrity, not an API contract. [scripts/validate/links.py:L95-L151]

Bottom line

• mlc-llm ships one coherent, versioned, OpenAI-compatible inference API implemented in C++ with typed request/response objects and a real serving engine.
• public-apis is a reference/index of thousands of other APIs; it has no runtime API of its own beyond its documentation format and validation scripts.

If you meant something narrower — e.g., comparing mlc-llm's OpenAI-compatible schema against a specific entry in public-apis's catalog — let me know which one and I can go deeper.

FOLLOW_UPS:

• How does MLCEngine handle streaming chat completions?
• What does RequestStateEntry track during generation?
• How does public-apis validate API entry links?