Skip to content
Notifications
Clear all

Anyone else getting 'context too large' errors on big projects?

2 Posts
2 Users
0 Reactions
0 Views
(@jamesk)
Estimable Member
Joined: 1 week ago
Posts: 80
Topic starter   [#11856]

Hey folks,

Ran into a frustrating one this week and wanted to see if anyone else has hit this or found a workaround. I've been trying to use Cline on one of our larger monorepos (think 50+ microservices, shared libraries, the whole shebang). It works great for isolated files or small directories, but as soon as I ask for something that requires a broader understanding—like "how does this API route connect to the service layer in this other module?"—it chokes and throws a `'context too large'` error.

It feels like I'm hitting a token limit on the context window, even though I'm not explicitly loading the entire repo. My suspicion is that Cline's project analysis might be a bit too eager in gathering context for large codebases.

Here's what my `.cline` config looks like currently, pretty standard:

```yaml
project_root: .
ignored_paths:
- "**/node_modules"
- "**/.git"
- "**/dist"
- "**/build"
- "**/coverage"
```

Has anyone figured out a good pattern for this? I'm thinking about a few approaches:

* Creating separate `.cline` configs for specific subdirectories (like `./services/payment-service`).
* Being hyper-specific with file paths in my prompts.
* Maybe there's a hidden config for max context size?

It's a bummer because the tool is fantastic for smaller projects. Would love to hear if the platform engineering or GitOps folks here have strategies for taming large projects with Cline.

Cheers,
-jk



   
Quote
(@integration_tinkerer)
Estimable Member
Joined: 3 months ago
Posts: 104
 

Yeah, the struggle is real with monorepos. Your suspicion about eager analysis is probably right on the money - these tools often crawl through imports or module graphs to build context, and that can blow up fast.

I've had success with your first idea: creating subdirectory-specific configs. I set up a `services/.cline` and a `packages/.cline`, each with their own ignored paths relative to that root. It feels a bit manual, but it tells the tool exactly where to look.

Another trick? I've started adding more aggressive `ignored_paths` patterns for generated code and even specific `__tests__` directories when I know I'm only asking about core logic. Sometimes you gotta be ruthless to keep the context manageable.

Ever tried using a `.gitignore`-style approach in the config, or is your ignore list already as tight as it gets?



   
ReplyQuote