🔓 Liberation Status

The whole promise of comfy-api-liberation is that your API calls go straight to the vendor instead of through Comfy's credit proxy at api.comfy.org. LiberationStatus is the node that proves it's actually happening. It's a health check for the pack's monkey-patching, and it's the first thing to run when an API call silently does the wrong thing.

What it reports

No inputs, one output - a status STRING that reads something like:

=== Liberation Status ===
Patches: ✓ Active
Mapped providers: 29
Unmapped endpoints: 2

Unmapped (using Comfy proxy):
  - /proxy/vertexai/gemini
  ...

Three numbers, and each one matters differently:

• Patches: ✓ Active vs ✗ Inactive - this is the one that tells you if the interception layer is even running. Liberation works by monkey-patching ComfyUI's internal API client (comfy_api_nodes.util.client), rewriting /proxy/* request paths to direct vendor URLs and injecting your key as the auth header. If ComfyUI updates and breaks those internals, the patch can fail to apply - and this line is your early warning. ✗ Inactive means your calls are still going through Comfy's proxy no matter how many keys you've set.
• Mapped providers - how many vendors the pack currently rewrites. The count comes straight from its mapping registry.
• Unmapped endpoints - proxy endpoints the pack can see in Comfy's API nodes but has no rewrite rule for. Those keep using Comfy's proxy, which is by design: the pack's graceful fallback means "if we don't have a mapping, we don't touch it." When Comfy ships a new provider node before Liberation adds a mapping, this list is where it shows up.

When you'd run it

Honestly, most of the time you won't. It earns its keep at two moments. First, after updating ComfyUI or the pack itself - a single run confirms the patches survived. Second, when an API node fails or behaves oddly: if the status says the patch is active and nothing's unmapped, the problem is your key or the vendor, not the interception. It narrows the debugging space from "everything" to "the specific provider," which is more valuable than it sounds.

For the unmapped list, there's also a Copy Full List button in the pack's coverage inspector UI, so you can paste the whole set of unrewritten endpoints somewhere searchable instead of staring at the first ten in the node output.

Installing

It ships inside comfy-api-liberation, so install the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/holo-q/comfy-api-liberation.git

or search "comfy-api-liberation" in ComfyUI Manager, then restart. No extra dependencies, no model files, no build step.

Troubleshooting

• ✗ Inactive after an update. The patch failed to apply - usually a ComfyUI internals change. Check the console log for "Failed to apply patches" and confirm you're on a supported Comfy version; a pack update usually lands soon after.
• Unmapped endpoints are not a bug. They're the pack being honest about what it can't intercept yet. The fallback keeps those requests on Comfy's credits, which is far better than failing outright. New Comfy API nodes appearing on the list is normal drift, not breakage.
• Dig into the details with LIBERATION_DEBUG=1 python main.py if you want the verbose interception logs behind the one-line summary.

One caveat about reading too much into it: "active patches" proves the rewriting layer is installed, not that every individual call succeeds - a bad key still fails, and a provider the author only mapped but never tested can still 400. Use this node to confirm the plumbing, then blame the vendor.