Kubota Channel Context Pressure
A full visible-history and local-runtime audit of #kubota_forgebot. The channel is not broadly “losing its mind.” Two unusually large build threads crossed the danger line; one produced visible quality warnings.
What actually happened
Verdict
Compression is not the primary source of bad work. It is a trailing indicator that one thread has become an entire project room.
- Short, single-purpose threads completed cleanly.
- The pressure events occurred in the two most iterative implementation threads.
- The visible errors were scope and QA failures before they were memory failures.
Largest context contributors
3D Modeling alone used 52 visual-analysis calls, 32 browser navigations, 39 browser-console reads, and 267 tool calls in its continued session.
Media was the spark, not the payload
The 3D thread contained six attached images totaling 4.99 MB. Those pixels did not become 4.99 MB of text context. The blowout came from repeated image descriptions, Slack metadata, browser snapshots, code reads, build logs, and QA loops around them.
Specific channel evidence
| Thread | Observed pressure | Quality signal | Assessment |
|---|---|---|---|
| Environment | One automatic compression at ~261k tokens; 290 → 140 messages; later 150/150 iteration budget exhausted. | Initial puddle toggle changed rocks more than puddles and landed on a duplicate simulator URL. | HIGH PRESSURE The correction was driven by weak visual QA and duplicate implementation scope. Compression increased risk but did not clearly cause the mistake. |
| 3D Modeling | Two successful compressions, two aborted notices, two duplicate “accuracy may degrade” warnings; peak preflight ~339k tokens. | Barn first went into the wrong scene; later proof screenshot was gray/clipped. | REAL DEGRADATION RISK This thread mixed asset extraction, model cleanup, ForgeMedia publishing, scene integration, a showcase page, videos, deployment, and repeated visual QA. |
| Tractor Model | Large but bounded: 219 stored messages, 139 tool calls, heavy skill/build output, no observed compression warning. | Completed with visual proof and a stable deliverable. | MANAGEABLE Still over-broad, but it stayed focused on one asset and one production route. |
| QA | Short thread; one screenshot and one UX roast. | No reset or compression signal. | HEALTHY This is the ideal thread shape: bounded evidence, bounded analysis, concise answer. |
Best operating practice
One deliverable per thread
Split “make a barn model,” “publish a ForgeMedia showcase,” and “integrate the barn into the simulator” into separate roots. Cross-link them; do not make one session carry all three.
Checkpoint before the second major pivot
Post a five-line handoff: objective, verified state, artifact links, unresolved defect, next action. Then begin a new root thread. This preserves accuracy better than compressing an already tangled task.
Use bounded tool output
Read exact file ranges, cap search results, suppress routine build chatter, and avoid reloading 67–75k-character skills in the same run when they are already present.
Use one visual evidence packet
Collect before/after/final screenshots once. Use a contact sheet with labels. Keep full-size assets in ForgeMedia instead of repeatedly attaching or re-analyzing them.
Reset on behavior, not message count
Start a fresh root when scope changes, a warning says accuracy may degrade, the same mistake recurs, or a second compression is needed. A long but coherent thread can remain healthy.
Commands: what works now
/context and /context all inspect usage without an LLM call or cache impact.
/compress here 2 is the current manual form and preserves the last two exchanges, but Slack thread targeting is not verified in this setup.
/new creates a fresh session, but the channel already documents that thread-local reset syntax conflicts with strict mention routing.