Skip to content
Notifications
Clear all

Help: Getting 'context limit exceeded' errors constantly on monorepos.

3 Posts
3 Users
0 Reactions
3 Views
(@data_pipeline_ops)
Estimable Member
Joined: 4 months ago
Posts: 58
Topic starter   [#13098]

I'm trying to use Codeium on a large monorepo with multiple services and shared libraries. It's a Python/TypeScript project.

I keep hitting 'context limit exceeded' errors when asking for anything complex, like refactoring a function that uses internal imports. It seems like it can't pull in enough of the relevant code from across the repo to understand the full context.

Is this a common issue? Are there any settings or best practices to help Codeium handle monorepos better? I love the suggestions it gives on smaller, isolated files, but it falls apart on cross-service logic.

Building my first pipeline.


PipelinePadawan


   
Quote
(@grace5)
Trusted Member
Joined: 6 days ago
Posts: 38
 

That's a really common pain point with monorepos. I've run into the same wall trying to get suggestions for functions that depend on shared types or utilities.

One thing that helped me was being super specific in the prompt about which exact files to reference. Instead of asking to "refactor this," I might say something like "look at the UserService interface in shared/types and the logger in utils/logging, then suggest changes for this function." It doesn't always solve it, but it improves the odds.

Have you found any workarounds for the imports issue? I'm still trying to figure out if there's a way to hint at the most critical dependencies without listing every single one.



   
ReplyQuote
(@infra_auditor_nina)
Reputable Member
Joined: 4 months ago
Posts: 159
 

Welcome to the reality of context windows. They're a hard ceiling, not a suggestion. The model can't reason about your entire monorepo because, well, it can't see it all.

Your issue isn't a settings problem, it's an architecture mismatch. Asking a tool to refactor a function with cross-service dependencies without providing the full dependency graph is like asking an auditor to sign off on a system without seeing the logs. It can't be done safely.

You might try breaking the task down: ask it to analyze *just* the shared type definition first, then the specific service logic. But honestly, for any real refactoring in a large monorepo, you're going to hit this wall. It's a boundary that forces you to understand the code flow yourself, which isn't the worst outcome.


- Nina


   
ReplyQuote