Running it through your own provider key
If you would rather not install a local model, the tool can use your own OpenRouter account. Your account, your contract, your retention settings.
Read this part first
On this path the specification is transmitted to the provider you configure. For published patents and published applications that is unremarkable. For an unpublished or privileged application it is a decision only you can make for that matter, against your own professional obligations. The tool does not make it for you, and it prints a note on every run that routes off your machine.
If you want the specification to stay on your hardware, use a local model instead: choose one for your machine.
Setting it up
Create a key
At openrouter.ai/keys, and add credit.
Turn on zero data retention
In your own provider account settings, if you want it. That setting is yours, held in your account, and it applies whether or not you use this tool.
Make the key available
Read from the environment first, then from
~/.continuation-drafter/config.json, a file the binary creates readable only by
you. Never from a command-line flag and never written to a log.
export OPENROUTER_API_KEY=sk-or-...
The local web UI can save the key into that file for you. The command line does not. Setting the environment variable always takes precedence over the saved file.
Name a remote model
A slash in the name routes remotely.
./continuation-drafter draft --spec spec.txt --parent parent-claims.txt \
--model openai/gpt-5.5
What you gain and what you give up
Remote models are faster and, on the strategy axis, they aimed their independent claims across more of the relevant loci in our testing, where strong local models tended to cluster on the most literal reading of the disclosure. That is a real difference in usefulness, and it is the reason the choice is a tradeoff rather than a preference.