How do their APIs compare?

Comparing the two repos, they operate at very different layers of the stack, so their "APIs" aren't quite apples-to-apples:

mlc-ai/mlc-llm: OpenAI-compatible inference API

MLC LLM exposes an OpenAI-compatible API surface through its MLCEngine, backed by REST server, Python, JavaScript, iOS, and Android bindings (per the README). The core is a C++ serving engine with a request/response model:

• Request lifecycle: A ChatCompletionRequest is parsed and turned into an engine Request object. In [cpp/json_ffi/json_ffi_engine.cc:L71-L104], the code builds prompts via CreatePrompt, collects stop strings, and constructs a GenerationConfig from fields like temperature, top_p, frequency_penalty, presence_penalty, logprobs, logit_bias, seed, max_tokens, stop_strs, and response_format — this is essentially the OpenAI chat-completions parameter surface.
• Validation: GenerationConfig::Validate enforces constraints like n >= 1, non-negative temperature, top_p in [0,1], and frequency_penalty in [-2, 2] [cpp/serve/config.cc:L235-L250].
• Response formatting: ResponseFormat::FromJSON restricts type to "text", "function", or "json_object" [cpp/serve/config.cc:L43-L57].
• Usage/metrics reporting: Mirrors OpenAI's usage object (prompt_tokens, completion_tokens, total_tokens), with additional engine-specific metrics (TTFT, decode tokens/s, prefill tokens/s) nested under an extra field when requested [cpp/serve/metrics.cc:L74-L100, L151-L160].
• Engine-level management API: The Engine class in [cpp/serve/engine.h:L54-L75] exposes a Create factory taking an engine config JSON, device, and a request-stream callback, plus lifecycle methods like Reset().

So MLC LLM's "API" is a synchronous/callback-driven, strongly-typed C++ engine interface wrapped in an OpenAI-compatible JSON schema for text generation.

significant-gravitas/autogpt: agent graph / block API

AutoGPT's relevant surface here isn't a serving API but a graph-based agent definition format (JSON files under autogpt_platform/backend/agents/). These aren't request/response API calls in the traditional sense — they're declarative workflow graphs made of nodes, each referencing a block_id, with input_default, input_links, and output_links wiring node outputs to other nodes' inputs (e.g. [autogpt_platform/backend/agents/agent_b6f6f0d3-49f4-4e3b-8155-ffe9141b32c0.json:L253-L285], [autogpt_platform/backend/agents/agent_e7bb29a1-23c7-4fee-aa3b-5426174b8c52.json:L351-L390]).

Some nodes internally call LLM-style APIs — e.g. a node with model, prompt, sys_prompt, retry fields configuring calls to models like gpt-5-mini-2025-08-07 [autogpt_platform/backend/agents/agent_6e16e65a-ad34-4108-b4fd-4a23fced5ea2.json:L818-L826] or gpt-5-2025-08-07 [autogpt_platform/backend/agents/agent_b6f6f0d3-49f4-4e3b-8155-ffe9141b32c0.json:L253-L260] — but these are consumer-side configurations of an external LLM call embedded in a workflow node, not AutoGPT's own inference-serving API.

Key contrast

• MLC LLM defines and implements an inference-serving API (OpenAI-compatible chat completions) at the C++ engine level, with its own request validation, generation config, and metrics/usage reporting.
• AutoGPT (in the retrieved data) doesn't expose a comparable inference API of its own; instead it's the consumer of LLM chat/completion-style APIs, orchestrated through a graph/block execution model with typed input/output schemas per block (e.g. [aut