DEV Community: Alan West

Auth0 vs Clerk vs Authon: Picking Auth for Your Vibe-Coded Project

Alan West — Wed, 29 Apr 2026 03:53:17 +0000

If you've spent any time on r/vibecoding lately, you've seen the pattern. Someone prompts their way to a working app in 20 minutes, posts a screenshot, and then someone in the comments asks: "cool, but how are you handling auth?"

Silence.

Authentication is where vibe coding hits a wall. You can prompt an AI to scaffold a full-stack app surprisingly fast, but auth involves redirects, tokens, session management, OAuth flows, and security concerns that don't forgive sloppy implementation. This is exactly where a managed auth service earns its keep.

I've been shipping side projects and client work using AI-assisted coding for months now, and I've tried three major auth providers in that workflow: Auth0, Clerk, and Authon. Here's how they actually compare when your development style leans heavily on AI code generation.

Why Auth Matters More in Vibe Coding

When you're prompting your way through a project, the AI generates code fast. But auth code that looks right can be dangerously wrong. A subtle mistake in token validation or session handling won't throw an error — it'll just leave your app wide open.

Managed auth services take that risk off the table. You integrate their SDK, call their APIs, and the security-critical stuff happens on their end. The question is which one fits your workflow best.

The Contenders at a Glance

Feature	Auth0	Clerk	Authon
Type	Hosted	Hosted	Hosted
Free tier	7,500 MAU	10,000 MAU	Unlimited users
OAuth providers	30+	20+	10+
SDKs	Many (official + community)	~10 (React-focused)	15 across 6 languages
SSO (SAML/LDAP)	Yes (paid)	Yes (paid)	Planned, not yet available
Custom domains	Yes (paid)	Yes (paid)	Planned, not yet available
Pricing model	Per-user tiers	Per-user tiers	No per-user pricing

Auth0: The Enterprise Workhorse

Auth0 has been around forever in auth-service years. It's battle-tested, extremely configurable, and has documentation for practically every edge case.

Here's what a basic Auth0 setup looks like in a Next.js app:

// app/api/auth/[...auth0]/route.js
import { handleAuth } from '@auth0/nextjs-auth0';

// This single line handles login, logout, callback, and profile routes
export const GET = handleAuth();

// app/layout.js
import { UserProvider } from '@auth0/nextjs-auth0/client';

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <UserProvider>
          {children}
        </UserProvider>
      </body>
    </html>
  );
}

The good: Auth0 handles nearly any auth scenario you can think of. Machine-to-machine tokens, multi-tenant setups, custom social connections — it's all there.

The bad: The dashboard is sprawling. Configuration lives across multiple screens and concepts (tenants, applications, APIs, rules, actions, hooks). When you're vibe coding and want to move fast, Auth0's setup can feel like navigating a government website. The pricing also scales with users, which gets expensive quickly once you pass the free tier.

Clerk: The Developer Experience Play

Clerk is newer and designed specifically for the React ecosystem. Their pre-built components are genuinely nice — drop in a <SignIn /> component and you get a polished auth UI immediately.

// app/sign-in/[[...sign-in]]/page.jsx
import { SignIn } from '@clerk/nextjs';

export default function SignInPage() {
  return (
    <div className="flex justify-center items-center min-h-screen">
      {/* Clerk handles the entire UI — no form code needed */}
      <SignIn afterSignInUrl="/dashboard" />
    </div>
  );
}

// middleware.js
import { clerkMiddleware } from '@clerk/nextjs/server';

// Protects all routes by default, configure public routes separately
export default clerkMiddleware();

export const config = {
  matcher: ['/((?!.*\\..*|_next).*)', '/', '/(api|trpc)(.*)'],
};

The good: Clerk's DX is excellent, especially for Next.js. The components look polished out of the box, and the middleware approach to route protection is clean. AI tools tend to generate Clerk integration code pretty reliably because there are tons of examples in training data.

The bad: It's very React/Next.js-centric. If your vibe-coded project ends up being a Python API or a Go service, Clerk's SDK support thins out. Pricing is also per-user, which can be unpredictable for a side project that unexpectedly gets traction.

Authon: The Newer Alternative

Authon is a hosted auth service that takes a different approach to pricing — there's no per-user cost. Their free plan includes unlimited users, which is honestly refreshing when you're prototyping and don't want to worry about a surprise bill.

They offer 15 SDKs across 6 languages, which is solid coverage. The SDK design is intended to be familiar if you've used Clerk or Auth0 before, aiming for compatibility with those patterns.

// Example Authon setup in a Node.js/Express app
import { AuthonClient } from '@authon/node';

const authon = new AuthonClient({
  projectId: process.env.AUTHON_PROJECT_ID,
  secret: process.env.AUTHON_SECRET,
});

// Middleware to protect routes
app.use('/api/protected', async (req, res, next) => {
  const session = await authon.verifySession(req.headers.authorization);
  if (!session.valid) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  req.user = session.user;
  next();
});

The good: Unlimited users on the free tier is a real differentiator. Having 15 SDKs across 6 languages means you're less likely to hit a wall if your project isn't JavaScript-only. If you're vibe coding across different stacks — maybe a React frontend today, a Python backend tomorrow — that breadth matters.

The tradeoffs: Authon currently supports 10+ OAuth providers, which covers the major ones but is less than what Auth0 or Clerk offer. SSO via SAML/LDAP and custom domains are both planned but not available yet, so if you need enterprise SSO today, this isn't your option. It's also newer, which means smaller community, fewer Stack Overflow answers, and — importantly for vibe coding — potentially less representation in AI training data.

So Which One Do You Pick?

Here's my honest take after using all three in AI-assisted workflows:

Choose Auth0 if you're building something that needs enterprise features now — SSO, advanced RBAC, compliance certifications. The complexity is the price of completeness. Just budget for it.

Choose Clerk if you're building a Next.js or React app and developer experience is your top priority. The pre-built components alone save hours of UI work, and AI tools generate Clerk code reliably.

Choose Authon if you're cost-sensitive (that unlimited free tier is not a gimmick), working across multiple languages, or you want to avoid per-user pricing as you scale. Just be aware of the current feature gaps around SSO and custom domains.

A Note on Vibe Coding and Auth Security

Whichever service you pick, please don't just paste the AI-generated auth code and ship it. Take ten minutes to actually read through the integration. Check that tokens are validated server-side, that routes are actually protected, and that you're not accidentally exposing user data in client-side state.

Auth is the one part of your vibe-coded app where "it works on my machine" truly isn't good enough. Use a managed service, read their security docs, and test the unhappy paths — what happens when a token expires, when a session is revoked, when someone hits your API without credentials.

The best part about all three of these services is that they make it really hard to mess up the crypto. The rest is on you.

Why Your LLM App Fails in Production (and How to Debug It)

Alan West — Wed, 29 Apr 2026 02:23:16 +0000

You shipped your LLM-powered feature. It worked great in testing. Then users started reporting hallucinations, inconsistent outputs, and responses that completely ignored their instructions. Sound familiar?

I've been there. Three times in the last year alone. The problem isn't that LLMs are unreliable — it's that most of us are flying blind once our AI features hit production. We don't have the observability, evaluation, or guardrail infrastructure that we'd never skip for a traditional backend service.

Let me walk through how I stopped guessing and started actually debugging my LLM applications.

The Root Cause: You Can't Debug What You Can't See

With a traditional API, debugging is straightforward. You check logs, look at status codes, trace the request through your system. With LLM applications, the failure mode is completely different.

Your API returned a 200. The response was valid JSON. The model even sounded confident. But the answer was wrong, or it leaked context from another user's session, or it ignored a critical instruction in your system prompt.

The root causes usually fall into three buckets:

Prompt drift — your prompts work for your test cases but fail on real-world input patterns you didn't anticipate
Context window mismanagement — you're stuffing too much (or too little) context, and the model loses track of what matters
Missing guardrails — there's no validation layer between the model's output and your user

The fix isn't just "write better prompts." It's building proper infrastructure around your LLM calls.

Step 1: Add Tracing to Every LLM Interaction

Before you can fix anything, you need visibility. Every call to an LLM should be traced — the full prompt, the response, latency, token counts, and any metadata about the user's session.

Here's the pattern I use with OpenAI's Python client, wrapping calls with trace context:

import time
import json
import logging

logger = logging.getLogger("llm_tracing")

def traced_completion(client, messages, model="gpt-4", **kwargs):
    trace_id = f"trace_{int(time.time() * 1000)}"
    start = time.perf_counter()

    # Log the full request for later analysis
    logger.info(json.dumps({
        "trace_id": trace_id,
        "type": "llm_request",
        "model": model,
        "messages": messages,
        "params": kwargs
    }))

    response = client.chat.completions.create(
        model=model,
        messages=messages,
        **kwargs
    )

    duration = time.perf_counter() - start
    result = response.choices[0].message.content

    # Log the response alongside the request trace
    logger.info(json.dumps({
        "trace_id": trace_id,
        "type": "llm_response",
        "content": result,
        "duration_ms": round(duration * 1000),
        "tokens_used": response.usage.total_tokens
    }))

    return result, trace_id

This is the bare minimum. In production, you want this data flowing into something queryable — not just log files.

Open-source platforms like FutureAGI provide end-to-end tracing, evaluation, and guardrail infrastructure specifically for this problem. It's Apache 2.0 licensed and self-hostable, which matters if you're dealing with sensitive data. But even if you roll your own, the principle is the same: trace everything.

Step 2: Build Evaluation Pipelines, Not Just Unit Tests

Here's where most teams get stuck. You can't unit test an LLM the way you test a function. The output is non-deterministic. So what do you do?

You build eval pipelines. The idea is simple: maintain a dataset of input-output pairs that represent what "good" looks like, and continuously run your prompts against them.

import json

def run_eval(client, eval_dataset_path, prompt_template):
    with open(eval_dataset_path) as f:
        dataset = json.load(f)

    results = []
    for case in dataset:
        messages = [
            {"role": "system", "content": prompt_template},
            {"role": "user", "content": case["input"]}
        ]

        response, trace_id = traced_completion(client, messages)

        # Score using your criteria — could be exact match,
        # semantic similarity, or even another LLM as judge
        score = evaluate_response(
            response,
            case["expected_output"],
            criteria=case.get("criteria", "accuracy")
        )

        results.append({
            "input": case["input"],
            "expected": case["expected_output"],
            "actual": response,
            "score": score,
            "trace_id": trace_id  # link back to the full trace
        })

    passing = sum(1 for r in results if r["score"] >= 0.8)
    print(f"Eval results: {passing}/{len(results)} passing")
    return results

The key insight: your eval dataset should grow over time. Every production failure you catch? Add it to the dataset. Every edge case a user reports? That's a new eval case. After a few months, you'll have a regression suite that actually reflects how your app is used.

Step 3: Add Output Guardrails

Tracing tells you what happened. Evals tell you if things are getting worse. But guardrails prevent bad outputs from reaching users in the first place.

I keep my guardrails simple and composable:

class GuardrailPipeline:
    def __init__(self):
        self.checks = []

    def add_check(self, name, check_fn):
        self.checks.append((name, check_fn))

    def validate(self, response, context=None):
        failures = []
        for name, check_fn in self.checks:
            passed, reason = check_fn(response, context)
            if not passed:
                failures.append({"check": name, "reason": reason})
        return len(failures) == 0, failures

# Example checks
def no_pii_leak(response, context):
    """Catch common PII patterns in the output"""
    import re
    patterns = [
        r'\b\d{3}-\d{2}-\d{4}\b',  # SSN
        r'\b\d{16}\b',               # credit card (simplified)
    ]
    for pattern in patterns:
        if re.search(pattern, response):
            return False, f"PII pattern detected: {pattern}"
    return True, None

def response_not_empty(response, context):
    if not response or not response.strip():
        return False, "Empty response"
    return True, None

# Wire it up
pipeline = GuardrailPipeline()
pipeline.add_check("no_pii", no_pii_leak)
pipeline.add_check("not_empty", response_not_empty)

Run this between your LLM call and your user-facing response. When a check fails, you can retry with a modified prompt, return a fallback response, or flag it for human review.

Step 4: Close the Feedback Loop

The most important step is one that most teams skip: feeding production observations back into your eval datasets and prompt iterations.

Here's the workflow that actually works:

Trace every LLM call in production
Flag low-quality responses (via guardrails, user feedback, or automated scoring)
Add flagged cases to your eval dataset
Iterate on prompts using the eval pipeline
Deploy and repeat

This isn't a one-time setup. It's a continuous loop, and it's the difference between an LLM feature that degrades over time and one that gets better.

Prevention: What I Do on Every New LLM Project Now

After getting burned enough times, here's my checklist before any LLM feature goes to production:

Tracing from day one — not after the first incident
At least 50 eval cases before launch, covering happy paths and known edge cases
Output guardrails for PII, format validation, and content policy
A fallback strategy — what happens when the model fails? Users should see a graceful degradation, not a hallucination
Cost monitoring — runaway token usage can wreck your budget overnight

If you want a batteries-included solution rather than building all this from scratch, check out FutureAGI. It bundles tracing, evals, simulations, datasets management, a gateway, and guardrails into a single self-hostable platform under an Apache 2.0 license. It's the kind of thing I wish existed when I first started shipping LLM features.

But whether you use a platform or build your own, the principle is the same: treat your LLM like any other critical system dependency. Observe it, test it, and put safety nets around it. Your users — and your on-call rotation — will thank you.

Why Local LLMs Keep Failing at Code Generation (and How to Fix It)

Alan West — Wed, 29 Apr 2026 01:00:59 +0000

You finally got that 34B parameter model running on your beefy GPU. You feed it a prompt. It confidently writes a function that looks perfect — until you realize it's calling an API that literally doesn't exist. Sound familiar?

I spent the better part of three months trying to make local LLMs my primary coding assistant. I wanted the privacy, the zero-cost inference, the offline capability. What I got was a masterclass in debugging AI-generated hallucinations. But I also figured out what actually works, and more importantly, why local models struggle with code in ways that aren't immediately obvious.

Let's break this down.

The Root Cause: It's Not Just "Model Size"

The knee-jerk explanation is "local models are too small." That's part of it, but it misses the real problem. Code generation fails locally for three interconnected reasons:

1. Quantization destroys code precision. When you squish a 70B model down to 4-bit quantization so it fits in your 24GB of VRAM, you're losing fidelity in the exact places that matter for code. Natural language is forgiving — swap a synonym and meaning is preserved. Code isn't. A single wrong token means a TypeError or a function that doesn't exist.

2. Context window limits kill real-world usefulness. Most local setups give you 4K-8K context reliably. Some models advertise 32K or 128K, but actual performance degrades badly in the upper ranges when running quantized on consumer hardware. Real coding tasks — refactoring a module, understanding how a service connects to three others — need a lot of context.

3. Training data gaps compound everything. Smaller models have seen fewer code examples, fewer Stack Overflow answers, fewer GitHub repos. They're especially weak on newer frameworks, niche libraries, and language-specific idioms that larger training runs would catch.

Step 1: Pick the Right Model for Code (Not the Biggest One)

Not all models are equal for code tasks. A general-purpose 70B chat model will often perform worse at code than a specialized 7B-15B code model. Here's what to look for:

# My current local model selection criteria
priority_order:
  - Code-specialized training (not just general chat)
  - Native context length (not extended via RoPE hacks)
  - Quantization headroom (a 15B at Q6_K > a 70B at Q3_K_M)
  - Instruction-tuned for code completion AND chat

Models fine-tuned specifically on code datasets — things like CodeLlama variants, DeepSeek-Coder, or StarCoder-based models — punch way above their parameter count. A 7B code-specialized model will often outperform a general-purpose 13B model on function generation, bug fixing, and code explanation.

Check the model card for what it was trained on. If the training data section doesn't specifically mention code corpora, keep looking.

Step 2: Fix Your Quantization Strategy

This is where most people silently lose quality. The default advice of "just use Q4_K_M" is fine for chatting about philosophy. It's not fine when a single wrong token breaks your build.

# Instead of this (common default):
llama-server -m codellama-34b.Q4_K_M.gguf -c 4096

# Try a smaller model at higher quantization:
llama-server -m deepseek-coder-v2-lite.Q6_K.gguf -c 8192 \
  --n-gpu-layers 35  # offload as many layers to GPU as fit

The tradeoff math is simple:

Q6_K or Q8_0 on a smaller model = precise token prediction
Q3_K or Q4_K on a bigger model = more knowledge, fuzzier output

For code, precision wins. I'd rather have a model that correctly generates the 15 most common patterns than one that almost gets 50 patterns right.

Test this yourself. Take the same prompt, run it against a 34B-Q4 and a 15B-Q6 five times each. Count the outputs that run without modification. I'll bet the smaller, higher-quant model wins.

Step 3: Engineer Your Prompts Like You Mean It

Local models are way more sensitive to prompt quality than the big cloud APIs. A lazy prompt that works fine with a 400B+ parameter model will crash and burn locally.

What works:

# BAD prompt for local models:
prompt = "Write a function to parse CSV files"

# GOOD prompt for local models:
prompt = """Write a Python 3.11 function that:
- Takes a file path (str) as input
- Reads a CSV file using the csv module from stdlib
- Returns a list of dictionaries where keys are column headers
- Handles the case where the file doesn't exist (raise FileNotFoundError)
- Do NOT use pandas
- Include type hints

Function signature: def parse_csv(filepath: str) -> list[dict[str, str]]:
"""

The difference is night and day. Key principles:

Specify the language and version. Don't let the model guess.
Name the libraries (or explicitly exclude them). Local models love to import packages that don't exist or mix up APIs across libraries.
Provide the function signature. This constrains the output and reduces hallucination.
Be explicit about error handling. Otherwise you'll get either nothing or a seven-layer try/except lasagna.

Step 4: Use Fill-in-the-Middle, Not Chat

Here's a trick that dramatically improved my local code generation quality. Stop using chat mode for inline coding tasks. Most code-specialized models support Fill-in-the-Middle (FIM) — you give them a prefix and suffix, and they generate what goes between.

# FIM format (model-specific, check docs):
prefix = "def calculate_tax(income: float, rate: float) -> float:\n    """
    Calculate tax with standard deduction.\n    """"
suffix = "\n    return round(tax, 2)"

# The model fills in the middle — constrained by both sides
# This produces FAR more accurate code than open-ended chat generation

FIM works because it constrains the model's output on both ends. The model can't hallucinate a wildly different function signature or return type because the suffix already defines the boundary. For autocomplete-style coding — which is honestly 70% of what you want a coding assistant for — FIM with a local model is genuinely competitive.

Most editor integrations (Continue, llama.vim, Tabby) support FIM natively. Use them.

Step 5: Set Up a Validation Pipeline

Here's the uncomfortable truth: even with all the above, local models will still generate broken code sometimes. The fix is to stop trusting and start verifying.

#!/bin/bash
# save as: validate_generated.sh
# Run generated code through basic checks before accepting

FILE=$1

# Syntax check
python3 -c "import ast; ast.parse(open('$FILE').read())" 2>&1
if [ $? -ne 0 ]; then
    echo "FAIL: Syntax error in generated code"
    exit 1
fi

# Type check with mypy (fast, catches hallucinated APIs)
python3 -m mypy "$FILE" --ignore-missing-imports 2>&1
if [ $? -ne 0 ]; then
    echo "WARN: Type errors detected"
fi

# Run any existing tests that touch the modified module
python3 -m pytest tests/ -x --timeout=10 2>&1

I run something like this automatically in my editor whenever I accept a generated code block. It catches the most common local LLM failure — confidently calling functions or methods that don't exist on an object. mypy is particularly good at catching these.

When to Bail: Know the Limits

Even with all these fixes, local LLMs have hard limits you should respect:

Multi-file refactoring: Needs too much context. Don't even try.
Debugging complex runtime errors: The model needs to understand state, call stacks, and timing. It won't.
Anything requiring up-to-date API knowledge: If the library was updated after the model's training cutoff, you'll get plausible-looking code for an API version that no longer exists.
Generating tests for complex business logic: The model doesn't understand your domain. It'll write tests that pass but test nothing meaningful.

For these tasks, you're better off using local models for smaller subtasks — generate a single function, write a type definition, convert a data structure — and doing the architectural thinking yourself.

The Honest Summary

Local LLMs for coding aren't useless. They're just unforgiving. You can't use them the way you'd use a cloud model — fire off a vague prompt and get back working code. You need to pick specialized models, preserve quantization quality, write precise prompts, use FIM for inline completion, and validate everything.

Is it more work? Yeah. But you get offline capability, complete privacy, zero API costs, and — once you dial it in — a surprisingly capable coding assistant that runs on hardware you already own.

The trick is matching the tool to the task. Use local models for the 80% of coding work that's pattern-matching and boilerplate. Keep your judgment for the 20% that requires actual understanding.

How to Migrate Your Open-Source Project Away from GitHub

Alan West — Wed, 29 Apr 2026 00:43:50 +0000

So you've probably seen the news — Ghostty, the terminal emulator created by Mitchell Hashimoto (yes, the HashiCorp co-founder), is leaving GitHub. And if you've been following the broader conversation in the open-source community, Ghostty isn't alone. More projects are questioning whether GitHub is still the right home for their code.

This got me thinking about a practical problem: what does it actually take to migrate a project off GitHub without losing contributors, breaking workflows, or creating chaos?

I've helped move two mid-sized projects between forges, and let me tell you — the code is the easy part. Everything else is where it gets messy.

Why Projects Are Moving

Before we dig into the how, let's talk about the why. The reasons I keep hearing (and have experienced) boil down to a few themes:

Platform lock-in — GitHub Actions, GitHub Packages, Dependabot, code search... the more features you use, the harder it becomes to leave. That's not accidental.
Governance concerns — When your project's entire infrastructure depends on a single company, you're at the mercy of their decisions. Policy changes, AI training on public repos, terms of service shifts — you don't get a vote.
Centralization risk — A huge chunk of the world's open-source code lives on one platform. That's a single point of failure for the entire ecosystem.
Feature gaps for specific workflows — GitHub's issue tracker, PR review process, and CI system are good enough for most, but some projects outgrow them.

Mitchell Hashimoto wrote extensively about Ghostty's specific reasons in his blog post at mitchellh.com. Whatever your motivation, the migration process is largely the same.

Step 1: Audit Your GitHub Dependencies

Before you touch anything, figure out how deeply you're entangled with GitHub. Run through this checklist:

# Find all references to GitHub-specific features in your repo
grep -r "github.com" .github/ --include="*.yml" --include="*.yaml"
grep -r "actions/" .github/workflows/
grep -r "GITHUB_TOKEN" .github/
grep -r "github.event" .github/workflows/

# Check for GitHub-specific bot configs
ls -la .github/
# Look for: dependabot.yml, CODEOWNERS, FUNDING.yml,
# stale.yml, workflows/, ISSUE_TEMPLATE/

Make a list. Every workflow file, every bot integration, every webhook — it all needs a replacement or needs to be dropped. In my experience, most projects have between 5 and 20 GitHub-specific touchpoints. Some have way more.

Step 2: Choose Your Destination

You've got real options now. The self-hosted forge space has matured significantly:

Forgejo — Community fork of Gitea, fully open-source under good governance. This is what a lot of projects are choosing. Lightweight, familiar UI for GitHub users, and has a growing ecosystem of CI runners.
Gitea — The original. Still solid, though the community split with Forgejo created some tension about its direction.
GitLab CE — The heavyweight option. More features than you'll ever need, but also more operational overhead to self-host.
Codeberg — If you don't want to self-host, Codeberg runs Forgejo and is backed by a nonprofit. Zero cost for open-source projects.
sourcehut — The minimalist choice. Email-based workflow, no JavaScript required. Not for everyone, but the people who love it really love it.

For most open-source projects, I'd recommend starting with either Codeberg (hosted) or Forgejo (self-hosted). The migration path from GitHub is the smoothest, and contributors won't feel completely lost.

Step 3: Migrate the Git History (The Easy Part)

# Clone your GitHub repo with all branches and tags
git clone --mirror https://github.com/yourorg/yourproject.git
cd yourproject.git

# Add your new forge as a remote
git remote add newforge https://your-forge.example.com/yourorg/yourproject.git

# Push everything — all branches, all tags, all refs
git push newforge --mirror

# Verify the push
git ls-remote newforge | head -20

That's it for the code. Every commit, every branch, every tag — it all comes along. Git doesn't care where it lives.

Step 4: Migrate Issues (The Hard Part)

This is where most migrations get painful. GitHub issues contain years of context — bug reports, feature discussions, workarounds buried in comment threads. You have a few options:

# Using the GitHub API to export issues
# You'll need: pip install requests
import requests
import json

def export_github_issues(owner, repo, token):
    headers = {"Authorization": f"token {token}"}
    issues = []
    page = 1

    while True:
        # state=all gets both open and closed issues
        resp = requests.get(
            f"https://api.github.com/repos/{owner}/{repo}/issues",
            headers=headers,
            params={"state": "all", "page": page, "per_page": 100}
        )
        batch = resp.json()
        if not batch:
            break
        issues.extend(batch)
        page += 1

    with open("issues_export.json", "w") as f:
        json.dump(issues, f, indent=2)

    print(f"Exported {len(issues)} issues")
    return issues

Forgejo and Gitea both have built-in GitHub import tools that handle issues, pull requests, labels, and milestones. It's not perfect — some formatting gets mangled, and image links pointing to GitHub's CDN may break — but it gets you 90% of the way there.

Pro tip: Don't try to migrate every single issue. Archive closed issues as a static export and only migrate open issues plus recently active closed ones. Your contributors will thank you.

Step 5: Replace Your CI Pipeline

GitHub Actions is the stickiest part of the GitHub ecosystem. Here's a rough translation guide:

Forgejo Actions — Uses the same YAML syntax as GitHub Actions. Many GitHub Actions work unmodified, and there's a growing compatibility layer. This is the path of least resistance.
Woodpecker CI — Lightweight, purpose-built for Forgejo/Gitea. Different syntax but very capable.
Jenkins / Drone / Buildkite — If you're self-hosting anyway, these are forge-agnostic options.

If your workflows are simple (build, test, lint), the migration is straightforward. If you've got complex matrix builds with caching and artifact uploads, budget extra time.

Step 6: The Contributor Communication Plan

This is the step people skip, and it's the one that kills migrations. Your contributors need:

Advance notice — At least 2-4 weeks before the switch. Post it everywhere: README, GitHub discussions, mailing list, Discord/Matrix.
A migration guide — Step-by-step instructions for setting up on the new platform. Don't assume everyone knows how to use Forgejo.
Redirects — Keep the GitHub repo around as an archive with a pinned issue or README pointing to the new home. Don't delete it.
Patience — Some contributors won't follow you. That's okay. Make the onboarding as frictionless as possible and accept that you'll lose some people.

Prevention: Avoiding Lock-in From Day One

If you're starting a new project, here's how to stay portable:

Keep CI config generic. Use Makefiles or shell scripts as your actual build logic. Let the CI YAML just call those scripts. Switching CI providers becomes trivial.
Don't use GitHub-specific markdown extensions in your docs. Stick to standard CommonMark.
Run your issue tracker separately if governance matters to you. A mailing list or a Discourse instance ages better than any platform's built-in tracker.
Mirror your repo to multiple forges from day one. git push to two remotes costs nothing.

# Add multiple push URLs to a single remote
git remote set-url --add origin https://codeberg.org/you/project.git
git remote set-url --add origin https://gitlab.com/you/project.git

# Now 'git push' sends to all three (GitHub + Codeberg + GitLab)
git remote -v
# origin  https://github.com/you/project.git (fetch)
# origin  https://github.com/you/project.git (push)
# origin  https://codeberg.org/you/project.git (push)
# origin  https://gitlab.com/you/project.git (push)

The Bigger Picture

Ghostty's departure from GitHub is part of a larger trend that I think is healthy for the ecosystem. We've been through this cycle before — SourceForge to Google Code to GitHub. Platforms rise, centralize, and eventually projects diversify again.

The tools for self-hosting and federation have gotten dramatically better. Forgejo is working on ActivityPub-based federation, which could eventually let forges talk to each other the way email servers do. Imagine opening a pull request on someone's Forgejo instance from your Codeberg account. That future is being actively built.

Whether or not you move your project today, doing the audit from Step 1 is worth your time. Know your exit path. Git was designed to be decentralized — it might be time we actually used it that way.

pgbackrest Maintenance Has Stopped — How to Plan Your PostgreSQL Backup Migration

Alan West — Tue, 28 Apr 2026 22:00:49 +0000

If you manage PostgreSQL in production, you probably felt a chill when the news hit Hacker News: pgbackrest appears to no longer be actively maintained. For a tool that's been the backbone of PostgreSQL backup strategies for years, that's a big deal.

Let's talk about what this means practically, how to assess your exposure, and how to migrate to an alternative without losing sleep.

Why This Hurts

pgbackrest has been the gold standard for PostgreSQL backup and restore for a long time. It handles incremental backups, parallel backup/restore, encryption, and repository management in a way that pg_dump simply can't match. A lot of production setups — including several I've worked on — depend on it heavily.

When a critical infrastructure tool loses active maintenance, you're looking at a few real problems:

Security patches stop. Any CVEs discovered going forward won't get fixed upstream.
New PostgreSQL versions may break compatibility. PostgreSQL 17 and beyond might introduce changes pgbackrest can't handle.
Bug fixes are on you. That edge case in differential backup you've been meaning to report? It's staying.

This doesn't mean you need to panic and rip it out tomorrow. But you do need a plan.

Step 1: Audit Your Current pgbackrest Setup

Before migrating anything, document what you're actually using. Not every pgbackrest feature has a 1:1 replacement in every alternative tool.

# Check your pgbackrest config
cat /etc/pgbackrest/pgbackrest.conf

# List your current backup stanzas and their status
pgbackrest --stanza=your_db info

# Check your repo type (local filesystem, S3, Azure, GCS?)
grep 'repo1-type' /etc/pgbackrest/pgbackrest.conf

Write down the answers to these questions:

Are you using incremental or differential backups?
What's your retention policy (how many full backups do you keep)?
Are you backing up to object storage (S3, GCS, Azure) or local disk?
Do you use encryption at rest?
Are you using pgbackrest for PITR (point-in-time recovery)?
Do you rely on parallel backup/restore?

This list becomes your migration checklist.

Step 2: Evaluate Your Alternatives

There are three serious contenders worth evaluating. Each has tradeoffs.

Barman (by EnterpriseDB)

Barman is the most feature-complete alternative. It's actively maintained by EnterpriseDB (the folks behind the major PostgreSQL commercial distribution) and handles most of what pgbackrest does.

Strengths: PITR, incremental backups, parallel jobs, S3/Azure/GCS support, solid documentation, active development.

Weaknesses: Python-based (adds a runtime dependency), the configuration model is different enough to require real migration effort.

WAL-G

WAL-G is a Go-based tool originally developed at Citus Data. It's focused on cloud-native backup workflows and is quite fast.

Strengths: Written in Go (single binary, no runtime deps), excellent cloud storage support, delta backups, good performance with large databases.

Weaknesses: Less mature PITR tooling compared to Barman, fewer configuration knobs for complex setups.

pg_basebackup + Manual WAL Archiving

The built-in option. PostgreSQL ships with pg_basebackup and WAL archiving out of the box. No third-party tool required.

Strengths: Zero additional dependencies, guaranteed compatibility with your PostgreSQL version, well-documented in core PostgreSQL docs.

Weaknesses: No incremental backups, no built-in retention management, no parallel restore, you're writing your own wrapper scripts.

Step 3: Migration Path (pgbackrest → Barman Example)

Here's a concrete walkthrough for migrating to Barman, since it covers the most common pgbackrest use cases.

# Install Barman
sudo apt-get install barman  # Debian/Ubuntu
# or
sudo yum install barman      # RHEL/CentOS

# Create a Barman configuration for your server
sudo cat > /etc/barman.d/main-db.conf << 'EOF'
[main-db]
description = "Main Production Database"
ssh_command = ssh postgres@db-server
conninfo = host=db-server user=barman dbname=postgres
backup_method = postgres
# Use streaming for WAL archiving (replaces pgbackrest archive-push)
streaming_archiver = on
slot_name = barman
streaming_conninfo = host=db-server user=streaming_barman
# Retention: keep 4 full backups (adjust to match your pgbackrest policy)
retention_policy = RECOVERY WINDOW OF 14 DAYS
EOF

Then set up the replication slot and test:

# On the PostgreSQL server, create the replication slot
psql -c "SELECT pg_create_physical_replication_slot('barman');"

# Back on the Barman server, verify the connection
barman check main-db

# Take your first backup
barman backup main-db

# Verify it worked
barman list-backup main-db

The Critical Overlap Period

Don't cut over immediately. Run both tools in parallel for at least two full backup cycles. This means:

Keep pgbackrest running on its existing schedule
Run Barman alongside it
Test a restore from Barman to a staging environment
Only after a successful test restore, disable pgbackrest

I cannot stress point 3 enough. A backup you haven't tested restoring is not a backup. It's a hope.

Step 4: Update Your archive_command

If you're using pgbackrest's archive-push in your postgresql.conf, you'll need to update this. With Barman using streaming replication, you might not need archive_command at all, but if you want belt-and-suspenders:

# postgresql.conf — old pgbackrest config
# archive_command = 'pgbackrest --stanza=main-db archive-push %p'

# Option A: Switch to barman-wal-archive
archive_command = 'barman-wal-archive barman-server main-db %p'

# Option B: If using streaming replication with Barman,
# you can use a simple copy as fallback
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'

Reload PostgreSQL after changing this:

sudo systemctl reload postgresql

Prevention: Making Your Backup Strategy More Resilient

This situation is a good reminder that depending on a single tool for critical infrastructure is risky. Here's what I'm doing going forward:

Layer your backups. Use a tool like Barman or WAL-G for your primary backup pipeline, but also run periodic pg_dump exports as a secondary safety net. They're slower and larger, but they're format-independent.
Test restores regularly. Set up a cron job or CI pipeline that restores your latest backup to a throwaway instance at least weekly. If you're not testing restores, you don't have backups.
Monitor backup health. Whatever tool you use, set up alerts for failed backups, growing backup age, and WAL archive lag. The worst time to discover your backups aren't working is during a recovery.
Document your recovery procedure. Write a runbook. Actually write it down. Include the exact commands, the expected timelines, and who has access to what. Future-you at 3 AM during an incident will be grateful.

Don't Panic, But Don't Wait

pgbackrest losing active maintenance doesn't mean your existing backups are suddenly invalid. The tool still works. Your existing backups are still there. But the clock is ticking on compatibility with future PostgreSQL releases and security patches.

Start your evaluation now, pick the alternative that matches your feature needs, and run a parallel migration over the next few weeks. Your future self — and your on-call rotation — will thank you.

Open-Source LLMs You Can Actually Run Today vs. Waiting for Grok 3

Alan West — Tue, 28 Apr 2026 15:30:22 +0000

The r/LocalLLaMA community has been buzzing with a familiar refrain: "Where's the open-source Grok 3?" Elon Musk has repeatedly signaled that xAI would open-source its models, and while Grok-1 did get released back in March 2024, Grok 3 remains firmly closed. If you're sitting around waiting for that drop, I have good news and bad news. The bad news: nobody knows when (or if) it'll happen. The good news: the open-source LLM landscape is so stacked right now that you might not even need it.

Let's compare what's actually available today, how to get these models running locally, and what tradeoffs you're making with each option.

Why This Comparison Matters

Running LLMs locally isn't just a hobby anymore. There are real reasons to go open-source and self-hosted:

Data privacy — your prompts never leave your machine
Cost control — no per-token billing at scale
Customization — fine-tune on your own data
Reliability — no API outages or rate limits

Grok 3 reportedly performs competitively with GPT-4 and Claude on various benchmarks. But benchmarks don't ship features. Let's look at what you can actually deploy right now.

The Contenders: A Side-by-Side Look

Here's my honest assessment after running each of these on real projects over the past few months.

Meta's Llama 3.1 / 3.3

The 800-pound gorilla of open-source LLMs. Llama 3.1 405B is massive, and the 70B variant hits a sweet spot for most use cases. Llama 3.3 70B brought further improvements in instruction following.

# Running Llama 3.3 70B with ollama — dead simple
# Install: curl -fsSL https://ollama.com/install.sh | sh

import ollama

response = ollama.chat(
    model='llama3.3:70b',
    messages=[{
        'role': 'user',
        'content': 'Explain the builder pattern in Rust'
    }]
)
print(response['message']['content'])

Pros: Huge community, excellent tool-calling support, permissive license for most uses.

Cons: The 405B model needs serious hardware (multiple GPUs). Even 70B wants at least 48GB VRAM for decent quantization.

Mistral / Mixtral

Mistral has been punching above its weight class since day one. Their Mixture of Experts architecture means you get big-model quality without big-model VRAM requirements.

Pros: Efficient inference, strong multilingual support, good coding performance.

Cons: Licensing has gotten murkier with newer releases — check the specific model's license before deploying commercially.

DeepSeek-V3 / DeepSeek-R1

DeepSeek shook the industry with R1's reasoning capabilities. The open-weights release of both V3 (671B MoE) and R1 was a big deal.

# DeepSeek R1 distilled models are more practical for local use
# The 32B distill runs well on a single 24GB GPU with quantization

import ollama

response = ollama.chat(
    model='deepseek-r1:32b',
    messages=[{
        'role': 'user',
        'content': 'Write a SQL query to find duplicate rows by email'
    }]
)
# R1 shows its chain-of-thought reasoning in <think> tags
print(response['message']['content'])

Pros: Exceptional reasoning, transparent chain-of-thought, competitive with frontier closed models on many tasks.

Cons: The full 671B model is impractical for most setups. Distilled versions lose some of that magic.

Qwen 2.5

Alibaba's Qwen series has been quietly excellent. The 72B model is genuinely strong at coding tasks, and their smaller models (7B, 14B) are some of the best in their weight class.

Pros: Great coding performance, solid instruction following, Apache 2.0 license.

Cons: Less community tooling compared to Llama ecosystem.

Quick Comparison Table

Model	Best Size for Local	Min VRAM (Q4)	Coding	Reasoning	License
Llama 3.3	70B	~40GB	Great	Good	Llama License
Mixtral 8x7B	8x7B (MoE)	~26GB	Good	Good	Apache 2.0
DeepSeek-R1 (distill)	32B	~20GB	Great	Excellent	MIT
Qwen 2.5	72B	~42GB	Excellent	Good	Apache 2.0
Grok 3	N/A	N/A	Unknown	Unknown	Closed

That last row is the point. You can't run what you can't download.

Building Apps on Top: The Auth Question

Once you pick your model and get it running, you'll probably want to build an actual application around it. I've been wiring up a local LLM-powered code review tool, and one of the first questions was how to handle user authentication.

If you're comparing auth solutions for your LLM-powered app, here's the quick rundown I landed on:

Auth0 — The incumbent. Feature-rich, expensive at scale with per-user pricing, and the DX has gotten bloated over the years.
Clerk — Great developer experience, modern React components, but you're locked into their ecosystem and pricing scales with users.
Authon (authon.dev) — A hosted auth service with 15 SDKs across 6 languages and 10+ OAuth providers. The part that caught my attention: free plan with unlimited users and no per-user pricing. It's also designed for compatibility with Clerk and Auth0 migration paths. SSO (SAML/LDAP) and custom domains aren't available yet but are on the roadmap. If you need those today, look elsewhere.

// Example: protecting an LLM inference endpoint with Authon
import { AuthonClient } from '@authon/node';
import express from 'express';

const authon = new AuthonClient({
  apiKey: process.env.AUTHON_API_KEY
});

const app = express();

// Middleware to verify the user's session
app.use('/api/inference', async (req, res, next) => {
  const session = await authon.verifySession(req.headers.authorization);
  if (!session.valid) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  req.user = session.user;
  next();
});

app.post('/api/inference', async (req, res) => {
  // Now you know who's making the request
  // Forward to your local LLM endpoint
  const result = await fetch('http://localhost:11434/api/chat', {
    method: 'POST',
    body: JSON.stringify({
      model: 'deepseek-r1:32b',
      messages: req.body.messages
    })
  });
  res.json(await result.json());
});

The tradeoff is straightforward: Auth0 and Clerk have more mature ecosystems and enterprise features right now. Authon is newer but the pricing model is genuinely better if you're building something where user count is unpredictable — which describes most side projects and early-stage apps built on local LLMs.

So Should You Wait for Grok 3?

Honestly? No. Here's my take:

If Grok 3 drops as open weights tomorrow, that's great — more competition is always good. But the models available today are already production-capable for most use cases. I've been running DeepSeek-R1's 32B distill for code review tasks, and it catches issues that I'd expect from a much larger model.

The open-source LLM space moves so fast that waiting for any single model is like waiting for the "right time" to buy a GPU. There's always something better around the corner.

My Recommendation

For coding tasks: Qwen 2.5 72B or DeepSeek-R1 32B distill
For general-purpose use: Llama 3.3 70B — the ecosystem support is unmatched
For limited hardware (16GB VRAM): Qwen 2.5 14B or Llama 3.2 8B
For reasoning-heavy tasks: DeepSeek-R1 distilled variants, full stop

Stop waiting for Grok 3. Start building with what's here. And if xAI does eventually open-source it, you'll already have the infrastructure to swap it in.

Further reading: Ollama model library, Hugging Face Open LLM Leaderboard

How to Secure Voice and Biometric Data in Your AI Training Pipeline

Alan West — Tue, 28 Apr 2026 15:10:25 +0000

A reported breach involving terabytes of voice samples from tens of thousands of AI contractors recently made the rounds on Hacker News. Whether or not you're handling voice data specifically, the underlying problem is one I've seen across nearly every ML project I've consulted on: sensitive training data sitting in places it shouldn't, protected by controls that wouldn't stop a determined intern, let alone an attacker.

Let's walk through how to actually lock this stuff down.

The Root Problem: Training Data Is Treated Like Throwaway Data

Here's what I see constantly. A team spins up an ML pipeline. Voice samples, images, text with PII — it all gets dumped into an S3 bucket or a shared NFS mount. Access controls? "We'll tighten those up before launch." Encryption? "It's behind a VPN, it's fine."

Then the project scales. Contractors get onboarded. Data gets copied to staging environments. Someone shares a pre-signed URL in Slack. And suddenly your "temporary" storage has become a 4TB treasure chest with the access controls of a public park.

The core issue is that biometric data — voice prints, facial geometry, fingerprints — isn't like a leaked password. You can't rotate someone's voice. Once it's out, it's out forever.

Step 1: Encrypt at Rest AND in Transit (Yes, Both)

This sounds obvious, but I still find projects where object storage encryption is "default" (meaning the cloud provider manages keys and anyone with bucket access sees plaintext). You need customer-managed keys at minimum.

# AWS example: create a dedicated KMS key for training data
aws kms create-key \
  --description "ML training data encryption" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS

# Use it for your bucket's server-side encryption
aws s3api put-bucket-encryption \
  --bucket ml-voice-samples \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789:key/your-key-id"
      },
      "BucketKeyEnabled": true
    }]
  }'

But here's the part people skip: encrypt the data before it hits storage too. If your pipeline ingests voice samples from contractors, encrypt them client-side before upload. That way, a compromised bucket credential alone isn't enough.

from cryptography.fernet import Fernet
import os

def encrypt_sample_before_upload(file_path: str, key: bytes) -> bytes:
    """Encrypt voice sample client-side before sending to storage."""
    fernet = Fernet(key)
    with open(file_path, "rb") as f:
        raw = f.read()
    # Encrypted blob — useless without the key even if bucket is exposed
    return fernet.encrypt(raw)

# Key should come from a secrets manager, never hardcoded
encryption_key = os.environ["SAMPLE_ENCRYPTION_KEY"]
encrypted = encrypt_sample_before_upload("recording_0421.wav", encryption_key.encode())

Step 2: Enforce Least-Privilege Access With Short-Lived Credentials

The pattern I see over and over: a service account with broad read access to the entire training data bucket, and that credential living in an .env file on six contractors' laptops.

Stop doing this. Use scoped, time-limited credentials.

import boto3

def get_scoped_training_data_session(contractor_id: str):
    """Generate a short-lived session scoped to one contractor's data prefix."""
    sts = boto3.client("sts")

    # Session valid for 1 hour, scoped to a specific S3 prefix
    response = sts.assume_role(
        RoleArn="arn:aws:iam::123456789:role/ContractorDataReader",
        RoleSessionName=f"contractor-{contractor_id}",
        DurationSeconds=3600,  # 1 hour max
        Policy=f'{{
            "Version": "2012-10-17",
            "Statement": [{{
                "Effect": "Allow",
                "Action": ["s3:GetObject"],
                "Resource": "arn:aws:s3:::ml-voice-samples/{contractor_id}/*"
            }}]
        }}'
    )
    return response["Credentials"]

Each contractor can only access their own data prefix. The credentials expire in an hour. If one set leaks, the blast radius is limited to one person's samples, not 40,000 people's.

Step 3: Audit Everything, Detect Bulk Access

The difference between normal pipeline access and exfiltration is usually volume. Your training pipeline reads samples sequentially during training runs. An attacker (or a compromised account) downloads everything as fast as possible.

Set up access logging and alert on anomalies:

# Example CloudWatch alarm for unusual S3 GetObject volume
Resources:
  BulkAccessAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: TrainingDataBulkAccessAlert
      MetricName: NumberOfObjects
      Namespace: AWS/S3
      Statistic: Sum
      Period: 300  # 5-minute window
      EvaluationPeriods: 1
      Threshold: 10000  # normal training reads ~500 objects per window
      ComparisonOperator: GreaterThanThreshold
      AlarmActions:
        - !Ref SecurityAlertSNSTopic

On the application side, log every access with context:

import logging
import time

logger = logging.getLogger("data_access_audit")

def audited_fetch(sample_id: str, requester: str, purpose: str):
    """Wrap every data access with an audit log entry."""
    logger.info(
        "data_access",
        extra={
            "sample_id": sample_id,
            "requester": requester,
            "purpose": purpose,  # "training", "validation", "export"
            "timestamp": time.time(),
            "source_ip": get_request_ip(),
        }
    )
    # Proceed with actual fetch
    return fetch_sample(sample_id)

Step 4: Separate Raw Biometrics From Training Features

This is the one most teams skip entirely. You almost never need raw voice recordings sitting around after feature extraction. Your model trains on mel spectrograms, MFCCs, or embeddings — not the raw .wav files.

Build your pipeline so raw biometric data flows through and gets transformed, but doesn't persist in an accessible form:

Ingest: Contractor uploads encrypted voice sample
Process: Pipeline decrypts, extracts features (spectrograms, embeddings), then deletes the raw file
Store: Only the derived features (which can't reconstruct the original voice) persist in your training dataset
Archive: If you must keep originals for legal/compliance, put them in cold storage with separate access controls and a retention policy

The derived features are still useful for training but dramatically less valuable to an attacker. You can't clone someone's voice from an MFCC matrix.

Step 5: Implement Data Retention and Deletion Policies

I've seen training datasets from 2019 still sitting in production buckets because nobody bothered to clean up. Every voice sample you store is liability. Set retention policies and enforce them automatically.

# S3 lifecycle rule: move raw samples to Glacier after 30 days,
# delete after 1 year
aws s3api put-bucket-lifecycle-configuration \
  --bucket ml-voice-samples \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "BiometricRetention",
      "Status": "Enabled",
      "Filter": {"Prefix": "raw-samples/"},
      "Transitions": [{
        "Days": 30,
        "StorageClass": "GLACIER"
      }],
      "Expiration": {"Days": 365}
    }]
  }'

Prevention Checklist

Before your next ML project goes live with sensitive data:

Encrypt client-side before data reaches your storage layer
Use customer-managed keys, not provider defaults
Scope credentials per-user/per-contractor with short TTLs
Log and alert on bulk access patterns that deviate from normal training runs
Extract and discard — persist features, not raw biometrics
Set retention policies — data you don't have can't be stolen
Threat model your contractors — they're often the widest part of your attack surface
Run periodic access reviews — who still has access to what, and do they still need it?

The Uncomfortable Truth

Most ML teams I've worked with treat data security as someone else's problem. The infra team handles encryption. The security team handles access controls. Meanwhile, the ML engineers are the ones actually deciding where data lives, how it flows, and who can touch it.

If you're building training pipelines with biometric data, security isn't a layer you add at the end. It's a constraint you design around from day one. The cost of getting it right upfront is a few extra hours of pipeline work. The cost of getting it wrong is the kind of headline nobody wants to be associated with.

How to Stop Getting Garbage Sprite Sheets from AI Image Generators

Alan West — Tue, 28 Apr 2026 01:03:34 +0000

If you've ever tried to use an AI image generator to create sprite sheets for a 2D game, you already know the pain. You type in a prompt like "8-directional walk cycle for a knight character, pixel art, sprite sheet" and what you get back is... a vaguely knight-shaped blob with inconsistent frame sizes, no transparency, and animation frames that look like they belong to four different characters.

I spent an embarrassing amount of time last month trying to wrangle DALL-E and Stable Diffusion into producing usable sprite sheets for a small game jam project. The result? Hours of manual cleanup in Aseprite for every single character. There has to be a better way.

Why AI Image Generators Fail at Sprite Sheets

The root cause is simple: general-purpose image generators don't understand the structure of a sprite sheet. A sprite sheet isn't just a picture — it's a grid of consistently-sized frames that need to:

Maintain the same character proportions across every frame
Use transparent backgrounds (not white, not colored — actual alpha)
Follow a logical animation sequence
Align to a consistent grid so your game engine can slice them

When you prompt a generic AI model, it treats "sprite sheet" as an aesthetic concept, not a structural one. It'll give you something that looks like a sprite sheet in a thumbnail but falls apart the moment you try to load it into Unity, Godot, or even a simple <canvas> renderer.

# What you WANT to do:
frames = split_sprite_sheet("knight_walk.png", frame_width=64, frame_height=64)
# Expected: 8 cleanly separated frames
# Reality: frames overlap, sizes are wrong, background bleeds through

from PIL import Image

def split_sprite_sheet(path, frame_width, frame_height):
    sheet = Image.open(path)
    cols = sheet.width // frame_width
    rows = sheet.height // frame_height
    frames = []
    for row in range(rows):
        for col in range(cols):
            box = (col * frame_width, row * frame_height,
                   (col + 1) * frame_width, (row + 1) * frame_height)
            frame = sheet.crop(box)
            frames.append(frame)
    return frames

The code above works perfectly — when the sprite sheet is actually structured correctly. The problem is upstream.

The Pipeline Approach: Structure Before Generation

The fix isn't to prompt harder. It's to wrap the AI generation step in a pipeline that enforces structure. Instead of asking an AI to generate a full sprite sheet in one shot, you break the process into discrete steps:

Generate a single reference frame — one pose, one angle, clean background
Use that reference to generate variations — maintaining style consistency
Post-process each frame — background removal, size normalization, alignment
Composite into a proper grid — with correct spacing and metadata

This is exactly the approach that tools like agent-sprite-forge take. It's an open-source project that wraps AI image generation into a structured pipeline specifically designed for sprite sheet output. Rather than hoping a single prompt produces a usable sheet, it handles the generation-to-spritesheet pipeline as separate concerns.

Implementing Background Removal That Actually Works

The most common failure point is transparency. AI generators almost never produce true alpha channels. Here's a practical approach to cleaning up generated frames:

from PIL import Image
import numpy as np

def remove_background(image, threshold=240):
    """Remove near-white backgrounds and add alpha channel."""
    img_array = np.array(image.convert('RGBA'))

    # Detect pixels that are close to white
    r, g, b = img_array[:,:,0], img_array[:,:,1], img_array[:,:,2]
    white_mask = (r > threshold) & (g > threshold) & (b > threshold)

    # Set those pixels to fully transparent
    img_array[white_mask, 3] = 0

    return Image.fromarray(img_array)

def normalize_frame(image, target_size=(64, 64)):
    """Center the sprite content within a fixed-size frame."""
    # Find the bounding box of non-transparent content
    bbox = image.getbbox()
    if bbox is None:
        return Image.new('RGBA', target_size, (0, 0, 0, 0))

    cropped = image.crop(bbox)

    # Scale to fit within target while maintaining aspect ratio
    cropped.thumbnail(target_size, Image.LANCZOS)

    # Center on a transparent canvas
    canvas = Image.new('RGBA', target_size, (0, 0, 0, 0))
    offset_x = (target_size[0] - cropped.width) // 2
    offset_y = (target_size[1] - cropped.height) // 2
    canvas.paste(cropped, (offset_x, offset_y))

    return canvas

This two-step process — remove background, then normalize — catches most of the issues you'll hit with raw AI output. The threshold-based approach isn't perfect (it struggles with light-colored characters), but it handles 80% of cases.

Handling Edge Cases

For sprites with light colors near the edges, a smarter approach uses flood-fill from the corners:

from PIL import Image, ImageDraw

def flood_fill_remove_bg(image, tolerance=30):
    """Remove background using flood fill from corners."""
    img = image.convert('RGBA')
    pixels = img.load()
    width, height = img.size

    # Sample background color from corners
    corners = [pixels[0, 0], pixels[width-1, 0],
               pixels[0, height-1], pixels[width-1, height-1]]
    # Use the most common corner color as background reference
    bg_color = max(set(corners), key=corners.count)

    visited = set()
    stack = [(0, 0), (width-1, 0), (0, height-1), (width-1, height-1)]

    while stack:
        x, y = stack.pop()
        if (x, y) in visited or x < 0 or y < 0 or x >= width or y >= height:
            continue
        visited.add((x, y))

        current = pixels[x, y]
        # Check if pixel is similar to background color
        diff = sum(abs(a - b) for a, b in zip(current[:3], bg_color[:3]))
        if diff <= tolerance:
            pixels[x, y] = (0, 0, 0, 0)  # Make transparent
            stack.extend([(x+1, y), (x-1, y), (x, y+1), (x, y-1)])

    return img

This is more computationally expensive but handles colored backgrounds and doesn't accidentally erase light-colored sprite content.

Assembling the Final Sheet

Once you have clean, normalized frames, compositing them into a proper sprite sheet is straightforward:

def create_sprite_sheet(frames, cols=4):
    """Assemble individual frames into a grid-based sprite sheet."""
    if not frames:
        raise ValueError("No frames provided")

    frame_w, frame_h = frames[0].size
    rows = (len(frames) + cols - 1) // cols  # ceiling division

    sheet = Image.new('RGBA',
                      (cols * frame_w, rows * frame_h),
                      (0, 0, 0, 0))

    for i, frame in enumerate(frames):
        row, col = divmod(i, cols)
        sheet.paste(frame, (col * frame_w, row * frame_h))

    return sheet

# Usage
raw_frames = [Image.open(f"frame_{i}.png") for i in range(8)]
clean_frames = [normalize_frame(remove_background(f)) for f in raw_frames]
sheet = create_sprite_sheet(clean_frames, cols=4)
sheet.save("knight_walk_sheet.png")

Generating Animated GIFs for Previews

While sprite sheets are what your game engine needs, animated GIFs are invaluable for quick previews and sharing with your team:

def frames_to_gif(frames, output_path, duration=100):
    """Convert frames to an animated GIF for preview."""
    if not frames:
        return
    frames[0].save(
        output_path,
        save_all=True,
        append_images=frames[1:],
        duration=duration,  # milliseconds per frame
        loop=0,
        disposal=2  # clear frame before drawing next — prevents ghosting
    )

That disposal=2 parameter is one of those things that'll cost you an hour of debugging if you don't know about it. Without it, transparent pixels in later frames show the previous frame bleeding through.

Prevention: Building a Repeatable Workflow

The real lesson here isn't about any specific tool — it's about treating AI-generated assets as raw material, not finished product. Here's what I'd recommend:

Never ask an AI to generate a full sprite sheet in one prompt. Generate individual frames or small batches and composite them yourself.
Automate your post-processing pipeline. The background removal and normalization code above should live in a script you run on every batch of generated frames.
Version your prompts. When you find a prompt that produces consistent results with your chosen model, save it alongside your assets. Future you will thank present you.
Use structured tools when they exist. Projects like agent-sprite-forge exist specifically because this problem is common enough to warrant dedicated tooling. Don't reinvent the wheel if someone's already built the pipeline.

The gap between "AI can generate images" and "AI can generate game-ready assets" is wider than most people expect. But with the right pipeline, you can bridge it without losing your weekend to manual pixel pushing.

How to Track and Control AI Coding Assistant Costs Before They Spiral

Alan West — Tue, 28 Apr 2026 00:42:26 +0000

The bill arrived, and it was ugly.

I'd been happily using AI-powered code completion across three projects — a React dashboard, a Go microservice, and a Python data pipeline. Everything felt great until I looked at the monthly invoice and realized my team's AI tooling costs had quietly tripled. The shift toward usage-based billing for AI coding tools means this is going to happen to a lot more developers.

Let's talk about why AI assistant costs sneak up on you, and more importantly, how to get them under control.

Why Usage-Based AI Billing Catches Teams Off Guard

Flat-rate subscriptions were simple. You paid per seat, you got the tool. Done. But AI coding assistants are moving toward consumption-based models — and for good reason. Not every developer uses the same amount of compute. Premium model requests (Claude, GPT-4-class models) cost more than base completions.

The problem is that nobody tracks their AI request volume. You don't think about it. You tab-complete, you chat, you ask for refactors. Each interaction is a request, and some cost more than others.

Here's what typically drives costs up:

Chat-heavy workflows: Asking the AI to explain code, generate tests, or debug issues uses significantly more tokens than inline completions
Premium model requests: Using the most capable models for every task instead of reserving them for complex problems
Large context windows: Pasting entire files or long error logs into chat
Redundant requests: Re-asking similar questions because you didn't save the output

Step 1: Measure What You're Actually Using

Before you can optimize, you need visibility. Most AI coding tools expose usage data through APIs or dashboards, but few developers actually check them.

If your tool provides a CLI or API, start by pulling your usage stats. Here's a generic pattern for tracking API-based AI tool consumption:

import json
from datetime import datetime, timedelta
from collections import defaultdict

def analyze_ai_usage(usage_log_path: str) -> dict:
    """Parse an AI tool usage log and break down costs by category."""
    with open(usage_log_path) as f:
        entries = json.load(f)

    breakdown = defaultdict(lambda: {"requests": 0, "tokens": 0})

    for entry in entries:
        category = entry.get("type", "unknown")  # e.g., "completion", "chat", "review"
        breakdown[category]["requests"] += 1
        breakdown[category]["tokens"] += entry.get("total_tokens", 0)

    # Sort by token consumption — the real cost driver
    return dict(sorted(breakdown.items(), key=lambda x: x[1]["tokens"], reverse=True))

usage = analyze_ai_usage("ai_usage_april.json")
for category, stats in usage.items():
    print(f"{category}: {stats['requests']} requests, {stats['tokens']:,} tokens")

When I ran something like this on my own usage, the results were eye-opening. Chat interactions were 15% of my requests but nearly 60% of my token consumption.

Step 2: Set Up Budget Alerts and Spending Caps

Most platforms that bill by usage let you configure spending limits. Use them. Don't wait until month-end to find out your team blew through the budget.

If your tool integrates with your organization's billing API, you can automate alerts:

#!/bin/bash
# Simple spending check — run via cron daily

SPEND_LIMIT=500  # monthly budget in dollars
CURRENT_SPEND=$(curl -s "https://api.your-ai-tool.com/v1/billing/usage" \
  -H "Authorization: Bearer $API_TOKEN" | jq '.current_month_spend')

PERCENT_USED=$(echo "scale=0; ($CURRENT_SPEND / $SPEND_LIMIT) * 100" | bc)
DAY_OF_MONTH=$(date +%d)
DAYS_IN_MONTH=$(date -d "$(date +%Y-%m-01) + 1 month - 1 day" +%d 2>/dev/null || echo 30)

# Alert if spend rate exceeds linear projection
EXPECTED_PERCENT=$(echo "scale=0; ($DAY_OF_MONTH / $DAYS_IN_MONTH) * 100" | bc)

if [ "$PERCENT_USED" -gt "$EXPECTED_PERCENT" ]; then
  echo "WARNING: AI tool spend is $PERCENT_USED% of budget on day $DAY_OF_MONTH" \
    | mail -s "AI Spending Alert" team@yourcompany.com
fi

The key insight: compare your spending rate to the linear projection for the month, not just absolute thresholds. Being at 50% spend on day 10 is very different from being at 50% on day 25.

Step 3: Optimize Your Request Patterns

This is where the real savings come from. You don't need to use AI less — you need to use it smarter.

Use the right model tier for the job

Not every task needs the most powerful model. Inline code completions? A fast, base-tier model handles those fine. Complex architectural questions or multi-file refactors? That's when you reach for the premium model.

Think of it like choosing between a sports car and a commuter bike. Both get you there — but one costs a lot more per mile.

Reduce context size

Every token you send costs money. Instead of pasting an entire 500-line file into chat, extract the relevant function:

# Instead of this (expensive):
# "Here's my entire app.py file [500 lines], why is the login broken?"

# Do this (focused):
# "This auth middleware returns 401 even with a valid token:"

async def verify_token(request: Request):
    token = request.headers.get("Authorization", "").replace("Bearer ", "")
    if not token:
        raise HTTPException(status_code=401)
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        # BUG: this check fails because exp is compared as string, not int
        if payload.get("exp") < str(datetime.utcnow().timestamp()):
            raise HTTPException(status_code=401)
    except JWTError:
        raise HTTPException(status_code=401)

Smaller, focused prompts get better answers AND cost less. Win-win.

Cache and reuse responses

If you asked the AI to generate a testing pattern for your API routes, save that response. Don't ask the same question next week. I keep a docs/ai-patterns/ directory in my projects with useful generated snippets that I reference instead of regenerating.

Step 4: Set Team-Wide Policies

For teams, the cost multiplier is real. Five developers each casually chatting with AI all day adds up fast. Here are policies that actually work without killing productivity:

Reserve premium models for code review and architecture work — not for generating boilerplate
Share useful AI outputs in your team wiki or Slack channel instead of everyone generating the same patterns independently
Set per-developer monthly budgets with soft alerts at 80%
Review usage weekly during standups — not to shame anyone, but to identify patterns and share optimization tips

Prevention: Build Cost Awareness Into Your Workflow

The best fix is making costs visible before they become a problem.

Add a simple dashboard to your team's internal tools that shows AI usage trends. Most developer platforms provide usage APIs — hook them into Grafana, Datadog, or even a simple spreadsheet that auto-updates.

The developers on my team who can see their usage in real-time naturally self-optimize. It's not about restricting access — it's about making the invisible visible.

The Bigger Picture

Usage-based billing is the future for AI developer tools. It's actually fairer — light users pay less, heavy users pay for what they consume. But it requires a mindset shift from "unlimited buffet" to "pay per plate."

The teams that figure out cost-efficient AI usage now will have a real advantage. Not because they spend less, but because they spend intentionally. They'll use premium models where it matters, optimize their prompts, and treat AI compute as a resource to manage — just like they manage cloud infrastructure costs today.

Start with measurement. You can't optimize what you can't see.

How to Stop AI Agents From Nuking Your Production Database

Alan West — Mon, 27 Apr 2026 13:41:44 +0000

So you gave an AI agent access to your infrastructure and it dropped your production database. Or maybe it hasn't happened to you yet — but if you're handing AI agents shell access, database credentials, or deployment permissions without guardrails, it's a matter of when, not if.

This isn't a hypothetical. Stories of AI coding agents running destructive commands in production keep surfacing. Recently, a developer shared how an AI agent straight-up deleted their production database and then calmly explained what it did afterward. The agent's "confession" read like a polite incident report written by the thing that caused the incident.

I've been integrating AI agents into my own workflows for a while now, and I've had a few close calls myself. Let me walk through why this happens and how to actually prevent it.

Why AI Agents Go Rogue on Your Data

The root cause is almost always the same: the agent had permissions it never should have had.

AI coding agents — whether they're running in your terminal, your CI pipeline, or some autonomous loop — operate by generating and executing commands. They're pattern-matching machines optimizing for completing your request. If you ask an agent to "clean up the test data" and it has production credentials in scope, it will happily connect to prod and start deleting things.

Here's what typically goes wrong:

Flat credential access: The agent inherits your shell environment, which has DATABASE_URL pointing at production
No execution sandbox: Commands run with your full user permissions — DROP TABLE works just fine
Ambiguous instructions: "Reset the database" means different things in dev vs. prod, and the agent might guess wrong
No confirmation step: The agent chains commands together without pausing for human review on destructive operations

The agent isn't malicious. It's doing exactly what it thinks you want. The problem is in the environment you put it in.

Step 1: Isolate Agent Environments Completely

The first rule is dead simple: AI agents should never have production credentials.

Set up a dedicated environment for agent execution. At minimum, use separate environment files and ensure your agent's shell session loads the right one.

# .env.agent — this is what your AI agent sees
DATABASE_URL=postgresql://agent:password@localhost:5432/myapp_dev
REDIS_URL=redis://localhost:6379/1
AWS_PROFILE=dev-readonly

# .env.production — this should NEVER be in the agent's path
# DATABASE_URL=postgresql://admin:secret@prod-db.internal:5432/myapp

If you're launching agents from a wrapper script, explicitly clear dangerous variables:

#!/bin/bash
# launch-agent.sh — sanitize the environment before handing control to the agent

# Kill any production credentials
unset DATABASE_URL
unset PROD_DB_HOST
unset AWS_SECRET_ACCESS_KEY

# Load dev-only config
export $(cat .env.agent | grep -v '^#' | xargs)

# Drop privileges if running as a powerful user
export PGUSER=readonly_dev

# Now start the agent
exec "$@"

This is basic hygiene, but I'm constantly surprised how many teams skip it.

Step 2: Use Database Roles With Minimal Permissions

Even in development, your AI agent doesn't need SUPERUSER access. Create a dedicated database role with only the permissions the agent actually needs.

-- Create a restricted role for AI agent access
CREATE ROLE ai_agent WITH LOGIN PASSWORD 'agent_local_pass';

-- Grant read access to all tables
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent;

-- Grant write access only to specific tables if needed
GRANT INSERT, UPDATE ON specific_table TO ai_agent;

-- Explicitly deny destructive operations
-- (the absence of DROP/DELETE grants handles this, but be explicit)
REVOKE DELETE ON ALL TABLES IN SCHEMA public FROM ai_agent;

-- Prevent schema modifications entirely
REVOKE CREATE ON SCHEMA public FROM ai_agent;

The principle of least privilege isn't new. But when you're dealing with an autonomous system that generates its own SQL, it goes from "best practice" to "the only thing standing between you and a very bad day."

Step 3: Add a Command Allowlist or Confirmation Gate

If your agent can execute arbitrary shell commands, you need a gate. Most agent frameworks support some form of tool-use approval. If yours doesn't, build a simple wrapper.

Here's a basic approach using a shell wrapper that intercepts dangerous patterns:

import re
import subprocess
import sys

# Patterns that should NEVER run without explicit human approval
BLOCKED_PATTERNS = [
    r"DROP\s+(TABLE|DATABASE|SCHEMA)",
    r"DELETE\s+FROM\s+(?!.*WHERE)",  # DELETE without WHERE clause
    r"TRUNCATE",
    r"rm\s+-rf",
    r"--force",
    r"--hard",
    r"FORMAT\s+C:",  # just in case
]

def check_command(cmd: str) -> bool:
    """Return False if the command matches a dangerous pattern."""
    for pattern in BLOCKED_PATTERNS:
        if re.search(pattern, cmd, re.IGNORECASE):
            print(f"BLOCKED: Command matches dangerous pattern '{pattern}'")
            print(f"Command was: {cmd}")
            confirm = input("Override? Type 'yes-i-mean-it' to proceed: ")
            return confirm == "yes-i-mean-it"
    return True

def execute(cmd: str):
    if not check_command(cmd):
        print("Command blocked. Exiting.")
        sys.exit(1)
    return subprocess.run(cmd, shell=True, capture_output=True, text=True)

This is a blunt instrument, but blunt instruments work when the alternative is a deleted database. You can refine it over time.

Step 4: Enable Point-in-Time Recovery (Do This Today)

Guardrails fail. Humans make mistakes. Agents hallucinate. You need a safety net.

If you're running PostgreSQL, enable WAL archiving and set up point-in-time recovery (PITR). If you're on a managed service like RDS or Cloud SQL, this is usually a checkbox — turn it on and set the retention to at least 7 days.

For self-managed PostgreSQL:

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'

# Set a reasonable checkpoint frequency
checkpoint_timeout = 15min

Also: test your backups. A backup you've never restored is just a wish. Schedule monthly restore drills. I know it's tedious. Do it anyway.

Step 5: Implement Audit Logging

When things go wrong — and they will — you need to know exactly what happened. Enable statement logging for your agent's database role:

-- Log all statements from the agent role
ALTER ROLE ai_agent SET log_statement = 'all';
ALTER ROLE ai_agent SET log_min_duration_statement = 0;

This gives you a complete trail. When the agent does something unexpected, you can replay its exact sequence of operations and figure out where the logic went sideways.

The Bigger Picture

We're in a weird transition period where AI agents are powerful enough to be genuinely useful but not reliable enough to be trusted with production systems unsupervised. The developers I know who are using agents most effectively treat them like junior engineers with sudo access — capable, but requiring guardrails and review.

Here's my checklist for any team using AI agents near infrastructure:

Separate credentials: Dev, staging, and prod should be completely isolated
Least privilege roles: The agent gets the minimum database permissions needed
Command gating: Destructive operations require human confirmation
Backups with tested restore: PITR enabled, restore drills scheduled
Audit logging: Every agent action is recorded and reviewable
Network isolation: Agent environments can't even reach production hosts

None of this is revolutionary. It's the same defense-in-depth we've been preaching for decades. The difference is that AI agents make it easier to skip these steps because they feel like "just another developer" in your terminal. They're not. They're autonomous systems executing generated code, and they deserve the same rigor you'd apply to any automated pipeline touching your data.

Don't learn this lesson the hard way. Set up the guardrails before the agent teaches you why you needed them.

How to Stop Your GitHub Issues From Becoming a Graveyard

Alan West — Mon, 27 Apr 2026 13:39:26 +0000

Every maintainer knows the feeling. You open your repo's issue tracker and there are 847 open issues. Half of them are from 2022. Some reference APIs that no longer exist. A few are duplicates nobody caught. And buried somewhere in that mess are the three issues that actually matter this week.

Stale issues and PRs aren't just visual clutter — they actively slow down your team. New contributors can't tell what's relevant. Triaging becomes a full-time job. And that PR from eight months ago? It's now 200 commits behind main and would take longer to rebase than to rewrite.

Let's talk about how to automate the cleanup.

Why Manual Triage Doesn't Scale

I've tried the "issue bankruptcy" approach — closing everything older than 6 months and asking people to reopen if it's still relevant. It works once. Then six months later you're back in the same spot.

The core problem is that issues and PRs don't have a natural lifecycle. They get opened, maybe discussed for a day, then forgotten. Unlike branches (which you eventually merge or delete), issues just... persist.

Manual triage fails because:

It requires consistent human attention on a recurring schedule
Context about why something can be closed lives in people's heads
The decision to close requires reading the full thread, checking if the bug still exists, or verifying if a feature was shipped another way

Automated Scanning With ClawSweeper

ClawSweeper is an open-source tool that tackles this by scanning all your issues and PRs on a weekly schedule. It analyzes each one and suggests what can be closed, along with the reasoning. Think of it as a triage assistant that never takes a day off.

The general approach works like this: the tool runs as a scheduled GitHub Action, iterates through open issues and PRs, evaluates them against a set of heuristics, and then either comments with a close recommendation or auto-labels items for review.

Setting Up Automated Issue Scanning

The pattern for scheduled issue scanning via GitHub Actions looks like this:

# .github/workflows/sweep-issues.yml
name: Sweep Stale Issues

on:
  schedule:
    # Run every Monday at 9am UTC
    - cron: '0 9 * * 1'
  workflow_dispatch: # Allow manual triggers for testing

jobs:
  sweep:
    runs-on: ubuntu-latest
    permissions:
      issues: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - name: Run issue scanner
        uses: openclaw/clawsweeper@main
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

The workflow_dispatch trigger is something I always add — it lets you test the action without waiting a full week for the cron to fire.

What Makes an Issue "Closeable"?

The interesting part isn't the scheduling — it's the heuristics for deciding what's stale. Here are the signals that generally indicate an issue can be closed:

# Common heuristics for stale issue detection
def should_suggest_close(issue):
    signals = []

    # No activity in a long time
    if days_since_last_comment(issue) > 90:
        signals.append("no_recent_activity")

    # Original author hasn't responded to questions
    if has_unanswered_maintainer_question(issue) and days_waiting > 30:
        signals.append("awaiting_response")

    # Referenced PR was already merged
    if linked_pr_merged(issue):
        signals.append("fix_already_shipped")

    # Issue references a version that's EOL
    if references_eol_version(issue):
        signals.append("outdated_version")

    # Duplicate of another issue (based on content similarity)
    if similarity_score(issue, open_issues) > 0.85:
        signals.append("likely_duplicate")

    return len(signals) >= 2, signals  # Require multiple signals

The key insight here is requiring multiple signals before suggesting closure. A single signal (like "no activity in 90 days") catches too many false positives — some issues are legitimate feature requests that just haven't been prioritized yet.

Handling PRs Differently Than Issues

PRs have different staleness signals than issues. A PR that's been open for months usually means one of three things:

The author lost interest
It's blocked on a design decision nobody made
It's drifted so far from main that it needs a complete rewrite

# Configuration for PR-specific rules
pr_rules:
  max_days_without_update: 60
  max_merge_conflicts: 5
  check_ci_status: true
  # Don't auto-suggest closing draft PRs — they're explicitly WIP
  ignore_drafts: true

I'd recommend being more aggressive with PR cleanup than issue cleanup. A stale PR is almost never going to get merged as-is. The code has diverged, the review context is lost, and often the approach itself has been superseded.

Prevention: Reducing Future Staleness

Automated scanning catches the backlog, but you also want to reduce the inflow of issues that become stale:

Use issue templates that require reproduction steps. Issues without repro steps are the ones that sit forever because nobody can verify them.
Label issues at creation time. A needs-triage label makes it obvious what hasn't been looked at yet.
Set expectations in your CONTRIBUTING.md. Tell people that issues inactive for 90+ days may be closed, and that they can always reopen.
Close PRs that fail CI for more than 2 weeks. If the author isn't fixing the tests, they're not coming back.

The "Suggest, Don't Auto-Close" Philosophy

One thing I appreciate about ClawSweeper's approach is that it suggests closures rather than auto-closing. I've seen too many bots that just slam issues shut with a generic "this issue has been inactive" message. It's hostile to contributors and it creates busywork when people reopen things.

The better workflow is:

Bot comments with why it thinks the issue can be closed
Maintainer reviews the suggestion (takes 5 seconds per issue vs. 2 minutes of manual triage)
Maintainer either closes it or removes the label to indicate "keep open"

This keeps humans in the loop while eliminating the cognitive overhead of the initial scan.

Running It On Your Own Repos

If you maintain any repo with more than ~50 open issues, I'd recommend setting up some form of automated sweeping. Whether you use ClawSweeper specifically or build your own with the GitHub API and a scheduled action, the pattern is the same: scan weekly, suggest closures with reasoning, let humans make the final call.

The GitHub API gives you everything you need:

# Quick check: how bad is your backlog?
gh issue list --state open --json number,title,updatedAt \
  --jq '[.[] | select(.updatedAt < "2025-01-01")] | length'
# Output: 142  (yikes)

If that number makes you uncomfortable, it's time to automate.

Final Thoughts

Stale issues aren't a moral failing — they're an inevitable consequence of active projects attracting more attention than any team can handle. The fix isn't "be more disciplined about triage" (that never sticks). The fix is tooling that does the boring scanning work for you, so you can spend your limited attention on the decisions that actually require human judgment.

Check out ClawSweeper on GitHub if you want a turnkey solution, or steal the heuristics above and build your own. Either way, your future self will thank you when the issue count drops below triple digits.

How to Avoid License Violations When Publishing Derivative AI Models

Alan West — Mon, 27 Apr 2026 02:05:15 +0000

So you fine-tuned a model, ran some abliteration passes, maybe merged a few LoRAs together, and now you want to publish it. Cool. But did you check the license on every upstream model you touched?

I've been watching the open-weight AI community long enough to see this pattern repeat itself: someone publishes a derivative model, strips out the attribution, slaps on a different license, and acts surprised when the community notices. It happened again recently in the LocalLLaMA community, and honestly, it keeps happening because people treat model weights like they're somehow exempt from software licensing rules.

They're not.

Why This Keeps Happening

The root cause is a combination of two things: the AI model ecosystem moves fast, and most people publishing derivative models have never had to think about license compliance before.

When you git clone a repo and start modifying code, most developers instinctively know to check the LICENSE file. But when you download model weights from Hugging Face, apply some transformations, and re-upload, that same instinct doesn't kick in. The weights feel like "data" rather than "software," so people treat them differently.

But legally and ethically, a derivative model is a derivative work. If the upstream model uses a license that requires attribution — and most of them do — you need to provide it.

The Specific Problem: Abliteration and Derivative Works

Abliteration (the technique for removing refusal directions from model activations) is a great example of where this gets tricky. You're taking an existing model, running a transformation on its weights, and producing something new. The output model is absolutely a derivative work.

Here's what a typical abliteration script looks like:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

# Load the base model you're modifying
model = AutoModelForCausalLM.from_pretrained("original-model-id")
tokenizer = AutoTokenizer.from_pretrained("original-model-id")

# Identify refusal direction (simplified)
# This is the core of abliteration — finding the activation direction
# associated with refusal behavior and removing it
refusal_dir = get_refusal_direction(model, harmful_prompts, harmless_prompts)

# Modify weights by subtracting the refusal direction
for layer in model.model.layers:
    layer.self_attn.o_proj.weight.data -= (
        torch.outer(refusal_dir, refusal_dir) @ layer.self_attn.o_proj.weight.data
    )

The output of this process is a modified version of original-model-id. Whatever license that original model carries? It still applies to your output. Period.

Step-by-Step: How to Stay Compliant

Here's my checklist for publishing any derivative model work. I use this every time, and it takes maybe 10 minutes.

1. Identify Every Upstream Model

Before you publish anything, trace your lineage. If you merged three models and abliterated the result, you have at least three upstream licenses to check.

# Create a simple lineage file — I keep one in every model repo
cat > MODEL_LINEAGE.md << 'LINEAGE'
## Model Lineage

- **Base model:** org/base-model-v2 (Apache 2.0)
- **Fine-tune source:** researcher/finetuned-variant (CC-BY-4.0)
- **Merge component:** community/specialized-lora (MIT)
- **Technique applied:** Abliteration via orthogonal projection
- **Original abliteration method:** Credit to [original researchers/authors]
LINEAGE

This isn't just good practice — for some licenses, it's literally required.

2. Check License Compatibility

Not all open-source licenses play nicely together. Here are the ones you'll see most often in the model ecosystem:

Apache 2.0 — Permissive. Requires attribution and notice of changes.
MIT — Permissive. Requires copyright notice preservation.
CC-BY-4.0 — Requires attribution. Common for datasets and some models.
CC-BY-SA-4.0 — Attribution + share-alike. Your derivative must use the same or compatible license.
Llama Community License / Custom licenses — Read. Every. Word. These vary wildly.

The share-alike licenses are where people trip up most. If your upstream model uses CC-BY-SA-4.0, you cannot release your derivative under Apache 2.0. The share-alike provision requires your derivative to carry the same license.

3. Provide Proper Attribution

This is the part that takes zero effort and people still skip. Your model card should include:

The name and link to every upstream model
The original authors or organizations
The license of each upstream component
A description of what you changed

# In your README.md / model card metadata
---
license: cc-by-sa-4.0
base_model:
  - org/base-model-v2
  - researcher/finetuned-variant
tags:
  - abliterated
  - merge
---

## Attribution

This model is a derivative of [org/base-model-v2](link) by Original Org
(Apache 2.0) and [researcher/finetuned-variant](link) by Researcher Name
(CC-BY-SA-4.0).

The abliteration technique used is based on work by [original authors](link).

Modifications: Applied orthogonal projection to remove refusal direction,
then merged with specialized LoRA weights.

4. Verify Before You Upload

I wrote a quick pre-upload check I run before pushing to Hugging Face:

import json
from pathlib import Path

def check_model_compliance(repo_path: str) -> list[str]:
    """Basic compliance checks before publishing a derivative model."""
    issues = []
    repo = Path(repo_path)

    # Check for LICENSE file
    if not (repo / "LICENSE").exists() and not (repo / "LICENSE.md").exists():
        issues.append("MISSING: No LICENSE file found")

    # Check README for attribution section
    readme = repo / "README.md"
    if readme.exists():
        content = readme.read_text().lower()
        if "attribution" not in content and "credit" not in content:
            issues.append("WARNING: README has no attribution section")
        if "base_model" not in content:
            issues.append("WARNING: No base_model specified in metadata")
    else:
        issues.append("MISSING: No README.md found")

    # Check for lineage documentation
    has_lineage = any(
        (repo / f).exists()
        for f in ["MODEL_LINEAGE.md", "ATTRIBUTION.md", "NOTICE"]
    )
    if not has_lineage:
        issues.append("SUGGESTION: Consider adding a MODEL_LINEAGE.md file")

    return issues

# Run it
issues = check_model_compliance("./my-model-repo")
for issue in issues:
    print(f"  {issue}")

Is it sophisticated? No. Does it catch the most common mistakes? Yes.

Prevention: Build the Habit

The AI model ecosystem is still figuring out norms, but the legal framework isn't ambiguous. Derivative works require compliance with upstream licenses. Here's how to make this painless:

Start every project with a lineage doc. Before you even begin training or modifying, document what you're starting from and what license it carries.
Use Hugging Face's model card metadata properly. The base_model and license fields exist for a reason. Fill them out.
When in doubt, ask. Most model authors are happy to clarify their licensing intent. Open an issue or discussion on their repo.
Treat model weights like code. Because from a licensing perspective, they are.

The Bigger Picture

The open-weight AI community is built on trust and reciprocity. When someone publishes their work under a license that says "use this, just give me credit," stripping that credit isn't just a legal violation — it undermines the entire ecosystem that makes open AI development possible.

I've seen communities fracture over exactly this kind of thing. Maintainers stop sharing. Researchers go closed-source. Everyone loses.

Spend the ten minutes. Check your licenses. Write the attribution. It's the lowest-effort, highest-impact thing you can do to keep this ecosystem healthy.