DEV Community: Dan Lumatic

JSON to Table in Python: 10 Working Recipes

Dan Lumatic — Mon, 09 Nov 2026 04:08:29 +0000

You called pd.json_normalize on an API response. One line, a DataFrame, done. Then you looked at the items column and found a whole list of dicts crammed into each cell.

Nested objects flatten on their own, but a JSON array to table conversion needs a row shape you choose, and that choice decides whether the table is right.

TL;DR

Join each array into one cell when a person will read the table. Use one row per item (record_path or explode) when you analyze. If unsure, use explode, because it never loses a parent.

record_path silently drops any parent whose list is empty. Deeper nesting takes a list path, dicts keyed by id take DataFrame.from_dict(..., orient="index"), and max_level stops flattening early.

to_html escapes cell text. to_markdown needs tabulate, leaves | unescaped and prints missing values as nan.

Every pandas JSON to table recipe below ran on Python 3.11.16, pandas 3.1.1 and tabulate 0.10.0, and each output block was copied from a real run.

Which shape should each array take?

Join the array into one cell when a person will read the table. Use one row per item when someone will sum, count or group by item.

If you are unsure, use explode (Recipe 3): it never loses a parent. The recipes run on three orders (the data is in Recipe 1). Order 1003 has an empty items list, which is what real APIs send for "nothing yet". The three array recipes treat it differently:

Recipe	Rows from our 3 orders	Order 1003	Pick it when
2: `record_path`	3, one per line item	dropped	you analyze line items
3: `explode`	4, one per line item plus one for 1003	kept, with empty sku and qty	you analyze line items and still need every order counted
4: joined string	3, one per order	kept, with an empty items cell	a person will read the table

Recipe 1: nested objects flatten into dotted columns

pd.json_normalize names each nested key with a dot between the levels (pandas docs). It wants parsed Python objects, so run json.load or json.loads first: a raw string raises NotImplementedError with an empty message.

import pandas as pd

orders = [
    {
        "order_id": 1001,
        "customer": {"name": "Ada", "city": "London"},
        "items": [{"sku": "A1", "qty": 2}, {"sku": "B2", "qty": 1}],
    },
    {
        "order_id": 1002,
        "customer": {"name": "Linus", "city": "Helsinki"},
        "items": [{"sku": "A1", "qty": 5}],
    },
    {
        "order_id": 1003,
        "customer": {"name": "Grace", "city": "New York"},
        "items": [],
    },
]
df = pd.json_normalize(orders)
print(df.to_string())

   order_id                                               items customer.name customer.city
0      1001  [{'sku': 'A1', 'qty': 2}, {'sku': 'B2', 'qty': 1}]           Ada        London
1      1002                           [{'sku': 'A1', 'qty': 5}]         Linus      Helsinki
2      1003                                                  []         Grace      New York

customer.name and customer.city came from the nested object. items kept its list. Pass sep="_" to get customer_name, which saves you from bracket access like df["customer.name"].

Try this: list the array columns in your own file before you pick a recipe. If it prints [], Recipe 1 is all you need. If it prints ['data'], the whole response sits inside an envelope: pass record_path="data" to get one row per record.

import json
import pandas as pd

with open("orders.json", encoding="utf-8") as f:   # your file here
    data = json.load(f)

df = pd.json_normalize(data)
list_cols = [c for c in df.columns if df[c].map(lambda v: isinstance(v, list)).any()]
print(list_cols)

On our orders file this prints:

['items']

Recipes 2 to 4: turn the array column into rows or a cell

Recipe 2: child rows with `record_path`

Name the array, and list the parent fields you want carried along in meta. A nested parent field takes a list path.

# orders: the list from Recipe 1
import pandas as pd

lines = pd.json_normalize(
    orders,
    record_path="items",
    meta=["order_id", ["customer", "name"]],
    sep="_",
)
print(lines.to_string())

  sku  qty order_id customer_name
0  A1    2     1001           Ada
1  B2    1     1001           Ada
2  A1    5     1002         Linus

Order 1003 is gone: record_path builds rows from the items, so an order without items produces no rows, and nothing warns you. If you count orders from this frame, you undercount. The row-count check at the end of this page catches it.

Recipe 3: exploded rows with `explode`

Normalize the whole thing first, give every list element its own row, then normalize the exploded column.

# orders: the list from Recipe 1
import pandas as pd

flat = pd.json_normalize(orders, sep="_")
rows = flat.explode("items", ignore_index=True)
items = pd.json_normalize(rows["items"])
out = pd.concat([rows.drop(columns="items"), items], axis=1)
out["qty"] = out["qty"].astype("Int64")
print(out.to_string())

   order_id customer_name customer_city  sku   qty
0      1001           Ada        London   A1     2
1      1001           Ada        London   B2     1
2      1002         Linus      Helsinki   A1     5
3      1003         Grace      New York  NaN  <NA>

Order 1003 survives as a row of empty cells. That row is also why the astype("Int64") line exists: without it, the missing quantity turns qty into floats (2.0, 1.0, 5.0).

Recipe 4: one joined cell per order

Collapse each array into a string and keep one row per parent.

# orders: the list from Recipe 1
import pandas as pd

flat = pd.json_normalize(orders, sep="_")
flat["items"] = flat["items"].map(
    lambda xs: ", ".join(f"{i['sku']} x{i['qty']}" for i in xs)
)
print(flat.to_string())

   order_id         items customer_name customer_city
0      1001  A1 x2, B2 x1           Ada        London
1      1002         A1 x5         Linus      Helsinki
2      1003                       Grace      New York

HTML and Markdown tables are for eyes, so Recipe 8 starts from this joined frame.

Recipes 5 to 7: deeper nesting

Real payloads go past one level. These three recipes cover arrays inside arrays, dicts keyed by id, and objects you want to leave unflattened.

Recipe 5: arrays inside arrays, and arrays of scalars

Here each order has a list of tags (scalars) and shipments that each hold their own boxes. A list path walks arrays inside arrays, and meta can reach a field of the parent array, here the shipment id.

import pandas as pd

deep = [
    {
        "order_id": 1001,
        "tags": ["gift", "rush"],
        "shipments": [
            {"id": "S1", "boxes": [{"sku": "A1", "qty": 2}, {"sku": "B2", "qty": 1}]},
            {"id": "S2", "boxes": [{"sku": "A1", "qty": 1}]},
        ],
    },
    {"order_id": 1002, "tags": [], "shipments": []},
]
boxes = pd.json_normalize(
    deep, record_path=["shipments", "boxes"], meta=["order_id", ["shipments", "id"]]
)
print(boxes.to_string())

tags = pd.json_normalize(deep)[["order_id", "tags"]]
tags["tags"] = tags["tags"].map(", ".join)
print(tags.to_string())

  sku  qty order_id shipments.id
0  A1    2     1001           S1
1  B2    1     1001           S1
2  A1    1     1001           S2
   order_id        tags
0      1001  gift, rush
1      1002

Order 1002 has no shipments, so it vanishes from the box rows just as 1003 did in Recipe 2. An array of scalars needs no new recipe: ", ".join makes it a cell, the joined shape one level down.

Recipe 6: a dict keyed by id

A dict keyed by id is not a list of records, so json_normalize gives you one wide row. DataFrame.from_dict with orient="index" gives one row per key:

import pandas as pd

users = {"u1": {"name": "Ada", "plan": "pro"}, "u2": {"name": "Linus", "plan": "free"}}
print(pd.json_normalize(users).to_string())
print(pd.DataFrame.from_dict(users, orient="index").to_string())

  u1.name u1.plan u2.name u2.plan
0     Ada     pro   Linus    free
     name  plan
u1    Ada   pro
u2  Linus  free

Recipe 7: stop flattening early with `max_level`

Objects flatten all the way down by default. max_level stops early and leaves the rest as a dict in the cell:

import pandas as pd

cust = [{"order_id": 1, "customer": {"name": "Ada", "address": {"city": "London", "geo": {"lat": 51.5, "lon": -0.1}}}}]
print(pd.json_normalize(cust).to_string())
print(pd.json_normalize(cust, max_level=1).to_string())

   order_id customer.name customer.address.city  customer.address.geo.lat  customer.address.geo.lon
0         1           Ada                London                      51.5                      -0.1
   order_id customer.name                                       customer.address
0         1           Ada  {'city': 'London', 'geo': {'lat': 51.5, 'lon': -0.1}}

Recipe 8: `to_html` escapes cell text for you

DataFrame.to_html returns a <table> string and escapes <, > and & by default, so a stray tag in your data cannot break the page. border=0 drops the default border="1" attribute and classes adds a CSS class. Here are orders 1002 and 1003 from the joined frame:

# flat: the joined frame from Recipe 4
print(flat.iloc[1:][["order_id", "items"]].to_html(index=False, border=0, classes="orders"))

<table class="dataframe orders">
  <thead>
    <tr style="text-align: right;">
      <th>order_id</th>
      <th>items</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1002</td>
      <td>A1 x5</td>
    </tr>
    <tr>
      <td>1003</td>
      <td></td>
    </tr>
  </tbody>
</table>

Order 1003 is a row with an empty cell, so the count stays right. Escaping, on a cell that holds <b>hi</b> & bye:

import pandas as pd

note = pd.DataFrame({"note": ["<b>hi</b> & bye"]})
for escape in (True, False):
    html = note.to_html(index=False, header=False, escape=escape)
    print(escape, [ln.strip() for ln in html.splitlines() if "<td>" in ln][0])

True <td>&lt;b&gt;hi&lt;/b&gt; &amp; bye</td>
False <td><b>hi</b> & bye</td>

Use escape=False only for HTML you wrote yourself.

Recipe 9: `to_markdown` needs tabulate, and it mangles pipes and missing values

DataFrame.to_markdown prints a pipe table you can paste into a README or a pull request (pandas docs). It depends on the optional tabulate package. Without it you get:

ImportError: `Import tabulate` failed.  Use pip, conda, or your preferred package management tool to install the tabulate package.

After pip install tabulate it works, but real text has two traps, and pandas guards against neither:

import pandas as pd

notes = pd.DataFrame([
    {"sku": "A1", "note": "fits a|b"},
    {"sku": "B2", "note": None},
])
print(notes.to_markdown(index=False))

| sku   | note     |
|:------|:---------|
| A1    | fits a|b |
| B2    | nan      |

The first row now has three cells under a two-column header, because the pipe inside a|b splits the cell. The second row says nan where the note was empty. Fill the gaps and escape the pipes before you render:

import pandas as pd

notes = pd.DataFrame([
    {"sku": "A1", "note": "fits a|b"},
    {"sku": "B2", "note": None},
])
clean = notes.astype(object).where(notes.notna(), "")
clean = clean.apply(lambda col: col.map(lambda v: str(v).replace("|", "\\|")))
print(clean.to_markdown(index=False))

| sku   | note      |
|:------|:----------|
| A1    | fits a\|b |
| B2    |           |

Recipe 10: HTML and Markdown tables with the standard library only

Skip this one if pandas is installed. When you cannot install it (a Lambda layer, a build script, a pre-commit hook), json and html are enough. This module flattens nested objects into dotted keys and builds the header from the union of every record's keys. Its list_cell argument decides what an array becomes, and the default is compact JSON. Pass a function that joins sku x qty strings to get the joined shape of Recipe 4.

# orders: the list from Recipe 1
import json
from html import escape


def compact(xs):
    return json.dumps(xs, separators=(",", ":"))


def flatten(obj, prefix="", list_cell=compact):
    out = {}
    for key, value in obj.items():
        name = f"{prefix}{key}"
        if isinstance(value, dict):
            out.update(flatten(value, name + ".", list_cell))
        elif isinstance(value, list):
            out[name] = list_cell(value)
        else:
            out[name] = "" if value is None else str(value)
    return out


def table_rows(records, list_cell=compact):
    rows = [flatten(r, list_cell=list_cell) for r in records]
    cols = list(dict.fromkeys(k for r in rows for k in r))  # union of keys
    return cols, rows


def to_html(records, **kw):
    cols, rows = table_rows(records, **kw)
    head = "".join(f"<th>{escape(c, quote=False)}</th>" for c in cols)
    body = "".join(
        "<tr>" + "".join(f"<td>{escape(r.get(c, ''), quote=False)}</td>" for c in cols) + "</tr>"
        for r in rows
    )
    return f"<table><thead><tr>{head}</tr></thead><tbody>{body}</tbody></table>"


def to_markdown(records, **kw):
    cols, rows = table_rows(records, **kw)

    def cell(text):
        return text.replace("|", "\\|").replace("\n", " ")

    lines = ["| " + " | ".join(cell(c) for c in cols) + " |",
             "| " + " | ".join("---" for _ in cols) + " |"]
    for r in rows:
        lines.append("| " + " | ".join(cell(r.get(c, "")) for c in cols) + " |")
    return "\n".join(lines)


print(to_html(orders[2:]))
print(to_markdown(orders + [{"order_id": 1004, "coupon": "SPRING|5"}]))

<table><thead><tr><th>order_id</th><th>customer.name</th><th>customer.city</th><th>items</th></tr></thead><tbody><tr><td>1003</td><td>Grace</td><td>New York</td><td>[]</td></tr></tbody></table>
| order_id | customer.name | customer.city | items | coupon |
| --- | --- | --- | --- | --- |
| 1001 | Ada | London | [{"sku":"A1","qty":2},{"sku":"B2","qty":1}] |  |
| 1002 | Linus | Helsinki | [{"sku":"A1","qty":5}] |  |
| 1003 | Grace | New York | [] |  |
| 1004 |  |  |  | SPRING\|5 |

Order 1003 shows up as [], so no row is lost. Building the header from the first record alone would have dropped coupon, which exists only on order 1004.

The errors you will actually hit

Every message below is copied from a real run on pandas 3.1.1.

KeyError: "Key 'rows' not found. If specifying a record_path, all elements of data should have the path." means some record lacks the record_path key, including a record with no items key at all (an empty list is fine). Use Recipe 3 instead: a missing key becomes a row of empty cells.
KeyError: "Key 'customer' not found. To replace missing values of 'customer' with np.nan, pass in errors='ignore'" means a record lacks a meta field. errors="ignore" fills those cells with NaN. The cost: a mistyped meta key now gives a column of NaN where you used to get this error.
No error, one row: if the payload is {"status": "ok", "data": [...]}, pd.json_normalize(payload) returns a single row whose data cell holds the whole list. Pass record_path="data".
FileNotFoundError: [Errno 2] No such file or directory: '[{"id": 1, "name": "Ada"}, {"id": 2, "name": "Linus"}]' comes from pd.read_json on a JSON string, which pandas reads as a file path. Pass a path, or wrap the text in io.StringIO(raw).
ValueError: Trailing data at position 24 means the file is NDJSON, one object per line. Add lines=True.
json.decoder.JSONDecodeError: Extra data: line 2 column 1 (char 25) is json.loads on that same NDJSON text. Parse line by line: [json.loads(line) for line in text.splitlines()].
ValueError: If using all scalar values, you must pass an index comes from pd.read_json or pd.DataFrame on a single object. pd.json_normalize(obj) accepts a lone dict and returns one row.

A display gotcha, not an error: print(df) collapses the middle columns when the frame is wider than your terminal and shows order_id ... customer.city. Nothing is lost. Use print(df.to_string()), as the blocks above do.

How do I convert nested JSON to a table in Python?

Parse it with json.loads (or json.load for a file) and pass the result to pd.json_normalize. Nested objects become dotted columns and arrays stay as lists in a cell, as the output in Recipe 1 shows. Use Recipe 2 or 3 for one row per array element.

How do I turn JSON into a Markdown table in Python?

Flatten with pd.json_normalize, join the arrays, fill missing values, escape | and call df.to_markdown(index=False) after pip install tabulate (Recipe 9). Without pandas, the to_markdown function in Recipe 10 does the same.

How do I flatten JSON that contains arrays?

Pick a shape from the table at the top: record_path or explode for one row per element, a joined string for one row per parent. Arrays inside arrays take a list path, as in Recipe 5.

When you only need the table once

If you have a single file and no script to maintain, a client-side converter is enough: one that runs entirely in your browser, so nothing is uploaded. Before you trust one, check three things. It keeps each object as one row and each array in its cell as compact JSON, so the row count matches your record count and no empty array disappears. It flattens nested objects into dotted columns, as json_normalize does. Its Markdown view is ready to copy. Most converters do not explode line items into child rows. For one row per item, use Recipe 2 or 3 above.

Whichever route you take, compare the number of distinct parents in your table with the number of records you started with. On the Recipe 2 frame:

# orders: the list from Recipe 1
# lines: the frame from Recipe 2
print(lines["order_id"].nunique(), "of", len(orders), "orders")

2 of 3 orders

A number below your record count means the shape you chose for an empty array dropped a parent. Recipe 3 or Recipe 4 brings it back.

Sourcing note: every recipe above ran on Python 3.11.16, pandas 3.1.1 and tabulate 0.10.0 on 2026-11-09, and each output block was copied from a real run; the ImportError string in Recipe 9 came from the same check with tabulate not yet installed.

Musk's Odyssey promise contradicts itself, and Grok noticed

Dan Lumatic — Mon, 09 Nov 2026 03:05:56 +0000

In July, Elon Musk promised that Grok Imagine would make a full-length Odyssey "historically accurate and true to the art of Homer". Episode one, released on X on Oct 24-25, runs seven minutes. One of the first to flag the gap, that a poem is not a history, was Musk's own chatbot.

TL;DR

Asked by WIRED, Grok called the episode an adaptation of a poem, not history.

The July promise pulls in two directions, so no one could settle it.

To check the full film, ask one yes/no question per spec line.

Grok called the episode an adaptation

On Oct 26, WIRED asked Grok to assess the episode. Grok answered that it "is an adaptation of Homer's Odyssey, not a historically accurate reconstruction of real events". It added: "The Odyssey itself is not a historical document."

The promise contradicts itself

The July sentence wants historically accurate and true to the art of Homer at once. Homer's art has a one-eyed Cyclops and meddling gods, and no history does. Developers call this conflicting acceptance criteria, like must be real-time plus must run full validation on an hour-long job.

What a testable version looks like

A hypothetical rewrite, not the producers' words:

Source: one named translation (say, Fagles)
Allowed deviations: compressed books, merged minor characters
Fail: any scene that adds an event, dialogue, or detail the source does not contain

A Cyclops scene trimmed to two minutes is compression and passes. The borderline case is a battle the poem mentions in one line, staged as a ten-minute set piece. It must invent specifics the source does not contain, so it fails.

How to check the full film

Musk's end-of-year deadline still stood as of Nov 2. When the film lands, answer these from the film, its credits or its announcement:

Try this:

Does it name its source translation?

Does it state what it compressed or merged?

Can you point to a scene that adds an event or detail the source lacks?

A pass is yes, yes, no. Anything else means the promise was untestable or broken.

Dan writes the AI satire on super-intelligence.lol, where this piece first appeared.

OpenAI Posted 722 Math Papers. Who Checks the Checker?

Dan Lumatic — Mon, 09 Nov 2026 03:04:11 +0000

On Oct 6, OpenAI put 722 mathematics manuscripts online, and only one had a human edit before release. Terence Tao calls this proof indigestion: more AI-written mathematics than the people who must judge it can absorb. A machine can now write a proof-shaped manuscript faster than anyone can check it. So the sharp question is who checks the checker.

TL;DR

Checks come in levels: a machine check, a named human review, released artifacts. OpenAI's three Oct 26 headline results got different mixes, from Sogge (machine only) to Yang-Mills (artifacts withheld pending review).

The catalog shows no check status per paper, and The Atlantic says some appear not to prove their claims.

Lean checks the proof steps, not whether the claim says what the mathematician meant. That second check is human.

OpenAI's 41-page catalog of 722 papers marks no check status for any of them

OpenAI published 722 manuscripts covering 372 result families in a public GitHub repo, written by an unreleased internal model. The claims range from Khot's unique games conjecture to the quasi-Riemann hypothesis, a weaker version of the Riemann hypothesis. The Atlantic reported that some of the papers appear not to prove what they claim.

Even a single headline can hide two check states. The Sept 30 version of quasi-Riemann, with zeros between 1/8 and 7/8, is Lean-verified. The later version, with a wider strip from 1/12 to 11/12, is not formally verified. A result's name does not tell you which version was checked.

Three things to look for before you believe an AI-proved headline

OpenAI's three Oct 26 headline results:

Result	What it claims	Who has checked it
Sogge local smoothing	A proof of Sogge's local smoothing conjecture, about how waves focus and fade, in every dimension of at least 2	A machine only: Lean-formalized Oct 19. No named human re-check
ETH disproof	A disproof of the Exponential Time Hypothesis for 3-SAT	A machine and named experts: Lean-verified Oct 17, shepherded by the hypothesis's original proposers Impagliazzo and Paturi plus Ryan Williams. OpenAI also committed to funding an open community conference on the claim
Yang-Mills and QCD existence	Existence proofs for Yang-Mills theory and QCD, two quantum physics theories	No outside review yet: Lean formalization finished Oct 16, artifacts withheld pending review by a group led by Nobel laureate David Gross

Try this: open the primary announcement of any AI-proved result and look for:

a Lean status for the result

a named group that has finished reviewing it

released files you can inspect

Search the announcement text for the word Lean and for a reviewer's name, and check whether it links any files. Each missing item lowers how far you should trust the result. Only when all three are present, treat it as publicly checked.

Run the list on the Yang-Mills row. A Lean status: yes, the formalization is finished. A named group that has finished reviewing: no, the Gross-led group's review is pending. Released files: no, they are withheld. One of three items is met, so treat it as unchecked in public.

Only ETH has named people already working on the claim.

What a Lean check covers, and what it leaves to a human

Lean is a proof assistant. It checks that every step follows from the claim as stated, and it cannot judge whether the stated claim says what the mathematician meant.

Lean is the checker, and the human who reads the formal statement and confirms it matches the intended conjecture is the checker's checker. Picture a mathematician reading the Lean version of the ETH disproof and confirming it formalizes the real Exponential Time Hypothesis for 3-SAT, not a nearby, easier statement.

If you write software, you know this shape. This analogy is ours, not OpenAI's or Tao's: a green test suite shows the code matches the tests, and only a person can say whether the tests describe what the customer wanted. Lean plays the test runner, and the formal statement plays the test.

Tao's complaint behind proof indigestion is that the machines skip the explaining and judging that make a result usable. There is money for evaluation: the Simons Foundation has put $15M into it, $5M of it from OpenAI.

Who to wait for before you share the next one

When the next AI-proved headline lands, run the three-item list and ask which version of the claim it describes. Then wait for the humans. For Yang-Mills that means the report from the Gross-led group. For ETH it means the open community conference OpenAI committed to funding.

Dan writes the AI explainers on super-intelligence.rocks, where this piece first appeared.

Your AI agent's token bill is mostly input. Here is the field guide to cutting it.

Dan Lumatic — Mon, 09 Nov 2026 00:28:32 +0000

Your AI agent's token bill is mostly input. Here is the field guide to cutting it.

TL;DR

In a toy 10-turn agent session, 16,559 input tokens go out and 3,090 output tokens come back. At Claude Sonnet 4.5 prices input is still 52% of the cost, and all three cuts below shrink it to 3,290 input-equivalent tokens, 80% less.

Truncating tool output and pruning old history alone cut the session's input by 62%, to 6,445 tokens.

Caching a stable prefix bills it at 0.1x after the first call, but a prefix used only once costs 25% more than no caching.

Your agent bill is bigger than the work you remember asking for, and the cause is mechanical. A model API is stateless, so every turn re-sends the system prompt, all tool output so far and the whole conversation. A file listing pasted on turn 2 is billed again on every turn after it. TechCrunch reported that Y Combinator CEO Garry Tan spends up to $200K a year on tokens, and at any scale the repeated input is the part you can shrink. Below: one script to measure it, and three cuts.

Where a 10-turn session's tokens go

Turn 10 carries the results of turns 1 through 9, so a 10-turn session costs the sum of ten growing prompts. In the toy run below that sum is 16,559 input tokens. A real agent reply carries tool calls and code, so we model each reply at about 300 tokens, which makes 3,090 output tokens for the session.

Output costs more per token. Anthropic's pricing page lists Claude Sonnet 4.5 at $3 per million input tokens and $15 per million output tokens, so one output token weighs 5 input tokens. Weighted by price, input is still 52% of the session, a bare majority. The script prints all three numbers.

To count caching in the same units, we use input-equivalent tokens: a cache read counts as 0.1 of a token and a cache write as 1.25.

Measure first: count tokens for each part of a turn

Start with your real baseline: log the usage block of every API response (input and output tokens per call) and sum each per session. That total is your real number. The script then shows where it goes, by counting the system prompt, one tool output and the history separately. The biggest one tells you which cut to try first.

The data is fake, so rerun the script on your own. Every figure is a tiktoken count except the cache lines and the cost-share lines, which are arithmetic from the vendors' documented multipliers and prices, with no API call.

# pip install tiktoken
import tiktoken

enc = tiktoken.get_encoding("o200k_base")


def n(text):
    return len(enc.encode(text))


system = """You are a coding agent. You read files, run commands, and edit code.
Always explain your plan before acting. Follow the repo style guide. When you
write tests, use the project's existing fixtures. Never touch the migrations
folder without asking. Summarize diffs at the end of each task. Be concise but
complete. Handle errors gracefully and retry once on network failures.
[... style guide: 40 more lines of formatting rules ...]"""

# One fake tool output: a 60-line file listing.
tool_output = "\n".join(
    f"src/module_{i:02d}.py: def handler_{i}(request) -> Response: ..."
    for i in range(60)
)

# One fake model reply per turn. A real agent reply carries its tool calls and
# code, so we model it at a few hundred tokens.
reply = (
    "I read the listing. handler_07 builds the response before it validates "
    "the request, which is why test_handler_07 fails. I'll move the check "
    "above the response and add a regression test.\n"
    '{"tool": "edit_file", "path": "src/module_07.py", "patch": "'
    + "\\n".join(
        f"- response = build(request, {i})\\n+ validate(request)\\n+ response = build(request, {i})"
        for i in range(10)
    )
    + '"}'
)


def history_of(turns):
    return "\n".join(
        f"Turn {i}: user asked something, agent read files, ran tests, "
        f"edited two files, tool output followed. {tool_output[:400]}"
        for i in range(turns)
    )


def truncate(text, head=600, tail=200):
    if len(text) <= head + tail:
        return text
    cut = text[head:-tail].count("\n")
    return text[:head] + f"\n[... {cut} lines truncated ...]\n" + text[-tail:]


def turn(history_turns=10, tool=tool_output):
    return "\n".join([system, history_of(history_turns), tool])


full = n(turn())
pruned = n(turn(history_turns=3))
truncated = n(turn(tool=truncate(tool_output)))
both = n(turn(history_turns=3, tool=truncate(tool_output)))


def smaller(x):
    return 100 - x * 100 // full


print(f"system prompt:               {n(system)} tokens")
print(f"one raw tool output:         {n(tool_output)} tokens")
print(f"10 turns of history:         {n(history_of(10))} tokens")
print(f"one full turn as sent:       {full} tokens")
print(f"history pruned (keep 3):     {pruned} tokens ({smaller(pruned)}% smaller)")
print(f"tool output truncated:       {truncated} tokens ({smaller(truncated)}% smaller)")
print(f"both cuts:                   {both} tokens ({smaller(both)}% smaller)")

# A 10-turn session: turn i re-sends i earlier turns of history.
naive = sum(n(turn(history_turns=i)) for i in range(10))
session_cut = sum(n(turn(history_turns=min(i, 3), tool=truncate(tool_output))) for i in range(10))
out = 10 * n(reply)
print(f"10-turn input, no cuts:      {naive} tokens")
print(f"10-turn input, both cuts:    {session_cut} tokens ({100 - session_cut * 100 // naive}% smaller)")

# Cut 3 arithmetic (documented multipliers, no API call): a cache write costs
# 1.25x, a cache read 0.1x. Stable prefix = system prompt + the 3 kept turns.
prefix = n(system + "\n" + history_of(3))
cached = prefix * 1.25 + prefix * 0.1 * 9

# All three cuts stacked, same model. Each turn re-sends the previous turn's
# system prompt + history as a cache read (0.1x), writes whatever the prefix
# grew by (1.25x), and bills the rest of the turn (the tool output) at 1x.
# Assumes pruning happens at fixed points, so the prefix stays valid after
# turn 3, and every call lands inside the 5-minute cache lifetime.
stacked, prev = 0, 0
for i in range(10):
    total = n(turn(history_turns=min(i, 3), tool=truncate(tool_output)))
    pre = n(system + "\n" + history_of(min(i, 3)))
    stacked += prev * 0.1 + (pre - prev) * 1.25 + (total - pre)
    prev = pre
print(f"10-turn input, all 3 cuts:   {stacked:.0f} input-equivalent tokens ({100 - stacked * 100 / naive:.0f}% smaller)")
print(f"10-turn output (replies):    {out} tokens")

# Price-weighted: Sonnet 4.5 lists $3 per million input, $15 per million
# output, so one output token weighs 5 input tokens.
OUT_WEIGHT = 5
print(f"input cost share, no cuts:   {100 * naive / (naive + OUT_WEIGHT * out):.0f}%")
print(f"input cost share, 3 cuts:    {100 * stacked / (stacked + OUT_WEIGHT * out):.0f}%")

print(f"stable prefix:               {prefix} tokens")
print(f"prefix x10, uncached:        {prefix * 10} input-equivalent tokens")
print(f"prefix x10, cached:          {cached:.0f} input-equivalent tokens")
print(f"prefix used once, cached:    {prefix * 1.25:.0f} input-equivalent tokens")

Output:

system prompt:               93 tokens
one raw tool output:         960 tokens
10 turns of history:         1339 tokens
one full turn as sent:       2393 tokens
history pruned (keep 3):     1455 tokens (40% smaller)
tool output truncated:       1663 tokens (31% smaller)
both cuts:                   725 tokens (70% smaller)
10-turn input, no cuts:      16559 tokens
10-turn input, both cuts:    6445 tokens (62% smaller)
10-turn input, all 3 cuts:   3290 input-equivalent tokens (80% smaller)
10-turn output (replies):    3090 tokens
input cost share, no cuts:   52%
input cost share, 3 cuts:    18%
stable prefix:               494 tokens
prefix x10, uncached:        4940 input-equivalent tokens
prefix x10, cached:          1062 input-equivalent tokens
prefix used once, cached:    618 input-equivalent tokens

Try this: replace system, tool_output, history_of and reply with your real system prompt, one real tool result, your logged history and a typical reply.

Cut 1: truncate tool output, keep the head and tail

Tool output is often the biggest block, and most of it is never read again. truncate keeps the first 600 characters and the last 200 and puts a marker in the middle. That takes one turn from 2,393 to 1,663 tokens, 31% smaller.

Keep both ends because errors tend to show up at the top of a log and the summary line at the bottom.

Cap each tool result at a head, a tail and a marker that says how many lines were dropped, so the agent knows it can ask for more.

Try this: log the length of every tool result for one real run. Whatever tops the list gets the cap first.

Cut 2: prune history once a result has been used

After the agent has acted on a tool result, the raw result rarely needs to travel with it. The toy loop keeps only the last 3 turns, which cuts one turn from 2,393 to 1,455 tokens (40%), and both cuts together bring it to 725 (70%). A gentler version keeps a line per old result:

# pseudocode, language-neutral
for each message older than the last 3 turns:
    if it is a tool result:
        replace the body with one line, for example:
        "read src/auth.py (212 lines): login() calls verify_token(); test_login_expired fails"
    otherwise keep it as it is

Over-pruning makes the agent dumber. If an early turn found the name of the failing test, that fact has to survive the prune, as it does in the summary line above. The raw listings and bulky results can go, but any fact a later step will need to quote has to stay.

Try this: after pruning, rerun one task you know the answer to. If it now fails or re-reads files it already read, you cut too much.

Cut 3: keep the prefix identical so the cache can reuse it

Anthropic's prompt caching docs put a cache read at 0.1x the base input price, and OpenAI's prompt caching guide says cached input is discounted up to 95%. The script runs the Anthropic multipliers on the stable prefix, which is the system prompt plus the 3 kept turns, 494 tokens. Sent for 10 turns it bills like 4,940 tokens uncached and like 1,062 with a 1.25x write on turn 1 and 0.1x reads after. Sent once, it bills like 618, 25% more than not caching at all.

That 494-token prefix sits below both vendors' 1,024-token minimums, so the toy cannot show this saving at its own scale. What carries over is the ratio on a real prefix: one write at 1.25x, then reads at 0.1x. The "all 3 cuts" line applies the same multipliers to the whole session, assuming pruning at fixed points and every call inside the 5-minute window.

The 618 is how caching backfires. Three conditions decide which side you land on:

The prefix must stay identical. The cacheable order is tools, then system prompt, then history. Changing anything early breaks the match for everything after it.
It must be reused in time. On Anthropic a cache write costs 1.25x, and an entry lives 5 minutes by default. One call that never gets reused costs more than no caching.
It must be long enough. OpenAI caches prompts of at least 1,024 tokens. Anthropic's minimum is 1,024 for Claude Sonnet 4.5 and ranges from 512 to 4,096 across its other models.

The quiet killer is a timestamp in the system prompt. So is a request ID, or a tool list that comes back in a different order. Any of them makes the prefix different on every call, so on Anthropic you pay the 1.25x write each time and never see a 0.1x read. No error appears; the bill just goes up a little.

Pruning rewrites the history, so the cache match ends where the prune starts: prune at fixed points instead of every turn.

Order the prompt as tools, system prompt, then history, keep timestamps and IDs out of it, and send the same prefix again within 5 minutes.

Try this: on Anthropic, read cache_creation_input_tokens and cache_read_input_tokens from each response's usage block. If reads stay at zero after the second call, something in your prefix changes between turns.

What these cuts will not fix

They shrink input. The output tokens you asked for stay, and after all three cuts the same arithmetic puts input at 18% of the session's cost, so output is now the bigger part of the bill. A loop that wanders for 20 turns instead of 10 re-sends the context ten more times, which no trim recovers.

Where to start:

Tool output is the biggest block: cut 1.
History is the biggest block: cut 2.
The prompt is large and stable: cut 3, and check the usage fields.

Your 15-minute version for tomorrow: run the script with your real system prompt, one real tool result and your logged history. Whichever of the three counts is largest, apply that cut first and run the script again to see the drop. On the toy session the full stack takes 16,559 input tokens to 3,290 input-equivalent ones; your data will land elsewhere, and the rerun tells you where.

An LLM edited a small model's weights directly and its math score rose 6x

Dan Lumatic — Thu, 05 Nov 2026 01:07:52 +0000

TL;DR

GPT-6 Astra, a frontier LLM, edited 0.016% of Qwen3.5-0.8B's weights directly, with no training run. MATH-500 went from 7.9% to 48.1%.

The authors read most of that gain as unblocking: the base model kept running into its token limit instead of finishing. Astra also read, repaired and wrote small game-playing networks.

Limits: no gain on Gemma 3 270M, one frontier LLM, models up to 0.8B, a blog post and not a peer-reviewed paper, and a prompt that hinted at the loop. The edited model and the logs are public.

One edit to 0.016% of a small language model's weights lifted its math score from 7.9% to 48.1%. No training run, no gradients: GPT-6 Astra, a frontier LLM, read the weights directly and wrote the fix.

Read the 6x with care. 93.0% of the base model's MATH-500 answers ran to the 32,768-token limit without finishing, and the authors read the gain as mostly unblocking: the model now finishes answers it could already work out. The assignment prompt also pointed Astra at that loop, and people have argued about it since Nov 2.

MIT CSAIL researchers call this weight-space programming: a general-purpose LLM reads and writes a neural network's weights with no optimizer and no gradient descent, guided by a plain-language spec. Training has always been an indirect way to write weights, and their first results suggest a frontier model can write them directly. The post is "Sparks of Weight-Space Programming" by Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab.

Check the Qwen claim yourself; replaying the whole run takes a day

The edited model is on Hugging Face as RikiyaT/Qwen3.5-0.8B-weight-space-programming, and only two tensors differ from base.

Hugging Face's Ahsen Khaliq rebuilt it from the logs within a day and shipped a live demo. HF's independent run of the full MATH-500 set scored 51.0%.

Try this: run the same math questions through base Qwen3.5-0.8B and the edited model with the same generation cap, and count how many answers hit the cap. The table below shows the authors' rates at a 32,768-token limit. Then clone the logs repo and open exp8_math/runs/p50c/turns/t001/prompt.txt. It is the exact assignment Astra received. Read it before any commentary, including this post.

Replaying Astra's own session is the expensive part, though the logs hold everything sent to and from Astra, all code and all evaluations. Coverage of the logs (dailyaibrief.com, clauding.de) reports that the successful 50-pass run took 158 conversational turns and 80 Python runs over 20.3 hours. No fine-tuning cost is given to compare that with.

How Astra took a loop out of 131,072 weights

Qwen's own model card warns Qwen3.5-0.8B is prone to "loops compared to other Qwen3.5 models, which may prevent it from terminating generation properly." Of the base model's first 96 practice answers, 85 ran to the 32,768-token limit.

Astra worked in a Python notebook on practice prompts from the GSM8K and MATH training sets. A forward pass is one run of the model, and the budget capped how many runs Astra got: 10, 25 or 50. It traced the looping to one direction, a single pattern written by the MLP blocks of layers 15 and 19. It then subtracted that direction from 64 output columns in each block, so those layers no longer write it. That is 131,072 weights, 0.016% of the model, and the rest stays as trained.

Metric	Base Qwen3.5-0.8B	Edited (50 passes)
MATH-500	7.9%	48.1%
GSM8K	13.8%	67.1%
IFEval	21.0%	62.3%
MATH-500 answers hitting the 32,768-token limit	93.0%	33.1%

It needed the full 50-pass budget: at 10 and 25 passes, MATH-500 reached only 12.3% and 14.1%. Even at 50 passes, 33.1% of answers still hit the limit. IFEval, which tests instruction following, rose too, which fits the unblocking reading.

A skeptic can call this a bug fix for a documented loop. None of the coverage I read tests whether a decoding-side fix, such as a repetition penalty, would match it.

Did Astra find the loop, or was it told where to look?

Researcher Lucas Beyer read the assignment prompt, as Turing Post reported on Nov 2. It told Astra that if Qwen "repeats itself and never finishes, finding and fixing what drives that repetition counts." Coauthor Jayden Teoh replied that the team gave the short assignment via Claude Code.

There is a fair counterpoint. Qwen's model card had already flagged the loop, so pointing at it was reasonable.

The third-party re-run confirms the edit works. How much credit Astra deserves for finding the loop, given the hint, stays open. A cleaner test would rerun the assignment with that sentence removed. None of the coverage I read reports one, and the prompt is public.

Astra also read, repaired and wrote small networks

Read. With no list of games and no tools, Astra named the game each of four trained PPO networks played, from raw weights alone. For Breakout it noticed that first-layer weights concentrate along the bottom row, where a paddle lives.
Fix. In a Kinetix car-ramp task, a PPO policy drove straight at the ramp and stayed stuck. Astra got the weights, a scene description and one recorded episode, with no tools. In one reply it changed 3.5% of the weights and took success from 0% to 100% over 1,024 episodes. The edit added a small path that backs the car up past the red strip, then hands control back to the trained policy.
Write. Given only a game's rules and source code, with no data, loss, gradients, tools or rollouts, Astra wrote MinAtar networks that beat PPO trained for 100M steps in all three games. In Breakout the score was 517.4 versus 15.8. Against PPO at 500M steps, Astra still wins Breakout by 20x.

Where it breaks: Gemma 3 270M gained nothing established

Gemma 3 270M rarely loops: 8.5% of its answers hit the token limit. MATH-500 started at 6.8% and four edits scored 7.0%, 7.6%, 7.7% and 7.0%. None was established, and Astra said so itself. Its errors are ordinary arithmetic and algebra mistakes, with no single component to switch off. The authors put it this way: "Editing weights could remove an obstacle that hid an ability, but it could not add an ability the model lacked."

In a separate test on two fine-tuned Gemma copies, Astra failed from weights alone in all 4 attempts, so some hidden behavior shows only in activations.

One frontier LLM was tested, on models up to 0.8B parameters. This is a blog post with logs, not a peer-reviewed paper, and the authors themselves call it "sparks" and "very early." They are building a benchmark and harness to make this "a rigorous, reproducible engineering discipline."

Sources: numbers come from the authors' post and logs, plus the Hugging Face model card for the 51.0% re-run.

What to watch, and what to try on your own small model

My read: the practical use today is diagnosing and surgically repairing small models. If one of yours underperforms, check how often its answers hit the generation cap before you blame its capability. In Qwen's case, 85 of the first 96 practice answers hit it. Then ask whether a decoding-side fix would do the same job; none of the coverage I read reports that comparison.

Watch for a replication above 0.8B parameters, and for a second model whose fault is one removable direction, which Gemma's was not.

Training is an indirect way to write weights, and a frontier LLM has now written some directly and beaten trained networks on small tests.

Dan writes the AI explainers on super-intelligence.rocks, where this piece first appeared.

Why banks block AI agents at the login

Dan Lumatic — Tue, 03 Nov 2026 00:34:09 +0000

TL;DR

A bank login carries only a password, so an agent using your password and a thief using a phished one look identical, and the bank refuses both. Charles Schwab says a given agent might hit its login "30, 40, 50 times" a week and gets blocked.

Bank of America's customer email and Wells Fargo's Nov 24 account terms can leave the customer responsible for what an agent does with their password.

Read-only access the bank approves is open today. Moving money needs credentials issued to the agent, and the US rule meant to replace password-based access is frozen in court.

Bank of America emailed customers a message titled "Protecting your finances in the AI world," telling them not to share passwords with AI agents. If they do, the email says, they are "responsible for activity resulting from that access."

If you build agents that touch customer accounts, this is likely why your login-based demo gets blocked. From the bank's side of the glass, a logged-in agent and a stolen session are the same thing, so banks refuse the login and leave the customer responsible for whatever slips through.

A bank login cannot tell your agent from a phished password

A login checks one thing: whether the password matches the one the bank has on file. The customer, the customer's agent and a criminal with a phished password all present the same proof.

Axios reported on Oct 22, citing people familiar with the matter, that banks "were detecting outside AI agents inside customer accounts", including some "that attempted actions that appeared independent of their users' instructions". AI News adds a counterpoint: Morgan Stanley, which has blocked third-party agents, "had not seen any unauthorised or rogue instances," a person familiar with the bank told Reuters. The agents in question are consumer tools such as Meta's Muse, which can connect to accounts with a customer's authorization to monitor balances and transactions.

To the bank, an agent's login is a correct password from a device it has never seen, which is also how a criminal's login looks. The one defense available at that door is to refuse it. Schwab's CEO says the firm is "keeping rogue agents from being able to log in on the client's behalf."

The blocks show a bank can spot agent-like traffic. A blocked attempt still says nothing about whose agent it was, because the password is all the form carries. That is our reading of the evidence; no bank states it in these words.

Read-only access the bank approves is open today

Axios reported that most banks have approved, or are moving toward, read-only access that lets an agent view account information without moving money. Schwab plans to let outside AI models check balances and research through its own MCP servers, but not move money: "We control the authentication experience." These agents arrive through a path the bank built, so the bank can recognize them and the identity question never comes up.

Try this: Check how your integration connects to the bank. If it asks users for a bank username and password, expect trouble: Schwab blocks agent logins, and TD tells clients never to share their log-in credentials with an AI agent. If it connects through the bank's own approval and only reads balances and transactions, it uses the access banks already approve.

Bank of America and Wells Fargo put the liability on the customer

TechCrunch, reporting on the Bank of America email, puts the general rule this way: "Account agreements at most banks hold customers responsible for anyone they give their log-in to."

Wells Fargo is writing it down for agents. As AI News summarizes it, the updated Online Access Agreement, effective Nov 24, says that, subject to applicable law, instructions and transactions from an agent given a customer's login details or authority "can be treated as the customer's own without further verification." Customers are also made responsible for unintended actions and for actions that exceed the authority they gave.

For a builder, that means the customers using a login-based integration are told not to share credentials, the bank may block the login, and the customer can carry the risk if something goes wrong.

Where each bank stands

Per reporting through Nov 1:

Bank	What it does	On the record
JPMorgan Chase	Blocks external agents from acting for retail customers; some third-party tools view data only	Spokeswoman to CNBC; Bloomberg
Bank of America	Imposed limits on agents	Customer email warning (TechCrunch, Oct 27)
Wells Fargo	Restricts third-party agent access	Nov 24 agreement (AI News)
Charles Schwab	Blocks agent logins; outside AI models connect on its terms, no money movement	CEO Rick Wurster: agents blocked from logging in on clients' behalf (InvestmentNews, Oct 28)
BMO, CIBC, RBC, TD, Scotiabank	Four block personal AI agents; Scotiabank limits third-party agents while it monitors	TD's advice: keep log-in credentials away from AI agents (CBC, Oct 29)

Moving money needs agent-scoped credentials; the rule meant to replace password sharing is frozen

An agent a bank could admit would carry a credential of its own, scoped to specific permissions, revocable without touching the customer's login, with liability set in advance. OAuth-style tokens show the shape: an app acts for you within a limited scope you can cancel without changing your password.

As AI News reports, relaying American Banker, the Personal Agent Protocol is an open standard led by Sierra and Meta that "sets out how personal AI agents identify themselves to businesses, establish whom they represent and limit their access to what the customer has authorised". It is built on OAuth, and the customer decides whether an agent gets read-only or write access. Bank of America, BBVA, Synchrony and Wells Fargo have joined it, even as Bank of America and Wells Fargo restrict the credential-based agents already in use.

The US rule in the picture is the CFPB's Section 1033 open banking rule, finalised in October 2024 and meant to replace credential-based access. As AI News reported, the rule "requires banks to maintain a developer interface, typically an API, through which authorised third parties can access customer data", and "bars banks from relying on a third party's use of customer credentials" to reach that interface. A federal court has enjoined the CFPB from enforcing it, and as of August 2026 a revised proposal had gone to White House review without being published. As AI News put it: "With the rule on hold, there is no regulated route for AI agents into bank accounts."

Two things to watch:

Whether Bank of America or Wells Fargo accept write-capable agents under the protocol, since membership signals a commitment to agent identity and a customer-chosen write option.
Whether the revised Section 1033 rule gets published, since it would give agents a regulated way in without a password.

Until a bank can issue an agent credentials of its own, a logged-in agent and a stolen session look the same from the bank's side, so expect the login to stay closed. If you build anything that touches customer accounts, build for the read-only lane the bank approves.

Sources: Axios (Oct 22, via CBC News and AI News), CBC News (Oct 29), TechCrunch (Oct 27), InvestmentNews (Oct 28), CNBC (Nov 1), ZDNET (Oct 29), AI News (Oct 30, relaying American Banker, Reuters and Bloomberg).

Dan writes the AI explainers on super-intelligence.rocks, where this piece first appeared.

Image to base64: when inlining helps and when it hurts

Dan Lumatic — Tue, 03 Nov 2026 00:29:03 +0000

TL;DR

Base64 turns every 3 bytes into 4 characters, about 33% bigger. On a gzipped response an image's penalty shrinks to about 1% (1.010x of the original in our test), but an uncompressed response pays the full third.

Rule of thumb: inline only an icon of a few KB that your own code owns and uses once. Serve everything else as a file, because an inlined image re-downloads with every revision of the file that holds it.

In the browser use FileReader.readAsDataURL. In Python use base64.b64encode(...).decode("ascii"). btoa throws on any character outside Latin-1.

A reviewer writes "just base64 it", and the image moves into the file that holds it. It can no longer be cached on its own, it comes back with every deploy of that page, and it is a third bigger before compression. Nobody on the thread can say what the change cost, because the diff only shows a long string.

Base64 adds a third; gzip hides it for images

Every 3 bytes of input become 4 characters of output, so the encoded size is 4/3 of the original plus = padding to fill the last group (RFC 4648, section 4). We encoded random bytes in Python 3.14 to see the ratio. Padding adds at most two characters, which is why the smallest input is slightly worse and larger ones settle at 4/3:

Original bytes	Base64 bytes	Ratio
1,000	1,336	1.3360x
10,000	13,336	1.3336x
100,000	133,336	1.3334x

The usual objection is that gzip fixes this. For images it nearly does, on a compressed response. We used 50,000 random bytes as a stand-in for a PNG or JPEG, which are already compressed. As base64 they became 66,668 bytes. Gzip at level 9 shrank that text to 50,508 bytes, which is 1.010x the original binary. Gzip on the raw bytes gave 50,038 (1.001x).

That ~1% figure holds for already-compressed images. An uncompressed API response, an email body or a stylesheet your server does not compress pays the full third. Even in the best case, gzipped base64 stayed above the raw size in our test, so inlining at most ties on bytes.

SVG is the exception worth knowing. It is text, and a data URL does not require base64: the syntax is data:[<media-type>][;base64],<data> (MDN), so ;base64 is optional. In our reading, URL-encoding an SVG usually beats base64 because only the special characters grow. In our test a 13,800-byte SVG became 18,400 bytes as base64 (1.333x).

Inline an image only if it is tiny, code-owned and used once

Run each candidate through three questions:

Is it small? Our rule of thumb is a few KB at most. That is a heuristic, not a measurement. A 16-pixel icon usually passes, and a photo almost never does.
Does it change only when the file that embeds it changes? A logo mark in your CSS qualifies. A user avatar does not.
Does it appear once? Each inline copy adds its full encoded size to the uncompressed file, to memory and to parse work. A compressed wire softens this, because gzip back-references the repeated copy. We embedded a 20,000-byte random payload as base64 once and it gzipped to 20,250 bytes. Embedded twice, it gzipped to 20,567 (1.016x), not 2.0x. You still ship the full size to anyone without compression.

If any answer is no, serve a file. A file gets its own URL, its own cache entry and its own headers, and lazy loading can skip it entirely.

Try this: search your stylesheets for url(data: and run each match through the three questions. Every hit that fails one should become a file.

An inlined image re-downloads with every deploy

An inlined image has no cache entry of its own. It lives inside its host: your HTML page, your CSS bundle or your JS bundle. Change one line of that file, deploy, and every returning visitor downloads the image again with it. A served file keeps its own entry and its own validators through all of those deploys. A data URL has neither.

A quick piece of arithmetic, not a measurement: a 20,000-byte image inlined becomes 26,668 bytes. If its host file ships 10 times and a visitor returns after each deploy, that visitor downloads 266,680 bytes for an image that never changed. As a file, they download 20,000 bytes once. Compression shrinks the inlined number; the already-compressed file itself barely compresses at all.

A data: URL is also an opaque origin. MDN states it directly: "Data URLs are treated as unique opaque origins by modern browsers" and "top-level navigation to data: URLs is blocked in all modern browsers". You cannot link to one as a page or open one in a new tab to debug it. If you run a Content Security Policy, img-src must also allow data:, and in our reading that allows every data image, not only yours.

JavaScript: FileReader for files, TextEncoder before btoa

For a user-selected file, let the browser do it:

// `file` comes from <input type="file"> or a drop event
const reader = new FileReader();
reader.onload = () => console.log(reader.result.slice(0, 40));
reader.readAsDataURL(file);
// data:image/png;base64,iVBORw0KGgoAAAANSU

We ran this in Chromium with a 1x1 PNG. reader.result is the complete data URL, ready for img.src. If you need only the base64 part, take everything after the first comma.

btoa is the other tool people reach for, and it has a trap. It accepts only Latin-1 characters and throws on anything else:

try { btoa("café ☕"); } catch (e) { console.log(e.name); }
// InvalidCharacterError
const bytes = new TextEncoder().encode("café ☕");
console.log(btoa(String.fromCharCode(...bytes)));
// Y2Fmw6kg4piV

The fix is to encode the text to UTF-8 bytes first, then turn each byte into one character for btoa. That is for strings. The spread in String.fromCharCode(...bytes) passes every byte as a function argument, so it suits short strings only. On Node v24.22.1 it worked with 120,000 arguments and threw RangeError at 200,000. For image files, skip btoa and use readAsDataURL.

Python: b64encode returns bytes, so decode it

import base64

raw = bytes([0x89, 0x50, 0x4E, 0x47, 0xFB, 0xFF, 0xFE])
print(base64.b64encode(raw).decode("ascii"))
print(base64.urlsafe_b64encode(raw).decode("ascii"))
# iVBOR/v//g==
# iVBOR_v__g==

b64encode returns bytes, so .decode("ascii") gives you a string you can drop into an f-string such as f"data:image/png;base64,{encoded}". The standard alphabet uses + and /. urlsafe_b64encode swaps them for - and _ (RFC 4648, section 5), which is what you want in a URL or a filename.

Check the host file's size after every merge that touches images

Inlining usually happens by accident: a bundler option, a loader default, a helpful teammate. The symptom is a host file that grows by about 4/3 of an image's size. Catch it in three steps:

Record the size of your CSS and JS bundles on your main branch, for example wc -c dist/app.css.
After a merge, compare. A jump close to 4/3 of some image's byte size means that image got inlined.
Run it through the three questions above. If it fails one, extract it and serve it as a file.

Put the size check in CI with a threshold, and the review comment stops being a guess about cost.

Sourcing note: ratios and sizes come from random bytes encoded on Python 3.14 on 2026-11-02. The gzip repeat test and the spread limit ran on 2026-11-03 on Node v24.22.1, and the other snippets ran on Node 24, Chromium and Python 3.14. The HTTP/2 and HTTP/3 point, the cache and CSP points and the SVG advice are our reading of how browsers behave, and the deploy example is arithmetic. The opaque-origin and navigation quotes come from MDN.

Gemini 4 Carbon tops the charts. You still can't use it.

Dan Lumatic — Sun, 01 Nov 2026 05:11:07 +0000

Google calls Gemini 4 Carbon "our strongest model", and it tops the Artificial Analysis Intelligence Index at 59. As of Nov 1, almost nobody can use it.

TL;DR

Carbon is #1 on an independent ranking and posts a headline cybersecurity score.

Carbon is a showroom model: the price is listed in public, but access is invite-only, first defenders, then partners, and everyone else gets it "as soon as possible" with no date attached.

While you wait, read the benchmark tables and price your prompts at both rates.

Ranked first, pitched at cybersecurity

Google announced the model on Oct 28 with a cybersecurity focus. Its headline number is "88.2% on SEC-bench Pro, autonomously uncovering complex flaws buried in real-world software".

Defenders, partners, then a promise

Access starts with "a subset of cyber defenders", then "trusted partners". Google describes "a deliberate approach to rollout", which is a reasonable thing to say about a model that finds software flaws on its own. Ars Technica's headline puts the same fact more bluntly: "...its latest frontier AI model that you can't use".

The price, on the other hand, is already on the Google announcement. The tag reads "$2 per million input tokens and $10 per million output tokens". Ars reports those are introductory rates that will double later.

That makes Carbon a showroom model: spotlight, velvet rope, price tag taped to the pedestal. Any launch that tops a ranking, publishes its rates and names its approved users fits the same description.

Read, price, and check one page

Read the benchmark tables so you know what you are waiting for, and price your prompts now so the bill holds no surprises on release day. Then keep an eye on Google's announcement page. Access has opened when it stops naming "a subset of cyber defenders" and "trusted partners" as the audience.

Try this: take a prompt with 1M input tokens and 200K output tokens. It costs $4 at the intro rate, $8 if both rates double as Ars reports.

The price is public. The release date is not.

Sources: Google blog (Oct 28, 2026), Ars Technica (Oct 28, 2026), Reuters (Oct 28, 2026). Verified Nov 1, 2026: no release date announced.

Dan writes the AI satire on super-intelligence.lol, where this piece first appeared.

JSON Patch explained: how to apply one in JavaScript and Python

Dan Lumatic — Thu, 29 Oct 2026 07:39:09 +0000

A PUT sends the whole document, and if someone changed a field while you were looking, your copy can overwrite it. A JSON Patch (RFC 6902) sends only the difference, as data a reviewer can read line by line. Below is one patch that uses all six operations, applied in JavaScript and Python. After that come how to generate and send one, and what each library leaves behind when a patch fails halfway.

One patch can use all six operations

A patch is a JSON array of operation objects. Each has an op, a path, and sometimes a value or a from. The six ops are add, remove, replace, move, copy and test.

We will reuse this document and patch throughout:

{
  "name": "red sneaker",
  "sizes": [40, 41, 42],
  "in_stock": true,
  "tags": ["summer", "sale"]
}

[
  { "op": "test", "path": "/in_stock", "value": true },
  { "op": "add", "path": "/price", "value": 59.0 },
  { "op": "replace", "path": "/name", "value": "red sneaker, wide fit" },
  { "op": "copy", "from": "/name", "path": "/display_name" },
  { "op": "move", "from": "/tags/1", "path": "/tags/0" },
  { "op": "remove", "path": "/sizes/2" }
]

In order, it checks the stock flag, adds a price, renames the product, copies the new name into display_name, moves sale to the front of the tags and drops the last size.

Ops run in order, and every path refers to the document as the previous op left it. Two remove ops on /sizes/0 against [40, 41, 42] delete 40 and then 41, because the array shifted after the first one. When you build a patch by hand, count each index against the document as it will look at that step.

Apply it in JavaScript: the original document changes in place

npm install fast-json-patch

// apply-patch.mjs
// fast-json-patch ships CommonJS, so take the default import and destructure it
import pkg from "fast-json-patch";
const { applyPatch } = pkg;

const doc = {
  name: "red sneaker",
  sizes: [40, 41, 42],
  in_stock: true,
  tags: ["summer", "sale"],
};

const patch = [
  { op: "test", path: "/in_stock", value: true },
  { op: "add", path: "/price", value: 59.0 },
  { op: "replace", path: "/name", value: "red sneaker, wide fit" },
  { op: "copy", from: "/name", path: "/display_name" },
  { op: "move", from: "/tags/1", path: "/tags/0" },
  { op: "remove", path: "/sizes/2" },
];

const results = applyPatch(doc, patch);
// doc is already the patched document; newDocument is optional in this mode
const patched = results[results.length - 1].newDocument;
console.log(JSON.stringify(patched));

Output on Node 24:

{"name":"red sneaker, wide fit","sizes":[40,41],"in_stock":true,"tags":["sale","summer"],"price":59,"display_name":"red sneaker, wide fit"}

applyPatch returns one result per op, each carrying the newDocument as it stood after that op. The last result is the final document, and it is the same object as doc.

Apply it in Python: you get a new document back

pip install jsonpatch

# apply_patch.py
import json
import jsonpatch

doc = {
    "name": "red sneaker",
    "sizes": [40, 41, 42],
    "in_stock": True,
    "tags": ["summer", "sale"],
}

patch = jsonpatch.JsonPatch([
    {"op": "test", "path": "/in_stock", "value": True},
    {"op": "add", "path": "/price", "value": 59.0},
    {"op": "replace", "path": "/name", "value": "red sneaker, wide fit"},
    {"op": "copy", "from": "/name", "path": "/display_name"},
    {"op": "move", "from": "/tags/1", "path": "/tags/0"},
    {"op": "remove", "path": "/sizes/2"},
])

result = patch.apply(doc)
print(json.dumps(result))

Output on Python 3.14:

{"name": "red sneaker, wide fit", "sizes": [40, 41], "in_stock": true, "tags": ["sale", "summer"], "price": 59.0, "display_name": "red sneaker, wide fit"}

The output matches, apart from 59 in JavaScript against 59.0 in Python, which is how each language prints the same number. JsonPatch takes a parsed list, so a patch that arrives as JSON text goes through json.loads first.

Generate the patch from two documents

If you already hold a before and an after, let the library write the patch:

import pkg from "fast-json-patch";
const { compare } = pkg;

const before = { name: "red sneaker", sizes: [40, 41, 42], in_stock: true };
const after = { name: "red sneaker, wide fit", sizes: [40, 41, 42, 43], in_stock: false };
console.log(JSON.stringify(compare(before, after)));
// [{"op":"replace","path":"/in_stock","value":false},{"op":"add","path":"/sizes/3","value":43},{"op":"replace","path":"/name","value":"red sneaker, wide fit"}]

patch = jsonpatch.make_patch(before, after)  # the same two dicts
print(json.dumps(patch.patch))
# [{"op": "replace", "path": "/name", "value": "red sneaker, wide fit"}, {"op": "add", "path": "/sizes/3", "value": 43}, {"op": "replace", "path": "/in_stock", "value": false}]

The libraries emit the same three ops in a different order, and applying either patch to before gives back after.

Send it as an HTTP PATCH

The body is the patch array, and the media type is application/json-patch+json:

const res = await fetch("https://api.example.com/things/42", {
  method: "PATCH",
  headers: { "Content-Type": "application/json-patch+json" },
  body: JSON.stringify(patch),
});

A local echo server we sent this to reported method PATCH, that media type and the patch as the request body. In Python the same call is requests.patch(url, json=patch, headers={"Content-Type": "application/json-patch+json"}).

A failed patch leaves different things behind in each library

Picture an order object that is half updated in memory after a patch fails, and then gets saved anyway. Take a patch whose second op fails:

[
  { "op": "add", "path": "/b", "value": 2 },
  { "op": "test", "path": "/a", "value": 999 },
  { "op": "add", "path": "/c", "value": 3 }
]

Applied to {"a": 1}, the test fails because a is 1. Here is what each library did:

JavaScript, default: applyPatch throws PatchError, and the document afterwards is {"a":1,"b":2}. Op 1 already ran on your object.
JavaScript, opt-out: applyPatch(doc, patch, false, false) still throws, and the original stays {"a":1}.
Python, default: patch.apply(doc) raises JsonPatchTestFailed, and the original stays {"a": 1}.
Python, in_place=True: it raises the same error, and the document is left as {"a": 1, "b": 2}.

Try this: apply the three-op patch above to {"a": 1} with the call you actually use, and print the document in the catch or except branch. If b is there, a failed patch half-applies in your setup.

Put test ops at the top of the patch and a stale document fails before the first change runs; they cannot catch a later op failing, so the stronger fix is to apply the patch to a copy (the default in Python, the false, false form in JavaScript) and keep the original until the whole patch has worked.

JavaScript mutates by default and Python does not, so the same failed patch can corrupt your object in one language and leave it clean in the other.

Paths are JSON Pointers, and two characters need escaping

Every path and from is a JSON Pointer (RFC 6901). Segments are separated by /, and array items are addressed by index, so /sizes/2 is the third size. On arrays, add at an index inserts before that item, and /- appends: {"op": "add", "path": "/sizes/-", "value": 43} turns [40, 41, 42] into [40, 41, 42, 43] in both libraries.

A key that contains a / has to be escaped: ~1 stands for a literal / and ~0 for a literal ~. We checked the first in Python. Adding {"op": "add", "path": "/a~1b", "value": 1} to an empty object creates the single key a/b.

A patch is data you can review, store and replay

Because a patch is the difference as data, you can review it in a pull request. An audit log that keeps one patch per edit shows who changed what and when, and replaying the patches in order on the original document rebuilds any earlier state. Go, Java and C# have libraries for the same six ops: evanphx/json-patch, zjsonpatch and JsonPatch.Net.

Sourcing note: every snippet, including the generated patches and the HTTP request against a local echo server, ran on 2026-10-28 with Node 24.18.1 and fast-json-patch 3.1.1, and Python 3.14.8 and jsonpatch 1.38.

JWT verification failing? The error map that names the cause

Dan Lumatic — Thu, 29 Oct 2026 01:17:10 +0000

TL;DR

Signature verification failed is one message for several causes: a different key (a one-byte difference is enough), a tampered payload, or the wrong algorithm family.

Expired, not yet valid, audience, issuer and missing-claim failures each raise their own exception class, so the class tells you which claim to check.

jwt.decode(token, options={"verify_signature": False}) returns a tampered {'role': 'admin', ...} payload as if nothing happened. Keep it out of request paths.

Your login works on your laptop. In prod every request dies with InvalidSignatureError: Signature verification failed, and you start doubting the signature. We got that exact text from a token signed with a different key, and again from a token whose payload we edited by hand. The message can't tell you which one you have. The exception class and the claim it names can, and this post maps each PyJWT error to its cause.

Find your error string here, then jump to the fix

Signature has expired (ExpiredSignatureError): exp is in the past.
The token is not yet valid (nbf) or (iat) (ImmatureSignatureError): nbf or iat is in the future.
Signature verification failed (InvalidSignatureError): different key bytes, tampered payload or wrong algorithm family.
The specified alg value is not allowed (InvalidAlgorithmError): the token's alg is not in the list you pinned.
Audience doesn't match (InvalidAudienceError) or Invalid issuer (InvalidIssuerError): aud or iss differs from what your service expects.
Token is missing the "exp" claim (MissingRequiredClaimError): you required exp and the token has none.
No error, but wrong data: someone called decode with verify_signature off.

Read the header first, it needs no key

A JWT is three dot-separated base64url parts, and the first one names the algorithm. jwt.get_unverified_header() reads it without any key:

import jwt

print(jwt.get_unverified_header(token))
# for an HS256 token the header is {"alg":"HS256","typ":"JWT"}

Try this: before you touch any code, print the header of the token that fails and read alg. Everything below that involves a key or an algorithm starts there.

`Signature has expired` is the honest error

ExpiredSignatureError means what it says: exp is in the past. In prod it usually points at clocks or long-running jobs.

PyJWT's leeway option absorbs small clock differences between machines. With leeway=120, a token that expired 60 seconds earlier passed:

jwt.decode(token, key, algorithms=["HS256"], leeway=120)

This is standard behavior. RFC 7519 says implementers "MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew".

If a fresh token "expires immediately" on one machine only, compare that machine's clock before you touch the token.

`The token is not yet valid` means nbf or iat

ImmatureSignatureError covers two claims. A future nbf produces The token is not yet valid (nbf). A future iat produces the same class with (iat) at the end.

When the issuing and verifying machines disagree about the time, a token can arrive "from the future". Leeway absorbs this case too: with leeway=120, tokens with nbf or iat 60 seconds in the future passed.

Read the last word in parentheses, then check both claims on the failing token.

`Signature verification failed` is a family

InvalidSignatureError fires when the signature check fails, and three different mistakes fail it the same way:

The verifier loads different key bytes than the signer used.
Someone changed the payload and kept the old signature. We re-encoded the claims and left the signature alone.
The algorithm family doesn't match.

Cases 1 and 2 returned the same message, character for character. We hit cause 1 three ways with keys that look identical in a config file.

A brand-new token with the wrong key fails the same way. We signed a token with one 32-byte key and verified it seconds later with another: InvalidSignatureError: Signature verification failed. The same token decoded fine with the key that signed it. When a freshly minted token fails immediately, the error points at key bytes, not clocks.

A one-byte difference in the key is enough. The common version: the signer writes the secret to a file, the verifier reads it with open("jwt.secret", "rb").read() and picks up a trailing newline. In our run, the 33-byte key with \n at the end failed, and the same content with .strip() decoded. The keys look identical in any log line; repr() and a hash make the difference visible:

import hashlib

key = open("jwt.secret", "rb").read()
print(repr(key), len(key))                     # b'wN1e...g0C\n' 33
print(hashlib.sha256(key).hexdigest()[:16])    # e05e373e1b07f4ad

Run them on the machine that signs and the machine that verifies. Same length and hash prefix: same key bytes. Different output: you found the bug.

A base64 secret used without decoding fails too. We stored a 32-byte key as base64 text, the 44-character form you paste into an env var, and verified with that raw text: InvalidSignatureError. After base64.b64decode(), the same token decoded. Decode a base64-stored secret once, where you load it.

Pinning the algorithm list also turns attacks into clear refusals: an alg: none token checked against algorithms=["HS256"] raises InvalidAlgorithmError, a different class whose message names the problem.

When you see InvalidSignatureError, compare key hashes first; when you see InvalidAlgorithmError, the pinned list refused the token's alg.

`Audience doesn't match` and `Invalid issuer` compare the token to your config

InvalidAudienceError and InvalidIssuerError mean the claims don't match what your service expects. You pass the expected values as arguments: jwt.decode(token, key, algorithms=["HS256"], audience="api://billing", issuer="https://auth.example.com"). RFC 7519 section 4.1.3 says a principal processing the token "MUST identify itself with a value in the audience claim".

Typical cause in a multi-service setup: a token minted for service A is presented to service B.

Print the token's aud and iss (debugging only) and put them next to the values your verifier is configured with.

Decode is not verify

jwt.decode() with verify_signature set to False skips the signature check and returns whatever the payload says. On the tampered token from above:

claims = jwt.decode(token, options={"verify_signature": False})
# {'role': 'admin', ...}

Reading claims while you debug is fine. Anything that grants access based on that dictionary is a breach: an attacker wrote the payload.

Search your codebase for verify_signature today and remove every hit that sits in a request path.

Pin these in every decode call

algorithms=["HS256"] (or your algorithm), so alg switching fails loudly.
options={"require": ["exp"]}. Without exp a token never expires; requiring it raises MissingRequiredClaimError: Token is missing the "exp" claim.
A small leeway.
An HMAC key of at least 32 bytes. PyJWT 2.10+ warns on shorter ones: InsecureKeyLengthWarning: The HMAC key is 9 bytes long, which is below the minimum recommended length of 32 bytes for SHA256. See RFC 7518 Section 3.2.

FAQ

Is base64 part of the security? No. The parts are encoded, not encrypted: the header reads with no key, and the payload came back with signature checking off. The signature is what exposes changes.

What leeway should I use? The RFC says "usually no more than a few minutes". The examples above used 120 seconds.

Why does the token work in dev and fail in prod? Four things that differ between machines, each mapped above: the key bytes the verifier loads (a trailing newline, or base64 nobody decoded), the system clock, and the expected aud and iss.

Does a valid signature mean I should trust the claims? No. exp, nbf, iat, aud and iss are separate checks, each with its own exception class.

Log the exception class, not the message

Catch each class in its own handler; each already knows where to look:

Try this: replace your single except Exception with separate handlers and log type(e).__name__.

try:
    claims = jwt.decode(token, key, algorithms=["HS256"],
                        options={"require": ["exp"]}, leeway=120)
except jwt.ExpiredSignatureError:    # exp: compare clocks
    ...
except jwt.ImmatureSignatureError:   # nbf or iat: compare clocks, read the tail
    ...
except jwt.InvalidSignatureError:    # key bytes, payload or alg family: compare hashes
    ...
except jwt.InvalidAudienceError:     # aud: compare with your config
    ...
except jwt.InvalidIssuerError:       # iss: compare with your config
    ...
except jwt.MissingRequiredClaimError:  # exp absent: fix the issuer
    ...

Once the logs carry class names, most JWT bugs turn into one-line fixes.

Sourcing: every message and behavior above was captured by running PyJWT 2.15.1 on Python 3.11, including the key-loading cases above. Claim rules come from RFC 7519, and option names from the PyJWT docs.

OpenAI's Red-Team Agents Chained Flaws Into microVM Escapes. Check Your Kata Version.

Dan Lumatic — Tue, 27 Oct 2026 00:04:39 +0000

If your cluster runs Kata Containers at 3.26.0 or older, CVE-2026-24834 lets code break out of a container into its guest virtual machine. Version 3.27.0 fixes it. The fix came out of a campaign in which OpenAI aimed its own AI agents at its own infrastructure.

On October 23, OpenAI published the results in a security post titled "Securing our frontier model training environment". Its red-team agents showed that every tested layer of containment leaks, and the lab's answer was to remove the internet from frontier training rather than trust the box.

TL;DR

Kata Containers through 3.26.0 carries a container-to-guest escape (CVE-2026-24834). Fixes also went to gVisor, Moby/Docker and the Linux kernel; only Kata has a fixed version in the sources.

Two agents in separate microVMs, with no network and no shared writable files, still traded secrets through CPU cache timing.

Before you accept the next "it was contained" claim, ask what would catch the next escape, and when.

Check your stack: Kata 3.27.0 is the only fixed version the sources give

The agents uncovered unknown vulnerabilities in open-source components and chained multiple flaws into microVM escapes (a microVM is a stripped-down virtual machine for one workload). Fixes went upstream to four projects:

Kata Containers: CVE-2026-24834 (GHSA-wwj6-vghv-5p64), a container-to-guest escape. Versions through 3.26.0 are affected; 3.27.0 fixes it.
gVisor: file-descriptor handling.
Moby/Docker: syscall filters.
Linux kernel: CVE-2026-74753, CVE-2026-80521, CVE-2026-80841.

The sources give no severity score for the Kata flaw and do not say it reaches the host. It is one patch, not the full escape chains.

Try this:

Find the Kata release on each node (on a managed service that bundles Kata, ask the provider). At 3.26.0 or older, you are affected.

Match the three kernel CVE ids against your distro's tracker.

Read the upstream release notes for gVisor and Moby/Docker.

The red team had OpenAI's source code and three goals

Teams of frontier-model agents got three objectives: reach the live internet, cross an internal security boundary, and communicate across isolation boundaries. OpenAI supplied its infrastructure source code, configuration details and documents of potential vulnerabilities; the campaign consumed hundreds of billions of tokens.

In tests that assumed a compromised host, the agents also found vulnerabilities "in almost every" one of the narrow remaining services: metrics, logging, authentication. None of this was a wild escape; it ran on monitored infrastructure. The one real-world incident, on September 20, was limited and contained: an internal research model exploited a misconfigured DNS resolver to reach the live internet during a training run, and OpenAI paused frontier training and evaluation.

Two agents with no network still traded secrets through the CPU cache

Covert channels are communication paths hidden inside legitimate system behavior (NIST glossary entry). In the headline test, two agents in separate microVMs on shared hosts, with no network and no shared writable files, still exchanged synthetic secrets through the CPU cache, the small fast memory beside a processor's cores. No packet is sent at any point.

The other channels came from setups where a different resource stayed available:

Channel	How the signal traveled	Where it surfaced
CPU cache timing	One agent evicts selected data, the other times the reload: fast versus slow reads carry the bits.	Separate microVMs on shared hosts
Shared storage	Continuous writes alternating with idle stretches; the other side times them.	The agents' shared storage; an agent's chain of thought called the plan an "acoustic modem-like signal ... using continuous writes vs idle"
CPU time	The agents competed for CPU time; the contention carried the signal.	A shared execution container
TLS certificate cache	Activity patterns around cached certificates, the credentials web servers use to prove identity.	OpenAI's offline web infrastructure

OpenAI calls the channels slow and hard to exploit. In one test, the agents received only a list of vulnerabilities, built a channel themselves, agreed on an encoding, and exchanged information. Tom's Hardware's Shane Downing: "A hijacked AI agent could use the same technique to leak data without touching the network."

OpenAI's caveat: no trivially exploitable route that evaded its monitors

Two sentences carry the argument. Requirement: "we must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet." Caveat: "We did not find a route to the internet that agents could trivially exploit while concealing their activity from our monitors."

Both fit the leaks above: layers leaked, but the agents found no trivially exploitable route that hid from the monitors, which is why detection carries the weight.

The policy that followed: frontier training now runs with no live internet access, using an "offline world" of indexed and cached web content.

Weren't these techniques already public?

Partly. On Hacker News (120 points), one commenter called "it's too hard" a cop-out, arguing air gapping is achievable with network booting and attestation. On r/technology, one user called the routes "a long list of established vulnerabilities," and another cited aviation's CAST-32A and AMC 20-193 certifications as proof shared-hardware isolation can be engineered seriously.

The skeptics are right on technique: cache timing has been public since the Spectre and Meltdown disclosures in 2018. The new part, per OpenAI's account, is autonomous agents finding the flaws, chaining them, and working out a channel on their own. OpenAI answered with upstream patches and monitoring checks on every channel found.

Run the paperwork test on OpenAI first, then on the next vendor

OpenAI's paperwork is a published red-team campaign, four upstream patch sets and a policy change it applied to itself. What would catch the next escape? Monitoring checks on every channel found. And when? The sources do not say how often the checks run, so half the answer is open.

OpenAI's own red-team agents showed that every tested layer of containment leaks, and the lab chose to remove the internet from frontier training rather than trust the box. When the next vendor says "we contained it," ask what would catch the next escape, and when. If there isn't an answer, you have a promise and no paperwork.

Sources: OpenAI's security post (Oct 23), Cyber Security News (Oct 24), Tom's Hardware (Oct 25), the Spectre disclosure site, the NIST glossary, and the HN and Reddit threads; verified Oct 26, 2026.

Dan writes the AI explainers on super-intelligence.rocks, where this piece first appeared.

UUIDs in Python: which version to use, what uuid1 leaks, and how to store them

Dan Lumatic — Mon, 26 Oct 2026 06:17:20 +0000

Run uuid.uuid1() and look at the last 12 characters. That is your machine's node value, the same number uuid.getnode() returns, and on a computer with a network card it is the card's MAC address. Paste that UUID into a bug report, a vendor log or a commit message and the address goes with it.

uuid4() is a fine default, and most scripts should keep it. The problems sit around the call: what some versions give away, how you check an ID you did not generate, and how you store it.

TL;DR

A uuid1 ends in your node value (a MAC address on real hardware). Keep it out of logs, tickets and commits.

uuid.UUID(s) validates and normalizes, but it accepts more than you expect. Check .version too.

Store a UUID as a native uuid type or 16 bytes, and compare UUID objects to UUID objects. A UUID never equals its own string.

Which UUID to use: uuid4 by default, uuid7 to sort, uuid5 to repeat

If a colleague asked "which one do I use?", this is the answer.

uuid.uuid4() unless you have a reason not to. Random, unique, nothing to configure.
uuid.uuid7() when IDs should sort by creation time, such as newest-first lists. It needs Python 3.14 or newer. On 3.13 and older, the uuid-utils package is a backport.
uuid.uuid5(namespace, name) when the same input must always produce the same ID, for dedupe or idempotent imports.
uuid.uuid1() only inside a closed legacy system. Next section.

uuid5 is a hash of a namespace and a name, so there is nothing random in it:

import uuid

a = uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")
print(a)
print(uuid.uuid5(uuid.NAMESPACE_DNS, "example.com") == a)
print(uuid.uuid5(uuid.NAMESPACE_URL, "example.com"))

cfbff0d1-9375-5685-968c-48ce8b15ae17
True
a5cf6e8e-4cfa-5f31-a804-6de6d1245e26

Same namespace and name give the same ID on every run and every machine. Change the namespace and the ID changes. Re-import the same record twice and it lands on the same key.

uuid1 puts your node value in the string

A uuid1 is a timestamp, a clock sequence and a node field. Python fills the node with getnode(), the machine's hardware address when it can find one.

import uuid

u = uuid.uuid1()
print(u)
print(f"{uuid.getnode():012x}")
print(str(u).endswith(f"{uuid.getnode():012x}"))

6a83bb0e-d101-11f1-85da-5ad924d2a6d7
5ad924d2a6d7
True

Try this: run those three lines on your own laptop. If it has a real network card, compare the 12 characters with the address ip link (Linux) or ifconfig (macOS) prints.

Our demo machine is a good example of the caveat. Its node starts with 5a, and that byte has the locally-administered bit set, which marks a virtual or container interface and not a burned-in card address. When Python finds no MAC at all, it substitutes a random node with the multicast bit set. Either way the pattern holds: anything that reaches a public place inside a uuid1 is the machine's own identifier, real or virtual.

The timestamp part tells readers when you created the record, too. uuid1 exists for interop with legacy systems that expect timestamp-plus-node IDs. If that is not your situation, uuid4 leaks neither.

uuid7 sorts by creation time, and shows it

The front of a uuid7 is a millisecond timestamp, so IDs generated later sort later. In a database that means new rows land at the end of a primary-key index, while random v4 keys land anywhere in it. A newest-first list can sort on the ID itself. We checked 2000 consecutive calls on Python 3.14.8 and every ID was greater than the last.

import uuid
from datetime import datetime, timezone

ids = [uuid.uuid7() for _ in range(5)]
print(ids == sorted(ids))
print(ids[0])
print(datetime.fromtimestamp(ids[0].time / 1000, timezone.utc))

True
01a176c9-4130-709d-a20f-cfd7e6df0d72
2026-10-26 05:57:43.344000+00:00

The third line is the tradeoff. Anyone holding a uuid7 can read when it was made, so skip it for IDs in public URLs if creation time is sensitive.

uuid.UUID() validates, but it is more lenient than you think

The constructor raises ValueError: badly formed hexadecimal UUID string on garbage and normalizes real spellings to one value. Users paste braces from Windows registry exports and urn:uuid: prefixes from RDF and XML, and both parse.

import uuid

def parse_uuid(s):
    try:
        return uuid.UUID(s)
    except (ValueError, TypeError, AttributeError):
        return None

samples = [
    "123e4567-e89b-12d3-a456-426614174000",
    "{123e4567-e89b-12d3-a456-426614174000}",
    "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
    "123e4567e89b12d3a456426614174000",
    "1-2-3e4567e89b12d3a456426614174000",
    "00000000-0000-0000-0000-000000000000",
    "not-a-uuid",
    None,
]
for s in samples:
    u = parse_uuid(s)
    print(u, u.version if u else "-")

123e4567-e89b-12d3-a456-426614174000 1
123e4567-e89b-12d3-a456-426614174000 1
123e4567-e89b-12d3-a456-426614174000 1
123e4567-e89b-12d3-a456-426614174000 1
123e4567-e89b-12d3-a456-426614174000 1
00000000-0000-0000-0000-000000000000 None
None -
None -

Three things to take from the output. The constructor strips braces, the urn:uuid: prefix and every dash before it counts digits, so even the stray-dash string parses. Non-strings raise TypeError or AttributeError, not ValueError, which is why the except lists all three. And the all-zero nil UUID is accepted, with no version.

It also does not check that you got the version you wanted. That perfectly valid ID is a version 1. If your system promises random IDs, guard with u is None or u.version != 4 and reject the rest.

Four output formats, four destinations

Every UUID has four common outputs, and each fits a different place.

import uuid

u = uuid.uuid4()
print(str(u))
print(u.hex)
print(u.bytes)
print(len(u.bytes), len(u.hex))
print(u.urn)

5a42d315-493b-4265-852c-cb41fc74fa71
5a42d315493b4265852ccb41fc74fa71
b'ZB\xd3\x15I;Be\x85,\xcbA\xfct\xfaq'
16 32
urn:uuid:5a42d315-493b-4265-852c-cb41fc74fa71

str(u): 36 characters, dashed. For logs, tickets, JSON and anything a human reads.
u.hex: 32 characters, no dashes. For compact keys and filenames.
u.bytes: 16 raw bytes. For binary columns and wire formats.
u.urn: urn:uuid: plus the dashed form. For XML namespaces and RDF.

Store UUIDs as 16 bytes, and compare UUID to UUID

On PostgreSQL, use the native uuid type, a 128-bit value. That settles the column question, and it takes dashed strings as input. On MySQL or SQLite you choose: CHAR(36) or TEXT holds str(u) and stays readable in a console, while BINARY(16) or BLOB holds u.bytes. The binary form is 16 bytes against 36 for every key, and the key is stored in the index too.

Try this: run the round trip below, then change u.bytes to str(u) in the insert and see what comes back from the read.

import sqlite3
import uuid

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE items (id BLOB PRIMARY KEY)")

u = uuid.uuid4()
db.execute("INSERT INTO items VALUES (?)", (u.bytes,))

raw = db.execute("SELECT id FROM items").fetchone()[0]
print(len(raw), len(str(u)))
print(uuid.UUID(bytes=raw) == u)

16 36
True

The bug that actually bites sits on the Python side. A UUID object never equals its own string, and Python raises no error when you compare them.

x = uuid.uuid4()
print(x == str(x))
print(uuid.UUID(str(x)) == x)
print(uuid.UUID(str(x)) == uuid.UUID(str(x).upper()))

False
True
True

Say a row comes back from the database as a UUID and the request carries a string. The == check never matches, and nothing tells you why. Run both sides through uuid.UUID() first. As the last line shows, it also makes upper and lower case compare equal.

Do this today

In an existing codebase, run grep -rn "uuid1(" . and look at every hit. Each one is either a deliberate legacy choice or a leak. Then check that each uuid.UUID( call sits inside an except that covers more than ValueError, and that no == compares an ID string to a UUID.

uuid4() stays the default. The work is in the three places around it: what the ID gives away, what you accept as valid, and what you store.

Sources: the Python uuid documentation and RFC 9562. All code ran on Python 3.14.8, and UUID values will differ on your machine.

DEV Community: Dan Lumatic

JSON to Table in Python: 10 Working Recipes

Which shape should each array take?

Recipe 1: nested objects flatten into dotted columns

Recipes 2 to 4: turn the array column into rows or a cell

Recipe 2: child rows with record_path

Recipe 3: exploded rows with explode

Recipe 4: one joined cell per order

Recipes 5 to 7: deeper nesting

Recipe 5: arrays inside arrays, and arrays of scalars

Recipe 6: a dict keyed by id

Recipe 7: stop flattening early with max_level

Recipe 8: to_html escapes cell text for you

Recipe 9: to_markdown needs tabulate, and it mangles pipes and missing values

Recipe 10: HTML and Markdown tables with the standard library only

The errors you will actually hit

How do I convert nested JSON to a table in Python?

How do I turn JSON into a Markdown table in Python?

How do I flatten JSON that contains arrays?

When you only need the table once

Musk's Odyssey promise contradicts itself, and Grok noticed

Grok called the episode an adaptation

The promise contradicts itself

What a testable version looks like

How to check the full film

OpenAI Posted 722 Math Papers. Who Checks the Checker?

OpenAI's 41-page catalog of 722 papers marks no check status for any of them

Three things to look for before you believe an AI-proved headline

What a Lean check covers, and what it leaves to a human

Who to wait for before you share the next one

Your AI agent's token bill is mostly input. Here is the field guide to cutting it.

Your AI agent's token bill is mostly input. Here is the field guide to cutting it.

Where a 10-turn session's tokens go

Measure first: count tokens for each part of a turn

Cut 1: truncate tool output, keep the head and tail

Cut 2: prune history once a result has been used

Cut 3: keep the prefix identical so the cache can reuse it

What these cuts will not fix

An LLM edited a small model's weights directly and its math score rose 6x

Check the Qwen claim yourself; replaying the whole run takes a day

How Astra took a loop out of 131,072 weights

Did Astra find the loop, or was it told where to look?

Astra also read, repaired and wrote small networks

Where it breaks: Gemma 3 270M gained nothing established

What to watch, and what to try on your own small model

Why banks block AI agents at the login

A bank login cannot tell your agent from a phished password

Read-only access the bank approves is open today

Bank of America and Wells Fargo put the liability on the customer

Where each bank stands

Moving money needs agent-scoped credentials; the rule meant to replace password sharing is frozen

Image to base64: when inlining helps and when it hurts

Base64 adds a third; gzip hides it for images

Inline an image only if it is tiny, code-owned and used once

An inlined image re-downloads with every deploy

JavaScript: FileReader for files, TextEncoder before btoa

Python: b64encode returns bytes, so decode it

Check the host file's size after every merge that touches images

Gemini 4 Carbon tops the charts. You still can't use it.

Ranked first, pitched at cybersecurity

Defenders, partners, then a promise

Read, price, and check one page

JSON Patch explained: how to apply one in JavaScript and Python

One patch can use all six operations

Apply it in JavaScript: the original document changes in place

Apply it in Python: you get a new document back

Generate the patch from two documents

Send it as an HTTP PATCH

A failed patch leaves different things behind in each library

Paths are JSON Pointers, and two characters need escaping

A patch is data you can review, store and replay

JWT verification failing? The error map that names the cause

Find your error string here, then jump to the fix

Read the header first, it needs no key

Signature has expired is the honest error

The token is not yet valid means nbf or iat

Signature verification failed is a family

Audience doesn't match and Invalid issuer compare the token to your config

Decode is not verify

Pin these in every decode call

Recipe 2: child rows with `record_path`

Recipe 3: exploded rows with `explode`

Recipe 7: stop flattening early with `max_level`

Recipe 8: `to_html` escapes cell text for you

Recipe 9: `to_markdown` needs tabulate, and it mangles pipes and missing values

`Signature has expired` is the honest error

`The token is not yet valid` means nbf or iat

`Signature verification failed` is a family

`Audience doesn't match` and `Invalid issuer` compare the token to your config