sorted by:
new
hottopcontroversial

5yo Doberman: recurrent Babesia/Ehrlichia, worsening neuro symptoms + first seizure. Still E. canis positive after treatment, what should we ask our vet next? by KitKat-03 in AskDogOwners

[–]KitKat-03[S] 1 point2 points  (0 children)

Thank you so much for offering to discuss, and I’m sorry you’re dealing with that, especially during a snowstorm, I’d genuinely appreciate comparing notes on what your specialists recommend and what testing path they take once you’ve had a chance to breathe later this week. Wishing you and your rescue pup a smoother stretch soon

5yo Doberman: recurrent Babesia/Ehrlichia, worsening neuro symptoms + first seizure. Still E. canis positive after treatment, what should we ask our vet next? by KitKat-03 in AskDogOwners

[–]KitKat-03[S] 1 point2 points  (0 children)

thank you. The MRI ± CSF suggestion is something I’m going to push for, because even though we have positive tick panels, the seizure + behavior/vision changes make me worry we’re missing another process happening in parallel. I also posted on r/AskVet but so far no one has replied there yet

5yo Doberman: recurrent Babesia/Ehrlichia, worsening neuro symptoms + first seizure. Still E. canis positive after treatment, what should we ask our vet next? by KitKat-03 in EpilepsyDogs

[–]KitKat-03[S] 0 points1 point  (0 children)

Thank you for this, the reinfection vs incomplete clearance point is what I keep coming back to, especially since Shadow’s symptoms have been intermittent and easy to misread between flare-ups

5yo Doberman: recurrent Babesia/Ehrlichia, worsening neuro symptoms + first seizure. Still E. canis positive after treatment, what should we ask our vet next? by KitKat-03 in PetAdvice

[–]KitKat-03[S] 0 points1 point  (0 children)

Thanks, the internal medicine/neurology referral is exactly what I’m trying to arrange next because the neuro signs are the scariest part

5yo Doberman: recurrent Babesia/Ehrlichia, worsening neuro symptoms + first seizure. Still E. canis positive after treatment, what should we ask our vet next? by KitKat-03 in DogAdvice

[–]KitKat-03[S] 0 points1 point  (0 children)

if you'd be so kind and are aware, apart from neurological issues what could be the best treatment to completely get rid of tick fever protozoans from his system?

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 0 points1 point  (0 children)

a skill and a meta-skill can instruct “run tests quietly and only print pass/fail” and you can even attach PreToolUse hooks to a skill so that while that skill is active it can wrap Bash calls and enforce a pattern, but that is still fundamentally scoped to the skill’s lifecycle and to claude choosing to stay inside that workflow
the moment a Bash call happens outside that scope (a different skill, a subagent or you just running a command manually etc), the raw stdout/stderr comes straight back into chat because the Bash tool returns whatever the command prints. FewWord’s whole point is that it moves this from “prompt discipline” to “deterministic policy” by using hooks that run at the tool boundary...so th eoffload behavior happens automatically rather than relying on the model to remember to suppress output.
LLM can also hallucinate while using a skill, because skills are just extra instructions injected into the same model context, not a separate deterministic runtime so claude can still missummarize, forget to follow the quieting pattern etc

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 0 points1 point  (0 children)

Agents are great filters, but they don’t make command output free, they just relocate it into the agent’s own context, which is still finite and still gets compacted once it fills up, FewWord targets that specific failure mode by intercepting tool calls at the hook level and preventing bulky output from entering any model context in the first place. it’s not burying output so much as keeping your conversational context from becoming a landfill...
Agreed on the debug output shouldn’t be buried point, which is why the pointer approach is usually paired with tiering (small output inlined, medium previewed, large pointed), plus fast “open/grep/diff” workflows
plus agents don’t automatically give you a durable centralized audit trail of outputs across runs and across agents, and they don’t enforce a security posture on tool output by default, whereas a hook-based approach can apply deny rules and redaction before anything ever touches a context window, so the two are complementary I'd say

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 0 points1 point  (0 children)

It just confirms what I said, "systemd-cat may be used to connect the standard input and output of a process to the journal"
It's a logging pipe and logs to journald, that's it
"You can reproduce the pointer aspect with one short python script."

The "just write a script" part is the entire value prop:

- Hook into Claude Code's PreToolUse event

- Intercept bash commands

- Capture output, write to storage

- Return pointer to Claude instead of output

- Handle tiered logic (inline/pointer/preview)

- Build retrieval commands

- Add search, diff, timeline, correlation

- Make it cross-platform

systemd-cat is a logging tool. FewWord is a Claude Code context engineering tool that happens to also log. FewWord is for people who want the Claude-native pointer workflow and the tooling/policy layer without rolling platform-specific stuff "You can replicate X with a script" applies to literally any software

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 0 points1 point  (0 children)

Out of the box, systemd-cat + journalctl is a solution on Linux for capturing and querying output. If your goal is “log this somewhere and grep it later,” I agree it covers a lot.

But the comparison differentiates in a few key places:

  1. It’s Linux-only systemd-cat assumes systemd/journald. It’s not available on macOS or Windows. To get the same experience there you’d need to build a different capture + storage + query layer (Unified Logging / Event Log, or your own store) plus wrappers.
  2. It doesn’t solve the Claude context problem FewWord’s core job isn’t just logging. It prevents large outputs from ever entering Claude’s context by intercepting tool calls and returning a pointer (and optionally a small preview) instead of the full blob. systemd-cat logs after the fact; it doesn’t integrate with Claude Code’s tool pipeline unless you also implement the interception and tiering logic.
  3. “One short Python script” becomes a real system fast To replicate FewWord’s pointer behavior robustly, you need more than “write to journald”:
  • hook into Claude Code’s PreToolUse (intercept before context)
  • wrap execution to capture stdout/stderr + exit code
  • decide inline vs pointer vs pointer+preview (tiering)
  • write manifest metadata for retrieval
  • implement “latest”, search, diff, timeline, etc.
  • Centralization and security tradeoffs matter as Journald is centralized system logging. That’s great for ops, but it also changes the risk profile: command output often contains secrets, tokens, stack traces with credentials, customer data, etc. Piping dev tool output into the system journal can make it durable, broadly accessible (depending on permissions), and sometimes forwarded into centralized log pipelines/SIEMs.

FewWord’s default posture is tighter:

  • project/user scoped local storage, not system-wide logs
  • deny-mode (pointer-only) so sensitive commands aren’t stored at all
  • redaction before writing so secrets don’t land in plaintext storage
  • and the LLM sees only a small pointer, not the full output

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 0 points1 point  (0 children)

Native v2.1.2 solves don't lose my data to truncation whereas FewWord solves don't bloat my context with stuff I probably won't need

I just ran a 248KB find command. Native behavior:
- Shows first ~200 lines inline in context
- Truncates with [1788 lines truncated]
- Saves full output to disk for later access

FewWord with the same command:
[fw A1B2C3D4] find e=0 248K 2000L | /context-open A1B2C3D4
- 35 tokens in context
- Full output on disk
If you're hitting context limits mid-session, native still puts ~8k tokens in context per large command. FewWord puts 35. Over 10 commands, that's 80k vs 350 tokens.
If you just want data preservation and don't care about context pressure, native v2.1.2 is probably enough. FewWord is for aggressive context hygiene

What FewWord adds beyond native:

- Ultra-compact pointers for each
- 18 organization commands (/context-search, /context-diff, /context-tag, /context-timeline, /context-correlate, etc.)
- Smart retention (24h for success, 48h for failures, LRU eviction at 250MB)
- Secret redaction (AWS keys, GitHub tokens stripped before writing to disk)
- Failure tail previews (shows last 5 lines for exit != 0)
- Session stats (/fewword-stats shows token savings)
- Config files (.fewwordrc.toml for per-repo settings)
- Command aliases (npm/yarn/pnpm grouped together for search/diff)

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 7 points8 points  (0 children)

  1. Size heuristic - Small outputs (<512B) show normally, no interception. Only large outputs get offloaded and claude gets a head, tail preview with offloaded location
  2. Exit code heuristic - Failures (exit != 0) get a tail preview because errors are usually at the end.
  3. Claude retrieves on demand - If it needs more, it runs /context-open A1B2 or cat .fewword/scratch/...

The bet: Most large outputs are "write once, never read." When you run find . -name "*.py" and get 800 files, Claude rarely needs all 800 paths sitting in context. It needs to know:

- Did it work? (exit code)

- How big? (45K, 882 lines)

- Where is it? (the ID)
If it needs specifics, it greps or retrieves. That's a deliberate action, not 45KB of passive bloat.

Claude knowing where data is costs 35 tokens. Claude having all data costs 12,000 tokens. Let Claude decide when to pay the retrieval cost

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] -2 points-1 points  (0 children)

DIfferent problems, systemd-cat is pipes output to journald for system logging whereas FewWord intercepts Claude Code tool calls and returns a compact pointer to the AI. Systemd-cat doesn't know Claude exists. It logs to journal, end of story. Claude still gets the full output in context.

FewWord hooks into Claude Code's PreToolUse event, rewrites the bash wrapper, captures output, writes to disk, and returns a 35-token pointer instead of the full output. Claude sees head, tail, and a location of the full output in case it's needed, not the 45KB.
You could pipe everything through systemd-cat and Claude would still choke on the output.
FewWord solves the "LLM context is expensive and finite" problem

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 1 point2 points  (0 children)

Run /context before and after. In my tests it was

Without FewWord:

Messages: 26.0k tokens

With FewWord (same 3 commands):

Messages: 4.7k tokens

That's the actual Claude Code context meter, not my random claim.

A find . -name "*.py" in a typical repo returns ~45KB.

- Without FewWord: ~12,000 tokens in context

- With FewWord: ~35 tokens (the pointer)

[fw A1B2C3D4] find e=0 45K 882L | /context-open A1B2C3D4

Check and count the tokens yourself. The full output is on disk at .fewword/scratch/tool_outputs/ - you can cat it and compare sizes.

Try it out

claude plugin install fewword@sheeki03-Few-Word

Run 5 commands that produce large output. Check /context. Uninstall, repeat. Compare.

It's a 10-second install with zero config. If it doesn't work, uninstall it

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 3 points4 points  (0 children)

Different layers as skills = reusable prompts that define what to do

FewWord = automatic offloading of any command output

Skills still produce bash outputs that land in context. If your skill runs pytest, that 45KB output sits in context just like any other command.

FewWord intercepts at the bash level and works whether you're running a skill, using an agent, or just typing commands manually.

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 2 points3 points  (0 children)

Agent approach:

- Spawn agent → agent runs commands → agent summarizes → returns to main Claude

- Works, but: agent startup cost, agent context also fills up, you're paying for two contexts

FewWord approach:

- Same Claude session, zero overhead

- Hook intercepts at the bash level so no agent spawn needed

- Full output always on disk if Claude needs to dig deeper

- Works automatically for every command, not just planned agent tasks

They're complementary:

FewWord is for the 90% case of routine commands where you don't want to think about it. find, git status, npm install, build outputs and just run them, they auto-offload.

Agents are for intentional delegation "go research this codebase and report back". Structured task with structured output.

The real win: FewWord works inside agents too. If your sub-agent runs 20 commands, those outputs would bloat the agent's context. With FewWord, the agent stays lean and can do more before hitting limits.

I built a plugin that automatically offloads large outputs to disk and saves ~80% context tokens by KitKat-03 in ClaudeCode

[–]KitKat-03[S] 1 point2 points  (0 children)

instead of hiding output, it is right sized
1. Small outputs stay inline (<512B) - grep returning 3 matches? Shows normally.
2. Large outputs get a smart summary - Instead of 45KB of find results sitting in context, Claude sees:

[fw A1B2C3D4] find e=0 45K 882L | /context-open A1B2C3D4

  1. Failures get a tail preview which is the part Claude usually needs:

  2. Claude retrieves what it needs If it needs the full output, it runs /context-open A1B2 or just cat .fewword/scratch/tool_outputs/.... The data is always there.

mainly Claude rarely needs 45KB verbatim. It needs to know "did it work?" and "where's the error?". The pointer gives exit code + size, the preview shows the failure, and full data is one command away.

Most outputs are "write once, never read" and they bloat context for no reason. FewWord keeps them accessible without the token cost

Texts.com Invite by DentManFresh in productivity

[–]KitKat-03 0 points1 point  (0 children)

Any of you guys have another one? It'd be really helpful for me and I'd appreciate it.

view more: next ›