How do their APIs compare?

These two repos aren't really comparable as "APIs" in a normal sense, and it's worth being explicit about why.

julien-cpsn/atac is a terminal API client (like Postman/Insomnia/Bruno, but TUI-based) — it doesn't expose an API of its own; it consumes HTTP/WebSocket APIs that users configure. Its internal "API surface" is really its Rust module structure:

• Request modeling lives in src/models/request.rs, which is one of the most-depended-on files in the codebase (29 importers per the import graph), and src/models/protocol/protocol.rs (22 importers) defines the protocol abstraction distinguishing HTTP vs WebSocket requests, as seen in code like the Protocol::HttpRequest / Protocol::WsRequest match in [src/app/business_logic/request/export.rs:L692-L696].
• Request sending logic (building a reqwest client, applying proxies, cookies, pre-request scripts, TLS settings) is in src/app/business_logic/request/send.rs, e.g. proxy and cookie-store setup at [src/app/business_logic/request/send.rs:L82-L107].
• WebSocket-specific send/receive logic is separated into src/app/business_logic/request/ws/send.rs, handling message types like Text/Binary/Ping/Pong/Close [src/app/business_logic/request/ws/send.rs:L180-L200].
• Scripting support (pre-request JS scripts via the boa JS engine) is in src/app/business_logic/request/scripts.rs, which builds a JS execution context and evaluates user scripts against the request/env JSON [src/app/business_logic/request/scripts.rs:L48-L82].
• Export functionality can generate equivalent client code in other ecosystems (e.g. Axios/JS, Rust) — see the rust_request/JS-generation logic in [src/app/business_logic/request/export.rs:L664-L695].
• The central App struct in src/app/app.rs (94 importers — the most depended-on file in the whole project) aggregates nearly all UI/state fields, including request-related inputs like url_text_input, query_params_table, and auth-related text inputs [src/app/app.rs:L79-L118, L199-L238].

Architecturally, this is a fairly tightly-coupled core: RepoPilot's import graph flags 8 circular dependency chains, several of which loop directly through app.rs, e.g. src/app/app.rs -> src/app/files/config.rs -> src/app/app.rs and a longer cycle through models/collection.rs and models/request.rs back into app.rs. That's consistent with app.rs being the top importer by a wide margin.

ultraworkers/claw-code doesn't appear to define an HTTP/network API either — from what's retrieved, it's structured as a Python "porting/parity" scaffold over an archived TypeScript codebase (archive/claude_code_ts_snapshot), which looks like a snapshot of Anthropic's Claude Code CLI tool internals. Its "API" is really a large catalog of tool modules (BashTool, GrepTool, LSPTool, WebFetchTool, ToolSearchTool, etc.) mirrored from TypeScript sources, as cataloged in src/reference_data/tools_snapshot.json [src/reference_data/tools_snapshot.json:L106-L145, L421-L460, L841-L880]. Each entry just records a name, source_hint (original .ts/.tsx path), and a boilerplate responsibility string — these are placeholders/mirrors, not live implementations.

The actual porting logic is driven by src/parity_audit.py, which maps archived TS root files and directories to expected Python equivalents (e.g. QueryEngine.ts → QueryEngine.py, tools.ts → tools.py) [src/parity_audit.py:L13-L69], and per-subsystem placeholder packages (e.g. src/remote/__init__.py) just load metadata from reference_data/subsystems/*.json and expose counts like MODULE_COUNT and SAMPLE_FILES [src/remote/init.py:L1-L15], mirroring subsystem catalogs such as src/reference_data/subsystems/services.json (130 modules, e.g. `