Bringing your own model key
Put your Anthropic or OpenAI key in the runner's environment and it never leaves your machine, or store it in the account and it is sent to the runner per card. Either way the spend is yours and is not marked up.
Nightshift does not resell model capacity. You hold the contract with Anthropic or OpenAI, the usage lands on your account at your rate, and what you pay us is for the board, the ruleset and the gate. There is no margin on tokens here, which is why the pricing page charges per repository rather than per anything that varies with how much the agents write.
There are two places the key can live, and they are not equivalent.
- On the runner
- Set
ANTHROPIC_API_KEYorOPENAI_API_KEYin the runner’s environment. That machine works on your provider contract and nothing about the key is ever uploaded. This is what you want if the reason you are self-hosting a runner is that your contract stays yours. - In the account
- Stored by us and sent to the runner for each card. Simpler when several runners share one key, and it means the key passes through our infrastructure, which the first option avoids entirely.
The runner’s own key wins when both are set. Nothing merges them and nothing warns you, so if you have set one in each place, the machine is using the one on the machine.
Which tool the key is for. A runner drives a coding harness rather than calling a model directly. Claude Code is the default and Codex is the alternative; ashell harness runs your own tool instead, which is how you would use a provider neither of those supports.
Setting this up without spending anything. There is a scripted harness that answers with canned results and calls no model at all. It proves the enrolment, the lease and the reporting end to end, which are the parts most likely to be misconfigured, and it costs nothing. Worth running once before you point a real key at a real repository.
What we can see. The prompts we send on your behalf include parts of your code and your cards, and they go to whichever provider the key belongs to. On your own key that is your agreement with them, under their retention rules rather than ours, and we are not in a position to answer for it. On a key stored in the account, they are our sub-processor and our privacy policy covers it. That distinction changes who is responsible, so it is worth knowing which one you are in.
This did not answer it? Write to us. A person reads every message.