A field sits in the config, looks like it’s active, and no code ever reads it. This kind of failure raises no error — it just makes people say “something feels off”.
Table of Contents
Once I stared at a config file for half an hour. The fields, the formatting, the indentation — all fine, every key written with care. Then it hit me: not a single line of code ever read it.
01It looks already configured
Autarkia, the single-machine personal agent backend I’m building, has a proactive-care module that decides whether to send a message when the user hasn’t said anything. Its config accepted three sections — trigger, expression, limits — which looked complete, as if “when to send, how to send, how much to send” were all defined. In production only guidelines and examples were ever read; the rest had no consumer at all.
The config I wrote from the documentation was a comment from day one.
The same thing is harder to see at the prompt layer. Building a layered persona for a new character, the voice and knowledge files were in place — correct format, correct content — but the loader required meta.context_profile in the entry file. Without it, neither file is ever injected. Search the system prompt for tone or conversation_rhythm: zero hits.
The trouble is there’s no symptom. The model keeps replying, just not like that person; there’s no exception in the logs, only a sense that “it’s weird today”.
02I blamed the model first
I assumed it was the model. Swapped models, tuned temperature, added examples — nothing worked. Then I wrote a script to dump the final message list sent to the model and compared it section by section against the config. The whole block was empty.
The third example cost money. One day I opened the bill and found ¥0.9587 for the first ten hours on one platform: 138,269 input tokens costing ¥0.2904, and 79,570 output tokens costing ¥0.6684. The output was a third of the tokens and seven-tenths of the bill.
Digging along that line turned up a single row where the request body was built: payload.pop("max_tokens", None). The config sat there dutifully declaring active_care_generation_max_tokens=400, and it got popped on the way into the payload. The model then wrote as freely as it liked, with reasoning tokens billed at ¥8.4/M. The config was present and the value was correct; someone just decided that field was redundant while assembling the request. That someone was me.
All three come from the same gap: nothing checks config against code. A misspelled key, a refactor that deletes the code reading it, a field popped on the way through — none of it raises an error.
What I do now: every field has to name the code that reads it; if it can’t, it gets deleted or moved into documentation, because leaving it only convinces the next person it’s already set up. Whether config took effect is checked by a script: after every prompt assembly, search for the key sections and fail if they’re missing. No bare except on core paths: errors in identity, time, or context assembly must log a warning with exc_info.
For a service that runs unattended for months, failures that raise nothing cost the most time: nothing goes down, it just keeps running in the wrong state.