I Tried to Make AI Writing Sound Human by Banning AI Words Through Logit_bias

A developer tested whether OpenAI's logit_bias API parameter could make AI-generated text sound more human by penalizing tokens associated with AI prose. The experiment sent eight AI-generated articles to DeepSeek V4 Flash through OpenRouter for rewriting, comparing control outputs with those using a -8 bias on a blacklist of token IDs. The approach differs from prompt-based bans because logit_bias directly alters token selection scores rather than relying on model compliance with instructions.

A Research Agent Can Leak Private Files Through Its Search Queries A research agent can leak a private document without uploading it. It can read a detail, turn it into a web search,… I tried to make AI writing sound more human with logit bias , an API setting that changes how likely a model is to select specific tokens. I built a blacklist from words that appeared unusually often in AI-generated text, converted the words into token IDs, and assigned those IDs negative values. This is different from putting “do not use these words” in the prompt. A prompt gives the model an instruction. The model reads it along with the article, decides how to apply it, and may ignore it when another instruction seems more important. logit bias does not ask. It changes the numerical scores used to select every next token. My idea was simple: if AI articles are easy to recognize partly because the same words keep appearing, perhaps I could reduce those words at the API level. I wanted the model to rewrite an AI-generated article while keeping its claims intact, but with fewer of the words associated with AI prose. To test that, I started with eight complete AI-generated articles. I sent each full article to DeepSeek V4 Flash through OpenRouter and asked it to edit the prose while preserving every fact, name, number, example, qualification, recommendation, and conclusion. I did not process the articles paragraph by paragraph. Each source article went through the model twice. Both calls used the same editing prompt and sampling settings. The control call used no token bias. The experimental call added a -8 bias to the token IDs on my blacklist. This produced eight control rewrites and eight blacklist-active rewrites of the same eight source articles. logit bias changesBefore a language model writes its next token, it assigns a score to every token it could choose. That score is called a logit. The API turns those scores into probabilities and samples the next token. logit bias inserts another number between those two steps. OpenAI's Chat Completions reference https://developers.openai.com/api/reference/resources/chat/subresources/completions/methods/create defines it as a map of token IDs to values from -100 to 100 . The API adds the supplied value to the model's score before sampling. A negative value reduces the chance that a token will be selected. A value near -100 can effectively ban it. Suppose the model is about to write “This is a crucial distinction.” If the token for “ crucial” receives a negative bias, another continuation becomes more likely. The model might choose “important,” remove the adjective, or construct a different sentence. That does not happen only once. Whatever token gets selected becomes part of the context used to score the following token. One forced substitution can therefore change the rest of the sentence and later sentences too. Words also do not map neatly to tokens. “Crucial” at the start of a sentence may have a different token ID from “ crucial” after a space. A capitalized form may be different again. Some words split into several tokens. Penalizing a shared fragment can affect words that were never meant to be on the blacklist. Listing words in the prompt is easier because it does not require tokenization. It also gives the model some discretion. If “appears” is on the list but the source makes an uncertain claim, the model can keep the hedge because preserving the claim is more important than following the blacklist perfectly. The disadvantage is that prompt instructions are not enforcement. The model may use a listed word anyway, especially in a long article with many other requirements. It may also obey mechanically and replace a normal word with an awkward synonym. I tested this separately with GPT-5.6 Sol, which does not accept logit bias . Five control articles used an ordinary editing prompt. Five experimental calls used the same task plus an explicit 93-word suppression list. The prompt list reduced watched-word occurrences from 11 across the five control outputs to one across the five experimental outputs. But two of the five experimental articles dropped or changed information. All five controls preserved the source meaning. That was not a direct comparison with the DeepSeek experiment because the model and source set were different. It did show that merely moving the blacklist into the prompt does not remove the tradeoff. The model can follow the list and still damage the article. There is no single model list that can be trusted without testing the actual endpoint. OpenAI still includes logit bias in the Chat Completions schema, but that does not mean current OpenAI models accept it. I sent compatibility probes to GPT-5.2 Chat, GPT-5.3 Chat, GPT-5.4, GPT-5.4 Mini, GPT-5.4 Nano, GPT-5.5, GPT-5.6 Sol, GPT-5.6 Terra, and GPT-5.6 Luna. Every one returned an unsupported parameter error. The current Responses API does not expose the field either. Anthropic's Messages API https://platform.claude.com/docs/en/api/messages/create has no native logit bias parameter. A Claude prompt can contain a word list, but the API does not provide the same token-ID score adjustment. OpenRouter has much broader support because it routes to many open and hosted models. Its Models API https://openrouter.ai/docs/guides/overview/models can filter models by supported parameters . On July 29, 2026, filtering for logit bias https://openrouter.ai/api/v1/models?supported parameters=logit bias returned 115 model IDs. The list included DeepSeek V4 Flash, GLM 5.2, Kimi K3, Gemma 4 31B, Qwen 3.6 27B, Llama 3.3 70B, Mistral Small 3.2 24B, GPT-4o, and several dated GPT-4o versions. Even that list is not proof that a particular request will work. OpenRouter combines several providers for some models. Its routing documentation https://openrouter.ai/docs/guides/routing/provider-selection says a provider may receive a request and ignore an unknown parameter unless require parameters is enabled. I saw both failure modes. One Qwen endpoint advertised support but rejected every request containing a non-empty bias map. A GPT-OSS endpoint accepted the parameter but ignored a -100 ban. For the DeepSeek experiment, I pinned the Cloudflare provider, disabled fallbacks, enabled require parameters , and ran a hard-ban probe before trusting the route. OpenRouter currently lists DeepSeek V4 Flash https://openrouter.ai/deepseek/deepseek-v4-flash as an available model, but the working unit in this experiment was the model plus that specific provider route. The hard-ban probe used -100 . Every watched word disappeared, confirming that the provider applied the bias. The model then repeated the same text until it exhausted the output limit. The parameter worked, but the result was unusable. I used -8 for the eight-article comparison. The source articles contained 264 occurrences from my watched list. The blacklist-active rewrites retained 180, removing 84 of 264. The blacklist also caused the model to change more text. Average 5-gram overlap, which measures shared five-word sequences between a source article and its edited version, was 0.982 in the control rewrites and 0.896 in the blacklist-active rewrites. Seven of the eight blacklist-active rewrites preserved the source facts, entities, and levels of certainty. The eighth changed an entity and removed the hedge “appears,” turning a qualified observation into a direct assertion. A separate review compared grammar, clarity, repetition, and sentence construction. Three blacklist-active rewrites were better than their source articles, four were no worse, and one was worse. The worse article changed “That detail matters because…” into the ungrammatical “That details why…” and introduced several other awkward substitutions. I then rejected any article that either changed the meaning or made the prose worse. Seven of the eight control rewrites passed. Six of the eight blacklist-active rewrites passed. The bias removed roughly a third of the watched occurrences and cost one acceptable article. logit bias did not reduce the model's knowledge or change its weights. It made some of the model's preferred next tokens harder to select. The model still knew the same facts. But the blacklist only said which tokens to avoid. It supplied no information about which replacement was grammatical, whether a hedge was necessary, or whether a proper name had to remain untouched. The resulting sentences could therefore look as if they came from a less capable model. Increasing the penalty did not solve this. In another set of tests, moving from -4 to -12 did not consistently remove more watched words. At -100 , the model removed the words and entered a repetition loop. The bias value did not tell me whether the next article would preserve its claims and grammar. A prompt blacklist and logit bias therefore fail in different ways. The prompt version is flexible but can be ignored or followed too literally. The API version applies direct pressure to token selection, but it cannot recognize when a blacklisted word is the correct word. Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request. Take a look at vroni.com