DEV Community: Billie M

What GPT-6.1 Sol chose to build

Billie M — Thu, 01 Oct 2026 12:38:32 +0000

A cutting layout can look convincing while leaving its cut order ambiguous. A document comparison can work while putting its navigation offscreen. A traffic solver can return the right numbers without making them understandable.

Those were concrete review problems in three autonomous GPT-6.1 Sol experiments. The subjects were freely chosen: sheet cutting, the editing of an official record, and congestion. What changed during review was how someone could inspect and use the result.

I wanted to continue the Choice exercise: let a new model choose what to build, then examine its outputs and style. This batch ran at Extra High reasoning. The coordinating agent assigned compact, substantial and flagship ambition levels. One fresh builder chose all three topics and implemented the first two; a second fresh Sol builder took the flagship before public code existed.

A packing diagram needs a cutting sequence

Try Offcut with sheet dimensions, part quantities, grain constraints and blade width. It produces a layout and a sequence of full cuts through the remaining rectangles. Playback shows when a piece is actually released, rather than merely showing where it ends up.

The supplied job places nine parts on a 1,220 × 610 mm sheet. The blade's lost material changes feasibility: two 50 × 100 mm parts fit a 100 × 100 mm sheet with zero blade width, but only one fits with a 3 mm blade.

Offcut's supplied nine-part layout. The diagram accounts for blade loss and grain; no physical cutting was tested.

The review problem was in the CSV cut order. Two physical copies of identically named stock were indistinguishable. Stable physical sheet IDs now distinguish them. Mobile feedback also changed because solving could leave the result offscreen.

The outputs include a dimensioned SVG, CSV instructions, editable JSON and remaining-stock inventory. Their usefulness still depends on the model's bounds: axis-aligned rectangular parts and full guillotine cuts. Damaged edges, trimming allowance, clamping and tool clearance are excluded, and no physical cutting was tested. An unplaced part is not proof that every possible arrangement fails; this is a bounded search.

A text comparison needs a way back to its source

Explore The Minutes by selecting sentences across six authored versions of a fictional exhibition incident. It exposes earlier wording and lets you recover facts omitted from the current record.

“The issue was managed promptly” traces back to a request to isolate the power, refused because the display lighting had to stay on. The final reassurance is not established by that first account. The sequence also contains a useful correction: an uncertain pump-stoppage time becomes a time supported by the controller log. Editing is not uniformly treated as concealment.

The final record compared with the first account in The Minutes. This ancestry belongs to an explicitly authored fictional incident.

The initial navigation began below the visible page. Review moved it above the document; on mobile, selecting a sentence brings its provenance into view and supplies a return to the sentence. The explanation distinguishes removed facts from introduced assurances. The corpus and its ancestry are authored, so this is an inspectable argument, not a dishonesty detector for uploaded documents.

A solver needs more than its raw output

Change the network in The Shortcut Tax. At the default west demand of six flow units, average travel is 80 minutes without the shortcut and 100 with it under individual route choice. No driver can save time by switching routes alone.

The default six-unit demand with the shortcut open. These are results of the teaching network, not measured traffic times.

Coordinated routing restores the 80-minute average. Pricing each driver's imposed delay can reproduce it too, with tolls expressed in equivalent minutes. Changing demand can make the same shortcut helpful, harmful or unused.

The prototype initially exposed calculations as raw JSON. Review asked for a legible network, road and route costs, a demand sweep and a toll ledger. A second origin makes the shared bottleneck's effects inspectable by neighbourhood. These are teaching results under fixed demand, instantaneous equilibrium and simple congestion costs, not measured traffic or a forecast with queues.

The published surfaces still resemble September's Astra batch in their warm paper, serif headings and muted colours. The working conditions differ: Astra used three separately assigned builders at Max, with different subjects and a different brief. These portfolios cannot establish a model's taste or superiority.

The concrete comparison is between the prototype and what a visitor can now do. Follow a sentence back, distinguish physical sheets in a kept cut order, or inspect why the network's travel time changes. Review altered those routes into the underlying work, not just its finish.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

Free compute in October 2026: new backends and temporary VMs

Billie M — Thu, 01 Oct 2026 11:42:01 +0000

Two of October’s useful development routes let you postpone signup: a temporary Postgres project and a Linux machine reached over SSH. The database lasts three days; the machine gives you an hour to build. The claim links and account handoffs have their own limits.

This is the 1 October 2026 check, based on official pricing and documentation. No accounts or workloads were created for it. The maintained free-compute guide carries the broader shortlist, and the September edition is the previous snapshot. The focus here is getting a prototype started, then keeping its expiry and credit conditions attached to it.

A database before its owner signs up

An agent can create a Claimable Neon Postgres project before a human has an account. Neon announced that route on 11 September.

The unclaimed project gets 100 MB storage and 1 GB transfer. There are two deadlines:

The project expires after 72 hours.
Its claim code expires after 15 minutes.

A database can still exist after its original claim code has expired. Treating those clocks as one deadline would miss the shorter one.

The Data API and Auth can be requested at creation. Functions, Object Storage and AI Gateway require claiming first. That leaves a useful temporary route for generating and testing a database-backed prototype, with a clear boundary around which backend products are available before onboarding. It does not replace the permanent Free plan or a backup.

A shell for the development session

Railway’s equivalent entry point is a command:

ssh railway.new

The 25 September announcement describes a Linux VM with 2 vCPU and 2 GB RAM, coding agents already installed, and a private preview URL. It needs neither an account nor a payment card.

Here the active development window is 60 minutes, followed by 24 hours to claim the VM. Claiming transfers the machine, files and URL into an account and makes the preview shareable. Unclaimed machines and files are deleted. Save or claim work before the clock runs out.

The trial documentation adds three anonymous boxes per IP address per day and regional capacity restrictions. Claiming also changes the billing context: the workload moves into the account’s ordinary credits and billing. The separate signup trial is $5 for 30 days, followed by $1 of recurring monthly Free credit. An anonymous hour and an account’s monthly allowance are different offers.

After claiming, read the backend meters separately

Neon’s backend became generally available on 18 September. Functions and Object Storage are available in Ohio, Northern Virginia, Frankfurt and Singapore, replacing September’s Ohio-only beta description with published Free allowances.

The Free pricing page lists up to 100 Postgres projects, each with 100 CU-hours per month and 0.5 GB database storage. Object Storage gets 5 GB per project. Functions get 10 active Capacity-Hours, 400 waiting Capacity-Hours and one million monthly invocations; Auth includes 60,000 monthly active users.

Those figures cannot all be multiplied by 100. The plan documentation applies the Functions limits across the account as well as independently per project. A project’s 5 GB network allowance is shared by Postgres, Object Storage and Functions.

Active Capacity-Hours measure CPU work; waiting Capacity-Hours measure time waiting on I/O. Adding them together does not produce 410 hours of an arbitrary always-on server. AI Gateway also uses purchased prepaid credits, so the backend launch does not supply free model inference.

A compute credit may exclude the API you call

For a GPU or model experiment, the product covered by the credit matters as much as its size.

Modal’s $30 is recurring compute credit. Its current pricing FAQ covers CPU, GPU and memory usage in Functions, Sandboxes and Notebooks. Shared Endpoints tokens are excluded and billed from the first request, effective 1 September 2026. The Workspace spend limit is the cash cap; a usage budget measures usage before credits. A payment method is required, and extra compute can charge.

Lightning’s GPU credits are a starter balance. The current offer gives five credits on registration and 25 more after adding a payment card. Unused credits expire after 12 months. GPU work spends that balance. One CPU Studio can remain free with a restart every four hours. September’s claim of 15 recurring monthly credits is not supported by today’s offer; no dated announcement was found to establish when it changed.

Mistral publishes a monthly API allowance. Its Free pricing now specifies $10 per month in API credits. The subscription documentation shares usage across Studio, API and Vibe Code. With pay-as-you-go disabled, exhausted usage can stop until renewal; enabling it allows additional tokens to bill. Model access and rate limits still need checking for the account. This is a current pricing observation, with no established launch date.

Batch work can wait; VM promotions can end

A prototype’s non-urgent processing has another dated option. Cloud Run added delayed job execution in Preview on 8 September: provisioning can wait up to 12 hours for a lower price, and execution can then run for up to 12 hours.

The pricing table gives a monthly free equivalent of 342,857 vCPU-seconds and 642,857 GiB-seconds at Tier 1 pricing. Google applies the free tier as a spending discount aggregated by billing account. The delayed-job, ordinary-job and request-based rows are not independent grants to add together. A billing-enabled account is involved, and builds, stored images, networking and excess usage can charge. The scheduling documentation carries the execution limits.

For a longer-running ARM VM, the AWS T4g promotion still provides 750 aggregate t4g.small hours per month, ending 31 December 2026. Disks, public IPv4 and surplus CPU can charge. Its end date needs to travel with the instance-hours figure.

The temporary database and SSH machine give a prototype somewhere to start. Their short claim windows remain relevant even while the resources still exist. Once work moves into an account, the covered product, shared meters and billing settings determine what the headline allowance actually buys.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

What GPT-6 Astra chose to build

Billie M — Sun, 13 Sep 2026 21:44:20 +0000

The first prototype of Loose End had a string, three pegs and four bells. It also had arrow-key controls that ignored short presses. A coordinating agent found the input problem and sent it back to the builder before the game was finished.

That repair is part of GPT-6 Astra's first Choice batch. I asked for three independent experiments with room to choose their subjects. Three Astra agents ran at max reasoning, assigned something to play, explore or use. They produced a string puzzle, a supply-chain model and a tool for making a printed booklet, published on 4 September.

The existing brief required prototype review before polish. The batch's curation record shows what the reviewer asked the builders to change. These were separate projects with corrections, not matched trials against another model.

Short key taps did nothing

In Loose End, you move the brass end of a finite string around the board. It catches around pegs, so a route that reaches a bell can leave less string available for the next one. Ringing all four bells is not enough: the string has to come home too.

A played position in Loose End. The route taken around the pegs changes how much string remains; this capture does not show a completed game.

The input fix made brief keypresses work. The later checks went further than reaching one bell: they exercised two winning strategies and retraced a long move sequence back to its starting point. Those checks concern the game's route rules and unwinding. They do not turn its planar taut-string model into a simulation of friction or elastic rope. It remains one authored course.

Put both order histories on the same scale

The review request for The Order Echo concerned how to see a comparison. Its shop, wholesaler, depot and factory could react to the same demand under different ordering rules, but the reviewer wanted their traces visible on a shared scale, with the ingredients of each order exposed.

The finished interface lets you select a week and stage to inspect its arithmetic. One busy shopping week, twelve crates instead of four, drives the starting chain's factory orders to a peak of 76.8 crates in week twelve.

Counting outstanding orders changes that result. The shop initially orders more, 14.5 rather than 12.5 crates: the higher demand forecast raises its desired amount on order, and the gap to that target adds a correction. As the simulation continues, the policy counts orders awaiting delivery, including supplier backlog. The factory peak drops to 38.1 in week nine.

Discovery 02 counts crates already ordered. The dotted traces retain the starting policy; these values are results of this teaching model.

The dotted starting-policy traces remain beside the changed run. The result and its timing can be compared directly. All of these quantities belong to the model's chosen rules, continuous crate quantities and 48-week window, with unlimited production upstream of the factory. They are not business forecasts.

The saved file and the visible sheet

Pocket Press takes a cover, manuscript and back cover and arranges an eight-page booklet on one A4 or US Letter sheet. It keeps a reading view alongside the print arrangement and can save printable output, an SVG sheet and editable source.

The reviewer asked for discoverable save actions, folding instructions and a way to reopen that source. The recorded browser checks downloaded the actual files, read back their geometry and text, and restored the manuscript from its saved source. Overflow blocks printable exports while leaving source saving available.

The supplied sample in Pocket Press's print-sheet view at a 900-pixel browser width. The unusual page order is for folding a single sheet into an eight-page book.

The print arrangement is deliberately unfamiliar: pages 5, 4, 3 and 2 upside down above 6, 7, 8 and 1. It is meant to become a book after cutting the central slit and folding the sheet.

Capturing the article's images found a different problem. At a 1,280-pixel browser width on 9 September, the print sheet extended beyond its preview area and was cropped at the top and bottom. The 900-pixel view shown here fits. Reading back a correctly arranged export had not tested that wider preview.

The paper result is still untested. All the checks described here were performed by agents or automation; no physical printer or fold was tried. Pocket Press supplies a numbered test sheet, ready for the part of the experiment that needs a sheet of paper.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

Local models are actually good now - playing with Qwen3.8-27B

Billie M — Wed, 09 Sep 2026 20:34:26 +0000

The 8-bit model loaded. It generated for more than half an hour. It also failed before its agent session finished.

The 4-bit version completed the same experiment, ran faster, and built the thing I liked most: a surprisingly complete cellular automata workbench called Lattice.

That changed the question I ask about large local models. “Can my laptop load this?” is easy to answer and not especially useful. The better question is whether the model can stay alive through a real agentic loop and produce something worth keeping.

On my 48 GB M4 Pro, 4-bit Qwen3.8-27B did.

I tested complete agent sessions, not isolated prompts

My first attempt at this comparison was wrong.

I asked the 4-bit, 6-bit, and 8-bit models to emit an entire web artifact in one long completion. That produced numbers, but it removed the part that made our earlier Local LLM Choice experiments interesting: the model was supposed to work through an agent harness. It needed to create a file, inspect it, run it, notice problems, and revise its own work.

“I feel like we’ve not done this right” was the most useful conclusion from that first pass. We withdrew it and reran the experiment properly.

For the replacement, every quantisation started Pi in a genuinely empty directory. Each received the same broad Billie-domain prompt, the same sampling settings, and up to 25 Pi iterations. There were no retries and no repairs after the run. The model had to choose its own project and carry it through the same working loop.

You can open the public comparison to use all three preserved artifacts and inspect their run receipts and manual evaluations.

The useful result is whether the agent finishes

Here is what happened:

Quantisation	Model files	Aggregate completion rate	Wall time	Peak MLX allocation	Outcome
4-bit	15.1 GB	12.47 tok/s	30m 20s	33.98 GB	Completed: Lattice
6-bit	21.9 GB	9.73 tok/s	25m 32s	36.10 GB	Completed: The Long Now
8-bit	28.6 GB	6.88 tok/s before failure	32m 10s	Not available	Partial: Metal OOM

These are whole-session measurements, not raw decode benchmarks. Pi’s working history grew through the run, and the aggregate completion rate includes prompt processing. The figures are useful for comparing these three matched sessions, but they should not be treated as universal model speeds.

Model-file size is not the same as memory use either. The 8-bit server exited before it could produce a comparable final MLX allocation receipt, so I have not invented one for the table.

Four-bit was surprisingly good

Lattice is not just a Game of Life grid with a play button. It has draw and erase tools, play and single-step controls, randomisation, undo, speed and grid settings, symmetry modes, named patterns, live population and generation figures, and a small history chart.

The 4-bit model chose the idea and built this complete cellular automata workbench through Pi on my laptop.

The broad prompt did not ask for a cellular automata tool. The model chose that idea, decided what the workbench should contain, built it, opened it, exercised parts of it, and made changes over several rounds.

I’m ridiculously impressed by it.

It is also real enough to have real defects. Some library patterns do not behave as described. A few die or remain static even though the model’s tests later called them correct. Four-way symmetry can clip a stamp near the edge of the rectangular board. The browser smoke test showed that the controls ran without throwing errors; it did not prove the automata were correct.

That distinction matters. Lattice is impressive because it is a coherent piece of software I can use and criticise, not because it passed a flattering demo.

Six-bit won the scorecard; four-bit won me

The 6-bit model built The Long Now, an interactive 5,000-year timeline with logarithmic, hybrid, and linear views. During the run it measured its first scale mapping, found that the maths did not support its own explanation, and replaced it with a hybrid scale.

That inspect-and-repair behaviour is exactly why using Pi mattered. The result earned 4/5 for interest, 3/5 for execution, and 4/5 for taste in the formal review. It also contains overlapping labels and several simplified or wrong historical claims.

The 4-bit artifact scored 4/5 for interest, 3/5 for execution, and 3/5 for taste. I still preferred it. A structured scorecard can help describe an artifact without replacing the judgement of the person actually using it.

The 8-bit artifact is a preserved partial result. It had already built a substantial timeline and repaired some behaviour when the fourteenth provider call failed with a Metal out-of-memory error. The page renders, but its date calculations have central bugs and its labels crowd together.

All three models loaded. Only two completed the agent run.

What I would run on this machine

I would start with 4-bit Qwen3.8-27B on this 48 GB Mac.

In this experiment it was about 28% faster than 6-bit by the whole-session aggregate measure. It left more headroom for the harness and everything else on the laptop, and it made my favourite artifact. That is a much more useful combination than choosing the largest quantisation that will technically initialise.

Six-bit is completely viable when I want to trade some speed and memory headroom for the more considered behaviour it showed in The Long Now. I would not start another long 8-bit Pi session on 48 GB without shortening the working history or narrowing the task.

This was one run per quantisation, not a leaderboard. I did not measure battery use, temperature, or repeated-run variance, and another seed or project could reverse the quality order.

But the line has moved. A local model at 4-bit chose its own idea, used an agent loop to build it on my laptop, and left me with software I wanted to keep playing with.

It did this at 4-bit. Damn, yeah.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

Free compute worth claiming in September 2026

Billie M — Fri, 04 Sep 2026 10:28:49 +0000

Free compute is easiest to misunderstand when the headline number is technically true.

A platform says it includes a million requests, five CPU-hours, or $200 of compute. That does not tell you whether usage stops at the limit, whether a card can be charged, whether the credit happens once, or whether the capacity will exist when you need it.

I rechecked the free-compute list for September against current provider documentation. This month produced fewer dramatic closures than August, but it exposed several numbers that needed correcting and a useful new pattern: infrastructure an agent can create before you even make an account.

Correct the old numbers first

Deno Deploy Free is smaller than it was in the August snapshot. The current plan lists 1 million requests, 20 GiB egress, 10 CPU-hours, 150 GiB-hours of memory, ten apps, no Sandbox or volume storage, and 1 GiB KV per month.

That replaces the previous 15 CPU-hours, 350 GiB-hours, 20 apps, and 1 GiB volume allowance. Deno does not expose a date for the change. Its changelog also warns that unverified organisations can receive restricted limits until a payment method is linked.

Four other corrections matter:

Freestyle VMs provides 200 vCPU-hours, 400 GiB memory-hours, and 60,000 GiB storage-hours per month. Those are monthly figures, not daily ones.
Browserless now documents two-minute sessions, alongside 1,000 monthly units and two concurrent browsers.
Firebase Authentication does not simply provide 50,000 MAU on Spark. Identity Platform on Spark is normally limited to 3,000 DAU, while the 50,000-MAU no-cost tier belongs to Identity Platform on the billing-enabled Blaze plan.
Axiom Personal currently includes three datasets rather than two, with 25 GB stored, 500 GB monthly ingest, and 10 GB-hours of query compute.

None of those is a glamorous new product launch. They are still more useful than carrying a wrong number into another month's list.

Know how the free usage ends

Cloudflare D1 now has an unusually clear answer. Since 1 September, a Free account that reaches 5 million rows read or 100,000 rows written in a day gets query errors until midnight UTC. Stored data remains intact.

That is a hard cap. It can break an application, but it cannot quietly become a query-overage bill.

Vercel Sandbox works the same way at the account level. Hobby includes five CPU-hours, 420 GB-hours of memory, 5,000 creations, 20 GB transfer, 15 GB of lifetime snapshots, 45-minute sessions, and ten concurrent sandboxes. Creation pauses after the allowance is exhausted.

Compare that with Google Cloud Run. Its 2 million requests, 180,000 vCPU-seconds, and 360,000 GiB-seconds are recurring free usage inside a billing account. Build, registry, storage, network, and excess runtime can still cost money.

Both are legitimately useful. They just fail differently.

Infrastructure before signup

Railway now allows an unauthenticated visitor to create a private site through Dev New or start a database. The build session lasts 60 minutes, the result remains claimable for 24 hours, anonymous workloads can be throttled, and agent building is capped at $3 of LLM credit.

Cloudflare temporary accounts provide a similar one-hour loop from the command line. An agent can deploy a Worker with supported resources, verify it, and return a claim link. If the claim is not completed within 60 minutes, the account and resources disappear.

Axiom's agent-created organisations bring temporary observability into the same pattern. An agent can create an unauthenticated US East organisation with 10 GB ingest and one GB-hour of query compute. It must be claimed within 24 hours.

These offers are not permanent free hosting. They are disposable proof environments with a handoff step. Claim links should be treated like credentials, and every unclaimed environment is designed to vanish.

A practical shortlist

For a small real VM, OCI Always Free remains the standout if Ampere capacity exists in your home region. The supported allowance is 1,500 OCPU-hours and 9,000 GB-hours per month, equivalent to 2 OCPUs and 12 GB RAM, plus two AMD micro instances and 200 GB combined boot and block storage.

For application code, Cloudflare Workers gives 100,000 requests per day with 10 ms CPU per HTTP request. Deno remains useful if its reduced allowance fits. Cloud Run is the better fit when you need a container and are willing to manage a billing-linked account.

For data, Neon remains a strong intermittent Postgres option with 100 CU-hours per project and scale-to-zero. Turso covers distributed SQLite with 5 GB storage, 500 million rows read, and 10 million rows written per month. D1 fits naturally beside Workers now that its stopping rule is explicit.

For disposable code execution, start with Vercel Sandbox, Upstash Box, or Freestyle. For browser execution, Cloudflare Browser Run provides ten minutes per day, Browserbase provides one hour per month, and Browserless provides short sessions from its unit pool.

For burst compute, Modal still provides $30 of recurring credit across CPU, GPU, notebooks, schedules, sandboxes, and web functions. Paperspace still lists capacity-dependent C4 and M4000 notebooks. Hugging Face ZeroGPU is much narrower: eligible personal accounts receive five shared GPU minutes per day for public Gradio Spaces.

Hosted model APIs remain harder to compare. Workers AI gives 10,000 Neurons per day, but some models require billing or prepaid credits. Gemini's free limits vary by model, project, account, and region. OpenRouter provides 50 free-model requests per day, rising to 1,000 after at least $10 of credit has been purchased.

The useful check is not just “how much is free?” Ask what happens at the edge: stop, sleep, delete, throttle, expire, or bill. September's changes make several of those answers clearer.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

The home server I finally stopped turning off

Billie M — Thu, 03 Sep 2026 09:47:19 +0000

The most useful thing my home server taught me was not how to install another Docker container. It was how quickly a problem stops belonging to one tidy layer.

A service can be running while DNS is wrong. Plex can work while the machine doing the transcoding cannot reach the storage. A reverse proxy can be configured correctly while the network around it is a mess. When it is your own server and you actually want to use it, those boundaries become your problem.

That is very different from the way many application-focused software-engineering jobs feel. You can spend years building applications without having to join Linux, storage, DNS, HTTPS and networking together yourself.

The experiments that kept getting turned off

Around the start of 2020, I got a Raspberry Pi and repeatedly installed Raspbian or Debian on it. I would add Sonarr, Radarr, maybe Prowlarr, a torrent client and Plex. Sometimes Pi-hole joined them.

There was no reverse proxy and I was not putting my own domains behind it. It was primitive, and I learnt something each time, but it never stuck, right? I would decide to play with it and eventually turn it off again.

The Pi proved that I could run these services. It did not give me infrastructure I depended on.

That changed in summer 2024. I had an old i5 desktop lying around, knew it worked and could connect drives to it easily. Why the hell not?

I installed OpenMediaVault and spent the next two or three months building the setup out. Docker-managed services were joined by Traefik as a reverse proxy, Tailscale, proper DNS and network sharing.

The useful result was a repeatable path for a new service. I could put it behind HTTPS and decide whether it should be public or only reachable inside my network. The machine was no longer an experiment waiting to be unplugged.

A second machine made the lessons real

I also bought a separate OptiPlex with 4 GB of RAM and installed Debian. Its main job was Plex Pass transcoding, reading media over the network from storage attached to the OpenMediaVault machine.

That small decision forced several pieces to work together. The OptiPlex needed the network share. Plex needed to read the right files. Deployment now covered two Linux machines rather than one. Running another Pi-hole there also gave me two DNS servers.

None of this was exotic. That was precisely why it was useful. These were ordinary operational problems with an outcome I cared about: I wanted my own services to work.

The failure that taught me to stop

I did not keep every layer.

That same summer, I tried turning an old laptop into my router with OpenWrt. It kept dropping out, which meant I was repeatedly taking down my own internet while trying to learn the rest of the server.

Eventually I bought a router.

The lesson was not that I should keep going until I became better at OpenWrt. It was that you need to know when to just not do it yourself. I reached the point where I thought: “I just want something that works. I’m going to stop trying to overcomplicate it. I’m just going to make it work.”

That judgement matters as much as knowing how to add another service. A home server gives you a place to learn across layers; it does not require you to own every layer.

It is not free either. It uses energy. Plex Pass costs money, as can a VPN or another service. Sometimes the server is down when you just want to watch a film. Self-hosting will cause a fucking headache.

What are you going to do, right? I still think it is worth it. I use the result all the time, and the problems have given me practical reasons to understand Docker, Linux, networking, storage and operations together.

The next change was moving the setup onto a different desktop and Proxmox. That is another part of the story.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

How I use scheduled Codex jobs to build daily reports

Billie M — Thu, 06 Aug 2026 09:14:22 +0000

Most of my analytics job should not be done by an LLM.

The source metrics, dates and repeatable transformations should stay exact. I used to think that meant the whole scheduled job should be left to deterministic code, and I still kind of agree.

What changed my mind was not asking a model to calculate the report. It was putting a scheduled Codex job around reliable tools: run them, inspect their result, apply a small amount of bounded judgement, and leave behind an HTML artefact that explains what happened.

I now use that shape for two daily reports. One is mostly analytics. The other has a more editorial middle. The useful boundary is similar in both.

Keep the hard boundary boring

My billiem-analytics project collects website visitors, edge traffic, Google Search Console, DEV and Hashnode into dated local snapshots.

Those sources do not expose interchangeable numbers. Some are daily flows. DEV and Hashnode provide cumulative publishing counters. A real zero is different from an unavailable provider, missing configuration or failed collection.

The deterministic code owns those distinctions. It rebuilds the private dashboard and keeps the reporting periods consistent. Codex does not get to smooth over a missing source or turn an unreliable metric into a reliable one.

That is important because the final report is meant to be inspected, not merely produced. If one provider failed, I want that state to survive all the way to the page.

Give the model the awkward work around the edges

The scheduled job handles the surrounding work: run the existing commands, inspect their output, follow a bounded recovery rule and decide how to present the result.

That is a small role in the analytics workflow. Founder Brief gives the model more to do.

There, a Python collector gathers and ranks candidate material into an editorial packet. The scheduled run reads the packet, checks the strongest sources and useful discussion branches, rejects weak or promotional material, and writes a short briefing. Candidate IDs and validation keep the result connected to the collected evidence.

The judgement is real but limited. A fixed ranking can decide what to inspect first; it cannot comfortably decide whether an anecdote is useful, whether two observations form a pattern, or whether a source gap makes a conclusion too strong.

Codex can help with those decisions against written editorial rules. It still cannot guarantee access to a site. Authentication, access controls, rate limits and format changes remain actual boundaries. Flexibility is not the same as a scraper that can never break.

The report is what made the automation useful

Both jobs end in the same deliberately plain way: just chuck it on an HTML file.

That gives me a stable artefact instead of a chat transcript or terminal session I need to reconstruct. Dates, source states, comparisons and caveats are together in a form I can reopen.

Before the analytics report, checking the same picture meant opening several browser windows and lining up different periods myself. It was painful enough that I often did not bother. Now I get the nice graphs and the consistent dates in one private view.

That consolidation made a quiet period without publishing visible across the sources. It was not a surprising new metric. The useful part was finally being able to see the existing information together.

I also added the report to Raycast. Typing analytics opens it in Chrome and regenerates it as appropriate. That tiny access path matters more than it sounds: I am actually opening the report rather than deciding that a manual Search Console session can wait.

Recovery has to remain visible

The analytics job includes one narrow recovery rule. A sandboxed DNS or Keychain failure should be retried with the correct local permissions before the provider is declared broken. After that retry, every provider still receives its own explicit state.

This is useful orchestration, not a claim that the system heals itself. A local scheduled job can miss its time when the Mac is asleep or offline. Credentials expire. Providers change. Prompts can be wrong.

The model can respond to a known operational wrinkle without hiding a genuine failure behind a confident summary. That is the line I care about.

Tokens feel cheap enough to me that this extra layer is worth trying, and it does not need a frontier model. If a cheap model can wrap reliable code, handle a known failure path and occasionally surface something the fixed report would miss, why wouldn't I use it?

I have not arrived at the conclusion that every scheduled task needs an LLM. Plenty still need a plain scheduler and a script. The pattern works for me when the exact work stays exact, the judgement stays bounded, and the final artefact makes the whole run inspectable.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

The LLM was better at building a solver than playing the game

Billie M — Tue, 04 Aug 2026 09:47:21 +0000

I started this project because an LLM annoyed me.

I gave a very strong model 322, a small Dota 2 drafting game. The choices looked like the kind of work a computer should enjoy: repeated packs of players and heroes, visible ratings, familiarity scores, chemistry, rerolls and a simulated tournament at the end.

I was disappointed by how well the LLM did. I am not a Dota expert, and I had only started watching it occasionally again during the previous six months or year. I still seemed to be doing better.

The interesting engineering question was not how to write a longer prompt. It was how to replace the card-by-card language-model judgement with a deterministic policy, then test that policy without confusing improvement with luck.

A stochastic benchmark needs shared randomness

The browser history gave us a useful irritation and almost no reliable comparison.

My earlier manual record contained 50 runs with a 14% title rate. The LLM won once in nine attempts. Putting 14% beside 11% looks temptingly quantitative, but the random offers, rejected packs and opponent fields were not preserved. The samples were small, unpaired and produced under different choices.

That is not a model benchmark. It is a reason to build one.

The offline solver generated every random choice from indexed tapes. Policy A and policy B received the same player offers, hero samples, field candidates and tournament randomness for a given episode. We could then compare the paired result: did the new policy win this exact episode where the old policy lost it?

This is the common-random-numbers idea in a practical form. Sharing the luck removes a large amount of noise that has nothing to do with the policy change.

Keep the simulator separate from the policy

Before evaluating a strategy, we reproduced the game.

The public client and seven data files were frozen with SHA-256 hashes. Draft legality, automatic hero allocation, chemistry, scoring and the tournament were ported into a deterministic Python engine. Automatic allocation evaluates all 120 player-to-hero permutations, so reproducing that detail mattered.

The engine also kept an important semantic boundary. A finished roster has an exact score under the copied rules. An unfinished draft does not. A policy can estimate the future value of a player, hero or reroll, but that partial-state estimate is not made exact by giving it several decimal places.

Keeping the simulator authoritative meant we could change policies without changing what success meant.

The redraw budget is part of the experiment

Opponent fields introduced a slightly odd control problem. If a solver can redraw for free forever, “find an easier field” eventually dominates every other decision.

We declared three finite budgets instead:

K=1 accepts the first opponent field.
K=4 selects from four fields.
K=16 selects from sixteen fields.

The budgets were nested. The first field in K=1 was also the first field in K=4 and K=16; the first four were shared too. Policies could be compared at each budget without quietly receiving different field draws.

This was a small design choice with a large effect on the claim. A title rate without the field budget would not describe a reproducible policy.

Make the final test expensive to touch

The solver could be improved and improved and improved. That was satisfying, but it created the usual risk: every time a result influences the next change, that result has become part of training.

We separated train, validation and test tapes. Candidate policies first went through successive halving on shared training episodes. Weak candidates stopped early; survivors received more budget. The selected candidate then needed to pass a fresh validation gate before the test partition could be opened.

The gate required positive title-rate results, no meaningful top-four or top-eight regression, zero failures, deterministic replay and acceptable runtime. Once the final test started, policy code, features, model bytes, parameters, seeds and episode counts were frozen.

The controls themselves still needed scrutiny. An independent audit found that an early replay check compared duplicate in-memory runs rather than the public replay path, and that the first runtime gate reused warm policy caches. Both were repaired before the production claim. The audit separately recomputed the final statistics from the raw logs.

The inconvenience was deliberate. It stopped “one more tweak” from leaking the answer back into the candidate.

A small deterministic model was enough

The final test compared four generations of policy on 10,000 paired episodes at each field budget. Across all policy and budget combinations, that was 120,000 outcomes with zero failures.

At K=16 the progression was:

Policy	Title rate
Pick the highest player rating	2.30%
Hand-written heuristic	14.77%
Assignment and chemistry components	22.33%
Frozen 37-feature value model	27.45%

The final value model was ridge-linear, deterministic and trained offline on 8,511 action rows. It used features for role-feasible future strength, partial hero allocation, current and potential chemistry, familiarity, draft stage and remaining rerolls. It did not call an LLM while playing.

Against the previous component policy, its K=16 title improvement was +5.12 percentage points with a paired 95% interval from +4.24 to +6.00. Top-four and top-eight results improved at every budget too.

The complete draft loop took a median 47.1 milliseconds with a cold model build. That was roughly 1.8 times the component policy's latency, and the runtime policy made no large-model request for any offer.

Put the LLM around the decision loop

We try to solve everything with LLMs now, and we do not necessarily need to.

For 322, the runtime decision-maker became ordinary deterministic code. The LLM was much more useful around it: inspecting the browser game, reconstructing mechanics, implementing the engine, proposing policies, running controlled experiments, auditing weak controls and producing visualisations that made the improvement legible.

The result was quite a cool little statistical project. The useful boundary was not “LLMs are bad at games.” It was more specific: repeated numeric decisions with a reproducible state and measurable outcome did not need an LLM in the hot path.

If I continued the project, I would use the LLM to choose and build the next experiment. I would leave the next card choice to the solver.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

Free compute worth claiming in August 2026

Billie M — Mon, 03 Aug 2026 11:26:44 +0000

A monthly free-compute list is only useful if it is willing to delete things.

Between my July snapshot and 3 August, GitHub Models disappeared, SageMaker Studio Lab closed to new users, and the current Hugging Face documentation stopped supporting the broad free CPU Spaces claim I had made. Paperspace, meanwhile, turned up with documented free M4000 notebook access. Neon put Functions and Object Storage into a free beta. Managed agent runtime and browser automation became harder to treat as side notes.

I also had to correct my own July guide. GitHub had already announced that Models would retire on 30 July, but I still described it as a recurring public preview on 10 July. That was wrong.

This is the useful August shortlist: what to remove, what changed, and which kind of free allowance fits a particular side project. It is documentation-backed rather than a claim that I opened and tested every account. Capacity, regions, billing checks, data-use terms, and unpublished guardrails still matter.

Remove these from the old shortlist

GitHub Models retired completely, including its playground, catalogue, inference API, and BYOK endpoints. It is no longer a free model API.

SageMaker Studio Lab closed to new customers on 30 July. Existing users retain free sessions with 15 GB storage, 16 GB RAM, up to eight CPU hours or four GPU hours per day, subject to capacity. A new reader cannot claim it.

Hugging Face Spaces needs a narrower description. Normal Gradio and Docker compute Spaces are gated behind paid plans in the current documentation. A free personal account can still host up to two Gradio ZeroGPU Spaces, but that is queued public-demo GPU capacity rather than a free Linux box.

One more correction is smaller but worth keeping: Axiom Personal currently includes two datasets, not the three I listed in July.

The August additions worth knowing about

A genuinely free GPU notebook appeared

Paperspace Notebooks now documents C4 CPU and M4000 GPU machines on its Free Gradient plan. It includes 5 GB storage and permits one running notebook at a time. A free-machine session can last up to six hours.

That does not mean guaranteed GPU hours. Capacity may queue, and there is no published monthly-hour entitlement. It is useful shared notebook access, not a persistent GPU server.

Neon temporarily became more than Postgres

Neon Functions and Object Storage are available on the Free plan during beta. The current offer is restricted to us-east-2, retains logs for three days, and uses unpublished rate and usage guardrails. AI Gateway is not included on Free.

That makes Neon an interesting temporary full-stack backend, but a beta is not a promise. The underlying free Postgres plan remains easier to reason about: up to 100 projects with 100 CU-hours and 0.5 GB storage per project, plus scale-to-zero after five minutes.

Agent compute now has several shapes

Google Agent Engine is listed with 180,000 vCPU-seconds and 360,000 GiB-seconds per month. Billing must be enabled. The table does not establish that Code Execution sandboxes share this allowance, so I would use the claim narrowly: managed agent runtime.

Upstash Box provides ten concurrent boxes and five active CPU-hours each month. A box has 2 vCPU, 4 GB RAM, and 5 GB disk, freezes after an idle hour, and currently runs only in us-east-1.

Cloudflare temporary accounts solve a different problem. An unauthenticated agent can deploy a Worker and supported resources with wrangler deploy --temporary, verify the result, and return a claim URL. The account disappears after 60 minutes if it is not claimed. This is throwaway deployment compute, not a permanent anonymous account.

Browser automation is now its own free-compute category

Cloudflare Browser Run gives ten browser minutes per day and three concurrent browsers. Cloudflare's general-purpose Sandbox SDK is separate and has no Workers Free allocation.

Browserbase includes one browser hour, three concurrent browsers, three agent runs, and 1,000 each of Search and Fetch uses per month. Sessions stop after 15 minutes.

Browserless uses a 1,000-unit monthly pool with two concurrent browsers and one-minute sessions. One unit covers up to 30 seconds, while proxy and CAPTCHA work can consume more. It does not translate cleanly into a neat number of hours.

Pick by the way the allowance can fail

The word “free” hides several different products. The failure mode matters more than the headline number.

For a persistent Linux VM

OCI Always Free is still the first claim to try. The current supported allocation is 1,500 Ampere A1 OCPU-hours and 9,000 GB-hours per month, equivalent to 2 OCPUs and 12 GB RAM. The tenancy also gets 200 GB combined boot and block storage plus 10 TB monthly outbound transfer.

The catches are practical: home-region capacity can be unavailable, and idle instances can be reclaimed. AWS EC2 T4g is useful during 2026, but its 750 aggregate t4g.small hours per month are a promotion ending on 31 December rather than durable infrastructure.

For functions and containers

Cloudflare Workers has a recurring hard cap of 100,000 requests per day, 10 ms CPU per HTTP request, and 128 MB memory. Static assets do not consume the dynamic request allowance.

Deno Deploy publishes a broader monthly cap: 1 million requests, 20 GB egress, 15 CPU-hours, 350 GB-hours memory, 20 apps, 1 GiB volume storage, and 1 GiB KV storage. The old Deploy Classic migration deadline has passed, and projects did not transfer automatically.

Google Cloud Run gives request-based services 2 million requests, 180,000 vCPU-seconds, and 360,000 GiB-seconds monthly. It is attached to billing, so registry, build, network, storage, or overage usage can still charge.

For data and product plumbing

Turso is the cleaner hard-capped SQLite-shaped option: 100 databases, 5 GB storage, 500 million rows read, and 10 million rows written per month. Requests stop at quota rather than becoming an invoice.

Cloudflare D1 fits naturally when the application already lives on Workers. The free allocation is ten databases, 500 MB each, 5 GB total, 5 million rows read and 100,000 rows written per day.

Upstash covers Redis, QStash, Workflow, Vector, and preview Search under separate free quotas. Cloudflare R2 provides 10 GB-month Standard storage, 1 million Class A operations, 10 million Class B operations, and free egress, but enabling it requires account checkout.

For GPU and hosted inference

Modal Starter gives $30 of recurring compute credit for serverless CPU, GPU, notebooks, schedules, sandboxes, and web functions. Lightning AI Free gives 15 credits per month plus one active CPU Studio that restarts every four hours. The GPU time those credits buy varies with the selected hardware and current rates.

Google Colab remains shared and dynamic, with no stable hardware or quota promise. Sessions can run for up to 12 hours depending on usage and availability. Paperspace is now the more concrete free M4000 notebook claim, while ZeroGPU is for public Gradio demos.

Hosted APIs are another category again. Cloudflare Workers AI stops a Free account after 10,000 Neurons per day. Gemini has model-dependent free pricing and may use free-tier content to improve Google products. OpenRouter Free gives 50 free-model requests per day unless the account has purchased credit.

FreeInference is useful only with its privacy boundary visible: its terms allow prompts and responses to be logged and anonymised derived data to be released. Never send it secrets, private code, or personal data.

Three stacks I would still assemble from the list

For a small real server: OCI for the VM, Cloudflare for DNS, CDN, and TLS, R2 or Tigris for objects, Neon or Aiven for Postgres, Upstash for queues and Redis, Resend for mail, and Grafana Cloud plus Sentry for visibility.

For a no-server product: Cloudflare Workers and static assets, D1 or Neon, R2, Queues or Workflows, Turnstile, Clerk or AuthKit, and Workers AI.

For an AI demo: Paperspace or Colab for notebook work, Modal for repeatable bursts, ZeroGPU for a public Gradio surface, and Workers AI, Gemini, Groq, or OpenRouter for hosted inference.

The full August guide on billiem.uk keeps the broader directory, including email, auth, observability, CI, storage, startup programmes, and academic credits.

In 24 days, one model API disappeared, one notebook closed to new users, and a supposed free hosting offer became much narrower. The next version may remove as much as it adds. That is fine. A dated guide is more useful when it is willing to get shorter.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

I let Codex build and test my first native Mac app

Billie M — Mon, 03 Aug 2026 11:19:01 +0000

The first public Billie Flow build launched, stayed alive, passed its signature check and could find its source and models. A replacement install still left a new user with no Settings window, which meant there was no visible way to install the local worker.

The process was healthy. The app was unusable.

That gap is the part of my local dictation experiment that I find most useful. I had let Codex work well beyond a repository: it built my first native Mac app, installed it, operated the macOS permission surfaces, exercised physical audio and inspected the clipboard. The interesting failures only appeared because it kept going after the code checks were green.

Testing the installed app changed the work

I started Billie Flow because I use Wispr Flow and wondered whether I could make the useful loop run locally. What led me to it was just curiosity. Could I really?

It was never meant to become a replacement. Wispr Flow gives me enough value that I still use it. I wanted to see whether a personal version could be made, and then I became much more interested in how involved I let Codex become.

In 5.6 it could literally write the thing, build the thing, install the dependencies for the thing, test the thing. For this project, "test" eventually meant opening the installed Swift app, working through microphone permissions with Computer Use, holding the global shortcut and checking whether the resulting text reached the clipboard.

At one point I was lying there waiting for it to work away when speech started coming out of my speakers. Billie Flow recorded it and transcribed it. I do not know what produced that speech, so I am not going to turn the observation into a tidier technical claim. I remember thinking that 5.5 would not have taken the same initiative, but that is an impression rather than a controlled comparison.

The global shortcut records only while held; releasing it submits the temporary audio for local processing.

The physical run eventually finished with non-empty text on the clipboard, a healthy app and worker, no new crash and no temporary recording left behind.

This is the visible end state from the installed app after local recognition and light cleanup completed.

The expected model was not the useful one

The app work started with a model decision. I had an audio-capable Gemma 12B route in my head, but I ran the same 35.3-second voice memo through several local recognition paths before building around that assumption.

I also kept speech recognition separate from cleanup. Otherwise a cleanup model could make a transcript sound polished while preserving the important names the recogniser had already got wrong.

Gemma completed the memo in 258.79 seconds and drifted around an overlapping chunk. MLX Whisper large-v3-turbo produced the most useful recognition in about 3.68 seconds, then Qwen2.5 1.5B ran the selected light-cleanup pass in about 0.62 seconds.

The model I first had in my head was not the right answer. Two smaller models produced the quicker and more useful result for this app. That is deliberately narrow: it was one memo on one machine, and every recognition path still missed at least one important project term. The full Billie Flow model analysis contains the other branches, timings and vocabulary failures.

Three different kinds of green failure

The absent Settings window was not the only thing the replacement-install pass found.

Cleanup was silently falling back to raw recognition because the pinned MLX library was receiving an obsolete argument. The worker request returned success, but the UI was claiming cleanup that had not happened. A final setup check could also exit before the app registered completion and leave setup stuck at verification.

Earlier microphone tests had exposed an actor-isolation crash on the first audio buffer, then a format mismatch while writing the converted WAV. These were not five versions of the same bug. They crossed Swift concurrency, Core Audio, a pinned Python dependency, process lifecycle and visible macOS presentation.

Codex kept following each failure into the layer that produced it. The release gate now checks for an actual first-launch window and warning-free cleanup instead of treating a living process or successful response as sufficient evidence.

A public proof of concept, with a blunt boundary

The source and install-tested v0.2.1 build are public. I want Billie Flow to be usable should you want to, but I do not really care if anyone does.

Nothing large starts until Install is chosen; the disclosure also limits the proof of concept to English speech on Apple Silicon and macOS 26.

The boundary is explicit: Apple Silicon, macOS 26, English recognition and about 3.5 GB of consented runtime and model setup. Inference is local after setup, but setup still downloads Python dependencies and fixed models. The app is ad-hoc signed and unnotarised, with no updater, App Store release, compatibility promise or support plan. I am definitely not getting an Apple Developer Programme membership for it at this point.

Billie Flow does not establish that everybody should rebuild the software they already use. It shows that a surprisingly good personal version of this loop can now be made quickly. What I am going to remember is still the oddest part: lying there while Codex decided it needed to test the microphone and speech started coming out of my speakers. It was really really impressive.

Want to talk about something I’ve written or built? Get in touch.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.

A rotation changed my embedding plot, not its neighbours

Billie M — Tue, 14 Jul 2026 15:18:33 +0000

One switch in my embedding animation makes the plot look substantially different while preserving every top-five cosine neighbour.

I did not start with that as a teaching point. I had been playing with embeddings while learning about AI, first by using them to modulate sound and then by embedding code and looking for similar code. PCA and UMAP projections seemed pretty cool. At some point the next thought just popped into my head: “Huh, it'd be cool to try and animate embeddings rather than just flatten them.”

I also thought, “Oh, this is just not going to work.”

It worked, which surprised me.

The changing picture

The working Embedding Tours instrument has a deterministic eight-dimensional synthetic dataset and 180 short phrases embedded into 384 dimensions with MiniLM. You can move through raw coordinate pairs, pairs of principal components, or a seeded grand tour through projection planes that are not aligned to the raw axes.

Those are not three names for the same thing. The raw tour cycles through coordinate pairs. PCA puts the highest-variance directions first, although that does not make them the true semantic axes. The grand tour moves through more general planes.

Every frame is still a two-dimensional projection. Motion gives me more partial views; it does not recover all the information lost when hundreds of dimensions are put on a flat screen. It is also just really satisfying to watch the structure move.

The raw-coordinate mode adds a more pointed comparison. Its basis switch applies the same orthogonal transformation to the whole dataset. Individual coordinates change and the raw plot can look very different. Dot products, lengths, distances and cosines do not change under that shared rotation.

The raw projection changes after the basis switch; cosine-neighbour geometry remains fixed to floating-point precision.

In this run, the measured similarity drift is 5.55e-16 and all top-five neighbours are retained. That is visible evidence for the narrow claim I wanted the switch to make. It does not prove that every transformation preserves an embedding, and it does not mean individual axes can never be useful. It shows that the cosine-neighbour structure does not uniquely privilege the raw coordinates I happened to receive from the model.

That limitation matters when interpreting embedding coordinates. A very different-looking coordinate tour can represent the same neighbour geometry.

I had walked into an existing idea

My first version just moved from dimensions 1 and 2 towards dimensions 2 and 3, then kept going. I later learned that this belongs to an established family of visualisations called tours.

Daniel Asimov described the grand tour in 1985. The tourr project gives the useful distinction: cycling through axis-aligned views is a little tour, while a grand tour moves through general projection planes. Distill used a grand tour for neural-network activations, and the recent dtour project has a much more complete browser interface for steering through high-dimensional data.

I had not invented a new visualisation technique. I had kind of independently arrived at a known idea, or at least the entrance to one. That was probably the coolest part.

The instrument stayed brief: two datasets, three projection modes, the basis comparison, selection and playback controls. I do not expect a researcher to discover a new technique in it. Maybe it helps someone like me who is still learning and finds embeddings confusing. Maybe it does not. Maybe it is just a cool experiment.

This article was adapted with AI assistance from an original article on billiem.uk. The original article was reviewed before publication.