When developing via VC Code + Kilocode + Claude Code, every 5-10 requests I get a ‘timeout 60000’

[median mauve]

Hi, chat! For the past few days, I have been encountering a persistent error when sending requests.
My setup: Debian 12\Win 11 + VC Code+ Kilocode + Claude Code.

All components of the setup are up to date.

When developing via VC Code + Kilocode + Claude Code, every 5-10 requests I get a ‘timeout 60000’ error.

I tested my network but found no problems with ping, latency or packet loss.

Then I thought the problem was the size of the requests, but the problem persists even with primitive requests.

I am in the process of preparing a ticket for GitHub, but so far I have not been able to reproduce the problem consistently.

Perhaps someone has encountered something similar recently?

The error log looks like this:

Command timed out after 600000 milliseconds: claude -p --system-prompt-file "C:\Users\user\AppData\Local\Temp\kilocode-system-prompt-xxxxx.txt" --verbose --output-format stream-json --disallowedTools "Task,Bash,Glob,Grep,LS,exit_plan_mode,Read,Edit,MultiEdit,Write,NotebookRead,NotebookEdit,WebFetch,TodoRead,TodoWrite,WebSearch,ExitPlanMode,BashOutput,KillBash" --max-turns 1 --model "claude-sonnet-4-5-20250929[1m]" {"type":"system","subtype":"init","cwd":"c:\scrypt\claude status test","session_id":"xxxx","tools":["KillShell","Skill","SlashCommand"],"mcp_servers":[],"model":"claude-sonnet-4-5-20250929[1m]","permissionMode":"default","slash_commands":["compact","context","cost","init","pr-comments","release-notes","todos","review","security-review"],"apiKeySource":"none","claude_code_version":"2.0.31","output_style":"default","agents":["general-purpose","statusline-setup","Explore","Plan"],"skills":[],"plugins":[],"uuid":"xxxx"}"
I tried using Sonnet 4/4.5/Haiku 4.5. It did not help solve the problem.

I attempted to reset the kilocode settings to default. Afterwards, I made a basic prompt request. Result:
Command timed out after 600000 milliseconds: claude -p --system-prompt-file "C:\Users\user\AppData\Local\Temp\kilocode-system-prompt-ddg454f-83b8-4e37-b989-8717fac3dg49.txt" --verbose --output-format stream-json --disallowedTools "Task,Bash,Glob,Grep,LS,exit_plan_mode,Read,Edit,MultiEdit,Write,NotebookRead,NotebookEdit,WebFetch,TodoRead,TodoWrite,WebSearch,ExitPlanMode,BashOutput,KillBash" --max-turns 1 --model claude-sonnet-4-20250514

[cyan jolt]

tq

[frosty moss]

Thats a timeout, indicating claude code doesn't respond within 1 minute of making the request.

This isn't something that Kilo causes.

[median mauve]

Could you please advise me on how I could diagnose the problem?
I checked the availability of:
api.anthropic.com - Claude API endpoints
claude.ai - WebFetch safeguards
statsig.anthropic.com - Telemetry and metrics
sentry.io - Error reporting

(as specified in their documentation)
All of the above domains are accessible from my network.

There have been no significant changes to my setup. I have been working successfully with Kilo for the past three weeks.

[frosty moss]

This is Claude simply not responding in a timely fashion. There’s not much you can do here short of network sniffing.

[median mauve]

It's nice to hear that as a subscriber to Max 20. I pay $200 a month for this service. 💀

Thanks for your answers. I'll try to contact the Antropic team.

[frosty moss]

Yeah. IMO the Max 20 plan is not at all worth it. You can get much better results out of just spending $200/mo on API credits.

[median mauve]

Unfortunately, this is not entirely true in my case. Since the beginning of summer, I have been using public token consumption trackers for Claude Code. Thanks to generous limits, I spent $7,000 worth of tokens per month during the summer. Over the past 20 days, I have spent $2,000 worth of tokens per month working in a generous mode.

Perhaps the trackers have misled me, but I see the following cost figures for my situation through them.

[frosty moss]

Its more complex than that. When using claude-code integration in Kilo, there is effectively no use of the cache. As a result, the token counts are VASTLY inflated compared to the direct usage via API (where caching DOES work).

[median mauve]

I didn't know that, thank you for sharing. When I have some free time, I'll check the costs in my use case)

[frosty moss]

Cache hit rates for sonnet/haiku are often north of 85% 🙂

[median mauve]

wow!

looks attractive)

[cyan jolt]

i wish we exposed the hit rate % not just the totals, in the task accordion, to show off how good BYOK can be (and have a durable record of it)

[frosty moss]

Hit rate is shown in the extended context accordion

[cyan jolt]

Is there another accordion, I am not seeing? These are all the Task ones, is there something else I can click? (tried all the labels)

Do we just number sense the Tokens and Cache?

[frosty moss]

Oh you mean actual percent? No it doesn’t show that.

Would be easy to add tho

[median mauve]

I ran numerous tests to solve my problem.
An unexpected discovery was manually setting the maximum output tokens variable. The number of errors decreased to 1-2 per hour. I'm happy with that for now...

Maybe this will help in a similar situation.