How do their APIs compare?

These two projects have fundamentally different notions of "API" — one is an in-process/library API for codebase-to-prompt conversion, the other is a network-facing agent gateway. Here's the comparison:

mufeedvh/code2prompt: library/binding APIs (no network server)

code2prompt exposes its functionality primarily as embeddable Rust and Python APIs, not as an HTTP service:

• Rust core API (code2prompt-core): centers on Code2PromptSession, built from a Code2PromptConfig. The main entry point is generate_prompt(), which internally calls load_codebase() then renders the template, returning a RenderedPrompt with prompt, token_count, and files [crates/code2prompt-core/src/session.rs:L602-L641]. Sessions can also be driven step-by-step (as the CLI does): build_session → gather_session_data → render_session_template → emit_cli_results [crates/code2prompt/src/main.rs:L60-L82, L122-L141, L142-L245].
• Templating API: handlebars_setup() and render_template() in [crates/code2prompt-core/src/template.rs:L1-L68, L107-L161] expose a fixed set of built-in template variables (absolute_code_path, source_tree, files, git_diff, etc.), with extract_undefined_variables() used to validate user templates against that registered set.
• Python bindings (code2prompt_rs, via PyO3): mirror the Rust session API almost 1:1 — construct a Code2PromptConfig, wrap it in a Code2PromptSession, call .select_file()/.deselect_file() (chainable, mutate-and-return-self), then .generate_prompt() to get a result object with .prompt, .token_count, .files [crates/code2prompt-python/README.md:L17-L52]. The conversion glue lives in PyRenderedPrompt::from(RenderedPrompt) [crates/code2prompt-python/src/python.rs:L508-L519].
• There's also an unofficial third-party MCP server (code2prompt-mcp, a separate repo referenced in [llms-install.md:L17-L66]) that exposes code2prompt as a tool for LLM agents over the Model Context Protocol — but that's not part of this repo's own API surface.

Notably, per the RepoPilot import graph, code2prompt-python/python-sdk/code2prompt_rs/__init__.py participates in the one flagged import cycle (with code2prompt.py), which is worth being aware of if you're extending the Python API surface.

rightnow-ai/openfang: HTTP/OpenAI-compatible gateway API

openfang runs as a network service (openfang-api crate) exposing REST-style endpoints, closer to a typical backend API:

• An OpenAI-compatible chat completions layer (openai_compat.rs) that mimics OpenAI's schema — ChatCompletionChunk, ChoiceMessage, ChunkDelta, and tool-call structures (OaiToolCall, OaiToolCallFunction) with careful serde handling to omit fields like tool_calls/content when absent, preserving backward compatibility with OpenAI clients [crates/openfang-api/src/openai_compat.rs:L700-L739, L740-L779]. This suggests openfang's agents can be consumed by any OpenAI-SDK-compatible client, including streaming tool-call deltas.
• A messaging/gateway API documented in the README with concrete REST routes: POST /login/start (QR login), GET /login/status, POST /message/send, GET /health [README.md:L343-L351] — this is a WhatsApp-style gateway, distinct from the agent chat API.
• Agents themselves are configured declaratively via TOML manifests (e.g., agents/coder/agent.toml defines model, system prompt, resource limits like max_llm_tokens_per_hour) [agents/coder/agent.toml:L1-L40], and the web UI (skills.js, agents.js) calls into this API to manage agent templates, skills, and profiles [crates/openfang-api/static/js/pages/agents.js:L259-L298].

Summary of the contrast

| Aspect | code2pr