FLAMEEE

The edge reads you before the payload

Tue, 03 Nov 2026 00:00:00 GMT

The scene repeats itself. The request works in the browser and fails in curl. You check the header, the token, the body, all identical, and conclude the target “detects tooling”. So you improve the User-Agent, add Chrome’s headers, and keep collecting 403s.

What took me a long time to internalise is that, at that point, the server has probably not read anything you sent. The decision was already made in the handshake, based on how your client introduced itself — before HTTP existed, before a header existed, before a payload existed. There is a whole layer of identity that I spent years filing under “networking detail”, and that in practice decides whether my test starts at all.

This post is about that layer. I am going to open the ClientHello field by field, show why every TLS library produces a stable signature, explain JA3 and why it died for browsers in 2023, decode JA4 end to end, and finish with the layers that are not TLS but count just the same. All of it measured, none of it “they say”.

Anatomy of a ClientHello

Before any fingerprint, the object. The current standard is RFC 9846 (July 2026), which obsoletes RFC 8446. Yes, TLS 1.3 was republished, and almost everything you will read still cites 8446. The ClientHello structure is unchanged:

TEXT

struct {
    ProtocolVersion legacy_version = 0x0303;
    Random random;
    opaque legacy_session_id<0..32>;
    CipherSuite cipher_suites<2..2^16-2>;
    opaque legacy_compression_methods<1..2^8-1>;
    Extension extensions<8..2^16-1>;
} ClientHello;

Six fields. I will walk through each one with a single question in mind: is this signal, or is it noise?

Field	Bytes	What it is	Does it fingerprint?
`legacy_version`	2	Pinned to `0x0303` in TLS 1.3	Barely: everyone sends the same thing
`random`	32	Drawn fresh on every connection	Never. If it shows up in a hash, the hash is broken
`legacy_session_id`	0–32	In compatibility mode, 32 random bytes	Yes: presence and length separate clients
`cipher_suites`	variable	Suite list, in preference order	Heavily: the set and the order
`legacy_compression_methods`	1	Exactly `00` in TLS 1.3	A constant today
`extensions`	variable	Set, order and content	The richest field of all

Three things here deserve attention, because they are where the mental model usually breaks.

legacy_version is a lie by design. TLS 1.3 does not state its version there; it says 0x0303 (TLS 1.2) and puts the real version in an extension, supported_versions. The reason is historical: old middleboxes rejected hellos carrying a higher version number, so the legacy field was frozen to slip past dumb equipment. The direct consequence for fingerprinting: JA3 reads the legacy field, so it cannot tell 1.2 from 1.3.

The 32-byte session id is “compatibility mode” (Appendix E.4 of RFC 9846). To make a 1.3 handshake look like a 1.2 resumption, the client sends a non-empty session id plus a dummy change_cipher_spec. In my measurements, every TLS 1.3 connection from all 10 stacks sent 32 bytes, and every client restricted to TLS 1.2 sent an empty one, with one exception (Go, which sends 32 bytes in both cases). So an empty session id in a 1.3 hello is a strong “not a browser” signal.

The random does not count. Across two Python requests runs the raw ClientHello bytes differ (0adf02f5c7e64d31… versus 60bebb560e3f784a…) while JA3 and JA4 are identical. That is the definition of a fingerprint that works: the bytes change, the structure does not.

The extensions are the signature

If you memorise one table in this post, make it this one. Extensions are what separates one client from another, and each is identified by a 16-bit number. These are the codepoints that actually show up, checked against the IANA registry:

hex	Name	What it does	Where it lands
`0x0000`	server_name	SNI: the host you want	`d`/`i` in JA4
`0x0005`	status_request	asks for OCSP stapling	set
`0x000a`	supported_groups	curves/groups accepted	JA3 (field 4), absent from JA4
`0x000b`	ec_point_formats	EC point format	JA3 (field 5)
`0x000d`	signature_algorithms	signature algorithms	JA4, in order
`0x0010`	ALPN	`h2`, `http/1.1`…	`h2`/`h1` in JA4
`0x0012`	signed_certificate_timestamp	SCT (CT)	set
`0x0015`	padding	hello padding	set
`0x0017`	extended_master_secret	1.2 legacy	set
`0x001b`	compress_certificate	certificate compression	set
`0x0023`	session_ticket	resumption	set
`0x002b`	supported_versions	the real version	`13`/`12` in JA4
`0x002d`	psk_key_exchange_modes	PSK modes	set
`0x0033`	key_share	public key exchange material	count, content never
`0xff01`	renegotiation_info	anti-renegotiation	set
`0xfe0d`	encrypted_client_hello	ECH	set
`0x44cd`	application_settings (ALPS)	application settings	set

Two rows in that table deserve their own paragraph, because they are the ones I have seen described wrongly most often.

0xfe0d in Chrome is ECH GREASE, not real ECH. Chrome calls SSL_set_enable_ech_grease(ssl, 1) on the opportunistic path, and BoringSSL documents that this “sends a GREASE ECH extension when no supported ECHConfig is available”. Since localhost has no ECHConfig in DNS, what goes out is a fake ECH: 218 bytes on the connection I inspected, with a random payload and a size that varies. The extension exists, but it is hiding nothing: it is extensibility noise.

0x44cd is real ALPS, and it is unregistered. The payload I captured is 00 03 02 68 32: a list length, a protocol length, and the letters h2. It literally says “my application settings are for h2”. Cross-check: on Chrome running with --disable-http2 that extension disappears, and the hello drops from 17 to 16 extensions. BoringSSL calls this family “ALPS (draft-vvv-tls-alps)” and keeps two codepoints (old and new, selected by alps_use_new_codepoint), while the draft leaves the IANA value as TBD. That is why the number you see on the wire is experimental and missing from the registry.

GREASE: noise on purpose

RFC 8701 reserves values to be advertised at random: 0x0A0A through 0xFAFA for extensions, groups, signature algorithms and versions; {0x0A,0x0A} through {0xFA,0xFA} for cipher suites and ALPN. The point is to force the other end to ignore what it does not know, so the ecosystem does not seize up when a new value appears.

For fingerprinting, GREASE is noise injected on purpose, and an accidental anti-fingerprint: the client changes its hello without changing software. In the measurements, only Chrome (and curl_cffi, which copies Chrome) sends GREASE: one cipher, two extensions, one group, one supported_versions entry and one signature algorithm, with values re-randomised on every connection. The other nine stacks send none.

TLS 1.2 and 1.3 don’t look alike on the wire

Worth putting side by side, because it is the easiest difference to lose:

	TLS 1.2	TLS 1.3
version	`legacy_version` and nothing else	fixed `legacy_version` + `supported_versions`
key exchange	groups and point formats	`key_share` with material in the hello
compression	a real list	exactly `00`
session id	real resumption	32 random bytes (compat)
resumption	session id / ticket	PSK + `psk_key_exchange_modes`

The effect on fingerprints is direct and a little cruel: because JA3 reads the legacy version, its version field is the same (771) for 1.2 and for 1.3. What separates the two hellos is the rest of the list, not the version. JA4 reads supported_versions and marks t12 against t13 in the first part. And since 1.3 requires key_share and psk_key_exchange_modes, the extension count moves with it.

Every stack writes its own hello

Here is the structural insight that makes the rest of this make sense: the ClientHello is not negotiated, it is written. It is the output of a table compiled into the binary.

In BoringSSL, ssl/extensions.cc holds a kExtensions[] table, and the builder walks that table calling each entry’s add_clienthello. In practice the extension order is a compile-time constant, except when it is shuffled. We will get there. The cipher list is a table too: kCiphers[], in ssl_cipher.cc, with the three TLS 1.3 suites in a fixed order.

Except “compiled table” does not mean “identical across stacks”. Measuring the same request through different tools:

Client measured	Ciphers / extensions (no GREASE)	JA4
macOS curl 8.7.1 (LibreSSL 3.3.6)	49 / 7	`t13d4907h2_0d8feac7bc37_7395dae3b2f3`
Homebrew curl 8.21.0 (OpenSSL 3.6.4)	30 / 12	`t13d3012h2_1d37bd780c83_882d495ac381`
Python 3.15 (requests and httpx, OpenSSL)	17 / 12	`t13d1712h1_ab0a1bf427ad_0d46a1bf4a7c`
Go 1.25 `net/http`	13 / 12	`t13d1312h2_f57a46bbacb6_ab7e3b40a677`
Java 21.0.8 `java.net.http`	37 / 13	`t13d3713h2_db35923f8641_7c76daad20ec`
Node 26.8.2 (undici)	52 / 12	`t13d5212h1_b262b3658495_8e6e362c5eac`
Chrome 156	15 / 17	`t13d1517h2_8daaf6152771_cb7bf5808d99`

Look at the first two rows. They are the two curl on the same machine: one is the system build, the other is Homebrew’s. Same command, same name, different fingerprint, because the macOS one uses LibreSSL and the Homebrew one uses OpenSSL. If you copied a Linux tutorial and ran it on a Mac, you are advertising a different stack.

Language is not the signal either. Python and Node both sit on OpenSSL; Python sends 17 ciphers and Node sends 52. What counts is the library and its version, not the language.

JA3: one line, one MD5, and a problem

JA3 (Salesforce, 2017) is about as simple as an idea gets: take five fields from the hello, join them into text, hash it.

TEXT

SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat

Decimal values, , between fields, - inside a field, MD5 at the end. The example from the official README, which I recomputed:

TEXT

769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0
  → ada70206e40642a3e4461f35503241d5

It worked in 2017 because it was cheap to compute and discriminating enough. And it still works today for what it is: a way of saying “these bytes appeared in this order”.

Except “in this order” is the fragile part, and the list of weaknesses is short and honest: order matters; there is no extension content (only the numbers); 1.2 and 1.3 blur together; MD5 is an identifier, not an authenticator; and the implementation divergence Fastly measured. None of those is fatal on its own. Together, they left JA3 ready to be killed.

And in 2023 someone killed it on purpose.

2023: Chrome broke JA3 on purpose

In the Chromium source, net/socket/ssl_client_socket_impl.cc, there is an unconditional line on the TLS connection path:

CPP

SSL_set_permute_extensions(ssl_.get(), 1);

On the other side, in BoringSSL, ssl_setup_extension_permutation() runs a Fisher-Yates shuffle with RAND_bytes over the kExtensions indices — and the emit loop walks the permutation instead of the natural order. In plain terms: Chrome shuffles the extension order of the ClientHello on every connection.

The motive is anti-ossification, and it is a good motive: if servers get used to a fixed order, any future change to Chrome breaks the internet. Shuffling forces the ecosystem to treat order as irrelevant. The side effect is that JA3, which depends on exactly that order, turned into noise.

Fastly measured the damage at the time: from 20 January 2023 the most common Chrome JA3 on their network fell away, and since the number of permutations is “nearly 15 factorial (about 10¹²)”, in practice every connection produces a unique JA3. Cloudflare put it bluntly: it made “older TLS fingerprints almost useless for identifying the latest version of Chrome”.

Now the number I measured, because this is where theory becomes obvious. Three fresh connections from the same Chrome 156 build:

TEXT

connection 1  →  JA3 0e250605ce1f2c793bb1a2269dd30e01
connection 2  →  JA3 47e376a38884e22f8a6bb4661daa71a9
connection 3  →  JA3 5c34099f1b500a60c0deacb3f8d31187
         all  →  JA4 t13d1517h2_8daaf6152771_cb7bf5808d99

Three different JA3. One JA4. If you built a WAF rule on browser JA3, it has been dead for three years.

JA4: how to read the whole fingerprint

JA4 (FoxIO, 2023) solves this with two decisions: sort what is arbitrary, and put readable information in front of the hash. The format is a_b_c:

TEXT

t13d1516h2_8daaf6152771_e5627efa2ab1

I am going to decode that specification example end to end, because it is the best study material there is, and because I recomputed every hash.

Part	Value	Meaning
`t`	t	TLS over TCP (`q` = QUIC, `d` = DTLS)
`13`	13	TLS 1.3, read from `supported_versions`
`d`	d	SNI present (`i` = no SNI, went to an IP)
`15`	15	15 cipher suites, not counting GREASE
`16`	16	16 extensions, not counting GREASE
`h2`	h2	first and last character of the first ALPN
`8daaf6152771`	hash	sha256 of the sorted ciphers, truncated to 12
`e5627efa2ab1`	hash	sha256 of the sorted extensions (minus SNI and ALPN) + sigalgs in order

The 15 ciphers, named from the IANA registry: 002f and 0035 (RSA CBC), 009c and 009d (RSA GCM), 1301/1302/1303 (the three TLS 1.3 suites), c013/c014 (ECDHE_RSA CBC), c02b/c02c (ECDHE_ECDSA GCM), c02f/c030 (ECDHE_RSA GCM) and cca8/cca9 (ECDHE ChaCha20). The classic modern-client mix: the 130x for 1.3 plus a 1.2 basket for talking to old servers.

The 16 extensions: 001b compress_certificate, 0000 SNI, 0033 key_share, 0010 ALPN, 4469 ALPS (the old codepoint), 0017 extended_master_secret, 002d psk_key_exchange_modes, 000d sigalgs, 0005 status_request, 0023 session_ticket, 0012 SCT, 002b supported_versions, ff01 renegotiation_info, 000b ec_point_formats, 000a supported_groups, 0015 padding.

Recomputing with sha256sum:

TEXT

sha256("002f,0035,009c,009d,1301,1302,1303,c013,c014,c02b,c02c,c02f,c030,cca8,cca9")[:12]
  = 8daaf6152771

sha256("0005,000a,000b,000d,0012,0015,0017,001b,0023,002b,002d,0033,4469,ff01_0403,0804,0401,0503,0805,0501,0806,0601")[:12]
  = e5627efa2ab1

Two details that are worth more than memorising the rules. First: SNI and ALPN are excluded from c on purpose, because they are already in a. So the same client produces the same c whether it goes to a domain or an IP. Second: sigalgs go in in the order they appear, unsorted, glued on after a _. Sort them and the hash changes; I watched that mistake appear in a lab, and FoxIO publishes the vector that gives it away (0403,0804,0401,…, unsorted).

Now the reveal, comparing the spec example with my measured Chrome 156:

TEXT

spec       t13d1516h2_8daaf6152771_e5627efa2ab1
Chrome 156 t13d1517h2_8daaf6152771_cb7bf5808d99

The b is identical. Chrome’s cipher list did not change between those builds. What changed were the extensions: one more (17 against 16), and c moved with it. That proves the algorithm is doing its job: the stable part stayed stable, the part that changed changed.

Sorting is a design decision

What I find most elegant about JA4 is not the format, it is the choice of where to sort. I built the minimal case: the same set of extensions, in two orders.

TEXT

order A: 10-11-13-16-23-35-43-51  →  JA3 692aefc05b6b8a9afca0d6486e3b15e4
order B: 51-43-35-23-16-13-11-10  →  JA3 79e887fad94c5bfc974a532532781ec3
                                     JA4_c 8ccb6ff8ed2a (identical in both)

same list, two orders, two JA3 and one JA4

Two JA3, one JA4. And the rule behind it is not “order doesn’t matter”: it is that you sort what is semantically irrelevant and actively randomised. TLS extensions are both. HTTP header order, on the other hand, is randomised by nobody and carries information — and JA4H, the HTTP client fingerprint from the same family, does not sort headers. JA4S, which looks at the server’s answer, preserves the original order on purpose.

Three decisions, one ruler. That is what separates a format that ages well from one that has to be replaced within five years.

What JA4 chooses not to see

No fingerprint sees everything, and it is worth being explicit about what is left out, because that is where bad diagnostic decisions come from.

Not in JA4	Why	Practical consequence
`random`, session id, `key_share` bytes	they are random	the hash is stable; the bytes never are
`supported_groups`	deliberately outside `c`	two clients differing only in a post-quantum group give the same JA4
the SNI string	only “present or not”	the hostname is not in the hash
extension order	sorted	invisible to JA4, visible to JA3
cipher order	sorted	you gain stability and lose the preference
ALPN beyond the first/last char	only 2 characters	`http/1.1` and `http/1.1,h2` look identical

That last one is the most treacherous, and it is in my records: httpx in HTTP/2 mode offers http/1.1, h2, the reverse order, and produces exactly the same JA4 (t13d1712h1_…) as requests, which only offers http/1.1. The a field takes the first and last character of the first value, so http/1.1 becomes h1 and the trailing h2 disappears. A sensor that only looks at JA3/JA4 cannot tell that client asked for HTTP/2.

And post-quantum deserves a note: Chrome, Go, Node and OpenSSL 4 offer X25519MLKEM768 (0x11ec, defined in RFC 10024); Java 21 and macOS curl do not. Because JA4 hashes neither groups nor key_share content (Chrome sends a 1216-byte share, different on every connection), the same client keeps the same JA4 before and after PQ. The instability from that change lives entirely in JA3, which hashes supported_groups.

It isn’t only TLS

If you got this far thinking the problem is TLS, the bad news is that there are three more layers. And a fourth thing that is not a layer at all, it is history.

each layer has an owner · not all accept a disguise

HTTP/2. The grammar came from an Akamai white paper in 2017 and it is still the one everyone implements: the fingerprint is built from the frames a client sends before any useful request. The notation is S[;]|WU|P[,]#|PS[,]: SETTINGS parameters with their values, in the order they appear; the WINDOW_UPDATE increment; the priority tuples; and the pseudo-header order, encoded as m, p, a, s. The paper measured more than 10 million connections and, in 2017, published each browser’s order: Chrome m,a,s,p, Firefox m,p,a,s, Safari m,s,p,a.

A premise correction, because I have repeated the error myself: the Akamai format does not include HEADER frame flags. The three flows are SETTINGS, WINDOW_UPDATE and PRIORITY, plus pseudo-header order. If you see someone attributing HEADER flags to Akamai, the source does not exist.

But 2017 is 2017. I measured the clients on this machine, with ALPN negotiating h2 on every connection so nothing degrades silently. Two of them, in the format above:

TEXT

Chrome 156   1:65536;2:0;4:6291456;6:262144|15663105|0|m,a,s,p
Java 21      1:16384;2:0;3:0;4:16777216;5:16384;6:393216|33488897|0|a,m,p,s

Chrome’s PS is still m,a,s,p: the 2017 row survived. Go is still a,m,p,s, matching the paper. And curl moved: it was m,p,s,a on 7.54 and became m,s,a,p on 8.x. That is why you pin the version next to every fingerprint in a table; without it, the table goes stale without warning.

The P field is dead. Across twelve connections, zero PRIORITY frames: P=0 in all of them. The paper’s P was built around Firefox 53’s reserved-stream priorities; today’s Chrome sends the deprecated priority block inside HEADERS plus an RFC 9218 priority header, and the grammar encodes neither. So P=0 means “no PRIORITY frame”, not “no priorities”. It is an honest measure of what a 2017 format loses in 2026.

And the lesson from the TLS section repeats one layer up: the two curl on this machine send the same WINDOW_UPDATE (1048510465) and the same SETTINGS order (3;4;2), but Homebrew sends INITIAL_WINDOW_SIZE=65536 while the macOS one sends 10485760. Same tool, different build, different string.

This matters because a proxy that terminates the connection (and Burp terminates it) builds its own SETTINGS, not the browser’s. And curl_cffi shows the limit of all of it: it ties Chrome on TLS (identical JA4) and on h2 (identical string), and still gets caught one layer up: the measured Chrome 156 sends HeadlessChrome/156 with 17 headers, curl_cffi sends Chrome/152 on Windows with 18, including cache-control. An impersonator has to be right at every layer, and the layers are ordered.

HTTP headers. Order, casing and defaults. JA4H covers this by hashing the names in the order they appear. The hygiene almost everyone forgets is this: if you forge the User-Agent to “Chrome 131” but leave sec-ch-ua saying another version, you did not become more browser-like. You became inconsistent, which is worse than the original.

TCP/IP. TTL, window, MSS and option order come from the kernel, not from your client. p0f has been doing this off a single SYN forever, and the modern equivalent is JA4T, in the format window_options_mss_wscale (FoxIO’s example: 64240_2-1-3-1-1-4_1460_8). It is the layer you cannot fix with a client flag — and why spoofing TLS from a VPS still tells a different story.

A fingerprint is a key, not a verdict

The most common conceptual mistake is assuming the edge decides by looking at a hash. It does not, and Cloudflare documents the opposite: alongside JA4 it computes what it calls JA4 Signals: aggregate statistics over the last hour, globally. The names are explicit: browser_ratio_1h, h2h3_ratio_1h, reqs_quantile_1h, uas_rank_1h, paths_rank_1h, cache_ratio_1h, ips_rank_1h, among others.

JA4 is the key. What carries weight is how that key is distributed. A vanishingly rare JA4 claiming to be Chrome, with a low browser_ratio_1h and high volume, is a lost cause, and no cipher adjustment fixes it. Worse: those signals are analytics, not rules (“They cannot be used as filter fields in WAF custom rule expressions”), so you cannot even simulate the decision by looking only at the hash.

And there is one confusion that costs hours: a block and a challenge are not the same thing. A challenge comes back as HTML, with the header cf-mitigated: challenge, and exists to run JavaScript in your browser. A cf_clearance obtained there is bound to the device that solved it, and solving from one IP while using it from another invalidates the solve. If that is your case, the problem is not TLS at all, and no impersonator will fix it.

Who computes this today

This is not a research niche. It is something you can write a rule against in production:

Where	What	Since
Cloudflare	JA4 in Bot Management (Enterprise), field `cf.bot_management.ja4`	JA4+Signals announced Aug 2024
AWS WAF	JA3	Sep 2023
AWS WAF	JA4, including as a rate-based rule key	Mar 2025
Google Cloud Armor	`origin.tls_ja4_fingerprint` and `origin.tls_ja3_fingerprint`	documented today
Akamai	JA4 (beta, via injected header)	2026
Fastly	VCL variable `tls.client.ja4` and NGWAF	Feb 2025

Across the 38 connections, the 10 stacks produced 24 distinct JA4, and three different clients collapsed onto the same one (requests, httpx in h1 and in h2). That sums up the state of the art: JA4 is good at saying “what kind of software is this”, and insufficient to say “which tool exactly”. For that you need the next layer.

What I take from this

Four things, and none of them is “use tool X”.

The block happens before the payload. If your encoding, your header and your token are right and you still get a 403, the answer was probably decided in the handshake. Staring at the body at that point is staring at the wrong place.

The stack is the signal, not the language. Two curl on the same machine, different fingerprints. A library upgrade changes your identity on the network, and nobody tells you.

Browser JA3 died in 2023, on purpose. It is not a bug and not a maintenance gap: it is an engineering decision by Chrome that Fastly measured and Cloudflare commented on. Anyone still building detection on browser JA3 is tracking a target that moves on every connection.

And the fingerprint is never the whole story. It is one key in a decision that also weighs prevalence, ASN, rate, cookie and behaviour. Confusing “my TLS is wrong” with “my IP is burned” is the fastest way to spend the whole afternoon tuning ciphers without changing anything.

In the next post I take the opposite route: I pick up Burp, show across three layers why it announces itself as a Java tool, and what can be done about it — including what cannot, and why.

omp: from zero to /vibe

Thu, 22 Oct 2026 00:00:00 GMT

First real post here, and it’s the tutorial I wish I’d had: going from zero to my omp (oh-my-pi) setup, configured and good-looking, step by step. Everything was checked against omp’s docs and CLI (18.12.5 here; the Linux path was tested in a clean Ubuntu 24.04 container, which installed 18.12.6).

Step	macOS	Linux (Debian/Ubuntu)	Windows
Package manager	Homebrew	apt	winget
Terminal	Warp (mine)	Warp or any terminal with a Nerd Font	Windows Terminal (or Warp)
Nerd Font	`brew install --cask`	zip into `~/.local/share/fonts` + `fc-cache`	zip → Install
Shell theme	Oh My Zsh + p10k	Oh My Zsh + p10k	inside WSL2 only
omp	`brew install can1357/tap/omp`	`curl -fsSL https://omp.sh/install \| sh`	`irm https://omp.sh/install.ps1 \| iex`

What a harness is

If you’ve only used LLMs through a chat window, this is the missing piece. A model on its own is text in, text out. It doesn’t read your repository, doesn’t run commands, doesn’t remember last week. The harness is the program around it that turns it into an agent:

The agent loop. The model asks for a tool call, the harness runs it and feeds the result back, and this repeats until the task is done.
The tools. Reading and editing files, a shell, search, a browser, MCP servers.
What goes into the context. The system prompt, project rules (AGENTS.md), skills, memory, file contents, and compaction when the context fills up.
Permissions and approvals. What runs on its own and what needs your “ok”.
Sessions and history. Picking up where you left off.
Sub-agents and orchestration. Splitting work across several agents (in omp, that includes /vibe).
Model routing. A strong model to think, a cheap one for the grunt work.

Think of a console: the model is the CPU; the harness is everything else, the controller, the memory card and the disc drive.

In practice, the agent acts instead of suggesting: it runs the command and reads the output, no copy-pasting on your end. It keeps state across a long task. And rules, skills and project context make the agent follow your method every time, without you pasting the same instructions into every conversation. Parallel work becomes sub-agents or workers. In my experience, the same model feels like a different one depending on the harness’s tools and how it handles context.

What it does not do: it doesn’t replace judgement, and it doesn’t make a bad model good.

Aspect	Chat	Harness
Runs commands	no	yes, with configurable approval
Edits files	you copy and paste	straight to disk
Project rules	you paste them every time	loaded automatically
Parallel agents	no	sub-agents and workers
Model choice	whatever the app offers	any provider, one per job

Examples of the category: Claude Code, Codex CLI, opencode, Aider, Cursor’s agent, and omp.

Why omp

For me, omp wins by putting all of that in one place: dozens of providers (via environment variables, OAuth login or any compatible gateway), local models detected automatically, model roles with a thinking level per role, sub-agents you can customise in markdown, /vibe, skills, memory across sessions, MCP, approval modes, secret obfuscation, isolated profiles and resumable sessions. And it looks good in the terminal, which is half of this post.

1. Prerequisites and terminal

omp needs no runtime: Homebrew and the official scripts ship a prebuilt binary. Bun (≥ 1.3.14, per the README) only matters if you’d rather install with bun install -g @oh-my-pi/pi-coding-agent.

The terminal has to accept a custom font. On macOS I use Warp, which also has Linux and Windows builds. On Windows, the sensible default is Windows Terminal.

macOS (Homebrew, official command from brew.sh, and Warp)

BASH

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install --cask warp

Linux (the basics the next steps use; terminal: Warp from its site, or whatever you already use)

BASH

sudo apt update && sudo apt install -y curl git unzip fontconfig

Windows (PowerShell; Windows Terminal is also on the Microsoft Store)

POWERSHELL

winget install --id Microsoft.WindowsTerminal -e

2. Nerd Font

A Nerd Font is a programming font patched with thousands of extra icons: the git logo, folders, powerline arrows, spinners. omp uses those icons when you turn on symbolPreset: nerd, its status line has a nerd preset, and the Powerlevel10k prompt in step 3 relies on them too. Without the font, the icons turn into little boxes.

I use JetBrains Mono Nerd Font, in the NL variant (no ligatures), whose family name is JetBrainsMonoNL Nerd Font.

macOS

BASH

brew install --cask font-jetbrains-mono-nerd-font

Linux (the nerd-fonts project’s manual method; fc-list confirms it)

BASH

mkdir -p ~/.local/share/fonts
curl -fsSLo /tmp/JetBrainsMono.zip \
  https://github.com/ryanoasis/nerd-fonts/releases/latest/download/JetBrainsMono.zip
unzip -oq /tmp/JetBrainsMono.zip -d ~/.local/share/fonts/JetBrainsMono
fc-cache -fv
fc-list | grep -i "JetBrainsMonoNL Nerd Font"

On Arch, the official package is sudo pacman -S ttf-jetbrains-mono-nerd.

Windows (download JetBrainsMono.zip from github.com/ryanoasis/nerd-fonts/releases/latest, extract it, select the .ttf files and right-click → Install). Then, in Windows Terminal’s settings.json (Settings with Shift held), set the font for every profile under profiles.defaults:

JSON

{
  "profiles": {
    "defaults": {
      "font": { "face": "JetBrainsMonoNL Nerd Font", "size": 13 }
    }
  }
}

If you use WSL2, install the font on Windows: Windows Terminal draws the icons, not Linux.

Pick it in the terminal. In Warp (any OS), choose JetBrainsMonoNL Nerd Font in the appearance settings. On macOS my ~/.warp/settings.toml looks like this:

TOML

[appearance.text]
font_family = "JetBrainsMonoNL Nerd Font"
font_size = 13.0

[appearance.themes]
theme = "dark"

[appearance.cursor]
cursor_display_type = "bar"

In any other terminal (iTerm2, Ghostty, Kitty, GNOME Terminal…) the principle is the same: the terminal font has to be a Nerd Font.

3. The shell’s look (optional)

I use Oh My Zsh with the Powerlevel10k theme. omp doesn’t need it, but it’s part of how my terminal looks. Zsh, Oh My Zsh and p10k are Unix-shell things: on Windows they work inside WSL2, not in PowerShell.

macOS: zsh is already the default shell; nothing to install.

Linux (and Windows inside WSL2: install it with wsl --install in an administrator PowerShell, reboot, open Ubuntu and continue from here)

BASH

sudo apt install -y zsh git curl
chsh -s "$(which zsh)"   # takes effect on your next login

macOS, Linux and WSL2: from here on it’s the same. Oh My Zsh, then Powerlevel10k as its theme, with the commands from the official READMEs:

BASH

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git \
  "${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k"

In ~/.zshrc, switch the theme (I keep only the git plugin):

BASH

ZSH_THEME="powerlevel10k/powerlevel10k"
plugins=(git)

Open a new terminal; the wizard starts on its own. If it doesn’t, run p10k configure. My picks were nerdfont-v3 + powerline, small icons, rainbow style, 24h clock, angled separators, two lines, transient prompt and instant prompt. The wizard writes everything to ~/.p10k.zsh. In Warp, the p10k prompt only shows up with honor_ps1 = true under [terminal.input].

4. Installing omp

macOS (how I install it)

BASH

brew install can1357/tap/omp

Linux (official script; installs to ~/.local/bin, which has to be on your PATH)

BASH

curl -fsSL https://omp.sh/install | sh
export PATH="$HOME/.local/bin:$PATH"   # put this in ~/.zshrc or ~/.bashrc

Windows (PowerShell, official script; inside WSL2, use the Linux command)

POWERSHELL

irm https://omp.sh/install.ps1 | iex

On any OS, check with omp --version. omp setup runs the onboarding wizard; after that, just run omp inside a project. Everything user-level lives in ~/.omp/agent/ (omp config path shows where): config.yml, models.yml, mcp.json, .env, skills/, agents/.

A provider. OAuth (subscription) is the same everywhere: omp login and pick from the list (inside a session, /login). For an API key, keep it out of your shell history:

macOS and Linux (works in zsh and bash)

BASH

printf 'API key: ' && read -rs K && printf '\nANTHROPIC_API_KEY=%s\n' "$K" >> ~/.omp/agent/.env && unset K
chmod 600 ~/.omp/agent/.env
omp models   # what's available now, grouped by provider

Windows (PowerShell 7.1+; stores a user environment variable that applies to new terminals)

POWERSHELL

$k = Read-Host 'API key' -MaskInput
[Environment]::SetEnvironmentVariable('ANTHROPIC_API_KEY', $k, 'User')
Remove-Variable k

omp reads OPENAI_API_KEY, GEMINI_API_KEY, OPENROUTER_API_KEY, DEEPSEEK_API_KEY and many more; omp --help lists the main ones.

5. Making omp look good

From here to the end, everything is the same on all three OSes: it’s omp config, not OS config. The look lives in ~/.omp/agent/config.yml. These are the values I changed from the defaults:

YAML

# ~/.omp/agent/config.yml — appearance
theme:
  dark: dark-dracula # built-in theme (default: titanium)
symbolPreset: nerd # Nerd Font icons (default: unicode)
statusLine:
  preset: nerd # icons in the status line (default: default)
  contextLine: annotated # annotated context usage
composer:
  shape: box # editor in a box (default: band)
display:
  showTokenUsage: true # tokens per reply
  showTurnTime: true # total time per turn, tool calls included

Or from the CLI, one key at a time (the name has to match the schema exactly):

BASH

omp config set theme.dark dark-dracula
omp config set symbolPreset nerd
omp config set statusLine.preset nerd
omp config set statusLine.contextLine annotated
omp config set composer.shape box
omp config set display.showTokenUsage true
omp config set display.showTurnTime true

All of this is also in /settings inside a session, if you prefer a menu. The other statusLine.preset options are default, minimal, compact, full, ascii and custom. The separator lives in statusLine.separator (powerline, powerline-thin, slash, pipe, block, none, ascii). Custom themes are JSON files in ~/.omp/agent/themes/.

Expected result: when you open omp, the editor sits in a box, the status line shows the model, folder and git state with icons, and the colours are Dracula’s. If you see little boxes, the font from step 2 isn’t selected.

6. Settings worth changing beyond looks

Mine, all of them off the defaults:

Key	Value	What it does
`defaultThinkingLevel`	`max`	default reasoning depth (default: `high`)
`temperature`	`0.7`	sampling temperature (default: the provider’s)
`memory.backend`	`local`	extracts lessons from sessions and injects a summary into the next one (default: `off`)
`autolearn.enabled`	`true`	lets the agent create and update managed skills
`autolearn.autoContinue`	`true`	runs a private lesson-capture turn when it stops; costs tokens
`model.loopGuard.enabled`	`false`	turns off automatic loop detection on reasoning and prose
`model.toolCallLoopGuard.threshold`	`20`	identical calls in a row before it steps in (default: `5`)
`bash.allowCompoundCommands`	`true`	evaluates each command in an `&&` chain separately
`browser.headless`	`false`	shows the window when the agent uses the browser
`computer.enabled`	`true`	enables desktop control (screenshots, input)

Two I recommend to everyone, even though they’re not on my list:

secrets.enabled: true (default false): credential-looking env vars and known patterns (JWTs, Bearer headers, cloud keys) become placeholders in the text sent to the provider and are restored right before a tool runs. It doesn’t catch short values or the static prompt.
tools.approvalMode: the default is yolo (everything runs). If you’re starting out, write approves reads and writes and asks before executing. Sub-agents always run in yolo; the approval that counts is the parent’s.

7. Providers and models

omp works with roles, set under modelRoles in config.yml:

Role	Used for
`default`	the main conversation
`smol`	light tasks; `/vibe` `fast` workers
`slow`	heavy reasoning
`plan`	plan mode (`/plan`)
`task`	sub-agents and `/vibe` `good` workers
`vision`	image analysis
`commit`	`omp commit`
`tiny` / `memory`	session titles and the memory pipeline

A :level suffix sets the thinking level per role (off, minimal, low, medium, high, xhigh, max, auto): default: deepseek/deepseek-v4-flash:max. Unset smol and slow inherit default. To switch: /model opens the hub, Ctrl+P cycles through the role models, Shift+Tab cycles the thinking level, and omp --model opus does fuzzy matching.

Your own gateway (any OpenAI- or Anthropic-compatible endpoint) goes in ~/.omp/agent/models.yml:

YAML

providers:
  my-gateway:
    baseUrl: https://gateway.example/v1
    api: openai-completions # or anthropic-messages, openai-responses…
    apiKey: MY_GATEWAY_API_KEY # name of an env var; omp uses its value
    authHeader: true # Authorization: Bearer <key>
    models:
      - id: vendor/big-model # the id the endpoint expects
        name: Big Model
        reasoning: true
        thinking: { mode: effort, efforts: [low, high, max], defaultLevel: high }
        input: [text, image]
        contextWindow: 1048576
        maxTokens: 131072

apiKey means “env var name or literal”: if it matches a non-empty variable, that value is used. A YAML error makes omp skip the whole file, so always check with omp models my-gateway. And before declaring a provider, run omp models <name>: if it’s already built in, all you need is the credential.

What I use:

default role: deepseek/deepseek-v4-flash:max, through the built-in DeepSeek provider. Everything that inherits default (the fast workers, for example) runs on it.
Main session and /vibe director: Claude Opus (anthropic/claude-opus-5-5). omp lets you switch just the session’s model without touching the default role: Alt+P picks a temporary model for the session, and omp --model opus does the same from the command line.
A gateway in models.yml with DeepSeek V4.1 Flash, Nemotron 3.5 Super VL 120B and GLM-5.3 Flash, all with a 1M context, their effort ladders declared and costs filled in so omp can track spend.

8. /vibe

/vibe turns the session into a director. The director keeps only read, an optional todo and five control tools; the searching, editing and running is done by persistent workers in the background, each with its own transcript.

The director reads and decides; the workers do.

TEXT

/vibe                       # enter the mode
/vibe migrate the parser    # enter and send the first directive
/vibe                       # exit (shuts the workers down)

Tier	Agent	Role	Use for
fast	sonic	@smol	mechanical execution, volume, drafts
good	task	@task	judgement, design, reviewing `fast` output

The director uses vibe_spawn (creates a worker with a brief and a tier), vibe_send (steers or sends the next step), vibe_wait, vibe_kill and vibe_list. You just talk to it in plain language.

To pick the tier models, the docs suggest aliases:

YAML

task:
  agentModelOverrides:
    sonic: '@fast_worker'
    task: '@good_worker'
modelRoles:
  fast_worker: my-gateway/vendor/fast-model
  good_worker: my-gateway/vendor/big-model:high

That override applies to every sonic and task sub-agent, not just /vibe. I didn’t configure any of it: fast inherits default (DeepSeek V4 Flash) and good falls back to the director’s active model (Opus). Cheap grunt work, expensive judgement.

How to brief. A worker can’t see the director’s conversation. Give it files, constraints and an acceptance criterion you can check:

TEXT

Goal: cursor pagination on GET /api/orders.
Files: src/api/orders.ts, tests/orders.test.ts. Don't touch anything else.
Acceptance: `npm test -- orders` passes, with a new test for the last page.
Deliver: the files you touched and the test output.

How to verify. The docs say it plainly: a worker finishing means the turn ended, not that it got things right. The director reads the touched files and the full output at agent://<id>. One worker per workstream, fast and good in parallel, and good reviewing fast when it matters.

Pitfalls: exiting /vibe shuts down every worker; it doesn’t mix with plan mode or goal mode; while it’s on, you can’t start, delete, fork or move the session. This post, by the way, was drafted by an omp worker in a director session.

9. Skills, MCP and AGENTS.md

AGENTS.md: omp loads ~/.omp/agent/AGENTS.md, .omp/AGENTS.md, and a plain AGENTS.md searched from the current directory up to the repo root (it reads CLAUDE.md too). Keep it short: hard rules, and where everything else lives.
Skills: a directory with a SKILL.md (name and description in the frontmatter). Only the name and description go into the prompt; the body loads on demand (skill://<name>). Yours live in ~/.omp/agent/skills/; with autolearn, the agent writes its own into ~/.omp/agent/managed-skills/. I have about 30 of mine (vulnerability classes, methodology, triage, report writing) and dozens of managed ones.
MCP: ~/.omp/agent/mcp.json, with ${VAR} expanded. I use Burp Suite through PortSwigger’s official MCP Server extension (local SSE, by default at http://127.0.0.1:9876), and a private knowledge base, a Python MCP server over my notes:

JSON

{
  "mcpServers": {
    "burp": { "type": "sse", "url": "http://127.0.0.1:9876" },
    "kb": {
      "type": "stdio",
      "command": "${HOME}/kb/.venv/bin/python",
      "args": ["${HOME}/kb/server.py"],
      "env": { "KB_PATH": "${HOME}/kb/data" }
    }
  }
}

10. A taste: bug bounty

For large programs I open several terminals running omp, each with one role, and they talk only through the filesystem. I call it the pack: an orch owns scope and the queue, attackers a1..aN take one host at a time, and a triage validates candidates. Every shared write goes through a bash script, bin/hb:

TEXT

~/hunting/
├── PROTOCOL.md            # the contract: roles, lease, rate, proof
├── bin/hb                 # the bus
├── scope/<program>/       # eligible.txt, deny.txt
└── state/
    ├── queue.jsonl        # append-only queue
    ├── claims/<host>/     # lease via atomic mkdir (owner + epoch)
    ├── findings.jsonl     # everything starts as "candidate"
    ├── dead-ends.md       # verified negatives + the control used
    ├── intel.md           # reusable patterns: "[tag] fact → action"
    └── loot/F-0001/       # request.txt, response.txt

An attacker’s loop:

BASH

HOST=$(bin/hb next a1) || exit 0     # atomic lease on the next host
bin/hb inscope "$HOST" || { bin/hb release "$HOST" a1; exit 3; }
grep -i "$HOST" state/dead-ends.md state/intel.md   # don't repeat dead tests
ffuf -u "https://$HOST/FUZZ" -w wordlists/base.txt -ac -rate 20 -t 10 -o "recon/$HOST/ffuf.json"
bin/hb finding a1 "$HOST" idor "https://$HOST/api/orders?id=2" "BOLA on /orders" "200 with account B's order"
bin/hb done "$HOST" a1 findings "1 candidate"

The guardrails are executable, not promises from the model:

Scope: hb inscope exits 0, 2 or 3; deny beats allow; unlisted hosts don’t get touched.
Rate limits: an explicit cap per tool, manual requests at 1/s per host, and a burst of 403/429 pauses the host for 10 minutes.
Proof before claims: without request and response in state/loot/, it’s only a candidate. Triage reproduces from scratch with a negative control, on a model from a different family.
Human review: the agent can draft the report, but the manual reproduction, the review and the submission are mine.

That deserves a post of its own. Next time.

Wrapping up

A harness won’t think for you, but it makes your method run the same way every time, in a terminal that’s nice to look at. Recap:

A terminal with a configurable font: Warp (macOS/Linux/Windows) or Windows Terminal.
JetBrainsMono Nerd Font: brew install --cask on macOS, zip + fc-cache on Linux, zip → Install on Windows; selected in the terminal.
(Optional) zsh + Oh My Zsh + Powerlevel10k, p10k configure (on Windows, inside WSL2).
omp: brew install can1357/tap/omp, curl -fsSL https://omp.sh/install | sh or irm https://omp.sh/install.ps1 | iex; then omp setup and omp login or an API key.
Theme and icons: theme.dark, symbolPreset, statusLine.preset, composer.shape.
Memory, secrets and approvals.
Model roles and, if you need it, a gateway in models.yml.
/vibe once the basics are boringly reliable.

FLAMEEE

The edge reads you before the payload

Anatomy of a ClientHello#

The extensions are the signature#

GREASE: noise on purpose#

TLS 1.2 and 1.3 don’t look alike on the wire#

Every stack writes its own hello#

JA3: one line, one MD5, and a problem#

2023: Chrome broke JA3 on purpose#

JA4: how to read the whole fingerprint#

Sorting is a design decision#

What JA4 chooses not to see#

It isn’t only TLS#

A fingerprint is a key, not a verdict#

Who computes this today#

What I take from this#

omp: from zero to /vibe

What a harness is#

Why omp#

1. Prerequisites and terminal#

2. Nerd Font#

3. The shell’s look (optional)#

4. Installing omp#

5. Making omp look good#

6. Settings worth changing beyond looks#

7. Providers and models#

8. /vibe#

9. Skills, MCP and AGENTS.md#

10. A taste: bug bounty#

Wrapping up#

Anatomy of a ClientHello

The extensions are the signature

GREASE: noise on purpose

TLS 1.2 and 1.3 don’t look alike on the wire

Every stack writes its own hello

JA3: one line, one MD5, and a problem

2023: Chrome broke JA3 on purpose

JA4: how to read the whole fingerprint

Sorting is a design decision

What JA4 chooses not to see

It isn’t only TLS

A fingerprint is a key, not a verdict

Who computes this today

What I take from this

What a harness is

Why omp

1. Prerequisites and terminal

2. Nerd Font

3. The shell’s look (optional)

4. Installing omp

5. Making omp look good

6. Settings worth changing beyond looks

7. Providers and models

8. /vibe

9. Skills, MCP and AGENTS.md

10. A taste: bug bounty

Wrapping up