Built a reusable rules system for Pi (and other coding agents)
▲ 0 r/AIcodingProfessionals+1 crossposts

Built a reusable rules system for Pi (and other coding agents)

One thing I kept running into with Pi was instruction management.

Every project slowly accumulates a huge AGENTS.md (or similar) full of rules that aren't always relevant to the task at hand.

You also end up copying the same instructions between repositories over and over.

So I built ai-rules.

The idea is simple: instead of maintaining one giant instruction file, you create small, reusable personal rules as Markdown files and only inject the ones that match each task.

Examples of rules you might capture:

- Go error handling

- Rust safety

- testing philosophy

- commit message conventions

- architecture preferences

- documentation standards

- personal coding habits

Then only the rules that actually matter for what you're asking Pi to do get compiled into a compact contract — not the whole rulebook every time.

In Pi (after setup):

/create-rule no fetch in React components

/airules Add UserCard data loading

From the terminal:

ai-rules run "Implement data loading in UserCard.tsx"

ai-rules doctor

Rules live in ~/.config/ai-rules/rules/. Local-first, plain Markdown + YAML frontmatter, versionable if you want.

Install:

npx u/therealsalzdevs/ai-rules setup

Early beta — Pi and OpenCode only right now (not Cursor / Claude Code / Codex).

Repo:

https://github.com/SalzDevs/ai-rules

I'd love feedback from people using Pi:

- How are you managing your AI instructions today?

- Do you keep everything in one AGENTS.md, or have you built another workflow?

- Does /create-rule + /airules feel better than repeating prefs each session?

u/No_Fix4730 — 7 days ago

I built a CLI that answers "can I run X on my Y" with real numbers

Tired of the recurring "Can I run Llama 70B on my 16GB MacBook?" threads?

I built a CLI that just answers the question.

Live data from Hugging Face. No recommendations. No AI hype. Just numbers.

Install

macOS / Linux

curl -fsSL https://raw.githubusercontent.com/SalzDevs/modelfit/main/install/install.sh | sh

Windows

irm https://raw.githubusercontent.com/SalzDevs/modelfit/main/install/install.ps1 | iex

Or grab a binary from the v1.0.0 release:

  • macOS (arm64, x86_64)
  • Linux (x86_64)
  • Windows (x86_64)

What it does

$ modelfit models

┌────────────────────────────┬────────┬─────────┬─────────┬─────────┬─────────┬─────────────────┬─────────┬─────────────────┬────────────┐
│ Model                      │ Params │ Q3_K_M  │ Q4_K_M  │ Q6_K    │ Q8_0    │ License         │ Context │ Fits @ Q4       │ Tok/s @ Q4 │
├────────────────────────────┼────────┼─────────┼─────────┼─────────┼─────────┼─────────────────┼─────────┼─────────────────┼────────────┤
│ Llama 3.1 8B Instruct      │ 8.0B   │ 3.7 GB  │ 4.6 GB  │ 6.1 GB  │ 8.0 GB  │ Llama Community │ 125K    │ 19% of 24.0 GB  │ ~12        │
│ Qwen 2.5 14B Instruct      │ 15B    │ 6.8 GB  │ 8.4 GB  │ 11.3 GB │ 14.6 GB │ Apache-2.0      │ 125K    │ 35% of 24.0 GB  │ ~6         │
│ Mixtral 8x7B Instruct      │ 47B    │ 19.0 GB │ 24.6 GB │ 35.7 GB │ 46.2 GB │ Apache-2.0      │ 31.2K   │ 103% of 24.0 GB │ ~2         │
│ Llama 3.1 70B Instruct     │ 71B    │ 31.9 GB │ 39.6 GB │ —       │ —       │ Llama Community │ 125K    │ 165% of 24.0 GB │ ~1         │
└────────────────────────────┴────────┴─────────┴─────────┴─────────┴─────────┴─────────────────┴─────────┴─────────────────┴────────────┘


$ modelfit details llama 8b

Llama 3.1 8B Instruct
  Family    llama · 8.0B · 125K context
  License   Llama Community
  Source    bartowski/Meta-Llama-3.1-8B-Instruct-GGUF (GGUF)
  Hardware  Apple M4 · ~120 GB/s bandwidth

┌──────────┬─────────┬───────┬────────────────┐
│ Quant    │ Size    │ Tok/s │ Fits @ 24.0 GB │
├──────────┼─────────┼───────┼────────────────┤
│ Q4_K_M   │ 4.6 GB  │ ~12   │ 19%            │
│ Q6_K     │ 6.1 GB  │ ~8    │ 26%            │
│ Q8_0     │ 8.0 GB  │ ~6    │ 34%            │
└──────────┴─────────┴───────┴────────────────┘

KV cache (fp16 estimate)

   4K context   +2.2 GB
  32K context  +18.0 GB
 128K context  +71.9 GB

What it doesn't do

  • It doesn't run models. It's a planning tool, not a runtime.
  • It doesn't tell you the "best model for your hardware." Numbers only — you decide.
  • It doesn't phone home. The only network call is to fetch model sizes from Hugging Face (24h cache, --offline to use cache, --refresh to force refresh).

The tok/s column is an estimate

Uses Karpathy's memory-bandwidth-bound formula:

tok/s ≈ bandwidth / (2 × model_size)

Everything is prefixed with ~ because real throughput depends on prompt evaluation, KV quantization, batch size, and a dozen other factors.

Hardware supported

macOS

  • Apple Silicon M1–M4 (Base, Pro, Max, Ultra)

Linux & Windows

  • NVIDIA H100, A100, V100
  • RTX 20, 30, 40, and 50 series

Linux

  • AMD Radeon RX 6400 → 7900 XTX (RDNA 1–4)
  • Intel Arc A310 → A770 (Alchemist)
  • Intel Arc B380 → B580 (Battlemage)

iGPUs are intentionally excluded from the tok/s calculations because the memory-bandwidth model doesn't apply cleanly to shared-memory systems.

Open source — MIT or Apache-2.0, your choice.

Repo: https://github.com/SalzDevs/modelfit

Honest feedback wanted:

  • What model-sizing questions does this answer wrong?
  • What information is missing?
  • What would make it genuinely useful?
reddit.com
u/No_Fix4730 — 19 days ago
▲ 7 r/opencode+4 crossposts

I built Groxy, a Go library for building forward proxy servers — looking for API feedback before v1

Hey everyone,

I just released v0.3.0 of Groxy, a pre-v1 Go library for building forward proxy servers.

Repo: https://github.com/SalzDevs/groxy

Docs: https://pkg.go.dev/github.com/SalzDevs/groxy

It supports:

- HTTP forwarding

- HTTPS CONNECT tunneling

- request/response/CONNECT middleware

- blocking helpers

- header helpers

- request/response body transforms

- configurable timeouts/logging

- opt-in HTTPS inspection using a local CA

The main new feature in v0.3.0 is HTTPS inspection for selected hosts. When enabled, Groxy can generate per-host certificates signed by a local CA, then run normal middleware on inspected HTTPS traffic.

This is explicit opt-in and requires trusting the generated CA. It should only be used for traffic you own or are authorized to inspect.

Groxy is still pre-v1, so I’d really appreciate feedback on:

- the middleware API

- HTTPS inspection config

- docs/examples

- what should come before v1

Thanks!

u/No_Fix4730 — 9 days ago