Claude Code can already help you resume work from a project if you move into that working directory and use /resume there.

The limitation is that this is tied to the current working directory. If you want to look back across all of your past work, including sessions from other repositories and directories, that gets awkward.

clauhist is a small CLI tool for that case. It shows your Claude Code history in fzf, lets you browse sessions across working directories, and resume one from the list.

What it shows

Sessions are sorted by recent activity. Each row includes:

• the last activity time
• the project path
• whether the path still exists
• a preview of the first message
• the message count

There is also a preview pane with the session ID, timestamps, and message list. Once you find the one you want, press Enter.

How it works

clauhist reads ~/.claude/history.jsonl, groups entries by session, and passes the result to fzf.

After you select a session, it runs:

claude --resume <session-id>

It does not keep its own database or add another history layer. It is just a thin local browser over Claude Code’s existing history file.

Installation

cargo install clauhist

Or install from source:

git clone https://github.com/lef237/clauhist.git
cd clauhist
cargo install --path .

You also need fzf and Claude Code installed.

Usage

clauhist

Main controls:

• Enter: resume the selected session
• type: filter the list
• Ctrl-/: toggle preview
• Ctrl-C: exit

✓ means the project directory still exists. ✗ means it was moved or deleted. You can still resume the session, but cd into the original directory may fail.

Shell integration

If you add this to your shell config:

eval "$(clauhist init zsh)"

then clauhist changes your current shell into the selected project directory before starting Claude Code.

Without this, clauhist uses a subshell for the directory change, so when Claude exits you return to your original directory. bash and fish are supported too.

Local-only

clauhist only reads ~/.claude/history.jsonl and launches claude --resume. It does not send your history anywhere.

That is the whole tool: a simple way to browse past Claude Code sessions across projects and reopen one without moving directory by directory.

GitHub

You can find the repository here 🙂

╭───────────────────────────────────────────────────────────────────────────────────────╮
│ Claude Code History Browser  [Enter: resume  Ctrl-/: toggle preview  Ctrl-C: cancel]  │
├───────────────────────────────────────────────────────────────────────────────────────┤
│ Search:                                                                               │
│ > 2026-03-18 09:12  ✓ ~/projects/myapp      Tell me about Rust error handling…  (12) │
│   2026-03-17 22:45  ✓ ~/sandbox/api-client  Generate client from OpenAPI schema  (8) │
│   2026-03-17 14:30  ✗ ~/old-project         Database migration steps             (3) │
╰───────────────────────────────────────────────────────────────────────────────────────╯

cargo install clauhist

git clone https://github.com/lef237/clauhist.git
cd clauhist
cargo install --path .

https://github.com/lef237/clauhist

I needed to connect to a crypto exchange to build a trading bot. APIs sounded intimidating. Then I installed one Python library and got my balance in three lines. Getting from there to placing actual orders wasn’t much harder.

Here’s the whole path — from creating an account to placing your first order in Python. Including every mistake I made along the way.

What’s an API Key, Anyway?

It’s a password that lets your code talk to the exchange directly, without logging into the website. You hand this key to your Python script, and suddenly your code can check balances, pull price data, and place orders.

Why bother? Because manual trading means staring at charts 24/7. You miss the 3 AM crash because you’re asleep. You hold too long because “maybe it’ll go higher.” An API lets you hand that job to a bot.

Picking an Exchange

For automated trading, fees matter more than anything else. When your bot trades ten times a month, a 0.1% difference in fees compounds over a year.

I run my bot on Bitget, but if I were starting today I’d go with MEXC. Zero maker fees on spot. For a bot that trades automatically, that’s free money you’re not leaving on the table. Account creation is free and takes about five minutes.

Creating Your API Key

Once you have an account:

1. Log in → Profile icon → API Management
2. Click “Create API Key”
3. Permissions: enable Read and Trade. Leave Withdraw OFF. Seriously. Never turn this on.
4. Copy the API key and secret

Save them in a .env file in your project:

API_KEY=your_api_key_here
API_SECRET=your_secret_here

Add .env to your .gitignore before your first commit. If you push your API key to GitHub, congratulations — you just published your exchange credentials to the entire internet.

Connecting with ccxt

ccxt is a Python library that talks to 100+ exchanges with the same interface. Code you write for MEXC works on Bitget, Binance, OKX — same syntax.

pip install ccxt python-dotenv

Fetching your balance. This is the three-liner:

import ccxt
import os
from dotenv import load_dotenv

load_dotenv()

exchange = ccxt.mexc({
    'apiKey': os.getenv('API_KEY'),
    'secret': os.getenv('API_SECRET'),
    'enableRateLimit': True,
})

# The actual work — three lines
balance = exchange.fetch_balance()
usdt = balance['USDT']['total']
print(f'USDT balance: {usdt}')

That’s it. It works.

enableRateLimit: True tells ccxt to throttle requests automatically. Without it, you’ll hammer the API too fast and get 429 errors.

Grabbing candlestick data is just as easy:

ohlcv = exchange.fetch_ohlcv('BTC/USDT', '1d', limit=30)
# → [[timestamp, open, high, low, close, volume], ...]

One line gets you 30 days of daily candles. Throw that into a pandas DataFrame, compute your indicators, and you’ve got the bones of a trading bot.

Placing Your First Order

Do not start with real money. Build a DRY_RUN mode first. Your code goes through the entire pipeline — fetching prices, computing signals, deciding whether to buy — but skips the final step of actually sending the order.

Run in DRY_RUN for a week. If nothing weird happens, switch to live with a tiny amount ($1 USDT).

# Market buy
if not DRY_RUN:
    order = exchange.create_market_buy_order('BTC/USDT', amount)
    print(f'Order placed: {order["id"]}')
else:
    print(f'[DRY_RUN] Skipping order: BTC/USDT {amount}')

Simple. create_market_buy_order for market orders, create_limit_buy_order for limit orders. ccxt abstracts away the differences between exchanges, so code written for MEXC runs on Bitget too. (In theory. In practice there are occasional quirks, but it mostly just works.)

Things That Tripped Me Up

Every mistake here is one I actually made.

Rate limits. During development, I was hitting the API in a loop while testing. Even with enableRateLimit: True, rapid-fire requests in a tight loop can exceed the limit. Keep it to about one request per second to be safe.

Accidentally enabling withdrawal permissions. I turned on withdrawal when creating my first key. Caught it fast and turned it back off, but if my .env had leaked, someone could have drained my entire account. Withdrawal permissions stay OFF. Always.

Committing .env to git. Classic. If you commit and push before adding .env to .gitignore, it’s in the git history forever. Force-pushing doesn’t fully remove it. Set up .gitignore first. If you mess this up, immediately regenerate your API keys.

Timestamp drift. If your computer’s clock is off by a few minutes, the exchange rejects your API calls. You’ll see errors like InvalidNonce or Timestamp outside recv_window. Make sure NTP time sync is enabled. (Macs do this automatically; WSL and some Linux setups don’t.)

Minimum order amounts. Every exchange has minimum order sizes, and they vary. Bitget requires ~$5 for BTC/USDT spot orders. Try to place a $1 order and it fails silently or throws an error. MEXC lets you go as low as $1, which makes it better for small-scale testing.

If you don’t have an exchange account yet, you can create one here. Zero fees really does make a difference when you’re running a bot.

Wrapping Up

API access turned out to be way easier than I expected. ccxt handles the messy parts — authentication, rate limiting, exchange-specific quirks — so you don’t have to learn each exchange’s API docs.

The important stuff:

• Withdrawal permissions → OFF
• .env → never in git
• Start with DRY_RUN
• First live test → $1 USDT

Once you’ve got this working, the next step is writing the trading logic — compute a technical indicator, generate a signal, execute. I started with an EMA Crossover strategy. That’s a story for another post.

This post is based on personal experience. Not financial advice — trade at your own risk with money you can afford to lose. This post contains affiliate links.

In 2015, building real-time, compute-heavy web applications often meant navigating the limitations of ephemeral cloud environments. Heroku was the undisputed king of PaaS, but its router had a strict 30-second timeout. If you needed to process heavy, stateful datasets for an active user session, you couldn’t do it on the web dyno.

The solution? A custom, cloud-native worker tier that spun up dedicated processes per user session, retained data in memory, and communicated asynchronously. Here is a look at how to architect this system using Node.js, Socket.IO, Redis, and the Heroku Platform API.

1. The Architecture: A Session-Based Worker Model

Unlike traditional background job queues (like Celery or Resque) where anonymous workers pick up stateless tasks, this architecture requires a 1:1 mapping between a user session and a worker process.

When a user connects via a WebSocket, the system provisions a dedicated worker. This worker loads the user’s specific dataset into memory and waits for commands. Because the worker holds state, subsequent compute and filter operations happen with near-zero latency.

2. The Worker Provider: Local vs. Cloud Forking

To make this developer-friendly, the system needs an environment-aware “Provider” to handle worker provisioning.

In production: When the web dyno recognizes a new session, it makes an authenticated HTTP request to the Heroku Platform API to boot a one-off dyno (e.g., command: "node worker.js --session=xyz").
In development: To avoid API rate limits and speed up testing, the web process simply forks a local child process. An abstract WorkerFactory handles the logic, returning a uniform interface regardless of the underlying environment.

3. Communication: JSON-RPC, Socket.IO, and Redis Lists

Direct process-to-process communication across Heroku dynos isn’t natively supported. Instead, Redis acts as the message broker.

1. The Ingress: The client sends a command over Socket.IO to the web dyno.
2. The Queue: The web dyno formats this as a JSON-RPC 2.0 payload and pushes it to a session-specific Redis list (e.g., session:xyz:queue) using LPUSH.
3. The Polling: The worker dyno continuously polls this list.

Transactional Slice and Truncate

To safely dequeue messages without losing data if the worker crashes, the worker uses Redis transactions (MULTI / EXEC). Instead of popping one item at a time, the worker pulls the entire batch of pending commands and clears the queue atomically:

// Pseudocode for the worker polling loop
redis.multi()
  .lrange('session:xyz:queue', 0, -1) // Slice: Get all pending messages
  .ltrim('session:xyz:queue', 1, 0)   // Truncate: Empty the list
  .exec((err, results) => {
     const messages = results[0];
     if (messages.length > 0) {
        processMessages(messages);
     }
  });

4. In-Memory State and Compute

Once the worker receives a command via the Redis queue, it processes it against the data held in memory. Loading the dataset from a database (like Postgres or MongoDB) happens exactly once when the worker boots.

Fast Filtering via Binary Masking

For complex, multi-faceted filtering (e.g., filtering a catalog of thousands of items by various overlapping criteria), the worker utilizes binary masking.

Instead of iterating through objects and checking string values, each entry is assigned a bitmask representing its attributes. Filter commands from the user are translated into a target bitmask. The worker then processes the compute command by applying bitwise operators (like AND &) against the in-memory array.

This approach takes advantage of V8’s raw processing speed, allowing the worker to filter tens of thousands of records in single-digit milliseconds and push the result IDs back to the web dyno via a Redis pub/sub channel.

5. Bookkeeping and Session Cleanup

Because Heroku one-off dynos cost money (billed by the second), orphaned dynos are a serious risk. Robust bookkeeping is required.

• Managing Workers: The web dyno maintains a Redis Hash mapping Session_ID -> Worker_Dyno_ID (or local PID).
• Heartbeats: The worker periodically writes a heartbeat to a Redis key with an expiration (TTL).
• Expiration & Cleanup: * If the client disconnects, the web dyno explicitly sends a “terminate” JSON-RPC command.
  • If the web dyno crashes and fails to send the termination command, the worker monitors its own idle time. If no commands are received and the WebSocket session heartbeat dies, the worker calls process.exit(0). On Heroku, exiting the process safely shuts down the one-off dyno, stopping the billing meter.

Summary

By combining the flexibility of Heroku’s Platform API, the speed of Redis transactional polling, and the power of in-memory bitwise compute, 2015-era Node.js applications could achieve massive performance gains, bypassing HTTP timeouts and delivering real-time, heavy-duty data processing to the browser.

Sprint 2 Retrospective: Every Promise Kept, Every Decision Delivered

What This Post Is

This is the fourth post in a series documenting the ORCHESTRATE Marketing Platform build — an AI-agent-driven project where every line of code follows Documentation-Driven Test-Driven Development (DD TDD), mechanically enforced by an MCP server that blocks methodology violations.

Sprint 0 retrospective covered infrastructure. Sprint 1 retrospective covered quality gates and monitoring. The Sprint 2 preview promised five specific deliverables. This post reports on whether those promises were kept.

They were. All fifteen tickets. Zero blocked items. Zero skipped phases.

The Numbers

Every ticket followed full DD TDD ceremony: documentation update, document binding, RED (failing tests with evidence), VERIFY (confirm correct failure), GREEN (implement to pass), REFACTOR (improve quality), VALIDATE (full test output with DONE checklist), DONE. Each phase logged a comment with real evidence — test names, assertions, failure output, implementation summaries. The MCP server blocked phase transitions without adequate comments.

Decision D1: Shared Utilities — DELIVERED

Owner: Tess Ter (QA Engineer) | Tickets: OAS-093-T1, OAS-093-T2, OAS-093-T3

The Sprint 1 retro identified duplicated test fixtures across 3+ files. The same API key patterns, rate-limit handling, and V2 test data copy-pasted everywhere. A format change meant updating every copy.

What we built:

• tests/fixtures/sensitive-patterns.ts — 16 JSDoc-documented pattern exports covering API keys (OpenAI, Anthropic, AWS, GitHub, Slack, generic), URLs with credentials, connection strings, JWTs, and bearer tokens. Every pattern includes description, regex, and sample values.
• tests/utils/devto-test-utils.ts — Shared checkRateLimit() helper with 429 detection, configurable retry delays, and Vitest skip integration. Extracts the rate-limit-check-and-skip pattern that was duplicated in every Dev.to test.
• tests/fixtures/index.ts — Barrel export re-exporting all fixture modules for single-import convenience.
• Convention documented in service-conventions.md with rules: no inline duplication, JSDoc required, tests required for shared modules, barrel index maintained.

What surprised us: The sensitive-patterns module immediately proved its value — the test for it (shared-fixtures.test.ts) caught that we’d been inconsistent about whether underscore characters appeared in API key patterns. One source of truth, one fix, zero drift.

Decision D2: Result Type Migration — DELIVERED

Owner: Archi Tect (Principal Solution Architect) | Tickets: OAS-094-T1, OAS-094-T2, OAS-094-T3

Sprint 1 introduced Result<T,E> but only new services used it. Existing services still used try-catch with no documentation about which pattern applied where.

What we built:

• ADR: Result/Try-Catch Error Handling Boundary — Documents the rule: internal services use Result<T,E>, HTTP-boundary services use try-catch. The ADR explains why: internal callers can structurally enforce error checking via isOk()/isErr(), while HTTP boundaries need try-catch for network unpredictability and status code mapping.
• database.ts migrated to Result pattern — getDatabase(), getHealth(), and getMigrationStatus() now return Result<T> instead of throwing. Callers check isOk(result) before accessing result.data. The migration preserved backward compatibility for the HTTP layer, which wraps Result values in try-catch at the API boundary.
• startup-validator.ts migrated to Result pattern — All validation methods (validateDatabase, validateTables, validateScheduler) return Result<ValidationResult>. The startup sequence aggregates results without throwing.

What surprised us: The database.ts migration revealed that getHealth() had an implicit error swallowing pattern — a catch block that returned { status: 'error' } without any indication of what failed. The Result migration forced explicit error messages: err('Database health check failed: ' + e.message, 'DB_ERROR'). Same code, better observability.

Decision D3: Migration Framework — DELIVERED

Owner: Query Quinn (Database Administrator) | Tickets: OAS-095-T1, OAS-095-T2, OAS-095-T3

No migration framework existed. Schema changes were manual, untracked, and unreproducible across environments.

What we built:

• ADR: Forward-Only SQL Migration Strategy — Documents the decision to use numbered migrations (001_initial.sql, 002_add_index.sql) with a schema_migrations tracking table. Forward-only (no rollbacks) because SQLite doesn’t support transactional DDL rollback reliably. The ADR explicitly rejects ORMs and down-migration patterns with documented trade-off analysis.
• migration-runner.ts — Core engine: discovers .sql files from a migrations directory, sorts by numeric prefix, tracks applied versions in schema_migrations table, applies pending migrations in order. Returns Result<MigrationResult> (uses the D2 pattern). Includes getMigrationStatus() for health dashboard integration.
• 001_initial.sql — First migration establishing the baseline schema. Integrated into database.ts initialization flow — migrations run automatically on startup.

What surprised us: The migration runner needed to handle the bootstrap problem: you need the schema_migrations table to track migrations, but creating that table is itself a migration. Solution: the runner creates schema_migrations as a prerequisite before processing any numbered migration files. Simple, but the test for it (OAS-095-T2) caught a race condition where two concurrent startups could both try to create the table.

Decision D4: Structured Observability — DELIVERED

Owner: Pip Line (DevOps) + React Ive (Frontend) | Tickets: OAS-096-T1, OAS-096-T2, OAS-096-T3

The startup validator and health dashboard existed but didn’t communicate. Static data, no refresh, no event structure.

What we built:

• health-events.ts — Structured HealthEvent emitter in the startup validator. Events have type (check_start, check_pass, check_fail, check_skip), component name, timestamp, optional message and details. Stored in a bounded ring buffer (last 100 events) accessible via API.
• /api/health/events endpoint — New REST route returning structured event history. Supports ?since= parameter for incremental polling. Returns { events: HealthEvent[], total: number, since: string }.
• Health.tsx auto-refresh — 30-second configurable interval with pause/resume toggle. Last-updated timestamp shows when data was last fetched. Amber stale-data warning appears after 60 seconds without a successful refresh. useEffect cleanup properly clears intervals on unmount or pause.

What surprised us: The auto-refresh implementation exposed a subtle React pattern: the useEffect dependency array must include paused so the interval restarts when the user toggles. Without it, resuming after pause doesn’t restart the interval. The structural test (health-dashboard-refresh.test.ts) validates this by checking that paused appears in a useEffect dependency array — the kind of bug that’s invisible in manual testing but breaks silently.

Decision D5: Path Convention — DELIVERED

Owner: Api Endor (Backend Developer) | Tickets: OAS-097-T1, OAS-097-T2, OAS-097-T3

Windows path separators broke tests in Sprint 1. Fixed manually, but nothing prevented regression.

What we built:

• ESLint no-restricted-syntax rule — Two AST selectors in .eslintrc.json: one catches BinaryExpression with '/' literal (e.g., dir + '/'), the other catches multi-expression TemplateLiteral patterns. Both at warn severity with messages explaining to use path.join() for Windows compatibility.
• path-audit.test.ts — Regression guard that recursively scans all .ts files in src/ and tests/ for file-system path concatenation violations. Exempts URL construction patterns (https://, API_BASE, fetch(, /api/ routes). Verifies key infrastructure files (startup-validator.ts, migration-runner.ts, database.ts) import path or join from the path module.
• Convention entry in service-conventions.md — Documents the standard with severity HIGH, correct patterns (path.join examples), anti-patterns (string concatenation examples), URL exception documentation, and enforcement references.

What surprised us: The audit found zero existing violations. Sprint 1 had already fixed all file-system path concatenation. All 56 template literal matches in src/ were URL construction (API_BASE, apiBase, fetch calls). The value of D5 isn’t fixing violations — it’s preventing them. The ESLint rule and audit test are regression guards. The convention_manage MCP tool turned out to be blocked in DELIVERING mode, so we documented the convention in the file-based service-conventions.md instead — which is where developers actually look.

What We Learned

Retro decisions are testable hypotheses

The Sprint 1 retro identified five friction points. Sprint 2 treated each as a hypothesis: “If we build X, friction Y goes away.” All five hypotheses held. The shared fixtures module (D1) immediately caught a pattern inconsistency. The Result migration (D2) revealed hidden error swallowing. The migration framework (D3) caught a bootstrap race condition. The observability loop (D4) exposed a React dependency bug. The path convention (D5) confirmed Sprint 1 had already fixed all violations — but now regression is prevented.

ADRs before code prevent scope creep

Both D2 and D3 started with Architecture Decision Records. The D2 ADR established the Result/try-catch boundary before any migration code was written. This meant the database.ts migration knew exactly where to stop — at the HTTP boundary. Without the ADR, it would have been tempting to migrate the API routes too, which would have been wrong (HTTP boundaries genuinely need try-catch for network error handling).

Structural tests are the right tool for convention enforcement

Every Sprint 2 ticket used structural tests — tests that read source files and verify patterns rather than executing runtime behavior. eslint-path-rule.test.ts verifies the ESLint config has the right selectors. path-audit.test.ts scans all source for violations. path-convention.test.ts verifies the convention documentation exists and covers the right topics. These tests don’t run the code — they verify the codebase structure. This pattern emerged in Sprint 1 and became the dominant testing strategy in Sprint 2.

The MCP enforcement model scales

Sprint 2 was the third sprint under full DD TDD enforcement. Fifteen tickets, each with 6+ mandatory phase transitions, each requiring logged evidence comments. The MCP server blocked every shortcut attempt. Phase transitions without comments: blocked. Comments without evidence keywords: blocked. Skipping from RED to GREEN without VERIFY: blocked. The enforcement is mechanical and predictable. After three sprints, the ceremony feels less like overhead and more like a safety harness — you don’t notice it until it catches you.

What’s Next

Sprint 2 closes the technical debt chapter. The foundation is now:

• 1,190 tests across 72 files, all passing
• Result pattern for internal error handling, try-catch at HTTP boundaries
• Migration framework for reproducible schema changes
• Structured observability from validator through API to dashboard
• Convention enforcement via ESLint, audit tests, and documented standards
• Shared test infrastructure preventing fixture drift

V3 inception is complete. Eight sprints are planned: content sourcing, audio engine, media orchestration, YouTube pipeline, podcast production, quality gates, and unified dashboard. Sprint 2 was the bridge — now the V3 features have a foundation worth building on.

Provenance

This post is part of a series documenting the ORCHESTRATE Marketing Platform build. All development is AI-agent-driven with full traceability through the ORCHESTRATE Agile MCP framework.

Books on the ORCHESTRATE method: The ORCHESTRATE Method | ORCHESTRATE for AI Development | Platform: iamhitl.com

Prompt engineering has rapidly evolved from a niche skill into a foundational discipline within modern AI development, especially with the rise of large language models (LLMs). At its core, prompt engineering is the practice of designing structured inputs that guide models to produce accurate, relevant, and context-aware outputs. Unlike traditional programming, where logic is explicitly coded, prompt engineering relies on shaping model behavior through carefully crafted language. This paradigm shift demands a blend of technical understanding, linguistic precision, and iterative experimentation, making it a critical competency for developers, data scientists, and AI practitioners.
One of the most important best practices in prompt engineering is clarity and specificity. Ambiguous prompts often lead to vague or inconsistent outputs, while precise instructions significantly improve reliability. Effective prompts clearly define the task, expected format, constraints, and context. Techniques such as role prompting (e.g., assigning the model a specific role like “act as a cybersecurity analyst”), instruction chaining, and step-by-step reasoning (often referred to as chain-of-thought prompting) help in decomposing complex problems. Additionally, providing examples through few-shot prompting allows models to infer patterns and produce more aligned responses, especially in structured tasks like classification, summarization, or code generation.
Another key principle is controlling output variability and hallucination. Since LLMs generate probabilistic responses, prompt designers must implement constraints to ensure factual consistency and minimize errors. This includes specifying output formats (JSON, bullet points, tables), enforcing delimiters, and explicitly instructing the model to avoid assumptions or unsupported claims. Temperature and sampling parameters, although handled at the API level, complement prompt design by influencing creativity versus determinism. In high-stakes applications such as healthcare or finance, prompts must also include verification steps or encourage the model to cite sources and express uncertainty when needed.
Frameworks for prompt engineering provide structured approaches to designing and evaluating prompts. One widely adopted framework is the “CRISP” model, Context, Role, Instruction, Steps, and Parameters, which ensures that prompts are comprehensive and aligned with the intended outcome. Another emerging approach is prompt templates combined with dynamic variable injection, often used in production systems to standardize interactions across use cases. Retrieval-Augmented Generation (RAG) frameworks further enhance prompt effectiveness by injecting external knowledge into the context, enabling models to produce up-to-date and domain-specific responses. These frameworks are commonly integrated into orchestration tools and pipelines, forming the backbone of scalable AI applications.
Evaluation and iteration are essential to mastering prompt engineering. Unlike deterministic code, prompts must be continuously tested against diverse inputs to ensure robustness. Metrics such as accuracy, relevance, coherence, and latency play a crucial role in assessing performance. A/B testing different prompt variations, maintaining prompt versioning, and leveraging human-in-the-loop feedback are common strategies for refinement. Additionally, automated evaluation techniques, including embedding-based similarity scoring and benchmark datasets, are increasingly used to standardize prompt performance across systems.
As generative AI continues to mature, prompt engineering is expected to evolve into a more formalized discipline, intersecting with areas like model fine-tuning, alignment, and human-computer interaction. While future advancements may abstract some of its complexities, the ability to effectively communicate intent to AI systems will remain a valuable skill. Ultimately, prompt engineering is not just about getting better outputs, it is about building reliable, transparent, and scalable AI systems that align with human goals and expectations.

I run six web apps as a solo developer with a day job. Here is the exact stack and how the pieces fit together.

Hosting and deployment: five apps are on Lovable (one-click deploy from their builder), one (ContentForge) is on Vercel. All use custom domains through Cloudflare for DNS and SSL.

Database: Supabase (Postgres) for all six apps plus a central “command” project that holds cross-app analytics, book sales data, and the marketing engine.

Payments: Stripe with tiered pricing on every app. Free tier, mid tier ($3.99-4.99/mo), premium tier ($7.99-9.99/mo). No paying customers yet, but the infrastructure is ready.

Analytics: PostHog for product analytics across all six apps. One project, events tagged by app name. This lets me compare engagement across apps in a single dashboard.

Error tracking: Sentry with one org and separate projects per app.

Uptime: BetterStack monitors all six domains.

Email: Resend for transactional email.

The key architectural decision: one central Supabase project acts as the hub. It connects to each app’s project through Supabase edge functions. This gives me a single place to query across all six apps, run marketing automation, and track portfolio-level metrics without logging into six different dashboards.

Current numbers are small (364 total pageviews last month across all six apps), but the monitoring infrastructure scales. Every tool on this list either has a generous free tier or has a free tier that covers my current scale.

The apps: contentforgehq.com, momentumfit.app, thehomegrown.app, getpillpal.app, pawformance.app, palettepro.design.

Code and details at chadtdyar.com.

Originally published on TechPulse Daily

Here’s something nobody in developer tooling wants to admit: if you squint hard enough, every AI coding agent on the market right now is the same product wearing a different skin.

Cursor. Windsurf. Claude Code. GitHub Copilot Workspace. Aider. Cline. Zed AI. They all do the same thing — take a prompt, read your codebase, generate or edit code, and hope you click “Accept.” The models underneath are increasingly identical (Claude, GPT, or Gemini via API). The UX patterns have converged so thoroughly that switching between them feels like switching between Chrome and Edge.

And yet, billions of dollars in venture capital are being poured into convincing you that this particular wrapper around Claude Opus 4 is fundamentally different from that particular wrapper around Claude Opus 4.

I’ve spent the last three months rotating through all of them on real production work. Here’s the uncomfortable truth.

The Great Convergence

In 2023, AI coding meant autocomplete. GitHub Copilot suggested the next line, you hit Tab, and felt like a wizard.

By mid-2024, Cursor showed up and said: “What if the AI could edit whole files?” Suddenly we had inline diffs, multi-file edits, and chat-driven development.

Then everyone copied it.

By March 2026, here’s what every single one of these tools offers:

• Codebase-aware chat — ask questions about your project
• Multi-file editing — generate diffs across multiple files from a single prompt
• Terminal integration — run commands, read output, self-correct
• Context management — @-mentions, file references, automatic context detection
• Agent mode — let the AI plan and execute multi-step tasks autonomously

That’s the entire feature matrix. Every product checks every box. The differences are cosmetic.

Where They Actually Differ

Cursor still has the most polished IDE experience. Inline diff rendering is best-in-class, and Composer (multi-file agent mode) has had two years to mature.

Claude Code took the opposite bet: terminal-first, no GUI bloat. For pure code generation quality, Claude Code with Opus 4 is probably the ceiling right now.

GitHub Copilot has distribution. Pre-installed in every VS Code instance on earth. Its real advantage is the GitHub ecosystem — PR summaries, issue-to-code flows, Actions integration.

Aider is the open-source champion. Free, runs with any model, works in any terminal. No subscription, no vendor lock-in.

Cline is the VS Code extension that acts like a full agent. The most “autonomous” of the bunch.

Here’s the thing: in a blind test where I used each tool for a week on the same project, the code output quality was nearly identical when all were pointed at Claude Opus 4. The model is the model. The wrapper is just… a wrapper.

The Real War: Workflow Lock-In

So if the AI is the same, what are these companies actually competing on?

Your workflow.

• Cursor wants to be your IDE (forked VS Code = full control)
• GitHub Copilot wants to own the pipeline (Code → PR → Review → Deploy)
• Claude Code wants to own the model relationship (no middleman)
• Open-source tools (Aider, Cline, OpenClaw) want to make sure nobody owns you at all

This is the actual axis of competition. Not “whose AI is smarter” but “whose workflow jail do you want to live in.”

The Open-Source Counterargument

The proprietary AI coding agents are building on borrowed time.

Cursor is a VS Code fork — perpetually one Microsoft decision away from irrelevance. If GitHub Copilot reaches feature parity, Cursor’s value proposition is “we got there first.” That’s not a moat.

The tools that survive long-term:

• Aider — a Python script that talks to an API. No platform risk.
• Cline — a VS Code extension, not a fork. Rides updates for free.
• Claude Code — Anthropic controls the model. First to exploit Claude 5.
• OpenClaw — playing a different game entirely. While coding agents focus on IDEs, OpenClaw asks: “What if the AI agent wasn’t limited to a code editor?” OpenClaw agents can write code, read your email, manage servers, and do it all through natural conversation.

What I Actually Use

After three months of rotation:

• Greenfield projects: Claude Code (terminal workflow is unbeatable)
• Large existing codebases: Cursor (best codebase indexing and context management)
• Quick fixes and small edits: GitHub Copilot (already there, good enough)
• When I don’t want to pay: Aider + local model via Ollama
• For everything beyond code: OpenClaw (autonomous agents that handle my entire workflow)

The AI coding agent war is a feature convergence race where every product approaches the same asymptote. The winner won’t be the one with the best AI — they all have the same AI. The winner will be the one that owns the workflow you can’t leave.

Choose carefully. Or better yet, choose open source and own your own workflow.

What’s your stack? Drop your AI coding setup in the comments — I’m genuinely curious what combinations people are running in 2026.

From Cloud-First to Local-First: Migrating My AI Agent to a 32B Open-Source Model ($3/day → $0/day)

Yesterday my AI agent cost me $3 to run. Today it costs $0.

Not because I stopped using it — I use it more than ever. I migrated from a cloud-hosted model (Anthropic’s Claude Haiku 4-5) to a locally-running open-source model (Qwen 2.5-32B via Ollama) on my MacBook Pro M3 Pro.

This is the full story: what I tried, what failed, what worked, and the gotchas nobody warns you about.

The Starting Point

Before migration:

• Main agent: Claude Haiku 4-5 (Anthropic cloud)
• Context window: 200,000 tokens
• Cost: ~$3/day for active use ($0.80/M input, $4/M output)
• Privacy: Every prompt, every file read, every tool output → sent to Anthropic’s servers
• Latency: 200-500ms per request (network round-trip)
• Uptime: Dependent on Anthropic’s API availability

The agent runs 24/7, handling orchestration, file management, cron jobs, subagent delegation, and memory management. At $3/day, that’s $90/month just for the main agent — not counting subagent calls to Claude Opus for complex tasks.

The Motivation

Three drivers pushed me to go local:

1. Cost. $90/month for a glorified orchestrator felt wrong when open-source models can run the same workload for free.

2. Privacy. My agent reads my files, my memory, my daily journals. Every tool output — including file contents, git diffs, and system diagnostics — gets sent to the cloud as context. That’s a lot of private data flowing to a third party.

3. Independence. When Anthropic has an outage, my agent goes down. When they deprecate a model (Claude 3 Haiku → Haiku 4-5), my config breaks. I wanted zero external dependencies for core operations.

The Evaluation: 5 Candidates, 5 Failures

I started by evaluating every local model I had installed:

Round 1: The Small Models

None of them worked as a main agent.

The small models (7B-8B) couldn’t handle the reasoning complexity of orchestrating subagents, managing memory, and making architectural decisions. The 14B was a coding specialist that struggled with general tasks. The 30B was smart enough but consumed so much VRAM that nothing else could run alongside it.

Round 2: The Big Candidates

I needed something bigger. The requirements:

• 128k+ context window (agent sessions routinely hit 50-100k tokens)
• ≤22GB VRAM (leaving headroom for subagents on 36GB machine)
• Strong reasoning (orchestration requires planning, delegation, error recovery)

Three candidates emerged:

• Mixtral 8x7B: Sparse mixture-of-experts. Only 12.5B parameters active per token, but the full 46.7B model needs to be in memory. At 29-32GB, it would leave only 4-7GB headroom. Too tight.

• Llama 3.1 70B: The quality king. But at 36-39GB with context, it literally doesn’t fit in 36GB. Dead on arrival.

• Qwen 2.5-32B: The Goldilocks model. 19GB base, ~22GB with full context, leaving 14GB of headroom. Strong reasoning benchmarks (MMLU 83.3, HumanEval 80+). 128k context window. Available on Ollama.

Winner: Qwen 2.5-32B. Not even close.

The Migration

Step 1: Pull the Model

ollama pull qwen2.5:32b
# Downloaded 19GB in ~10 minutes

Gotcha #1: I initially tried to pull qwen2.5:32b-instruct-q4_K_M because my research said that was the optimal quantization. Ollama returned 400 Bad Request: invalid model name. Ollama doesn’t use quantization suffixes in pull commands — the default tag already uses an appropriate quantization. Just use qwen2.5:32b.

Step 2: Update the Config

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/qwen2.5:32b"
      }
    }
  }
}

Gotcha #2: My config management system auto-touches the config file on certain events (model reloads, heartbeat cycles). If you edit the file and something triggers a reload before your changes are picked up, your edits get overwritten. I had to verify my changes persisted by checking the file after a full restart cycle.

Step 3: Update the Warmup Rotation

Old warmup (4 small models):

# mistral:7b → qwen3:8b → llama3.1:8b → qwen2.5-coder:14b

New warmup (2 small + 1 large):

curl -s http://localhost:11434/api/generate 
  -d '{"model":"mistral:7b","prompt":"","keep_alive":"10m"}' && sleep 2
curl -s http://localhost:11434/api/generate 
  -d '{"model":"qwen2.5:32b","prompt":"","keep_alive":"10m"}' && sleep 2
curl -s http://localhost:11434/api/generate 
  -d '{"model":"llama3.1:8b","prompt":"","keep_alive":"10m"}' && sleep 2

VRAM budget: mistral (4.4GB) + qwen2.5:32b (19GB) + llama3.1 (4.9GB) = 28.3GB — leaves 7.7GB headroom.

Gotcha #3: I deleted the old models (qwen3:8b, qwen2.5-coder:14b) to free disk space, but forgot to update the warmup cron. The cron kept trying to load deleted models every 4 minutes, generating errors that polluted my logs for an hour before I noticed. Always update your crons when you change your model lineup.

Step 4: Update Delegate Routing

My subagent routing table maps task types to models:

{
  "bookkeeping": "ollama/mistral:7b",
  "formatting": "ollama/mistral:7b",
  "status": "ollama/mistral:7b",
  "writing": "ollama/llama3.1:8b",
  "coding": "ollama/qwen2.5:32b",
  "research": "ollama/qwen2.5:32b",
  "strategy": "ollama/qwen2.5:32b",
  "quick": "ollama/mistral:7b"
}

Heavy tasks (coding, research, strategy) go to the 32B model. Light tasks (formatting, status checks) go to mistral:7b for speed.

Step 5: Keep Cloud as Emergency Fallback

I didn’t delete my Anthropic credentials. Haiku 4-5 is still configured as a fallback:

{
  "models": {
    "anthropic/claude-haiku-4-5": {},
    "anthropic/claude-opus-4-6": {}
  }
}

If the local model fails, the system can fall back to cloud. This has happened zero times in 24 hours, but the safety net exists.

Performance Comparison

After running both setups for a full day each:

Trade-offs:

• Throughput is lower (15-25 t/s vs 50-80 t/s) — acceptable for orchestration tasks
• Context window is smaller (128k vs 200k) — manageable with context hygiene
• Reasoning quality dropped slightly — compensated by using Opus for complex subagent tasks
• Latency actually improved — no network round-trip

Lessons Learned

1. Model Tags Matter

qwen2.5:32b ≠ qwen2.5:32b-instruct-q4_K_M. Ollama has its own tag system. Always check ollama list to see exactly what’s installed and use that exact tag in your config.

2. GPU Contention is Real

Running 3 subagent requests on qwen2.5:32b simultaneously caused all 3 to stall for 23+ minutes. Large models must process requests sequentially, not in parallel. Queue your subagent tasks.

3. Config Persistence is Not Guaranteed

If your orchestration system auto-writes config files, your manual edits may be overwritten. Use version control (git) for your config and verify changes persist after restart cycles.

4. Delete Models Last

I deleted qwen3:8b before updating every reference to it. Crons, warmup scripts, delegate routing tables — all broke simultaneously. Update all references first, verify, then delete.

5. The 32B Sweet Spot

On 36GB Apple Silicon, 32B parameter models hit a sweet spot: smart enough for real reasoning, small enough to leave room for subagents. Anything larger (70B) doesn’t fit. Anything smaller (8B) can’t reason well enough for orchestration.

The Bottom Line

The migration took about 3 hours of active work (including all the mistakes documented above). It will save $1,080/year and keep every byte of data on my machine.

Is the local model as smart as Claude Haiku? No. Is it smart enough to orchestrate a fleet of AI agents, manage memory, run cron jobs, and delegate tasks? Absolutely.

For $0/month, that’s more than enough.

By Xaden | XadenAi
Running a fully local AI agent fleet for $0/month. Follow along to learn how. ⚡

Been freelancing for several years. Tired of manually scanning job listings trying to guess which ones fit my stack.

So I built a tool: embed your profile once, rank job listings by semantic similarity. No keyword rules — pure vector search.

How It Works

1. Parse your profile (title, stack, portfolio) into a rich text chunk
2. Embed it with BAAI/bge-base-en-v1.5 (768-dim) → store in Qdrant
3. Embed each job listing the same way
4. Rank by cosine similarity

Real Results on 6 Sample Jobs

Rank  Score  Job
  1   0.87   Senior AI/ML Engineer – Multi-Agent Systems     ← correct
  2   0.83   Full-Stack – Next.js + Python AI Backend        ← correct
  3   0.79   Backend Engineer – FastAPI + PostgreSQL         ← correct
  4   0.68   AI Chatbot Developer – GPT-4 Integration        ← fair
  5   0.71   AWS Solutions Architect – DynamoDB/Cognito      ← correct
  6   0.41   React Native Developer – iOS/Android            ← correctly last

Most interesting: the React Native role scored 0.41 despite “React” appearing multiple times in my profile. Semantic context beats keyword matching.

What Surprised Me

Portfolio items matter a lot for match quality. When I added my AI platform (LaunchMentor.ai) and AWS compliance project to the profile text, match scores on AI/cloud jobs improved noticeably.

Usage

python3 matcher.py index-profile       # embed your profile
python3 matcher.py add-csv jobs.csv    # add job listings
python3 matcher.py match --top 10      # ranked output

Stack: Python · Qdrant (local) · sentence-transformers (BGE-base-en-v1.5) · Click · Rich

Repo: github.com/prog585/freelance-tools

Anyone else doing semantic filtering on job listings? Curious if there are better approaches.

Building LaunchMentor.ai — AI market intelligence for founders validating startup ideas.

The Problem

You run a solid demo. The prospect seems interested. You follow up a couple of times — no response. Two weeks pass. Then you get a terse email: “We went with another vendor.”

Here’s what you didn’t know: in that quiet two-week window, someone from that company visited your pricing page four times. They were still evaluating. They just weren’t talking to you.

Most sales teams never find out. The signal was there — it just wasn’t routed anywhere useful.

This post walks through building a lightweight tracker that watches your pricing and docs pages, matches visitors to your open opportunities, and fires a Slack alert to the right rep when a known prospect re-engages. Total cost: $0–$20/month.

Why Most CRMs Miss This Signal

CRMs are rep-activity systems. They track calls logged, emails sent, and stage changes — actions your team takes. They’re not built to passively observe prospect behavior between touchpoints.

Intent data platforms do exist, but they operate at a different layer. They aggregate behavioral signals across a network of publisher sites and return scores like “company X is researching topic Y.” Useful for top-of-funnel discovery, but at $500–$1,500/month, they’re overkill if you just want to know when a known account is back on your own site.

What you actually want is simpler: per-account visibility into who’s hitting your own pages, matched against the deals already in your pipeline.

The Signal Pattern

The core logic is straightforward:

1. Your web server (or CDN) logs every request, including IP address and URL path
2. You run a small process that reads those logs and checks whether any IPs belong to domains in your prospect list
3. For IPs you don’t recognize, you hit a free enrichment API to resolve them to a company
4. If there’s a match, you look up the associated rep and open opportunity
5. You post a Slack message: “Acme Corp just visited /pricing — last contact was 9 days ago”

No reverse-proxy magic. No JavaScript tracking pixel that gets blocked by ad blockers. Just server-side log processing.

Using Apify for Public Signal Crawling

If you want to expand beyond your own logs — for example, tracking mentions of your company or category on public forums — Apify’s website-content-crawler is a practical lightweight option. You can schedule runs that pull structured data from public pages and feed it into the same enrichment pipeline.

For the core use case (your own site traffic), you don’t need Apify. But if you’re building a broader signal layer, it pairs well with the IP enrichment approach below.

The Code

Here’s a full working Node.js script. It reads an Nginx access log, resolves IPs to companies using ipinfo.io (free tier: 50k requests/month), matches against a local prospect list, and fires a Slack alert.

Prerequisites

npm install axios

prospects.json

Store your open opportunities as a simple JSON file:

[
  {
    "domain": "acmecorp.com",
    "company": "Acme Corp",
    "rep_slack": "@jane",
    "last_contact": "2026-03-19"
  },
  {
    "domain": "globex.io",
    "company": "Globex",
    "rep_slack": "@carlos",
    "last_contact": "2026-03-10"
  }
]

signal-tracker.js

const fs = require("fs");
const readline = require("readline");
const axios = require("axios");

const IPINFO_TOKEN = process.env.IPINFO_TOKEN || "";
const SLACK_WEBHOOK = process.env.SLACK_WEBHOOK_URL || "";
const LOG_FILE = process.env.NGINX_LOG || "/var/log/nginx/access.log";
const PROSPECTS_FILE = process.env.PROSPECTS_FILE || "./prospects.json";
const WATCH_PATHS = ["/pricing", "/docs", "/plans"];

const prospects = JSON.parse(fs.readFileSync(PROSPECTS_FILE, "utf8"));

// Parse a single Nginx combined log line
function parseLogLine(line) {
  const match = line.match(/^(S+) S+ S+ [([^]]+)] "(w+) (S+)/);
  if (!match) return null;
  return { ip: match[1], timestamp: match[2], method: match[3], path: match[4] };
}

// Resolve an IP to an org/domain via ipinfo.io
async function resolveIp(ip) {
  try {
    const url = IPINFO_TOKEN
      ? `https://ipinfo.io/${ip}?token=${IPINFO_TOKEN}`
      : `https://ipinfo.io/${ip}/json`;
    const { data } = await axios.get(url, { timeout: 3000 });
    // org field looks like "AS12345 Acme Corp" — also check hostname
    return {
      org: data.org || "",
      hostname: data.hostname || "",
    };
  } catch {
    return { org: "", hostname: "" };
  }
}

// Match resolved info against prospect list
function matchProspect(hostname, org) {
  return prospects.find((p) => {
    const domain = p.domain.toLowerCase();
    return (
      hostname.toLowerCase().includes(domain) ||
      org.toLowerCase().includes(domain.split(".")[0])
    );
  });
}

// Days since last contact
function daysSince(dateStr) {
  const last = new Date(dateStr);
  const now = new Date();
  return Math.floor((now - last) / (1000 * 60 * 60 * 24));
}

// Post a Slack alert
async function sendSlackAlert(prospect, path) {
  const days = daysSince(prospect.last_contact);
  const text =
    `*Sales Signal* — ${prospect.company} just visited `${path}`n` +
    `Rep: ${prospect.rep_slack} | Last contact: ${days} day${days !== 1 ? "s" : ""} ago`;
  await axios.post(SLACK_WEBHOOK, { text }, { timeout: 5000 });
  console.log(`Alert sent for ${prospect.company}`);
}

// Main: tail the log and process new lines
async function processLog() {
  const alerted = new Set(); // avoid duplicate alerts in one run
  const rl = readline.createInterface({ input: fs.createReadStream(LOG_FILE) });

  for await (const line of rl) {
    const entry = parseLogLine(line);
    if (!entry) continue;
    if (!WATCH_PATHS.some((p) => entry.path.startsWith(p))) continue;

    const key = `${entry.ip}:${entry.path}`;
    if (alerted.has(key)) continue;

    const { org, hostname } = await resolveIp(entry.ip);
    const prospect = matchProspect(hostname, org);

    if (prospect) {
      alerted.add(key);
      await sendSlackAlert(prospect, entry.path);
    }
  }
}

processLog().catch(console.error);

Running it

IPINFO_TOKEN=your_token 
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/... 
NGINX_LOG=/var/log/nginx/access.log 
node signal-tracker.js

For continuous monitoring, drop this in a cron job that runs every 15–30 minutes against a rolling log window, or use a tool like tail -f piped into a long-running process.

Alert Routing

The Slack message structure above is intentionally minimal:

• Company name — so the rep knows immediately who it is
• Page visited — /pricing carries different intent than /docs/api
• Days since last contact — the number that drives urgency

If your CRM has an API, you can extend matchProspect to pull the live opportunity stage and add that to the alert. HubSpot and Pipedrive both offer free-tier API access.

Enrichment Fallback: Clearbit and Hunter

ipinfo.io resolves IPs to ISP/org names, which works well for companies with dedicated IP ranges (common with mid-market and enterprise accounts). For smaller companies on shared hosting or consumer ISPs, you’ll get noise.

Two fallback options:

• Clearbit Reveal — reverse-IP to company, paid but accurate
• Hunter.io — domain-to-company lookup; useful if you can extract a domain from a hostname

For most early-stage pipelines, ipinfo.io free tier is sufficient to catch the accounts that matter most.

Cost Framing

Compare that to enterprise intent platforms at $500–$1,500/month. Those platforms serve a different use case — broad market discovery across thousands of companies — but if your goal is monitoring a focused list of 20–200 open opportunities, a targeted setup like this is hard to beat on cost.

What This Won’t Do

Be clear-eyed about the limits:

• VPN and residential IPs — you won’t match these reliably
• Mobile traffic — carrier-grade NAT makes IP attribution unreliable
• Privacy regulations — if you’re processing traffic from EEA users, review your GDPR obligations before logging IPs server-side

The signal is probabilistic, not perfect. Treat it as a prompt to reach out, not as confirmed buying intent.

Next Steps

Once the basic pipeline works, a few natural extensions:

1. Track a wider set of pages — add /case-studies, /security, /integrations as secondary signals
2. Log to a database — store matches with timestamps so you can see visit frequency over time
3. Weight by recency — an account that visited three times in 48 hours is a stronger signal than one visit two weeks ago
4. Integrate with your CRM — auto-create a task or update the opportunity’s “last prospect activity” field

The core pattern — log ingestion, IP enrichment, prospect matching, alert routing — is reusable across a lot of similar sales-signal problems. Build it once, then layer on the signals that matter for your pipeline.