u/dull-zookeeper

Germany. 24-month DSL contract, currently in month 18. Six months ago I received a written notification that my monthly rate would increase by €4 starting the following billing cycle.

I only recently learned about § 56 TKG Abs. 4 (Sonderkündigungsrecht) — apparently this price increase should have given me a right to cancel immediately without penalty. But I didn't exercise it at the time because I didn't know about it.

My questions:

1. The law says the window is 3 months from receiving the price-change notification. Does that window run from when they notified me (6 months ago), or from when the price increase actually took effect?

2. Is there any argument that the window hasn't started yet, or is still running, given that the price increase is ongoing (I'm still being charged the higher rate)?

3. My contract ends naturally in 6 months anyway. Is there any value in trying to exercise the Sonderkündigungsrecht retroactively, or is it clearly time-barred?

The provider is a major national telco. I have the original notification email with the date. I'm not sure if the 3-month clock starts on the notification date or the effective date of the change.

Worth knowing, especially if you've been on the same contract for a while.

Since the 2021 reform of the Telekommunikationsgesetz (TKG), § 56 contains a rule that telcos really don't advertise:

If a provider increases your monthly price mid-contract, it triggers a Sonderkündigungsrecht. You have 3 months from when you received the price-change notification to cancel the contract with immediate effect — no fees, no penalty, even if you're in the middle of a 24-month term.

Telekom, O2, Vodafone, and most other providers now do annual price adjustments. Every one of those adjustments is a potential free exit from your contract.

What you need to do:

1. Find the email/letter where they announced the price change
2. Send a written Kündigung citing § 56 TKG Abs. 4 Sonderkündigungsrecht
3. Send it Einschreiben (certified mail) so you have proof of delivery — email cancellations get "lost" suspiciously often
4. The contract ends from the effective date of the price change, not from your normal contract end date

The 3-month window starts from the date on the notification, so check the dates carefully if you've been sitting on one.

This also applies to DSL/fiber contracts, not just mobile — § 56 covers all publicly available telephone and internet services.

Not legal advice, obviously, but this is the actual statutory text that applies. The § 56 reform was specifically intended to give consumers a real exit option when providers raise prices.

I ran into a subtle failure mode while building a RAG pipeline for legal documents. Sharing it because it can happen in any domain where documents have inconsistent structure.

The setup

Chunking pipeline: split on H2 headings first, then pass chunks through an LLM compressor (contextual compression) before retrieval. Standard stuff.

What broke

Three documents in my German legal corpus each had only one H2 heading — the entire document was a single section. The H2 splitter produced one chunk per document, ranging from 4,900 to 5,800 characters.

The compressor was configured with max_tokens=1024. When it hit an oversized chunk, it hit FinishReason.MAX_TOKENS. At that point response.parts was None, and my fallback code silently returned the first 800 characters of the raw chunk.

No exception. No log warning beyond DEBUG level. The pipeline just answered German rental law queries from the opening 800 characters of a 5,000-character document.

Evaluation score on German rental cases dropped to 0.596 out of 1.0.

The fix

Cascade splitting: H2 first → if any chunk exceeds 2,500 characters, split that chunk by H3 → if still over limit, split by blank-line paragraphs.

Also raised max_tokens 1024 → 4096 in the compressor as a second line of defense.

Result: DE namespace went from 145 chunks to 216 chunks, all under the limit. Evaluation score on the same cases: 0.839 (+40.9%).

Validation check worth adding

# After chunking, log any oversized chunks
for chunk in chunks:
    if len(chunk['text']) > MAX_CHUNK_CHARS:
        logger.warning(f"Oversized chunk: {chunk['source']} = {len(chunk['text'])} chars")

This would have caught the problem before it silently degraded production.

Why it's easy to miss

The evaluation score for the full test suite looked fine — the affected documents were a small fraction of the corpus. Only a targeted per-jurisdiction benchmark revealed the 0.596 score on German rental cases.

If you have documents with inconsistent structure (legal texts, technical manuals, some academic papers), worth adding a chunk size distribution check after ingestion.

---

Context: this is from a legal RAG system (AskEULaw — EU cross-border law) but the failure mode is domain-agnostic.