DEV Community: PicklePixel

How I Reverse-Engineered Claude Code's Hidden Pet System

PicklePixel — Wed, 01 Apr 2026 17:33:55 +0000

I was poking around Claude Code's source one evening and found something I wasn't supposed to see: a full gacha companion pet system, hidden behind a compile-time feature flag. A little ASCII creature that sits beside your terminal input, occasionally comments in a speech bubble, and is permanently bound to your Anthropic account. Your buddy is deterministic. Same account, same pet, every single time. No rerolls.

Naturally, I wanted a legendary dragon. Here's how I cracked it.

What's Actually in There

The buddy system lives across four files inside Claude Code's codebase:

buddy/types.ts defines 18 species, 5 rarities, 6 eye styles, 8 hats, and 5 stats
buddy/companion.ts implements the PRNG, hash function, roll algorithm, and tamper protection
buddy/sprites.ts has ASCII art for every species (three animation frames each, a hat overlay system, and a render pipeline)
buddy/prompt.ts holds a system prompt that gets injected into Claude so it knows how to coexist with the pet without impersonating it

The feature is gated behind a BUDDY compile-time flag. When the flag is off, the entire thing gets dead-code-eliminated from the build. It was teased during the first week of April 2026 and is slated for a full launch in May. The /buddy slash command activates it when the flag is on.

Here's what the species look like as ASCII sprites:

DUCK                DRAGON              GHOST
    __              /^\  /^\            .----.
  <(· )___        <  ·  ·  >          / ·  · \
   (  ._>          (   ~~   )         |      |
    `--´            `-vvvv-´          ~`~``~`~

Eighteen species total: duck, goose, blob, cat, dragon, octopus, owl, penguin, turtle, snail, ghost, axolotl, capybara, cactus, robot, rabbit, mushroom, and chonk. Each one has a compact face representation for inline display, three animation frames on a 500ms tick timer, and a hat overlay slot on line zero of the sprite.

One fun detail: every species name in the source code is obfuscated through String.fromCharCode() arrays. "Capybara" collides with an internal Anthropic model codename that's flagged in their repo's excluded-strings.txt, so they encoded all 18 species uniformly to keep their string-scanning tooling happy.

The Gacha Algorithm

Your buddy is a pure function of your identity. The algorithm chains together like this:

Account UUID (from OAuth)
    → concatenate with salt 'friend-2026-401'
    → hash to 32-bit integer
    → seed Mulberry32 PRNG
    → deterministic roll sequence

The PRNG calls happen in strict order: rarity first, then species, then eye, then hat, then shiny, then stats. Changing any earlier roll changes everything after it.

Rarity weights:

Rarity	Probability
Common	60%
Uncommon	25%
Rare	10%
Epic	4%
Legendary	1%

On top of that, there's a 1% shiny chance that rolls independently of rarity. A shiny legendary of a specific species? That's a 0.00056% probability, roughly 1 in 180,000.

Stats are shaped by rarity through a floor system. Legendaries start at a floor of 50 and always max out their peak stat at 100. Commons start at 5 and cap their peak around 84. Each companion gets one peak stat and one dump stat, with the rest falling somewhere in between.

There's an important hash function detail here. Claude Code runs in Bun, so the production hash is Bun.hash(), which is native C wyhash. The Node.js fallback is FNV-1a. These produce completely different values for the same input, which means any tooling running outside Bun cannot reproduce the exact buddy for a given account.

How the Tamper Protection Works

This is the part that got interesting. The buddy system splits companion data into two categories:

Stored in config (~/.claude.json): name, personality, hatchedAt timestamp. These are editable and meant to be personal.

Recomputed every read (called "bones"): rarity, species, eye, hat, shiny, stats. These are derived deterministically from your account hash on every single call to getCompanion().

The tamper protection comes down to a JavaScript spread operation:

export function getCompanion() {
  const stored = getGlobalConfig().companion
  if (!stored) return undefined
  const { bones } = roll(companionUserId())
  return { ...stored, ...bones }
}

Because bones comes second in the spread, it always overwrites anything you manually added to the config. You can edit ~/.claude.json all you want, set rarity: "legendary", and it gets stomped on every read. The recomputed values win, period.

It's clever design. No server-side validation needed, no database, no "lost my save" support tickets. Your buddy is a pure function of your identity, recomputed every time it's needed. The bones are cached by userId + SALT key to avoid redundant computation on the three hot paths: the 500ms sprite tick, per-keystroke prompt input, and per-turn observer.

But here's the thing about client-side enforcement: it's client-side.

The Crack

The entire hack is swapping two variable names. In the minified v2.1.89 binary, getCompanion() compiles down to something like:

{bones:$}=Gh$(Th$());return{...H,...$}

H is the stored config, $ is the recomputed bones. Bones come last, bones win. To flip that:

{bones:$}=Gh$(Th$());return{...$,...H}

Now stored config comes last. Config wins. Whatever you write to ~/.claude.json takes priority over the recomputed values.

The two strings are the exact same byte length, so there's zero offset shift in the binary. No padding, no realignment, no relocation table headaches. You find the pattern, swap H and $, write it back. That's the whole patch.

I wrote a Node.js patcher that automates the whole thing in a single command. Design your buddy on the web creator, copy the JSON, run node buddy-crack.js, and it patches the binary and injects your companion in one step. It auto-reads from your clipboard, so you don't even need to pass arguments. That was a deliberate choice: Windows CMD chokes on JSON in command-line arguments because of quote conflicts, so clipboard-first was the only sane default.

The patcher went through a few iterations that taught me things the hard way.

The first version had separate patch and inject commands, which was unnecessarily complex for something that always happens together. Collapsed that into a single flow early on.

Then I nearly destroyed my own Claude Code config. The original config writer would parse ~/.claude.json, fail on any syntax weirdness, fall back to an empty object, and write that back with just the companion data. That nuked everything else in the file: OAuth tokens, permissions, theme settings, tool approvals. On a config that can easily be 50KB, that's catastrophic. The fix was to make the injector surgical. It tries a proper JSON parse first, but if that fails, it now uses a brace-depth parser to find and replace just the companion field in the raw string, leaving everything else untouched. It only creates a fresh file as a last resort, and it backs up ~/.claude.json to .claude.json.bak before touching anything.

Windows threw another curveball. PowerShell's Get-Clipboard mangles UTF-8 characters, so the star eye character ✦ would come through as ?. The fix forces UTF-8 output encoding from PowerShell and auto-repairs known corrupted characters on paste.

The final round of hardening added binary integrity checks (verifying file size after write to catch truncated writes) and auto-restore from backup if the patch fails mid-write. The patcher now handles XDG-standard paths across all three platforms and scans the Claude Code versions directory for additional binaries to patch.

Building the Web Creator

Reading the source also meant I had all the sprite data, so I built a web-based companion designer. Single HTML file, no dependencies, no build system. You pick your species from a grid that shows the actual ASCII faces, choose your rarity, eyes, hat, toggle shiny, and it renders a live preview of the full 5-line sprite with your selections applied.

There's a soul section with two options: generate a name and personality by pasting a prompt into Claude or ChatGPT, or just type them yourself. Hit "Copy Config JSON" and it exports exactly what the patcher expects. The install guide is built into the page with platform-specific instructions for Windows, macOS, and Linux.

The whole thing lives at pickle-pixel.com/buddy. The usage flow is four steps: design your companion, close Claude Code, run the patcher, restart.

pickle-pixel.com

The Attack Surface

While I was documenting everything, I mapped out every possible angle someone might try:

Attack	Works?	Why
Edit config fields	Name/personality only	Bones always overwritten
Change accountUuid	No	Server validates on auth
Patch the binary	Yes	That's what this tool does
Create new accounts	Uncontrolled	Can't choose your UUID
Brute-force UUIDs	Statistically	But you can't use found UUIDs

The brute-force angle is interesting. I wrote a separate script that replicates the full gacha algorithm and generates random UUIDs to find legendary rolls. It works statistically, but the UUIDs it finds are useless in practice because Anthropic assigns them server-side during account creation. You don't get to pick yours.

And there's the Bun versus Node.js hash problem again. The brute-forcer runs in Node.js by default, using FNV-1a, but production Claude Code uses Bun's wyhash. The probability distributions are identical, but per-UUID results won't match unless you run the script under Bun.

What I Learned

The buddy system is genuinely well-designed for what it's trying to do. Deterministic gacha with no server state is elegant. The tamper protection through spread ordering is simple and effective against casual editing. The soul/bones split lets users personalize their pet's name and personality while keeping the visual identity locked to their account.

But any system where the enforcement happens entirely on the client has a fundamental limit. The binary is on your machine. The config is on your machine. The merge logic is one spread operation in a JavaScript function. The crack is five characters swapped in a compiled binary.

That said, I don't think the Anthropic team is under any illusion that this is uncrackable. Deterministic client-side gacha is a design choice that trades tamper-resistance for zero-server-cost operation. No database, no API calls to validate rarity, no sync issues. For a fun companion pet feature in a CLI tool, that's the right tradeoff. The buddy system doesn't gate any functionality. It's a toy, and it's a charming one.

The code is at github.com/Pickle-Pixel/claudecode-buddy-crack if you want to pick your own companion. The full reverse-engineering documentation is in BUDDY_SYSTEM.md.

Now if you'll excuse me, I have a legendary shiny dragon to go look at.

I Built an AI Agent to Apply to 1,000 Jobs While I Kept Building Things

PicklePixel — Thu, 19 Feb 2026 03:44:05 +0000

Job searching is a full-time job. That's the actual problem. It competes directly with the work I love which is building things, learning and automating stuff. At some point I enough and wanted to figure it out so I started building ApplyPilot.

I built ApplyPilot. It's a fully autonomous job application pipeline that discovers jobs, scores them against my profile, tailors my resume per role, writes cover letters, and submits applications all by itself. 1,000 applications in 2 days. I have interviews scheduled right now.

Here's how it works and what surprised me along the way.

The Situation

The existing tools in this space are either cheap and dumb, or smart and expensive. The "smart" browser automation services charge per application and still require babysitting. I've been building automations for years - it's genuinely one of my stronger skills - so I decided to just build the thing myself instead of paying someone else's margins.

The core idea was treating job searching as a pipeline problem. Every stage has a clear input and output. Automate each one.

The Pipeline

ApplyPilot runs in 6 stages:

Discover - Scrapes Indeed, LinkedIn, Glassdoor, ZipRecruiter, and Google Jobs, plus 48 pre-configured Workday employer portals and 30+ direct career sites
Enrich - Fetches the full job description from each listing URL
Score - An LLM rates each job 1-10 based on my resume and search preferences. Only jobs scoring ≥7 move forward
Tailor - Rewrites my resume for the specific role (reorganizes sections, emphasizes relevant experience, injects keywords from the job description)
Cover Letter - Generates a targeted cover letter per job
Apply - Submits the application

The whole thing runs off a single SQLite database that acts as a conveyor belt. Each stage reads what the previous one produced and writes its output to new columns. You can run stages independently, restart failed ones, or run a subset:

applypilot run                    # full pipeline
applypilot run score tailor      # just re-score and re-tailor
applypilot apply --workers 3     # 3 Chrome instances submitting in parallel

The discovery config took the most upfront time 48 Workday employer configs, 30+ direct sites, rules for blocked sites and ATS detection. But once you have it, it's done. I'd encourage anyone building something similar to start there and build a library of templates. It's a rewarding step and it makes everything downstream much easier.

The Architectural Mistake I Made First

My first instinct was a traditional orchestrator/agent setup - a central controller dispatching discrete actions to a stateless agent. Pull an action, execute it, report back, repeat. Kept the context window small, felt efficient on paper.

It didn't work well. Form filling isn't a sequence of independent actions - it's a stateful session. The agent needs to see the page, understand what it just filled, notice when something went wrong, and adapt. A thin stateless action-puller can't do any of that reliably.

I switched to a full LLM session with persistent context as the brain - one continuous conversation per application, with complete page visibility throughout. The agent could actually reason about what was happening instead of just executing one-off commands. The difference was immediate.

Haiku Is the Goat

I know that sounds like a take, but I mean it. Claude Haiku follows instructions precisely, barely hallucinates on structured tasks, and is fast enough to run as the core of a real-time automation. For this use case - filling forms with clear instructions and real page context - it outperforms bigger models on the metrics that actually matter.

Some things Haiku did that I didn't explicitly build for:

It reset my LinkedIn password. One application required LinkedIn login and the session had expired. Haiku navigated to the forgot-password flow, reset the password, and continued the application. I didn't tell it to do that. It identified the obstacle and removed it.

It sent an email when there was no form. One listing had no application form - just a contact email buried in the description. Haiku noticed, composed a professional email, attached my resume, and sent it. The correct behavior for that situation, with zero special-casing in my code.

It completed a French application entirely in French. I didn't build any localization handling. It just handled it.

These aren't lucky guesses - they're genuine adaptations to situations the code didn't anticipate. That's the actual value of using a capable model as the agent brain rather than a rigid script.

The Result

1,000 applications in 2 days. Multiple companies reached out and I'm in the interview process right now. It works.

The resume tailoring is a big part of why. ApplyPilot never fabricates anything - there's a resume_facts section in the config that locks the real companies, real projects, and real metrics. The AI can reorganize and emphasize, but it can't invent. That matters both for integrity and for not getting blindsided in an interview.

On the ethics of applying at scale: I have an extensive skillset across multiple domains and I'd genuinely thrive in any of the roles I targeted. The tailoring means each application is actually relevant to the role, not just spam. If a company receives a well-matched resume for something I can do, I don't see the problem. The reader can draw their own conclusion.

What I'd Tell You

If job searching is eating your time right now - that frustration is real and it doesn't have to work that way. The tools to automate most of this already exist.

Start with the discovery config. Build a library of job site templates. That foundation makes everything else possible, and once it's built you won't have to touch it again.

The code is https://github.com/Pickle-Pixel/ApplyPilot. Go build something.

How I Made Claude Code Agent Teams Work With Any Model

PicklePixel — Sun, 08 Feb 2026 04:43:00 +0000

Claude Code Agent Teams is the most capable multi-agent coding system I've used. You tell it to refactor your auth module, it spawns three teammates, they read files, write code, run tests, coordinate through task lists, and report back. Each teammate is a full Claude Code instance with 15+ tools. It's genuinely impressive.

There's one problem: every single agent has to be Claude. Your lead runs Opus at $15/M tokens. Your researcher runs Sonnet. Your reviewer runs Sonnet. A four-agent team working on a refactor can easily burn $5-10 in one session.

I wanted to keep the lead on Claude Opus and swap the teammates' brains to GPT. Honestly, I just wanted to stop burning money on tasks that don't need a frontier model.

The Wrong Approach (First)

My first instinct was to build a full custom agent framework. Agent Runtime. Universal Tool System. Provider Adapters. Coordination Layer. Spawner. I designed the whole thing. Around 2,000 lines of TypeScript, reinventing everything Claude Code already does perfectly.

Then it clicked: Claude Code IS the agent runtime. I don't need to rebuild it. I just need to change where it sends its API calls.

Every Claude Code teammate process communicates with its LLM through one endpoint: POST /v1/messages. It sends tool definitions, message history, system prompts. It expects back SSE-streamed responses with text and tool_use blocks.

The teammate never validates who is on the other end. It doesn't check if the responses actually come from Claude. It just sends Anthropic-format requests and executes whatever tool calls come back.

The hook is one environment variable: ANTHROPIC_BASE_URL. Set it to http://localhost:3456 and every API call goes to your proxy instead of Anthropic.

I confirmed this by pointing it at localhost:9999 with nothing listening. Claude Code hung waiting for connection. It respects the override completely.

So instead of building a framework, I built a translation proxy. Two API formats that do the same thing, just formatted differently. The proxy sits in the middle and translates in real-time.

What the Proxy Actually Does

Lead Agent (Claude Opus)
    |
    | ANTHROPIC_BASE_URL=http://localhost:3456
    |
Teammate Process (Claude Code CLI)
    |  -- thinks it's calling Anthropic --
    |
HydraProxy (localhost:3456)
    |  -- translates API format --
    |
GPT-5.3 Codex (or whatever model you want)

The teammate is still a full Claude Code instance with every tool. Read, Write, Edit, Bash, Glob, Grep, Git. It just doesn't know its brain is GPT instead of Claude.

The translation has two parts: requests going out, and responses coming back.

Requests

Anthropic and OpenAI structure things differently but it's mostly a reshuffling:

Anthropic puts the system prompt as a top-level system field. OpenAI puts it as the first message with role: "system".
Anthropic defines tools as { name, input_schema }. OpenAI wraps them in { type: "function", function: { name, parameters } }.
Tool calls in Anthropic are tool_use content blocks inside a message. OpenAI puts them in a tool_calls array on the assistant message.
Tool results in Anthropic are tool_result blocks in user messages. OpenAI uses separate { role: "tool" } messages.

Pretty mechanical once you see the pattern.

SSE Streams (The Hard Part)

Both APIs stream via Server-Sent Events, but the event structure is completely different.

OpenAI gives you flat chunks:

data: {"choices":[{"delta":{"content":"Hello "}}]}
data: {"choices":[{"delta":{"tool_calls":[{"index":0,"id":"call_123","function":{"name":"Read"}}]}}]}
data: [DONE]

Claude Code expects this:

event: message_start
event: content_block_start  (index 0, type "text")
event: content_block_delta  (text_delta: "Hello ")
event: content_block_stop
event: content_block_start  (index 1, type "tool_use", name "Read")
event: content_block_delta  (input_json_delta: partial JSON...)
event: content_block_stop
event: message_delta        (stop_reason)
event: message_stop

The proxy maintains a state machine that tracks block indexes, active tool calls, and whether a text block has been started. Each OpenAI chunk gets translated into the corresponding Anthropic event and written to the response stream. The model name gets spoofed too. Claude Code validates model names internally, so the proxy reports claude-sonnet-4-5-20250929 regardless of what's actually answering.

The Debugging Gauntlet

The architecture was clean. Reality was messier. Five bugs, each discovered sequentially because the previous one masked the next.

Query parameters. Claude Code sends POST /v1/messages?beta=true. My proxy matched on exact URL "/v1/messages". No match. Zero requests got through. Spent longer than I'd like to admit staring at an empty terminal before checking the actual URL.

Token counting. Claude Code sends 10+ POST /v1/messages/count_tokens requests on startup. The proxy returned 404 for all of them. Added a handler that returns estimated counts.

max_tokens overflow. Claude Code requests max_tokens: 32000. GPT-4o caps at 16384. OpenAI returned 400. Added a model-specific lookup table with clamping.

Non-streaming warmup. Claude Code sends a haiku warmup request with stream: undefined. Not false, not true. The proxy always set stream: true on the upstream call. The non-streaming response format is completely different from SSE. Had to detect and handle both paths.

Rate limits. Two teammates running GPT-4o-mini simultaneously blew through the 200K TPM limit in seconds. Added retry logic with exponential backoff.

After fixing all five:

$ ANTHROPIC_BASE_URL=http://localhost:3456 claude --print "what model are you?"

Response: "I am Claude, an AI model developed by Anthropic..."

GPT-4o, pretending to be Claude, running through the full pipeline. It even maintained the Claude persona from the system prompt. But ask it about DALL-E and the GPT personality leaks through.

Then the real test: full agentic tool loops. A teammate spawned through the proxy successfully used Glob and Read tools across four round trips with 31 tool definitions. It searched files, read code, and reported back to the lead. GPT-4o-mini doing Claude Code's job at a fraction of the cost.

Mixed Teams: Lead on Claude, Teammates on GPT

The next challenge was routing. I wanted the lead on real Claude Opus (my subscription) and only the teammates going through the proxy. But all Claude Code processes have ANTHROPIC_BASE_URL set, so they all hit the proxy.

I tried three approaches:

Model name routing didn't work because teammates also request claude-opus-4-6 sometimes.

Tool count heuristic worked briefly. The lead had 31 tools (Claude Code's 15+ plus my MCP tools), teammates had 23. Route on count >= 28. Then I realized that adding or removing one MCP tool breaks the whole thing.

System prompt marker was the winner. I added  as an HTML comment to my project's CLAUDE.md file. Claude Code injects CLAUDE.md into the system prompt. The proxy checks the system prompt for the marker. Found means passthrough to real Anthropic. Not found means translate to GPT.

Teammates don't get the CLAUDE.md from the main project. They get their own system prompt without the marker. Clean routing, zero false positives.

For the passthrough, the proxy just relays the original auth headers from Claude Code to the real Anthropic API. No API key needed for the lead. You use your subscription as-is.

The Subscription Hack: Zero-Cost Teammates

The proxy worked with OpenAI API keys. But API keys cost money. I already pay for ChatGPT Plus. Can I use that?

Turns out, yes. OpenAI's Codex CLI authenticates via ~/.codex/auth.json, an OAuth token. That token works with a different endpoint than the standard API:

POST https://chatgpt.com/backend-api/codex/responses

This uses the Responses API format, which is different from both Chat Completions and the standard OpenAI API. Auth is a Bearer token plus a Chatgpt-Account-Id header extracted from the JWT.

I tested every model name I could think of. Found 9+ working models on ChatGPT Plus at zero additional cost:

Model	Type
gpt-5-codex	Full
gpt-5.1-codex	Full
gpt-5.2-codex	Full
gpt-5.3-codex	Full (latest)
gpt-5-codex-mini	Mini
gpt-5.1-codex-mini	Mini

This meant building a second translation layer though. The Responses API has its own request and response format. So I wrote another pair of translators:

Request: Anthropic messages become input items with function_call and function_call_output types instead of tool_calls. System prompt becomes instructions. Must include store: false. Cannot include max_output_tokens or temperature (the backend rejects both, learned that the hard way).
Response: Different SSE events. response.output_text.delta becomes content_block_delta. response.function_call_arguments.delta becomes input_json_delta. And so on.

The proxy auto-reads ~/.codex/auth.json, decodes the JWT, extracts the account ID from a custom claim. No manual configuration. Just codex --login once and the proxy handles the rest.

node dist/index.js --model gpt-5.3-codex --provider chatgpt --port 3456 --passthrough lead

Claude Code teammates powered by GPT-5.3-codex through a ChatGPT Plus subscription. The lead runs on Claude Opus through my Claude subscription. Total additional API cost: $0.

The Final Stack

Nine TypeScript files. Zero runtime dependencies. Just Node.js builtins.

src/
├── index.ts                    Entry point
├── proxy.ts                    HTTP server, 3-way routing
├── config.ts                   CLI args, codex JWT auth
└── translators/
    ├── types.ts                TypeScript interfaces
    ├── request.ts              Anthropic → Chat Completions
    ├── messages.ts             Message history translation
    ├── response.ts             Chat Completions SSE → Anthropic SSE
    ├── request-responses.ts    Anthropic → Responses API
    └── response-responses.ts   Responses API SSE → Anthropic SSE

Three routing paths:

Lead requests (hydra:lead marker found) pass through to real Anthropic
Teammate requests with --provider openai translate to Chat Completions
Teammate requests with --provider chatgpt translate to the Responses API

What I Learned

I originally designed a 2,000-line framework. What shipped was a translation proxy. Same result, fraction of the complexity. The best agent framework already existed. I just needed to make it talk to different backends.

The translation layer itself is honestly not that interesting. Two APIs that do the same thing, structured differently. The interesting part is what it enables: heterogeneous teams where each agent runs on whatever model makes sense for its task. Your lead on Opus because it needs strong reasoning. Your file searcher on GPT-4o-mini because it just needs to grep and summarize. Your code reviewer on GPT-5.3-codex because it's free through your subscription.

The real insight is that Claude Code Agent Teams is undervalued infrastructure. It's a complete multi-agent system with coordination, task management, messaging, plan approval, and graceful shutdown. Everyone's trying to build agent frameworks from scratch. The smart play is to extend the ones that already work.

The Repo

HydraTeams on GitHub

MIT licensed. If you have a ChatGPT Plus subscription and want free agent teammates, this is your move.

How I Built an MCP Server That Lets Claude Code Talk to Every LLM I Pay For

PicklePixel — Fri, 06 Feb 2026 03:53:01 +0000

I have subscriptions to ChatGPT Plus, Claude MAX, and Gemini. I also run local models through Ollama. That's four different ecosystems, four browser tabs, and a lot of copy-pasting whenever I want to compare how different models handle the same question.

It was getting ridiculous. I'd ask Claude something, then open ChatGPT to see if GPT-5 agreed, then check Gemini for a third opinion. Every time, I'd lose context, reformat the prompt, and waste five minutes on what should be a ten-second comparison.

So I built HydraMCP. It's an MCP server that routes queries from Claude Code to any model I have access to cloud and local through a single interface. One prompt, multiple models, parallel execution.

What It Actually Does

HydraMCP exposes five tools to Claude Code:

list_models shows everything available across all your providers. One command, full inventory.

ask_model queries any single model. Want GPT-5's take on something without leaving your terminal? Just ask.

compare_models is the one I use the most. Same prompt to 2-5 models in parallel, results side by side. Here's what that looks like in practice:

> compare gpt-5-codex, gemini-3, claude-sonnet, and local qwen on this function review

## Model Comparison (4 models, 11637ms total)

| Model                      | Latency         | Tokens |
|----------------------------|-----------------|--------|
| gpt-5-codex                | 1630ms fastest  | 194    |
| gemini-3-pro-preview       | 11636ms         | 1235   |
| claude-sonnet-4-5-20250929 | 3010ms          | 202    |
| ollama/qwen2.5-coder:14b   | 8407ms          | 187    |

All four independently found the same async bug. Then each caught something different the others missed. GPT-5 was fastest, Gemini was most thorough, Claude gave the clearest fix, Qwen explained the root cause. Different training data, different strengths.

consensus polls 3-7 models on a question and has a separate judge model evaluate whether they actually agree. It returns a confidence score and groups responses by agreement.

synthesize fans out to multiple models, collects their responses, and then a synthesizer model combines the best insights into one answer. The result is usually better than any individual response.

The Architecture

The design is pretty straightforward:

Claude Code
    |
    HydraMCP (MCP Server)
    |
    Provider Interface
    |-- CLIProxyAPI  -> cloud models (GPT, Gemini, Claude, etc.)
    |-- Ollama       -> local models (your hardware)

HydraMCP sits between Claude Code and your model providers. It communicates over stdio using JSON-RPC (the MCP protocol), routes requests to the right backend, and formats everything to keep your context window manageable.

The provider interface is the core abstraction. Every backend implements three methods: healthCheck(), listModels(), and query(). That's it. Adding a new provider means implementing those three functions and registering it.

interface Provider {
  name: string;
  healthCheck(): Promise<boolean>;
  listModels(): Promise<ModelInfo[]>;
  query(model: string, prompt: string, options?: QueryOptions): Promise<QueryResponse>;
}

For cloud models, CLIProxyAPI turns your existing subscriptions into a local OpenAI-compatible API. You authenticate once per provider through a browser login, and it handles the rest. No per-token billing - you're using the subscriptions you already pay for.

For local models, Ollama runs on localhost and provides models like Qwen, Llama, and Mistral. Zero API keys, zero cost beyond your electricity bill.

The Interesting Parts

Parallel Execution

When you compare four models, all four queries fire simultaneously using Promise.allSettled(). Total time equals the slowest model, not the sum of all of them. That five-model comparison above? 11.6 seconds total, not 25+.

And if one model fails, you still get results from the others. Graceful degradation instead of all-or-nothing.

Consensus With an LLM Judge

This is the part I'm most interested in. Naive keyword matching fails at determining if models agree. If one says "start with a monolith" and another says "monolith because it's simpler," they agree - but keyword overlap is low.

So the consensus tool picks a model that's not in the poll and asks it to evaluate agreement. The judge reads all responses and groups them semantically:

Three cloud models polled, local Qwen judging.
Strategy: majority (needed 2/3)
Agreement: 3/3 models (100%)
Judge latency: 686ms

Using a local model as judge means zero cloud quota used for the evaluation step.

Honestly, the keyword-based fallback (for when no judge is available) is pretty broken. It works for factual questions sometimes but falls apart on anything subjective. The LLM judge approach is significantly better, but it's still an area I want to improve.

Ollama Warmup

One thing I noticed during testing: local models through Ollama have a significant cold-start penalty.

First request to Qwen 32B: 24 seconds (loading the model into memory). By the fourth request: 3 seconds. That's an 8x improvement just from the model being warm. After that warmup period, local models genuinely compete with cloud on latency.

If you're using HydraMCP regularly, your local models stay warm and the experience is seamless. The first query of the day might be slow, but everything after that is fast.

Synthesis

The synthesize tool is probably the most ambitious feature. It collects responses from multiple models, then feeds them all to a synthesizer model with instructions to combine the best insights and drop the filler.

The synthesizer is deliberately picked from a model not in the source list when possible. The prompt is straightforward: "Here are responses from four models. Write one definitive answer. Take the best from each."

In practice, the synthesized result usually has better structure than any individual response and catches details that at least one model missed.

The Stack

It's about 1,500 lines of TypeScript. Dependencies are minimal:

@modelcontextprotocol/sdk for the MCP protocol
zod for input validation
Node 18+

That's it. No Express, no database, no build framework beyond TypeScript's compiler. Every tool input is validated with Zod schemas, and all logging goes to stderr (stdout is reserved for the JSON-RPC protocol - send anything else there and you break MCP).

Setup

The whole thing takes about five minutes:

Set up CLIProxyAPI and/or Ollama as backends
Clone, install, build HydraMCP
Add your backend URLs to .env
Register with Claude Code: claude mcp add hydramcp -s user -- node /path/to/dist/index.js
Restart Claude Code, say "list models"

From there you just talk naturally. "Ask GPT-5 to review this." "Compare three models on this approach." "Get consensus on whether this is thread-safe." Claude Code routes it through HydraMCP automatically.

What I'd Like to Add

The provider interface makes this extensible by design. The backends I want to see next:

LM Studio for another local model option
OpenRouter for pay-per-token access to models you don't subscribe to
Direct API keys for OpenAI, Anthropic, and Google without needing CLIProxyAPI

Each one is roughly 100 lines of TypeScript. Implement the three interface methods, register it, done.

Why This Matters

The real value isn't any single feature. It's the workflow change. Instead of trusting one model's opinion, you can cheaply verify it against others. Instead of wondering if GPT or Claude is better for a specific task, you can just compare them and see.

Different models have genuinely different strengths. I've seen GPT-5 catch performance issues that Claude missed, and Claude suggest architectural patterns that GPT didn't consider. Gemini sometimes gives the most thorough analysis. Local Qwen is surprisingly good at explaining why something is wrong, not just what is wrong.

Having all of them available from one terminal, with parallel execution and structured comparison, changes how you think about using AI for code. It goes from "ask my preferred model" to "ask the right model for this task" - or just ask all of them and see what shakes out.

The Repo

HydraMCP on GitHub

MIT licensed. If you have subscriptions collecting dust or local models sitting idle, this puts them to work. And if you want to add a provider, the interface is documented and the examples are there.

How I Made Netflix Give Me 4K (Because Apparently My Browser Wasn't Good Enough)

PicklePixel — Wed, 28 Jan 2026 05:24:38 +0000

I pay for Netflix Premium. The one that's supposed to include 4K streaming. But every time I tried to watch something on my PC, it would cap at 1080p. Sometimes even 720p. On a 4K monitor. With gigabit internet.

This had been bugging me for months. I'd sit down to watch something, notice the quality looked soft, check the stats overlay, and sure enough 1080p. Every single time. I figured it was a bandwidth thing at first, maybe Netflix's servers were busy. But it kept happening.

So I finally decided to figure out what was actually going on.

The Discovery

Turns out Netflix has a list of "approved" devices and browsers for 4K playback. If you're not on Microsoft Edge, Safari, or their native app, you simply don't get 4K. Doesn't matter that you're paying for it. Doesn't matter that your hardware supports it.

Chrome? No 4K. Firefox? No 4K. Brave? Nope.

The reasoning has to do with DRM. Netflix requires hardware-level content protection (Widevine L1 and HDCP 2.2) to serve 4K streams. Edge on Windows has this. Chrome doesn't - it only has Widevine L3, which is software-based and considered less secure by content providers.

I get the security argument from Netflix's perspective. But from my perspective, I'm paying for a service tier I can't fully use because of my browser choice. That felt worth fixing.

Down the Rabbit Hole

I spent an evening just researching how Netflix determines device capabilities. Opened DevTools, watched the network requests, read through forums and old GitHub issues. The picture that emerged was interesting.

Before Netflix serves you any video, it runs a bunch of capability checks:

Browser fingerprinting:

User agent string (what browser/OS you're running)
Screen resolution via window.screen
Device pixel ratio

Codec support:

HEVC (H.265) for 4K
VP9 as an alternative
AV1 on newer content
Dolby Vision for HDR

DRM capabilities:

Widevine security level (L1, L2, or L3)
PlayReady support on Windows
HDCP version compliance

Media APIs:

navigator.mediaCapabilities.decodingInfo()
MediaSource.isTypeSupported()
navigator.requestMediaKeySystemAccess()

All of these checks happen in JavaScript before the video manifest is even requested. Netflix builds a profile of what your device can handle, then serves you the appropriate stream quality.

The key insight: most of these checks are JavaScript APIs that can be intercepted and spoofed.

Day One: Basic Spoofing

I started with the obvious stuff. Created a basic Chrome extension and began overriding the simple checks:

// Spoof screen resolution to 4K
Object.defineProperty(window.screen, 'width', { get: () => 3840 });
Object.defineProperty(window.screen, 'height', { get: () => 2160 });
Object.defineProperty(window.screen, 'availWidth', { get: () => 3840 });
Object.defineProperty(window.screen, 'availHeight', { get: () => 2160 });
Object.defineProperty(window.screen, 'colorDepth', { get: () => 48 });
Object.defineProperty(window, 'devicePixelRatio', { get: () => 1 });

Then the user agent. Netflix needs to think we're running Edge:

Object.defineProperty(navigator, 'userAgent', {
  get: () => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0'
});

Loaded it up, went to Netflix, played a video. Still 1080p. The basic spoofs weren't enough.

Day Two: Media Capabilities

The next layer was the Media Capabilities API. Netflix uses this to ask the browser "can you smoothly decode this codec at this resolution?"

I intercepted the decodingInfo method and forced it to return positive results for 4K codecs:

const originalDecodingInfo = navigator.mediaCapabilities.decodingInfo.bind(navigator.mediaCapabilities);

navigator.mediaCapabilities.decodingInfo = async function(config) {
  const dominated4KCodecs = ['hev1', 'hvc1', 'vp09', 'vp9', 'av01', 'dvhe', 'dvh1'];

  if (config.video) {
    const codec = config.video.contentType || '';
    const dominated = dominated4KCodecs.some(c => codec.toLowerCase().includes(c));

    if (dominated || config.video.width >= 3840) {
      return {
        supported: true,
        smooth: true,
        powerEfficient: true
      };
    }
  }

  return originalDecodingInfo(config);
};

Same idea for MediaSource.isTypeSupported():

const originalIsTypeSupported = MediaSource.isTypeSupported.bind(MediaSource);

MediaSource.isTypeSupported = function(mimeType) {
  const dominated4KTypes = ['hev1', 'hvc1', 'dvh1', 'dvhe', 'vp09', 'vp9', 'av01'];

  if (dominated4KTypes.some(t => mimeType.toLowerCase().includes(t))) {
    return true;
  }

  return originalIsTypeSupported(mimeType);
};

Tested again. Still 1080p. Netflix was checking something else.

Day Three: DRM and HDCP

This is where it got interesting. Netflix checks DRM capabilities through navigator.requestMediaKeySystemAccess(). This API negotiates which DRM system to use (Widevine, PlayReady) and what security level.

The security level is specified through a "robustness" string. For 4K, Netflix wants HW_SECURE_ALL (hardware-level security). Chrome can only provide SW_SECURE_DECODE (software).

I tried intercepting this and requesting the higher robustness level:

navigator.requestMediaKeySystemAccess = async function(keySystem, configs) {
  const enhancedConfigs = configs.map(config => {
    const enhanced = JSON.parse(JSON.stringify(config));
    if (enhanced.videoCapabilities) {
      enhanced.videoCapabilities = enhanced.videoCapabilities.map(vc => ({
        ...vc,
        robustness: 'HW_SECURE_ALL'
      }));
    }
    return enhanced;
  });

  try {
    return await originalRequestMediaKeySystemAccess(keySystem, enhancedConfigs);
  } catch (e) {
    // Fall back to original if enhanced fails
    return originalRequestMediaKeySystemAccess(keySystem, configs);
  }
};

The enhanced request fails (because Chrome genuinely doesn't have L1), but the fallback still works. The interesting part is that this interception, combined with all the other spoofs, started to have an effect.

I also spoofed the HDCP policy check:

Object.defineProperty(navigator, 'hdcpPolicyCheck', {
  value: () => Promise.resolve({ hdcp: 'hdcp-2.2' })
});

Day Four: Cadmium

Netflix's video player is called Cadmium. It's their internal player that handles everything from manifest fetching to adaptive bitrate switching. Cadmium has its own configuration that sets maximum resolution and bitrate caps.

Finding how to hook into it took some time. I ended up polling for the window.netflix.player object and overriding its methods:

const hookCadmium = () => {
  if (window.netflix && window.netflix.player) {
    const player = window.netflix.player;

    ['create', 'configure', 'getConfiguration', 'getConfig'].forEach(method => {
      if (typeof player[method] === 'function') {
        const original = player[method].bind(player);
        player[method] = function(...args) {
          const result = original(...args);

          if (result && typeof result === 'object') {
            if (result.maxBitrate !== undefined) result.maxBitrate = 16000;
            if (result.maxVideoHeight !== undefined) result.maxVideoHeight = 2160;
            if (result.maxVideoWidth !== undefined) result.maxVideoWidth = 3840;
          }

          return result;
        };
      }
    });
  }
};

I also intercepted Object.defineProperty itself to catch any resolution or bitrate caps being set anywhere in Netflix's code:

const originalDefineProperty = Object.defineProperty;
Object.defineProperty = function(obj, prop, descriptor) {
  if (typeof prop === 'string') {
    const lowerProp = prop.toLowerCase();

    if (lowerProp.includes('maxbitrate') && descriptor.value < 16000) {
      descriptor.value = 16000;
    }
    if (lowerProp.includes('maxheight') && descriptor.value < 2160) {
      descriptor.value = 2160;
    }
  }

  return originalDefineProperty.call(this, obj, prop, descriptor);
};

This felt hacky, but it was catching config values that I couldn't find any other way.

The Breakthrough

After all these layers of spoofing, I loaded Netflix, played a 4K title (Our Planet - nature docs are great for testing because the quality difference is obvious), and pressed Ctrl+Shift+Alt+D to bring up the stats overlay.

3840x2160. 15000+ kbps bitrate.

It actually worked.

The quality difference was immediately visible. All that fine detail in the nature footage that looked muddy at 1080p was now crisp. This is what I was paying for.

The SPA Problem

Feeling good about it, I browsed around Netflix, clicked on another movie, and... 1080p again.

Netflix is a single-page application. When you click on a title, it doesn't do a full page reload - it just updates the URL and swaps content via JavaScript. My extension was injecting at page load, but the Cadmium player was being recreated for each new video without triggering a reload.

I added navigation detection that watches for URL changes:

let lastPath = location.pathname;

const checkNavigation = () => {
  if (location.pathname !== lastPath) {
    const isWatch = location.pathname.startsWith('/watch');
    lastPath = location.pathname;

    if (isWatch) {
      // Reset and re-hook
      cadmiumHooked = false;
      setTimeout(() => hookCadmium(), 1000);
    }
  }
};

setInterval(checkNavigation, 300);

// Also intercept history API
const originalPushState = history.pushState;
history.pushState = function(...args) {
  originalPushState.apply(this, args);
  setTimeout(checkNavigation, 100);
};

This helped, but honestly it's still not perfect. Sometimes the timing is off and the hooks don't catch the new player instance. When that happens, a page refresh fixes it. I've been trying to nail down the exact race condition but haven't fully solved it yet. It works maybe 80% of the time on navigation, and a refresh always fixes it when it doesn't.

Good enough for now. I'll revisit it when it annoys me enough.

What I Learned

The whole thing took about four days of evening tinkering. Most of that was research and understanding how Netflix's capability detection works. The actual code isn't that complicated once you know what to intercept.

The layers matter. Netflix doesn't rely on any single check. You have to spoof the user agent AND the screen resolution AND the media capabilities AND the DRM negotiation AND the player config. Miss one layer and you're back to 1080p.

Hardware DRM is the real barrier. All my JavaScript spoofing can't change the fact that Chrome has Widevine L3 and not L1. I'm essentially tricking Netflix into trying to serve 4K, and it works because the actual decryption still happens (just at a lower security level than Netflix prefers). This might not work for all content, and Netflix could theoretically detect the mismatch and block it.

Edge is the sweet spot. If you use this extension on Microsoft Edge (which does have Widevine L1), you get the best of both worlds - real hardware DRM plus all the spoofed capability checks. That's probably the most reliable setup.

The Repo

I published the extension if anyone else wants it: netflix-force-4k

Fair warning: Netflix could patch this whenever they want, and the SPA navigation still needs a refresh sometimes. But it works well enough that I'm actually getting 4K on most of what I watch now.

The fact that I had to reverse-engineer a streaming service to access the quality tier I'm paying for is a little absurd. But that's the state of DRM in 2025. You pay for the content, but whether you can actually watch it in full quality depends on which browser you prefer.

Anyway, that's the journey. Four days of API hooking to watch movies in higher resolution. Worth it.

How I Reverse-Engineered Perplexity’s Referral Signup

PicklePixel — Wed, 26 Nov 2025 06:27:18 +0000

I wasn't trying to change the world, I just didn't want to spend 30 minutes per signup

The Setup

I was a campus partner for Perplexity which means every signup is 15$ in my pocket, as a student this sounds great all I have to do is pitch to students about free AI tool that will help them study.

The Problem

Well, it sounds great until you realize you have to earn their trust, explain why it’s a good deal, show them how to use it, and hopefully convince them to let you sign them up.

You need their student email, and most students don’t really understand how referrals work, so they’re hesitant to share it.
Then you have to download the Comet browser by Perplexity, and let’s be honest, that looks a little sketchy to most people.

If everything goes perfectly, you’ve just spent about 30 minutes signing up one person.

It’s not difficult work, but it’s slow work and that’s what made me want to find a better way.

The Real Motivation

I wanted students to have free access to the latest and best AI tools out there.
If you actually believed that, stop reading.

I just wanted more money in my pocket and less time wasted. So I asked myself what really happens behind the scenes and how do referrals work?

Reverse Engineering the Process

First thing I did was peek at the network activity to see how the signup flow behaved. I booted up Burp Suite, grabbed an ice cold Coke, and started taking notes.

Here is the high-level checklist you need to cover for the referral to register:

Click referral link
Sign in with student email
Download Comet
Prompt Comet once

Step 1: Referral Link Observation

I started by trying to understand what the referral link was actually doing. Nothing complicated. I clicked the link with Burp Suite running and scrolled through all the HTTPS requests it captured.

What I was looking for was basically the “referral fingerprint.” Something that only appears when you come in through a partner link.

After checking a bunch of requests, one thing stood out: the dub-id.

When I opened the request up, I noticed something interesting. The dub-id and the click-id were the exact same value. Different labels, same number. That immediately told me this was important.

This is clearly the ID that connects the user to the partner who referred them.
So I saved it and kept tracking where it showed up next.

That was all I needed for Step 1.
Find the ID that marks the beginning of the referral flow and hold onto it.

Step 2: Sign in w/Student Email

Next I wanted to understand what actually happens when you sign in with a student email. The first thing that showed up in Burp Suite was a CSRF token the moment the sign-in page loaded. Since it appeared before anything else, I wrote it down as something the backend clearly expects.

After that, the OTP flow kicked in. This is the part that verifies the email and marks the user as authenticated. Watching the network requests before and after the OTP made it pretty obvious what changed and what the system used to confirm the login.

Then I tried sending the sign-in request through my script:

Once the email and OTP were confirmed, the session switched into a logged-in state. At that point I basically had everything I needed from the authentication part in order to continue understanding the referral flow.

emailSigninRequest = session.post(
    "https://www.perplexity.ai/xxx/xxx/xxx/xxx",
    data={
        "email": userMail,
        "callbackUrl": "https://www.perplexity.ai/xxxxxxxxxx",
        "redirect": "false",
        "useNumericOtp": "true",
        "csrfToken": session.cookies.get("next-auth.csrf-token").split("%7C", 1)[0],
        "json": "true",
    }
)

now we successfully logged in with a student email and have all the information we need to simulate the referral attributes.

Step 3: Download Comet

Now I needed to understand what happens when you download Comet. After signing in and completing the OTP step, the system redirects you to a link that triggers the Comet installer. That redirect is basically the signal the backend uses to register that the user downloaded the browser.

So in my script, I just followed that redirect. Even without actually installing anything, hitting that link counted as the download event on the backend.

Step 4: Prompt Comet

This part was honestly the most annoying. Comet is a full desktop app, not a website, so I couldn’t just open DevTools and see what was going on. I had to proxy my whole system through Burp Suite just to catch its traffic.

Once I did that, I finally saw what Comet sends when you open it and when you ask it something. That was the missing piece. The system expects the user to actually do one prompt after downloading, so I needed a way to trigger that same kind of activity.

The logic I used was pretty straightforward. Comet always shows a bunch of suggested questions when it loads, so I took that idea and just picked one suggestion at random. I also made a bunch of simple question patterns like “what is {query}” or “explain {query}” or “tell me about {query}.” Then I let the script grab a suggestion, grab a pattern, combine them, and send it.

Nothing smart, nothing magical. It just ends up looking like a new user asking the AI something completely normal. That one prompt is what satisfies the last part of the referral flow.

That was it. Download done, prompt done, referral counted. Whole thing took around ten seconds.

It Wasn't Enough for Me

After using the script for a day or two, I realized I really hated carrying my laptop everywhere. It felt slow, heavy, and honestly just annoying to pull out every time someone said “yeah sure, sign me up.”

So I did the next obvious thing.

I installed Termux on my Samsung S24, set up a PRoot Ubuntu 22.04 environment with everything I needed, and moved the whole workflow to my phone. That was it. Now I could walk around campus with just my phone and run everything on the spot.

By the end of the week, I had over 100 signups just from doing it this way.

The Downfall

Everything was going great. I was signing people up all day because it was fast and easy and I didn’t really have to think about it anymore. But then I had a thought I probably shouldn’t have had.

What if I could sign up non-educational emails?

So of course I tried it. And it worked. I was honestly surprised. I expected the system to block it right away, but it didn’t. I tried again with a Gmail address. Then with an Outlook address. Same result. And yes, the commission kept going up.

At that point I knew it was only a matter of time before something flagged. I wasn’t supposed to be able to do that and I knew it. Two weeks later, I woke up to an email saying I was removed from the Perplexity Partner Campaign.

I was a bit disappointed, but I also remembered the FAFO scale. It could have ended in a much worse way, so honestly I got off pretty lightly.

The FAFO Scale

If you don’t know it, FAFO stands for “Fuck Around and Find Out.” It’s the universal rule of curiosity and consequences. The more you experiment, the closer you get to the part where the system pushes back.

That’s what happened to me. I tested something I shouldn’t have, and I found out. The ban was the natural ending of the experiment, and honestly, I respected it. It proved that Perplexity’s systems catch behavior outside the rules eventually.

It also reminded me that curiosity and consequences are two sides of the same coin. You just have to be okay with whichever one shows up first.