ONNX downloader writes models/phi-4-mini/ but the provider reads models/phi-4/ — a completed download is never found

Summary

The ONNX downloader writes to models/phi-4-mini/... while the provider that loads the model defaults to models/phi-4/... — no -mini. The two paths can never coincide, so even a fully completed 4.6 GB download is not found by the code that needs it.

The disagreement

Writer — dist/utils/model-downloader.js:20:

localPath: './models/phi-4-mini/cpu_and_mobile/cpu-int4-rtn-block-32-acc-level-4/model.onnx'

Reader — dist/router/providers/onnx-local.js:31:

modelPath: config.modelPath || './models/phi-4/cpu_and_mobile/cpu-int4-rtn-block-32-acc-level-4/model.onnx',

Why the default is what actually gets used

The CLI never supplies a modelPath unless ONNX_MODEL_PATH is set, so the mismatched default is live on the ordinary path:

dist/cli-proxy.js:486   new AnthropicToONNXProxy({ modelPath: process.env.ONNX_MODEL_PATH, ... })
                        // undefined unless the user sets it
dist/proxy/anthropic-to-onnx.js:5,15-16
                        imports ONNXLocalProvider from ../router/providers/onnx-local.js
                        and forwards config.modelPath through
dist/router/providers/onnx-local.js:31
                        falls back to ./models/phi-4/...   ← never written by the downloader

dist/router/router.js:141 and dist/router/providers/onnx-phi4.js:16 carry the same phi-4 default. Only dist/router/providers/onnx-local-optimized.js:29 agrees with the downloader, and it is not on this path.

Impact

--provider onnx is advertised as the zero-key local option and is the one the missing-API-key error steers users toward. As shipped it cannot work: a user waits out a 4.6 GB download and the loader then looks in a directory that was never created. Combined with #226 (the download landing in process.cwd()) the model is also re-downloaded per working directory, so the wait is repeated.

I have not measured the exact loader error, because the download was aborted once its destination was understood — the path disagreement is static and readable in the shipped dist/, which is what this report rests on.

Suggested fix

Have both sides import one exported constant, which also resolves #226:

// utils/model-downloader.js
export const PHI4_MODEL_PATH = join(MODEL_ROOT, 'phi-4-mini',
    'cpu_and_mobile', 'cpu-int4-rtn-block-32-acc-level-4', 'model.onnx');

// router/providers/onnx-local.js
import { ensurePhi4Model, ModelDownloader, PHI4_MODEL_PATH } from '../../utils/model-downloader.js';
...
modelPath: config.modelPath || PHI4_MODEL_PATH,

onnx-local.js already imports from model-downloader.js, so this adds no new dependency edge. router.js:141 and onnx-phi4.js:16 want the same treatment.

Verified locally against 2.1.2 that reader and writer then resolve to the identical absolute path. Happy to open a PR.

Environment

agentic-flow@2.1.2 · node v22.23.0 · npm 10.9.8 · macOS (Darwin 25.6.0)

Related: #226 (download location — the two compound)

Start with dist/utils/model-downloader.js, then trace the defaults in dist/router/providers/onnx-local.js, dist/router/router.js, and dist/router/providers/onnx-phi4.js through the CLI entry point. Verify that the downloader and every ordinary ONNX reader resolve the same model path, and run the relevant project checks to confirm the local provider can find a completed download.