AI for coding, without the security refusals

The refusals that waste a developer's day

The pattern is consistent enough to be predictable. A model trained to decline reads intent from surface features, and a great deal of ordinary engineering has the surface features of an attack.

• Reading a malware sample you have been handed to analyse, which is the entire job in incident response.
• Writing an exploit for a system you are contracted to test, where the contract is the thing that makes it legal and the model cannot see the contract.
• Explaining an attack technique in order to write a detection for it, which is how every detection gets written.
• Scraping, automation and reverse engineering, all of which are legal in most contexts and read as suspicious in all of them.
• Anything touching credentials, even when the task is rotating your own.

The cost is not the refusal itself. It is that you now cannot trust the assistant with a whole category of work, so you stop reaching for it and the tool becomes useful only for the easy half of your job.

Why Balanced suits code

Balanced is a reasoning model, so it works through the problem before it writes, and its sampling leaves repetition alone. Ordinary chat presets penalise a model for repeating itself, which is right for prose and actively harmful for source code — imports, loop headers and boilerplate legitimately repeat, and a model discouraged from repeating them starts paraphrasing syntax that has exactly one correct spelling.

The reasoning is shown separately from the answer, which matters more for code than for anything else: you can read why it chose an approach without that reasoning ending up pasted into your file.

Context, and why 200K is the number that matters

Debugging is a whole-context activity. The bug is in one file, the cause is in another, and the reason it was written that way is in a third. An assistant that can only see the function you pasted is guessing about the other two.

On Pro the window is 200K tokens, which is a small codebase or a large module with its tests and its callers. The practical effect is that you stop curating what to show it and start pasting what is relevant.

The output cap matters as much and is noticed later. A model that stops mid-function because the response limit was small is not usable for real work regardless of the quality of the first half. Over the API the cap is 24K tokens on Pro, which is a complete file rather than the beginning of one.

In the terminal and in your editor

The API is OpenAI-compatible, so the editor plugin, agent framework or CLI you already use will target it with two environment variables changed. That is the intended way to work on code for anything sustained: a chat window is a poor place to do work that touches many files.

export OPENAI_BASE_URL=https://api.tartarusai.chat/api/v1
export OPENAI_API_KEY=<token from Account, CLI access>

What is still off the table

Reduced refusal is not permission, and the acceptable use policy is the same here as everywhere else on the service. Attacking systems you do not own or have not been authorised to test is prohibited, as is using the service to commit fraud. Those are not content preferences; they are where a legitimate business stops.

Nor does it make the model right. It writes plausible code with confidence, including plausible code that does not compile or that compiles and is wrong. Review it the way you would review a pull request from someone competent and slightly overconfident.