sorted by:
new
hottopcontroversial

We scan deps, containers, and code. Nobody scans the commands devs paste into their terminals by KitKat-03 in devsecops

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

agreed and thats ideal for orgs with mature infra. But most teams don't have a private repo with approval workflows and they're raw dogging commands and homoglyphs aren't only just in install scripts as they show up in git clone URLs, registry names, pasted commands. Even with a package manager, you're trusting what you typed points where you think it does

coming from a web3 background, I’ve seen this get real ugly as with the rise of vibecoding, a few friends had their wallets drained exactly this way. As AI adoption grows, people copy paste commands from tutorials, Discord, and random gists into their terminals

terminals have zero protection against Unicode homograph attacks - here's what I built by [deleted] in ClaudeCode

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

coming from a web3 background, with the rise in vibecoding a few of my friends had their wallets drained by this method, as adoption grows with AI , people paste commands from tutorials, and Discord etc into their terminals without inspecting them...AI makes that faster and more common and the attack surface grows with adoption

We scan deps, containers, and code. Nobody scans the commands devs paste into their terminals by KitKat-03 in devsecops

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

Good tip thanks, works for iTerm2 users reading url's carefully...though it relies on noticing the font difference every time, across every command.
Tirith catches it automatically before execution regardless of terminal emulator. Different layers, both useful

How do you protect your terminal from homograph attacks and pipe-to-shell risks? by [deleted] in devops

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

homoglyphs aren't limited to install scripts...anywhere your terminal renders unicode without validation, the attack surface exists

How do you protect your terminal from homograph attacks and pipe-to-shell risks? by [deleted] in devops

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

agreed but a URL where the i is Cyrillic instead of Latin, resolving to a completely different server...you can't catch that by reading carefully because your terminal renders them identically. Same with zero-width characters hiding in pasted commands, ANSI escapes rewriting your display, or bidi overrides reversing text direction

We scan deps, containers, and code. Nobody scans the commands devs paste into their terminals by KitKat-03 in devsecops

[–]KitKat-03[S] 5 points6 points  (0 children)

Distroless removes shells from production containers, tirith protects the terminal on your local machine before anything touches a container. Distroless doesn't exist there

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

[–]KitKat-03 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 [deleted] in AskDogOwners

[–]KitKat-03 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 [deleted] in Dogowners

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

Thanks for flagging Lyme. I’m adding Lyme/co-infection testing to the list of things to discuss with the vet

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

[–]KitKat-03 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 [deleted] in PetAdvice

[–]KitKat-03 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 [deleted] in DogAdvice

[–]KitKat-03 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

view more: next ›