Unable to make Gemini CLI do long jobs, is there a way to improve?

[raghav135]

I am trying to get gemini-cli extract requirements from documents , for example, extract all requirements as markdown from a 400 page pdf document. But gemini-cli is only able to extract like 10 requirements out of 100+, even after giving hint like treat the "table of content" subcategories as requirements.

I want to understand if there is a way to improve this like by using some tools / flags / anything else ?

For example, without gemini-cli, I may have tried below:

1. iterate the pdf content in chunks and identify requirements mentioned in each chunk
2. Then consolidate the requirements gathered
3. Then loop for each requirement, get details from that section , and save as markdown

Thanks in advance for your help.

[scidomino]

There is no tool or setting that will fix this. This is a fundamental issue with LLMs having trouble working with long contexts. Here's a paper on it from last year: https://arxiv.org/abs/2307.03172

Different models have different performance characteristics though. Make sure you are using pro and not flash.

[raghav135]

Thanks for reply.
Update: when i convert pdf to text, able to create 250 documents, whereas only 12 when giving pdf

There is no tool or setting that will fix this. This is a fundamental issue with LLMs having trouble working with long contexts. Here's a paper on it from last year: https://arxiv.org/abs/2307.03172

Different models have different performance characteristics though. Make sure you are using pro and not flash.

[Manamama]

Use Sequential Thinking MCP for example. Many similar "PM" like MCPs should do. Do not count on some GEMINI.md files here: the instructions context would have been gone too soon, unless you refresh it now and then via usual in built tool.

[bdmorgan]

The only thing I can think of would be to enable some sort of "slicing" feature that a user opts into. If you need all the context aggregated into one fell swoop, slicing your doc into pieces for partial processing wouldn't work. But if you just want to extract requirements, it seems like that approach would work (i.e. break a 400 page doc into 10 40-page sub-docs and process them in parallel/series). The only glitch there might be some things get missed at the page breaks but with a little work you could intelligently break them with some overlaps to make sure nothing much got missed. Just a thought.

Not really sure if this would be a CLI feature as opposed to some sort of script that you could build "outside" the CLI

[raghav135]

Thanks for your reply, will try table of contents based slicing feature.

[raghav135]

Thanks for your reply, will try.

Use Sequential Thinking MCP for example. Many similar "PM" like MCPs should do. Do not count on some GEMINI.md files here: the instructions context would have been gone too soon, unless you refresh it now and then via usual in built tool.

[psinha40898]

Hey just a fan of the project here,

In general, there may be some reasonable application layer approaches to scaffold for the context limitations of LLMs.

1. Having tools that read and write to actual json plan files will almost certainly reduce hallucinations for longer tasks. You can see this throughout the industry in applications like Claude Code and Windsurf. This would also be complimentary to a "Plan Mode" in general.

I think the prevalence of this approach is due to its durability; reading and writing to plan files may increase performance and evals across most models for most prompts that already mandate planning (which the Gemini CLI's already does).

The current codebase, including prompts, seem to have already set the foundations for this implementation. I have a drafted PR (see #5345) in case a community contribution would be supported for this, but I'm not sure about the project's status with respect to Plan Mode as there are other PRs under stalled reviews for the issue (see #1742).

2. (Assuming an internal CLI implementation) Chunking, or "slicing", as mentioned here by @bdmorgan is certainly an approach that is used throughout AI apps today. As already identified, the issue of context becomes complicated.

Restricting the implementation to a tightly defined use case where the entire context does not need to be respected may or may not be simple.

On the other hand, expanding to use cases where the entire context does matter will certainly require deep thought in both implementation and evals in order to avoid being brittle. Sometimes referred to as "chunk and concat" (summarize each chunk and pass the concatenated summary to the next chunk), there are plenty of ways it can go wrong without robust evals and well defined use cases.

So plan tools (and mode) may be an easy win that should wholistically help with context issues without requiring much thought to avoid model performance regressions, chunking may be more directly effective for this specific issue but also more complicated to implement.

[Manamama]

Uhm. Plus these as a crutch until that PR:

• https://github.com/modelcontextprotocol/servers/tree/main/src/memory , or

• TaskMaster MCP etc.

• Experimental, alpha methinks: https://github.com/EchoingVesper/vespera-atelier - I tested it yesterday: looks promising, but rough around some function calls still.

• aider has had some plan for a while, too.