AT_APICallError: prompt token count of 130389 exceeds the limit of 128000 #1637

Originally created by @bb33bb on GitHub (Sep 6, 2025).

Originally assigned to: @rekram1-node on GitHub.

AT_APICallError:
prompt
token count of 130389 exceeds the limit of 128000

this will bock the whole work process, and we have to restart the process.

Originally created by @bb33bb on GitHub (Sep 6, 2025). Originally assigned to: @rekram1-node on GitHub. ``` AT_APICallError: prompt token count of 130389 exceeds the limit of 128000 ``` this will bock the whole work process, and we have to restart the process.

yindo closed this issue

yindo commented

@github-actions[bot] commented on GitHub (Sep 6, 2025):

This issue might be a duplicate of existing issues. Please check:

#2317: Github Copilot provider allows only 128k token conversations - Similar 128k token limit error with specific providers
#1172: High input token usage on a small project - Similar context limit exceeded with tokens in 160k-172k range
#924: Dramatic increase in token consumption - Reports sudden increase in token usage causing exhaustion
#1212: Fetched documentation exceeds context window limit - Similar AI_APICallError about context limits being exceeded
#491: AI_APICallError: input length and 'max_tokens' exceed context limit - Very similar error format about exceeding token limits

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Sep 6, 2025): This issue might be a duplicate of existing issues. Please check: - #2317: Github Copilot provider allows only 128k token conversations - Similar 128k token limit error with specific providers - #1172: High input token usage on a small project - Similar context limit exceeded with tokens in 160k-172k range - #924: Dramatic increase in token consumption - Reports sudden increase in token usage causing exhaustion - #1212: Fetched documentation exceeds context window limit - Similar AI_APICallError about context limits being exceeded - #491: AI_APICallError: input length and 'max_tokens' exceed context limit - Very similar error format about exceeding token limits Feel free to ignore if none of these address your specific case.

yindo commented

@rekram1-node commented on GitHub (Sep 6, 2025):

can you try running /compact

@rekram1-node commented on GitHub (Sep 6, 2025): can you try running /compact

yindo commented

@rekram1-node commented on GitHub (Sep 6, 2025):

the slash command

@rekram1-node commented on GitHub (Sep 6, 2025): the slash command

yindo commented

@bb33bb commented on GitHub (Sep 6, 2025):

the slash command

ok，thanks! going to try

@bb33bb commented on GitHub (Sep 6, 2025): > the slash command ok，thanks! going to try

yindo commented

@ndrwstn commented on GitHub (Sep 11, 2025):

The Core Problem: Tools Should Never Cause Token Limit Failures

This issue represents a fundamental design flaw: tools themselves are causing AI sessions to fail by returning more content
than can fit in the model's context window. This is a preventable failure mode that shouldn't exist.

The Current Situation

When an AI uses tools like `read`, `grep`, `glob`, or `ls` on large files or directories, these tools can return massive
amounts of content that exceed the model's token limit. This causes an immediate, unrecoverable error:
```
AT_APICallError: prompt token count of 130389 exceeds the limit of 128000
```

This is particularly problematic because:

The AI has no way to predict how much content a tool will return before calling it
The failure is catastrophic - the entire session becomes blocked
The user's only recourse is to restart or use `/compact`, losing context
It's a self-inflicted failure - the system is breaking itself

Why This Is Different From General Token Management

This isn't about managing conversation history or user-provided context. This is about tools returning unsafe amounts of data.
The tools are essentially landmines that can blow up the session at any moment.

Proposed Solution: Token-Aware Tool Limits

All tools should implement proactive token limiting to prevent context overflow:

Token Budget Allocation: Each tool should be aware of:
- The model's total context window
- Current conversation token usage
- A safe percentage to allocate for tool output (e.g., 25-40% of remaining context)
Smart Truncation: When content exceeds the budget:
- Truncate intelligently at natural boundaries (lines, files, matches)
- Return clear metadata about what was truncated
- Provide actionable suggestions (use offset/limit, narrow search pattern, etc.)
Dynamic Limits Based on Model: Different models have different context windows:
- Claude 3.5: 200k tokens
- GPT-4: 128k tokens
- Smaller models: 8k-32k tokens
Tools should adapt their limits accordingly.

Reference to PR #2328

PR #2328 ("fix: AI_APICallError: prompt is too long: 209045 tokens > 200000 maximum due to large file read") attempted to
address this for the `read` tool by:

Adding token estimation utilities
Pre-checking file sizes
Using 75% of context for file content
Providing truncation messages

However, this solution needs to be:

Extended to ALL tools (grep, glob, ls, webfetch, etc.)
Made configurable rather than hardcoded percentages
More conservative in token estimation to ensure safety

Implementation Suggestions

```typescript
// Example for any tool
const MAX_TOOL_OUTPUT_PERCENTAGE = 0.3; // Use max 30% of available context

async function executeToolWithTokenLimit(params, ctx) {
const modelContext = ctx.model.contextWindow;
const currentUsage = ctx.conversation.tokenCount;
const availableTokens = modelContext - currentUsage;
const maxToolTokens = Math.floor(availableTokens * MAX_TOOL_OUTPUT_PERCENTAGE);

// Execute tool with token limit
const result = await executeTool(params, maxToolTokens);

if (result.truncated) {
result.output += `\n\n⚠️ Output truncated to fit context (${result.tokenCount}/${maxToolTokens} tokens used)`;
result.output += `\nSuggestions: Use more specific patterns, offset/limit parameters, or narrow your search`;
}

return result;
}
```

Current Tool Limits Are Insufficient

The current hardcoded limits are arbitrary and don't prevent token overflow:

`read`: 2000 lines (could be 200k+ tokens with long lines)
`grep`/`glob`: 100 results (could be massive depending on content)
`ls`: 100 files (seems reasonable but still arbitrary)

These limits need to be token-based, not count-based.

The Bottom Line

Tools should never cause the session to fail due to token limits. This is a preventable failure that makes the system
unreliable. Every tool should have built-in safety mechanisms to ensure they can't break the context window, regardless of the
input data size.

This would transform tools from potential failure points into reliable, predictable components that gracefully handle large
datasets while preserving the AI's ability to continue working.

Obviously, written by OpenCode and Claude.

@ndrwstn commented on GitHub (Sep 11, 2025): ## The Core Problem: Tools Should Never Cause Token Limit Failures This issue represents a fundamental design flaw: **tools themselves are causing AI sessions to fail by returning more content than can fit in the model's context window**. This is a preventable failure mode that shouldn't exist. ### The Current Situation When an AI uses tools like \`read\`, \`grep\`, \`glob\`, or \`ls\` on large files or directories, these tools can return massive amounts of content that exceed the model's token limit. This causes an immediate, unrecoverable error: \`\`\` AT_APICallError: prompt token count of 130389 exceeds the limit of 128000 \`\`\` This is particularly problematic because: 1. **The AI has no way to predict** how much content a tool will return before calling it 2. **The failure is catastrophic** - the entire session becomes blocked 3. **The user's only recourse** is to restart or use \`/compact\`, losing context 4. **It's a self-inflicted failure** - the system is breaking itself ### Why This Is Different From General Token Management This isn't about managing conversation history or user-provided context. This is about **tools returning unsafe amounts of data**. The tools are essentially landmines that can blow up the session at any moment. ### Proposed Solution: Token-Aware Tool Limits All tools should implement **proactive token limiting** to prevent context overflow: 1. **Token Budget Allocation**: Each tool should be aware of: - The model's total context window - Current conversation token usage - A safe percentage to allocate for tool output (e.g., 25-40% of remaining context) 2. **Smart Truncation**: When content exceeds the budget: - Truncate intelligently at natural boundaries (lines, files, matches) - Return clear metadata about what was truncated - Provide actionable suggestions (use offset/limit, narrow search pattern, etc.) 3. **Dynamic Limits Based on Model**: Different models have different context windows: - Claude 3.5: 200k tokens - GPT-4: 128k tokens - Smaller models: 8k-32k tokens Tools should adapt their limits accordingly. ### Reference to PR #2328 PR #2328 (\"fix: AI_APICallError: prompt is too long: 209045 tokens > 200000 maximum due to large file read\") attempted to address this for the \`read\` tool by: - Adding token estimation utilities - Pre-checking file sizes - Using 75% of context for file content - Providing truncation messages However, this solution needs to be: 1. **Extended to ALL tools** (grep, glob, ls, webfetch, etc.) 2. **Made configurable** rather than hardcoded percentages 3. **More conservative** in token estimation to ensure safety ### Implementation Suggestions \`\`\`typescript // Example for any tool const MAX_TOOL_OUTPUT_PERCENTAGE = 0.3; // Use max 30% of available context async function executeToolWithTokenLimit(params, ctx) { const modelContext = ctx.model.contextWindow; const currentUsage = ctx.conversation.tokenCount; const availableTokens = modelContext - currentUsage; const maxToolTokens = Math.floor(availableTokens * MAX_TOOL_OUTPUT_PERCENTAGE); // Execute tool with token limit const result = await executeTool(params, maxToolTokens); if (result.truncated) { result.output += \`\\n\\n⚠️ Output truncated to fit context (\${result.tokenCount}/\${maxToolTokens} tokens used)\`; result.output += \`\\nSuggestions: Use more specific patterns, offset/limit parameters, or narrow your search\`; } return result; } \`\`\` ### Current Tool Limits Are Insufficient The current hardcoded limits are arbitrary and don't prevent token overflow: - \`read\`: 2000 lines (could be 200k+ tokens with long lines) - \`grep\`/\`glob\`: 100 results (could be massive depending on content) - \`ls\`: 100 files (seems reasonable but still arbitrary) These limits need to be **token-based, not count-based**. ### The Bottom Line **Tools should never cause the session to fail due to token limits.** This is a preventable failure that makes the system unreliable. Every tool should have built-in safety mechanisms to ensure they can't break the context window, regardless of the input data size. This would transform tools from potential failure points into reliable, predictable components that gracefully handle large datasets while preserving the AI's ability to continue working. --- Obviously, written by OpenCode and Claude.

yindo commented

@shantur commented on GitHub (Sep 18, 2025):

This single issue keeps pushing me back to Codex / Claude Code

I would suggest a bit different approach.

If Context Limit < Current Context + Current Tool Output
Compact conversation automatically

if Context Limit < Compacted Context + Current Tool Output
Respond to LLM saying the current tool output is too long, find alternate ways to do it.
else
Continue conversation

This should keep the flow going on.

@rekram1-node - What are your thoughts

@shantur commented on GitHub (Sep 18, 2025): This single issue keeps pushing me back to Codex / Claude Code I would suggest a bit different approach. If Context Limit < Current Context + Current Tool Output Compact conversation automatically if Context Limit < Compacted Context + Current Tool Output Respond to LLM saying the current tool output is too long, find alternate ways to do it. else Continue conversation This should keep the flow going on. @rekram1-node - What are your thoughts

yindo commented

@rekram1-node commented on GitHub (Sep 18, 2025):

@shantur can you share a session that you ran into this issue with? Would be helpful for debugging where the calculation isn't working

@rekram1-node commented on GitHub (Sep 18, 2025): @shantur can you share a session that you ran into this issue with? Would be helpful for debugging where the calculation isn't working

yindo commented

@shantur commented on GitHub (Sep 18, 2025):

@rekram1-node - I don't think I will be able to share the current session but I can explain when it happens.

When the context is consumed almost to the limit and a tool is run that generates a large output - even after truncation the output is still large to fit in the context at that time it happens.

I was seeing this many times when I was asking Claude to run tests that generates a lot of logs.

@shantur commented on GitHub (Sep 18, 2025): @rekram1-node - I don't think I will be able to share the current session but I can explain when it happens. When the context is consumed almost to the limit and a tool is run that generates a large output - even after truncation the output is still large to fit in the context at that time it happens. I was seeing this many times when I was asking Claude to run tests that generates a lot of logs.

yindo commented

https://opencode.ai/s/FNQDFRRt

@shantur commented on GitHub (Sep 18, 2025):

@shantur commented on GitHub (Sep 18, 2025): https://opencode.ai/s/FNQDFRRt

yindo commented

@habenicht-io commented on GitHub (Sep 21, 2025):

I'm not sure if this is the same, a similar, or a different problem.
The error is definitely reproducible though.
This is a fully built Vue application whose source code is not available to me.
I wanted to use Grok Fast to determine if a component can still be overridden.
The JavaScript file is 3.6MB in size and has only one line.
I suspect that the tooling fails because a single line is already much too large for the context window.

@habenicht-io commented on GitHub (Sep 21, 2025): <img width="1721" height="1288" alt="Image" src="https://github.com/user-attachments/assets/1ea563f1-b6c9-4d47-8893-0bf228c012ae" /> I'm not sure if this is the same, a similar, or a different problem. The error is definitely reproducible though. This is a fully built Vue application whose source code is not available to me. I wanted to use Grok Fast to determine if a component can still be overridden. The JavaScript file is 3.6MB in size and has only one line. I suspect that the tooling fails because a single line is already much too large for the context window.

yindo commented

@rekram1-node commented on GitHub (Sep 21, 2025):

wonder if the truncation logic needs some work, I think it might just do line counts which would fail for minified js

@rekram1-node commented on GitHub (Sep 21, 2025): wonder if the truncation logic needs some work, I think it might just do line counts which would fail for minified js

yindo commented

@Kirow commented on GitHub (Oct 6, 2025):

AI_APICallError: prompt token count of 165969 exceeds the limit of 128000

Used GPT-4.1 via GitHub Copilot provider, that suppose to have 1,047,576 window. Is it problem on opencode side or GitHub has limited model configuration?

@Kirow commented on GitHub (Oct 6, 2025): > AI_APICallError: prompt token count of 165969 exceeds the limit of 128000 Used GPT-4.1 via GitHub Copilot provider, that suppose to have 1,047,576 window. Is it problem on opencode side or GitHub has limited model configuration?

yindo commented

@rekram1-node commented on GitHub (Oct 6, 2025):

@Kirow github limits the context window a LOT they limit to 128,000k

@rekram1-node commented on GitHub (Oct 6, 2025): @Kirow github limits the context window a LOT they limit to `128,000k`

yindo commented

@nuson999 commented on GitHub (Oct 8, 2025):

@rekram1-node Opencode was able to compact automatically to prevent it, but in recent release 0.14.6, it seems broken.

@nuson999 commented on GitHub (Oct 8, 2025): @rekram1-node Opencode was able to compact automatically to prevent it, but in recent release 0.14.6, it seems broken.

yindo commented

@dan-kirberger commented on GitHub (Nov 24, 2025):

wonder if the truncation logic needs some work, I think it might just do line counts which would fail for minified js

I bet that's the issue for me! In another thread you mentioned using the opencode export command (instead of /export) and it was clear from the output there that a single mega-long line of output from the LSP tool was causing an issue.

For me, the jdtls Java LSP is compiling/checking my repo and flagging a ton of info and warn level notices that aren't relevant, instantly clogging the context i bet. It would seem this is returning an enormous amount of output.

in our case, our app uses "lombok" but the language server can't detect/use it automatically so we get clogged.

my team's solution might just be to clobber and overwrite the entire jdtls config block

@dan-kirberger commented on GitHub (Nov 24, 2025): > wonder if the truncation logic needs some work, I think it might just do line counts which would fail for minified js I bet that's the issue for me! In another thread you mentioned using the `opencode export` command (instead of /export) and it was clear from the output there that a single mega-long line of output from the LSP tool was causing an issue. For me, the jdtls Java LSP is compiling/checking my repo and flagging a ton of info and warn level notices that aren't relevant, instantly clogging the context i bet. It would seem[ this](https://github.com/sst/opencode/blob/dev/packages/opencode/src/tool/write.ts#L86) is returning an enormous amount of output. in our case, our app uses "lombok" but the language server can't detect/use it automatically so we get clogged. my team's solution might just be to clobber and overwrite the entire `jdtls` config block

yindo commented

@shantur commented on GitHub (Nov 24, 2025):

@rekram1-node - I have just seen this today and I think I know what happened.

grep tool seems to only limit with number of lines. One of the file in the codebase was a compiled / obfuscated javascript file with almost everything in 1 line, that kept taking more than 70K tokens in my case and api call was going over token limit.

Maybe need to review the token / output limitation of the tools

@shantur commented on GitHub (Nov 24, 2025): @rekram1-node - I have just seen this today and I think I know what happened. grep tool seems to only limit with number of lines. One of the file in the codebase was a compiled / obfuscated javascript file with almost everything in 1 line, that kept taking more than 70K tokens in my case and api call was going over token limit. Maybe need to review the token / output limitation of the tools

yindo commented

@rekram1-node commented on GitHub (Nov 25, 2025):

Yeah that's prolly accurate

@rekram1-node commented on GitHub (Nov 25, 2025): Yeah that's prolly accurate

yindo commented

@dan-kirberger commented on GitHub (Nov 26, 2025):

Would something like this help: https://github.com/dan-kirberger/opencode/compare/4e83107d799ca01f0364d23aa9e5c2a43ae1b641...e695d5f - maybe as a general config that could be leveraged in all tools?

maybe something configured generically in config?

@dan-kirberger commented on GitHub (Nov 26, 2025): Would something like this help: https://github.com/dan-kirberger/opencode/compare/4e83107d799ca01f0364d23aa9e5c2a43ae1b641...e695d5f - maybe as a general config that could be leveraged in all tools? maybe something configured generically in config?

yindo commented

@hosseinalipour commented on GitHub (Dec 22, 2025):

Exact same error for big-pickle twice today.

@hosseinalipour commented on GitHub (Dec 22, 2025): Exact same error for big-pickle twice today.

yindo commented

@berenar commented on GitHub (Dec 24, 2025):

I faced this issue today with this prompt:

which ai agents support  .aiignore ?

and the model github-copilot/claude-opus-4.5

As you see, compacting doesn't help.

Let me research the .aiignore question:
% WebFetch https://docs.anthropic.com/en/docs/claude-code/memory
% WebFetch https://docs.cursor.com/context/ignore-files
% WebFetch https://opencode.ai/docs/config
% WebFetch https://docs.anthropic.com/en/docs/claude-code/settings
% WebFetch https://docs.anthropic.com/en/docs/claude-code
% WebFetch https://www.cursor.com/features

Let me check for more specific info on .cursorignore:
% WebFetch https://docs.cursor.com/context/ignore-files
% WebFetch https://cursor.com/docs/context/ignore-files

Now let me check OpenCode's documentation for MCP servers:
% WebFetch https://opencode.ai/docs/mcp-servers

Now let me look up Sentry, Playwright, and GitHub MCP servers:
% WebFetch https://github.com/getsentry/sentry-mcp
% WebFetch https://github.com/microsoft/playwright-mcp
% WebFetch https://github.com/modelcontextprotocol/servers

prompt token count of 227815 exceeds the limit of 128000

retry
Bernat

prompt token count of 227820 exceeds the limit of 128000

prompt token count of 223535 exceeds the limit of 128000
▣  Compaction · claude-opus-4.5

@berenar commented on GitHub (Dec 24, 2025): I faced this issue today with this prompt: ``` which ai agents support .aiignore ? ``` and the model `github-copilot/claude-opus-4.5` As you see, compacting doesn't help. ``` Let me research the .aiignore question: % WebFetch https://docs.anthropic.com/en/docs/claude-code/memory % WebFetch https://docs.cursor.com/context/ignore-files % WebFetch https://opencode.ai/docs/config % WebFetch https://docs.anthropic.com/en/docs/claude-code/settings % WebFetch https://docs.anthropic.com/en/docs/claude-code % WebFetch https://www.cursor.com/features Let me check for more specific info on .cursorignore: % WebFetch https://docs.cursor.com/context/ignore-files % WebFetch https://cursor.com/docs/context/ignore-files Now let me check OpenCode's documentation for MCP servers: % WebFetch https://opencode.ai/docs/mcp-servers Now let me look up Sentry, Playwright, and GitHub MCP servers: % WebFetch https://github.com/getsentry/sentry-mcp % WebFetch https://github.com/microsoft/playwright-mcp % WebFetch https://github.com/modelcontextprotocol/servers prompt token count of 227815 exceeds the limit of 128000 retry Bernat prompt token count of 227820 exceeds the limit of 128000 prompt token count of 223535 exceeds the limit of 128000 ▣ Compaction · claude-opus-4.5 ```

yindo commented

@dan-kirberger commented on GitHub (Dec 24, 2025):

probably similar to this: https://github.com/sst/opencode/issues/5259 - the "WebFetch" tool may need some restrictions on length

@dan-kirberger commented on GitHub (Dec 24, 2025): probably similar to this: https://github.com/sst/opencode/issues/5259 - the "WebFetch" tool may need some restrictions on length

yindo commented

@rekram1-node commented on GitHub (Dec 31, 2025):

closing in favor of another, fixing soon

@rekram1-node commented on GitHub (Dec 31, 2025): closing in favor of another, fixing soon

yindo commented

@Suoliy commented on GitHub (Jan 22, 2026):

closing in favor of another, fixing soon

This problem has still not been fixed, and I am encountering it now using Opus 4.5.

@Suoliy commented on GitHub (Jan 22, 2026): > closing in favor of another, fixing soon This problem has still not been fixed, and I am encountering it now using Opus 4.5. <img width="911" height="133" alt="Image" src="https://github.com/user-attachments/assets/d5e4c1d2-08c9-43a8-8eda-0de44da53e57" />

yindo commented

@ivmos commented on GitHub (Jan 27, 2026):

This still happens, reproduced with OpenCode 1.1.36 and Copilot/Sonnet 4.5

@ivmos commented on GitHub (Jan 27, 2026): This still happens, reproduced with OpenCode 1.1.36 and Copilot/Sonnet 4.5 <img width="507" height="74" alt="Image" src="https://github.com/user-attachments/assets/184445c0-dc2e-402b-bf80-ff806cd0a289" />

yindo commented

@joelaforet commented on GitHub (Jan 29, 2026):

I encountered this as well using OpenCode 1.1.42 and Copilot/Opus 4.5. I tried switching to Sonnet 4.5 (in screenshot) but that didn't fix the issue.

@joelaforet commented on GitHub (Jan 29, 2026): I encountered this as well using OpenCode 1.1.42 and Copilot/Opus 4.5. I tried switching to Sonnet 4.5 (in screenshot) but that didn't fix the issue. <img width="1050" height="722" alt="Image" src="https://github.com/user-attachments/assets/1fb63f46-f89d-4beb-a237-7953d6b2262b" />

yindo commented

@joelaforet commented on GitHub (Jan 29, 2026):

I believe I generated this issue by pasting in too large of text into a prompt. Forking the session before that message got sent seems to work fine now!

@joelaforet commented on GitHub (Jan 29, 2026): I believe I generated this issue by pasting in too large of text into a prompt. Forking the session before that message got sent seems to work fine now!

yindo commented

@avenda commented on GitHub (Jan 30, 2026):

Same here:

with the latest version 1.1.44 and with custom models lke MiniMax, GLM and Claude model too.

@avenda commented on GitHub (Jan 30, 2026): Same here: <img width="656" height="166" alt="Image" src="https://github.com/user-attachments/assets/74cbb938-968d-49db-9e85-4a9ce4608e94" /> with the latest version 1.1.44 and with custom models lke MiniMax, GLM and Claude model too.

yindo commented

@laruss commented on GitHub (Feb 1, 2026):

Always happens when agent tries to watch images + sometimes when taking snapshot of the page. Sooo annoying...

@laruss commented on GitHub (Feb 1, 2026): Always happens when agent tries to watch images + sometimes when taking snapshot of the page. Sooo annoying...

yindo commented

@ShahNewazKhan commented on GitHub (Feb 3, 2026):

I believe I generated this issue by pasting in too large of text into a prompt. Forking the session before that message got sent seems to work fine now!

Confirmed, I got into this state also by pasting a huge PDF into the prompt, forking the session from before that message got sent worked to recover that session, thanks for this insight!

@ShahNewazKhan commented on GitHub (Feb 3, 2026): > I believe I generated this issue by pasting in too large of text into a prompt. Forking the session before that message got sent seems to work fine now! Confirmed, I got into this state also by pasting a huge PDF into the prompt, forking the session from before that message got sent worked to recover that session, thanks for this insight!

yindo commented

@cuipengfei commented on GitHub (Feb 4, 2026):

This is a known limitation in GitHub Copilot's API. I've gathered data confirming:

max_prompt_tokens is capped at 128K for most models
Even though context_window is 400K, you can't use it all for input

Full analysis with API data: https://github.com/orgs/community/discussions/186340

@cuipengfei commented on GitHub (Feb 4, 2026): This is a known limitation in GitHub Copilot's API. I've gathered data confirming: - `max_prompt_tokens` is capped at 128K for most models - Even though `context_window` is 400K, you can't use it all for input Full analysis with API data: https://github.com/orgs/community/discussions/186340

yindo commented

@Z0org commented on GitHub (Feb 4, 2026):

Is there any solution? Happens to me a lot using Kimi K2.5 with OpenCode 1.1.40. I think for me it mostly happens when Kimi tries to read images. /compact also does not work for me because I directly get the error again.

@Z0org commented on GitHub (Feb 4, 2026): Is there any solution? Happens to me a lot using Kimi K2.5 with OpenCode 1.1.40. I think for me it mostly happens when Kimi tries to read images. /compact also does not work for me because I directly get the error again.

yindo commented