A long chat re-sends its history every turn, and caching only covers the unchanged prefix
Long chat sessions incur costs not from the current message, but from re-sending the entire conversation history with each turn. For instance, a two-line reply on turn 40 includes the previous 39 turns, making the bill reflect the full thread despite the on-screen appearance. A larger context window doesn't solve this; it merely encourages longer threads, increasing costs. The suggested solution is to start new sessions when tasks change, retaining old ones only for the same task, balancing cost with workflow friction.
Time & source
Times shown in UTC
Display time zone: UTC
Local time zone unavailable; showing UTC.
PublishedOffset at this time: UTC+0Oct 10, 2026, 00:44 UTC
IngestedOffset at this time: UTC+0Oct 10, 2026, 04:00 UTC
- Published
- Oct 10, 2026, 00:44
- Ingested
- Oct 10, 2026, 04:00
- Source type
- Dev community
- Tier
- Community
- Source status
- Healthy
Tier is a per-source editorial setting, not a per-item score.
Discussion trend
The percentage is based on collected discussion signal, not new comments or independent people. The curve only compares the same topic across time.
The cost of a long session isn't in the message you just typed. It's in everything before it going back through the model again. A two-line reply on turn 40 carries the previous 39 turns with it. On screen the session looks light. The bill reflects the whole thread.
Prompt caching softens this, but only while the prefix stays byte-identical. Edit an earlier message, or let the framing drift even slightly, and everything after the edit point is a cache miss. You pay full price for history you already paid for once. This is the part that produces the mismatch people describe: a session that felt cheap on screen and came back with a number that doesn't match the work they think they did.
A bigger context window doesn't fix this. It makes staying in the same thread more comfortable, which extends the thread, which is the direction the bill doesn't want. The fix is unglamorous: start a new session when the task changes, and keep the old one only while it's still the same task. Whether that's worth the friction depends on how often your threads actually change direction mid-session, and I'm not sure that ratio is the same for everyone.