I have tried Notion. Tried Apple Notes. Tried dumping things in a text file. All of them eventually become a graveyard of notes I never revisit.

So I set up something different. This post is about the system – what it is, why it works, and the one thing that makes it actually stick.

The problem with most note-taking

Most people take notes the wrong way. They copy. They highlight. They summarize what they read. Then they file it somewhere and feel organized.

None of that is learning. None of it compounds.

When you copy a sentence from a textbook, you are transcribing, not thinking. The note exists but the understanding does not. Two weeks later the note is as foreign as the textbook was the first time.

The thing that actually builds knowledge is elaborative encoding – restating an idea in your own words, connecting it to something you already understand. This is not a productivity tip. It is how memory works. You encode new information by hooking it into existing mental models. No hooks, no retention.

A second brain should force you to do that. Most setups do not.

Two systems, one vault

The system I use is a hybrid of PARA and Zettelkasten. They solve different problems.

PARA (Projects, Areas, Resources, Archive) is for navigation. It answers “where do I put this?” and “where do I find that?” It is project-oriented, folder-based, practical. Good for builders.

Zettelkasten is for thinking. It answers “what do I actually know?” and “how does this connect to that?” It is idea-oriented, flat, link-based. Good for writers and researchers.

The mistake people make is picking one and ignoring the other. PARA without Zettelkasten gives you a well-organized filing cabinet you never think with. Zettelkasten without PARA gives you a beautiful graph of ideas with no place to track actual work.

The vault structure I landed on:

00-Inbox/          everything lands here first
Projects/          one subfolder per active project
Daily/             date-named daily notes
Notes/             Zettelkasten permanent notes (flat)
Learning/          STEM subjects, structured
Templates/         note templates
Archive/           completed projects, old notes

Projects and Daily are pure PARA. Notes is pure Zettelkasten. Learning is the interesting hybrid.

The three note types that matter

Zettelkasten has three kinds of notes, and most explanations of the system spend too much time on the taxonomy and not enough on why the types are different.

Fleeting notes are raw captures. They live in 00-Inbox. They are temporary by design – process them within a week or delete them. Zero friction at capture time. Do not organize, do not format, just dump it.

Concept notes live in Learning/. One concept per note, explained in your own words. Fixed structure: what it is in your words, the core intuition, a concrete example you can trace through, where you got confused, and how it connects to things you already know. That last field – where you got confused – is the most valuable part most people skip. Your confusions are where your understanding has gaps. Future you needs to know where those are.

Permanent notes live in Notes/. These are the ones that compound. One fully-formed idea per note, stated as a claim. Not a topic – a claim.

BAD: Eigenvalues GOOD: Eigenvalues represent stretch magnitude along a transformation's invariant axes

BAD: CNCFlow GTM GOOD: CAD users switch tools only when workflow pain exceeds switching cost

The difference matters. A topic title is a filing label. A claim title is a thought. When you write it as a claim, you have to commit to believing something. That forces the thinking.

The rule that makes everything work

Write in your own words only. No copy-pasting.

This sounds obvious. It is the hardest part. The temptation when reading a paper or watching a lecture is to quote the good parts, paste them into a note, and feel like you captured something. You did not. You moved text from one place to another.

A wrong note you wrote yourself is more valuable than a correct note you copied. When you write something wrong, you will notice the contradiction when you link it to something else. The note will tell you where your understanding broke. A copied note just sits there looking authoritative.

Learning STEM in the vault

STEM is where this system earns its keep more than anywhere else.

The standard study loop – read, highlight, review – fails because it is passive. You are reading the author’s thoughts, not building your own. By the third session you are highlighting things you highlighted before because nothing stuck.

The vault forces a different loop. After reading a section or watching a lecture, I write a Concept Note in Learning/{subject}/. Not a summary – my understanding. If I cannot explain it in my own words, I do not understand it yet, and that is useful to know.

Then I ask: does this connect to anything in Notes/? Can I extract a permanent note – a cross-domain insight?

Working through linear algebra:

• Concept Note in Learning/Math/Linear-Algebra/: eigenvalues
• Then in Notes/: Eigenvalues are to matrix transformations what CAD constraints are to parametric models -- they identify the invariant structure

That second note is mine. Nobody wrote it in a textbook. It is hooked into my mental model of CAD, which I think about constantly. I will not forget it.

This is the compounding effect the system is supposed to produce. Your STEM learning starts talking to your project work. The graph of connected notes becomes a map of your actual understanding, not a collection of things you have read.

Wiring an AI agent into the vault

The last piece is automation. I use Hermes (my local AI agent) to read and write to the vault directly.

Before any research task, Hermes searches Notes/ and Learning/ for what I already know. This prevents re-deriving things and surfaces relevant context automatically. If I ask it to explain something I have already written a concept note on, it reads the note first and builds on my existing understanding rather than explaining from scratch.

After a learning session, Hermes writes structured Concept Notes to the right Learning/ subfolder and extracts candidate permanent notes to Notes/. I review and edit them – the thinking is mine, but the structuring is automated.

For projects, Hermes appends decisions to the decisions log table in the relevant Project Note. Every non-obvious decision gets a row: what was decided, why. This sounds like overhead. It pays back immediately the first time you pick up a paused project and actually remember why you made the choices you did.

What I skip

I do not write notes for things I can re-derive in five minutes. I do not write notes for things that are already in the code, the commit history, or the PR description. I do not write notes to feel productive.

The weekly review is Sunday, twenty minutes. Process Inbox, promote or delete every note, update status tags on Learning notes (seedling – just captured, growing – building understanding, evergreen – solid and stable), write or update one permanent note. If the review takes longer than twenty minutes, the system is too complicated.

Delete freely. A cluttered vault is a dead vault. If a note has not been touched in six months and is not evergreen, archive it or delete it.

The real test

The system works if, six months from now, I can open the vault and quickly surface what I actually think about a topic – not what I have read about it, but what I understand and how it connects to everything else I am working on.

The graph view in Obsidian will show clusters. Notes in the CS cluster linking to notes in the Projects cluster. An insight from linear algebra linking to a CNCFlow architecture decision. A note on organic growth on X linking to a note on network effects from graph theory.

Those links are the point. Not the notes themselves – the connections between them. That is the second brain: not a better filing cabinet, but a map of how your own thinking connects.

So I built freeseek-proxy: a local proxy that sits between OpenAI-compatible clients (opencode, Claude Code, any SDK) and DeepSeek’s web chat backend. You send standard /v1/chat/completions requests; it handles sessions, PoW, TLS fingerprinting, and SSE translation behind the scenes.

This post covers the four hardest problems I had to solve.

The architecture (it’s two processes, not one)

The proxy is split into two halves that talk over localhost:

                  ┌──────────────────────────┐
                  │   Client                 │
                  │   (opencode / curl / SDK)│
                  └────────────┬─────────────┘
                               │
                  POST /v1/chat/completions
                       (OpenAI format)
                               │
                  ┌────────────▼─────────────┐
                  │   TypeScript Proxy       │
                  │   Hono on Bun :9123      │
                  │                          │
                  │   · Request normalization│
                  │   · Tool-call compat     │
                  │   · SSE reformatting     │
                  │   · Session management   │
                  └────────────┬─────────────┘
                               │
                    HTTP localhost:8081
                               │
                  ┌────────────▼─────────────┐
                  │   Python Backend         │
                  │   FastAPI + uvicorn      │
                  │                          │
                  │   · curl_cffi (TLS spoof)│
                  │   · WASM PoW solver      │
                  │   · Cookie management    │
                  │   · Auth (token / login) │
                  └────────────┬─────────────┘
                               │
                   HTTPS chat.deepseek.com
                               │
                  ┌────────────▼─────────────┐
                  │      DeepSeek API        │
                  └──────────────────────────┘

Why two languages? DeepSeek does browser fingerprinting. Their servers check TLS fingerprints, and if yours looks like python-requests or node-fetch, you get blocked. The Python side uses curl_cffi with impersonate="chrome120" to produce a TLS handshake indistinguishable from Chrome. The TypeScript side handles everything else — request translation, streaming, tool calls — where Bun’s performance and type safety matter more.

Problem 1: Proof-of-Work with a WASM SHA3 solver

DeepSeek doesn’t just check your auth token. Before every chat completion, you must solve a Proof-of-Work challenge. The flow is:

1. Request a challenge from /api/v0/chat/create_pow_challenge
2. The server returns a challenge string, salt, difficulty, and expiry
3. You run a SHA3-based hash computation until you find a valid answer
4. Encode the answer as base64 JSON and send it as x-ds-pow-response header

The catch: DeepSeek’s PoW algorithm is implemented in a WebAssembly module. In the browser, this runs natively. Outside the browser, you need a WASM runtime.

The solver uses wasmtime (a standalone WASM runtime for Python) to load DeepSeek’s own sha3_wasm_bg.wasm binary and call its exported wasm_solve function:

 1class DeepSeekHash:
 2    def init(self, wasm_path: str):
 3        engine = wasmtime.Engine()
 4        with open(wasm_path, "rb") as f:
 5            wasm_bytes = f.read()
 6        module = wasmtime.Module(engine, wasm_bytes)
 7        self.store = wasmtime.Store(engine)
 8        linker = wasmtime.Linker(engine)
 9        linker.define_wasi()
10        self.instance = linker.instantiate(self.store, module)
11        self.memory = self.instance.exports(self.store)["memory"]
12        return self
13
14    def calculate_hash(self, algorithm, challenge, salt, difficulty, expire_at):
15        prefix = f"{salt}_{expire_at}_"
16        # Allocate WASM memory, write challenge + prefix
17        challenge_ptr, challenge_len = self._write_to_memory(challenge)
18        prefix_ptr, prefix_len = self._write_to_memory(prefix)
19        # Call the exported solver
20        self.instance.exports(self.store)["wasm_solve"](
21            self.store, retptr,
22            challenge_ptr, challenge_len,
23            prefix_ptr, prefix_len,
24            float(difficulty),
25        )
26        # Read the answer from WASM memory
27        value_bytes = bytes(memory_view[retptr + 8 : retptr + 16])
28        value = np.frombuffer(value_bytes, dtype=np.float64)[0]
29        return int(value)

The memory management is manual — you allocate via __wbindgen_export_0, write UTF-8 bytes one at a time, call the solver, then read the result from a return pointer. Stack pointer cleanup happens in a finally block. It’s the kind of code where one off-by-one error means silent corruption.

Why Python 3.11 specifically? The wasmtime + numpy + curl_cffi stack was verified working on 3.11. Python 3.14 caused silent failures in the WASM path during testing — the process would get killed mid-computation with no error message. This isn’t a “should work” situation; it’s a “was tested and doesn’t” situation.

Problem 2: TLS fingerprinting and Cloudflare

DeepSeek sits behind Cloudflare. Standard HTTP clients get 403s or “Just a moment…” challenge pages because their TLS Client Hello doesn’t match what a real browser sends.

The fix is curl_cffi with browser impersonation:

1response = requests.post(
2    f"{BASE_URL}{path}",
3    headers=headers,
4    json=body,
5    cookies=cookies,
6    impersonate="chrome120",  # TLS fingerprint matches Chrome 120
7    stream=stream,
8)

impersonate="chrome120" makes the TLS handshake (cipher suites, extensions, ALPN) identical to Chrome 120. This is why the backend is Python, not Node — there’s no equivalent library in the JS ecosystem that matches real browser TLS fingerprints this precisely.

The cookie management layer adds another defense: if a request hits Cloudflare anyway, the proxy can automatically refresh cookies via a configurable shell command:

1def refresh_cookies(self) -> dict[str, str]:
2    if not self.refresh_command:
3        return self.load_cookies()
4    subprocess.run(self.refresh_command, shell=True, check=True)
5    cookies = self.load_cookies()
6    self.save_cookies(cookies)
7    return cookies

This lets you plug in whatever cookie extraction tool you prefer — a headless browser script, a browser extension export, etc.

Problem 3: Translating SSE formats

DeepSeek’s streaming format is not OpenAI’s streaming format. Both use Server-Sent Events, but the payload structure is completely different.

OpenAI format (what clients expect):

1data: {"choices":[{"delta":{"content":"Hello"},"index":0}],"model":"gpt-4"}

DeepSeek format (what the server sends):

1data: {"v":{"response":{"fragments":[{"type":"text","content":"Hello"}]}},"o":"APPEND"}

DeepSeek uses a nested structure where content lives inside response.fragments, operations can be APPEND, SET, or BATCH, and thinking content is separated from regular content by fragment type. There’s also metadata like response/status and response/accumulated_token_usage mixed into the stream that clients don’t want.

The proxy handles this translation in parseSSELine and extractDeepSeekContent:

 1function extractDeepSeekContent(
 2  data: DeepSeekSSEData,
 3  includeThinking: boolean
 4): string {
 5  // DeepSeek nests content in multiple possible locations
 6  const target = data.v?.response ?? data.response ?? data;
 7  const fragments = target?.fragments;
 8
 9  if (Array.isArray(fragments)) {
10    return fragments
11      .filter(f => includeThinking || f.type !== "thinking")
12      .map(f => f.content)
13      .join("");
14  }
15
16  // Fallback: direct content field
17  if (typeof data.v === "string") return data.v;
18  if (typeof data.content === "string") return data.content;
19  return "";
20}

For streaming responses, each DeepSeek SSE chunk gets translated into an OpenAI chat.completion.chunk on the fly. For non-streaming, the proxy accumulates all chunks, then builds a single chat.completion response.

Problem 4: Tool calls on a model that doesn’t support them

This is the most interesting problem. DeepSeek’s web chat API doesn’t support OpenAI-style tool calls. There’s no tools parameter, no tool_choice, no tool_calls in the response. But clients like opencode and Claude Code rely heavily on tool use — without it, the agent can’t read files, run commands, or interact with your codebase.

The solution is a prompt-engineering compatibility layer. When the proxy detects tool-related fields in the request, it:

1. Injects a system prompt describing available tools and the expected JSON format
2. Flattens the conversation into a single prompt (including tool results from previous turns)
3. Parses the model’s response for JSON tool call envelopes
4. Translates back into OpenAI’s tool_calls format

The injected system prompt instructs the model to output tool calls as JSON:

 1function buildToolSystemPrompt(tools, toolChoice) {
 2  return [
 3    "You are replying through an OpenAI-compatible proxy that supports tool use.",
 4    toolChoiceRule, // varies by mode: auto/required/none/function
 5    `If you decide to call a tool, output only valid JSON with this exact shape:`,
 6    `{"opencode_tool_call": {"name": "tool_name", "arguments": { ... }}}.`,
 7    `For multiple calls: {"opencode_tool_calls": [...]}.`,
 8    "Do not wrap the JSON in markdown.",
 9    "Available tools:",
10    availableTools, // name, description, JSON schema for each
11  ].join("\n\n");
12}

The conversation history gets flattened because DeepSeek’s chat API takes a single prompt string, not an array of messages:

 1function formatConversationForDeepSeek(messages) {
 2  return messages.map(message => {
 3    if (message.role === "system") return `System: ${content}`;
 4    if (message.role === "user") return `User: ${content}`;
 5    if (message.role === "assistant") {
 6      if (message.tool_calls?.length)
 7        return `Assistant tool request: ${formatted calls}`;
 8      return `Assistant: ${content}`;
 9    }
10    if (message.role === "tool")
11      return `Tool (${message.tool_call_id}) result: ${content}`;
12  }).join("\n\n");
13}

On the response side, parseToolEnvelope scans the model output for JSON objects containing opencode_tool_call or opencode_tool_calls keys, validates that the function names match known tools, and converts them into proper OpenAI tool_calls with generated IDs:

 1function parseToolEnvelope(text, tools) {
 2  for (const candidate of extractJsonObjectCandidates(text.trim())) {
 3    const payload = JSON.parse(candidate);
 4    const rawCalls = payload.opencode_tool_calls ?? [payload.opencode_tool_call];
 5    const toolCalls = rawCalls
 6      .filter(call => tools.some(t => t.function.name === call.name))
 7      .map(call => ({
 8        id: `call_${uuidv4()}`,
 9        type: "function",
10        function: { name: call.name, arguments: JSON.stringify(call.arguments) },
11      }));
12    if (toolCalls.length) return { toolCalls };
13  }
14  return null;
15}

The JSON extraction is deliberately robust — it uses a bracket-depth parser to find JSON objects embedded in natural language, handles escaped strings, and tries multiple candidates. This matters because the model sometimes wraps tool calls in explanatory text despite being told not to.

For streaming with tools, there’s an extra step. The proxy can’t stream tool calls token-by-token (the client needs the complete tool call object). So when tools are present, the proxy collects the full response first, parses tool calls, then re-streams the result as a synthetic SSE sequence. This adds ~latency but is the only correct approach.

What the client sees

After all this translation, what comes out the other end is a standard OpenAI response:

1curl http://localhost:9123/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "deepseek-chat",
5    "messages": [{"role": "user", "content": "Hello"}],
6    "stream": true
7  }'

data: {"id":"chatcmpl-abc","object":"chat.completion.chunk","choices":[{"delta":{"role":"assistant"},"index":0}]}
data: {"id":"chatcmpl-abc","object":"chat.completion.chunk","choices":[{"delta":{"content":"Hello"},"index":0}]}
data: {"id":"chatcmpl-abc","object":"chat.completion.chunk","choices":[{"delta":{"content":"!"},"index":0}]}
data: [DONE]

Indistinguishable from OpenAI. Any client that speaks the OpenAI protocol works without modification.

What I learned

WASM outside the browser is viable but fragile

The wasmtime runtime works, but debugging WASM memory issues from Python is miserable. There’s no stack trace when you read the wrong offset — you just get garbage bytes. The debug flags in pow.py exist because I needed them.

TLS fingerprinting is the real gate, not auth tokens

I initially thought the hard part would be authentication. It wasn’t. The hard part was making HTTP requests that don’t get blocked. curl_cffi with browser impersonation is the only reliable solution I found for Python. If you’re building any kind of web scraper or API proxy in 2026, TLS fingerprinting is the first problem you’ll hit.

Tool call compatibility via prompting is surprisingly reliable

I expected the prompt-engineering approach to tool calls to be flaky. It’s not. DeepSeek’s models are good at following structured output instructions, and the JSON extraction parser handles edge cases well. The key is being very explicit about the expected format and validating against the known tool list.

Two-process architecture was the right call

Splitting into TypeScript + Python felt like overengineering at first. It wasn’t. Each language does what it’s best at: Python for the “pretend to be a browser” parts (TLS, WASM), TypeScript for the “translate between API formats” parts (streaming, types, request handling). Trying to do both in one language would have meant worse tooling for at least half the problem.

Links

• Repo: freeseek-proxy
• curl_cffi: docs — Python HTTP client with browser TLS impersonation
• wasmtime-py: GitHub — Python bindings for the Wasmtime WASM runtime
• Hono: hono.dev — Lightweight web framework for Bun/Node/Deno