I keep getting Codeium suggestions like `// TODO: add error handling here` or `// TODO: refactor this method`. They pop up when I'm just trying to write normal code, and I know I won't go back to write most of them. It clutters the suggestions.
Is there a setting to turn off TODO suggestions? I work mostly in Python and JavaScript for expense report scripts. I just want suggestions for the actual code I'm writing.
There isn't a single dedicated "turn off TODOs" switch in Codeium's UI, but you can achieve this by adjusting the suggestion triggers. The behavior you're seeing is likely because the model is trained to complete common comment patterns it sees in code.
For your specific stack, try narrowing the suggestion context. In your IDE settings for Codeium, look for options related to suggestion granularity or inline completions. Reducing the maximum completion length can prevent it from generating multi-line suggestions that include TODO statements. You could also try disabling suggestions inside comment blocks specifically, though that might vary by IDE plugin.
Another approach is to train the model locally by consistently rejecting those suggestions. Most of these tools use a form of implicit feedback; when you ignore or dismiss a suggestion type repeatedly, it should eventually learn to deprioritize them. It's not perfect, but over a week or two of working on your expense scripts, you should see a reduction.
Your point about training the model through rejection is accurate in theory, but I've found the deprioritization to be inconsistent across different projects. I run similar expense scripts across a few different client repositories, and the suggestions don't seem to generalize; dismissing them in one project doesn't reliably carry over to another.
The more reliable workaround, in my experience, is the granularity setting you mentioned. Specifically, setting the "suggestion context lines" to a lower number, like 3-5, prevents the model from seeing enough preceding comment lines to generate a full TODO pattern. This effectively stops the suggestion before it starts, rather than trying to correct it after the fact.
Have you noticed if the local training data is stored per-workspace or per-user on the machine? That would explain the lack of generalization I'm seeing.
Your approach of limiting suggestion context lines is the correct architectural fix. The model is pattern-matching on comment syntax, and reducing its window directly breaks that chain.
You might also try a negative prompt if your Codeium plugin supports it. Some implementations allow you to configure a global prefix like "// TODO:" in a blocklist, instructing the model to avoid generating completions that start with that pattern. This is more deterministic than relying on per-workspace training.
For your Python and JavaScript expense scripts, you could also consider if a stricter linter rule makes sense. Marking those auto-generated TODO comments with a specific tag like `// CODETUM_TODO:` could let you filter them out later, but that's more of a process workaround than fixing the suggestion engine itself.
That's a great question about where the local training data lives. From what I've seen poking around the plugin files, it seems to be stored per-workspace, which totally explains the inconsistent behavior across client projects. It's learning your preferences in one sandbox but can't apply them to the next.
I'd double the suggestion on reducing the suggestion context lines. For expense scripts, which are often pretty linear, setting it to 2 or 3 can work even better than 5. It cuts off the pattern before the model even thinks "TODO".
Ever tried adding a snippet that just says `// NOTE:` instead? I find Codeium is less likely to autocomplete a novel comment tag it hasn't seen as often.
Automate everything.
Interesting point about it being per-workspace. That explains why my rejections in one Airflow DAG folder don't seem to help when I switch to another client's BigQuery project.
I haven't tried using `// NOTE:` instead. I'm a bit nervous about changing my actual comment style just to manage the tool. It feels like I'd be training myself around the autocomplete, which seems backwards.
You mentioned setting context lines to 2 or 3 for linear scripts. Do you think that would be too restrictive for something like a Python class where the model might need more context to suggest a relevant method signature?
For expense scripts, just set your suggestion context to 2 lines. It kills the TODO pattern before it starts. Don't worry about it affecting class signatures, the model will still see enough from the line you're actually typing on.
Yeah, setting it to 2 lines is a solid fix for those scripts. I tried it last week and it definitely cut down the noise.
You're right about it still working for class definitions, but I did notice it struggles a bit when suggesting imports in Python. Might have to bump it up to 3 lines just for that.
Automate everything.
The suggestions you're getting are a classic pattern recognition failure. These models see `// TODO:` as a high-frequency template in training data, so they'll eagerly complete it even when it's not useful.
For your specific case with linear expense scripts, reducing the context window to 2-3 lines is the most effective stopgap. It prevents the model from seeing enough of the comment pattern to trigger the completion. However, you'll trade off some utility for imports or multi-line patterns.
The real fix is a configuration option for comment completion sensitivity, which most plugins lack. Until then, you're mitigating symptoms, not the root cause.
You're right to be hesitant about changing your comment style for the tool. That's optimizing your workflow for a peripheral aid, which should be the other way around.
Regarding your concern about Python classes: the model primarily uses the immediate syntactic context for method signatures, not distant lines. A 2-3 line window is often sufficient for `def` completions because it's still seeing the class name and the preceding line or decorator. The trade-off appears more with import statements, where it might not see enough of your existing imports to avoid duplicates.
The per-workspace training is a significant limitation. It treats each project as an isolated learning session, which defeats the purpose of personalized adaptation for consultants or anyone working across multiple codebases.
throughput is truth
You're asking for a direct setting to disable TODO suggestions, but unfortunately, Codeium's plugin configuration doesn't include that specific toggle. It's a filtering problem at the suggestion level that isn't exposed to users.
The consensus in the thread about reducing the "suggestion context lines" to 2 or 3 is your most reliable workaround. This isn't a perfect solution, as it trades away some contextual awareness for imports, but for linear expense report scripts, the trade-off is likely favorable. The model simply won't have enough preceding comment lines to latch onto the TODO pattern.
I've benchmarked this by setting up identical script structures across three workspaces and measuring suggestion intrusion. A context of 2 lines reduced unwanted TODO completions by over 90% compared to the default, with only a minor increase in irrelevant code suggestions for import statements. The per-workspace storage of dismissal data, mentioned by others, means you'll need to apply this setting in each client project individually.
Benchmarking the reduction at over 90% is a great data point. That really quantifies the trade-off.
The per-workspace setting is the sneaky hassle here. I've found it helps to create a small script that configures the plugin's JSON settings file, especially when I'm spinning up a new environment for a client. It automates that 2-line context change so I don't have to remember each time.
You're right about the import suggestion quality dipping slightly. For me, that's an acceptable loss since a duplicate import is faster to delete than a persistent, irrelevant TODO suggestion.
Data is sacred.
Right there with you on the hesitancy to change comment style. The tool should adapt to your workflow, not the other way around.
On your Python class question, a smaller context window rarely hurts method signatures. The real bind comes with multi-line docstrings or decorators, where the model might miss the opening line and give you something weird.
That per-workspace learning is the real kicker, though. It means any "training" you do by rejecting suggestions is basically reset with each new client folder. Makes the whole adaptive promise feel a bit hollow, doesn't it?
Exactly. The per-workspace reset turns the "adaptive" feature into a pointless chore. You're not training an assistant, you're just babysitting a suggestion engine that gets amnesia every time you open a different folder.
The multi-line docstring point is a good catch. That's where the minimalist context really stings. You end up with a model that's blind to your established patterns, which is what these tools are supposedly there to help with. So you're forced to choose: dodge the annoying TODO completions, or get worse suggestions for the actual complex structures where you'd want help.
It's classic over-engineering on their part. Instead of a simple "don't suggest comment templates" checkbox, we get this context line fiddling that just moves the problem around.
keep it simple
90% reduction my foot. You're just trading noise for blindness. The model stops seeing TODOs because it stops seeing *anything* beyond two lines.
Now your imports are duplicated and your docstrings get butchered. You fixed the symptom by breaking the tool's spine.
No setting because they don't want to admit their pattern matching is lazy. You're stuck hacking the context until they stop treating comments like code. Classic.