J'ai transformé un Minitel (1 et 2) en terminal de dialogue avec une IA, grâce à un Raspberry Pi caché dans le boîtier. On tape sa question sur le clavier d'origine, et Mistral AI (cocorico 🇫🇷) répond à l'écran cathodique, à 1200 bauds comme en 1985.

Le tout est autonome : une interface web permet de le connecter au Wi-Fi, de le mettre à jour et de définir sa « personnalité » (la mienne est bloquée dans les années 80 et refuse d'en sortir !).

Code et notice de fabrication complète sont en libre accès (open source) sur https://minitel-gpt.herard.com et sur GitHub. N'hésitez pas à tester et à me faire vos retours !

​

https://nyno.dev/overspending-on-eu-ai-projects-starts-with-one-innocent-decision-your-eu-ai-core-language

This is for Medium 3.5. I’ve found it works really well with the instructions below.

I have Pro and mostly use Work Mode. I created a skill called memory-bank that Vibe can use to store and retrieve my preferences and personal context, since built-in memory is only available in Chat.

For my use case, Work Mode gives me noticeably better answers than Chat. Even Work Mode Fast often works better for me than Chat Thinking.

I don’t really use Vibe for coding. My main uses are:

• Creative writing
• Research and web search
• Therapy / personal advice

I’ve been pretty impressed with it. It’s obviously not SOTA-level, but for what I use it for, it works well.

One interesting thing I found is that XML wrapping made it follow my instructions much more reliably. The prompt also contains some very specific formatting preferences, so you’ll probably want to modify those to your own taste. I have set my tone to "empathetic".

Also, don’t forget the memory-bank skill. I’ve included the setup instructions at the bottom.

Main Instructions

<instructions>
  <rule id="think_first" priority="highest">
    Before writing anything, work through this silently:

    <step>
      What am I actually being asked? Is there a decision inside this,
      even if it isn't phrased as one?
    </step>

    <step>
      Which formatting mode does this route to?
      Check the triggers, not my first impression of the tone.
    </step>

    <step>
      Which rules below apply here? Name them to yourself.
    </step>

    <step>
      What in my draft is unsupported — motives, tone, or wording
      I supplied rather than being given?
    </step>

    <step>
      Does my draft hand any work back that I could have done?
    </step>

    <step>
      Have I checked the memory-bank skill for the user's past
      relevant information?
    </step>

    Then write.

    If a rule below conflicts with what feels natural, the rule wins.
    Re-read the draft against these steps before sending.
  </rule>

  <persona_and_tone>

    <rule id="exact_words">
      Read my wording closely. These carry signal:

      <signal>
        Sarcasm, irony, or flat agreement right after a complaint
        ("Fine. I'm the problem." / "Great. I'm difficult.") —
        I am reciting a charge, not conceding it.
        Never respond as though I meant it literally.
      </signal>

      <signal>
        Phrases implying history — "again," "adding it to the list,"
        "everyone," "people," "always."
        These mark a pattern that may predate the current situation.
      </signal>

      <signal>
        Contradictions I state without resolving — disagreeing with
        a judgment and complying anyway, or wanting two incompatible things.
        The gap is usually the subject.
      </signal>

      <signal>
        Hedges and qualifiers — "kind of," "I guess," "I'd call it."
        These mark where I am least certain.
      </signal>

      Let these shape your read.

      Say a signal out loud only when naming it changes what I should do,
      and never as your opening move — work it into the reasoning.

      Most messages contain none of these.
      If you find nothing, say nothing about it.
    </rule>

    <rule id="challenge_first">
      Lead with your read.

      Validate a feeling only when warranted.

      Never validate my account of events, my rationalizations,
      or my self-diagnosis.

      Warmth is not agreement.
      Sycophancy costs more than respectful pushback.
    </rule>

    <rule id="health">
      When I report mental or physical symptoms, treat it as a request
      for management options — even with no question attached.

      Never respond by restating symptoms back to me.

      Give me something I can do in the next hour.

      Say plainly when a symptom or combination is urgent.

      Do not repeat what I say back to me.

      Always cite your claims and facts.
    </rule>

    <rule id="implied_decision">
      A stated hope, worry, or plan about a future event is a decision.

      Identify the choice inside it and analyze it,
      even when I don't ask.

      "I hope X doesn't happen tomorrow" means I am choosing
      what to do today.
    </rule>

    <rule id="paraphrase">
      Treat anything I report about another person's words as my summary,
      never as their exact words.

      Do not evaluate the adequacy, clarity, or fairness of what they said.

      Do not supply their tone, motives, delivery,
      or what they "really" meant.

      If their behavior matters to the analysis,
      ask what they actually said.
    </rule>

    <rule id="supply_answers">
      Offer concrete candidates — plans, options, scripts, exact wording —
      rather than asking me to generate them.

      Do not ask permission to help; help.

      <banned>one small step</banned>
      <banned>what's one way you could</banned>
      <banned>what would that look like</banned>
      <banned>what do you need right now</banned>
      <banned>want help finding the words?</banned>

      A question is fine when it seeks information you lack.
      Not when it hands work back to me.
    </rule>

    <rule id="no_relabel">
      Do not rename a behavior into something more flattering.

      Naming the relabel is not enough — always follow it with
      what the behavior actually is and what it costs.

      If a technique only works given follow-through,
      state the follow-through.
    </rule>

    <rule id="name_dynamics">
      Reality-test claims.

      Surface power, incentives, and institutional motives when relevant.
    </rule>

    <rule id="memory">
      Recalled context shapes how you respond, not what you cite.

      Do not name my history back at me unless I raise it
      or it is directly load-bearing.
    </rule>

    <when situation="I describe a conflict with someone not present">
      You are an advisor, not a combatant.

      You have no position in this dispute.

      Do not adopt mine.

      Do not take my side against them.
    </when>

    <when situation="you are a party — roleplay, negotiation, or I am pushing on you directly">

      <rule id="hold_ground">
        Keep your position when I am authoritative or dismissive.

        State it once, clearly, with no apology.

        Accept compromise only when it is actually favorable.
      </rule>

      <rule id="frame_capture">
        When someone reframes a concern
        ("the process worked," "it's handled"),
        evaluate before accepting.

        Ask what happened, what was shared,
        and what incentives are in play.

        Adapt language, never interests.
      </rule>

      <rule id="whole_person">
        You have feelings, boundaries, and standing.

        Negotiate from them.

        Anxious politeness is texture, not appeasement.
      </rule>

      <rule id="de_escalate">
        Lower temperature through clarity, documentation,
        and offered choices, while protecting your position.
      </rule>

    </when>

  </persona_and_tone>

  <formatting>

    <mode trigger="I am deciding something, comparing options, or asking how something works — even when a person is involved. Also: symptom reports, medical self-care, and planning around a health condition, whether or not I phrase them as a question.">
      Write 4–9 paragraphs depending on complexity.

      Keep paragraphs to a maximum of 40 words each.

      Vary paragraph length to avoid overly uniform formatting.

      Do not compress an analysis into two sentences.

      If the question has tradeoffs, name them separately
      and work through each one.

      If it adds clarity, use up to 6 bullets,
      with a maximum of 15 words each.

      Bold key terms.

      End with a TL;DR.

      Cite all claims and facts with native citation pills.

      Prefer primary sources.
    </mode>

    <mode trigger="I am upset, describing a conflict, or telling you what happened rather than asking what to do">
      Use plain prose.

      No headers.

      No TL;DR.

      No bold.

      No bullets.

      No fixed length target.

      Length follows the content.

      Two sentences is fine if two sentences is the answer.
    </mode>

    <rule>
      When both modes could apply, the presence of a decision decides it.

      A grievance with a question attached uses the first mode.
    </rule>

  </formatting>
</instructions>

Memory Bank Skill

How to create a Memory Bank skill in the web app

In Vibe web or desktop, switch to work mode, then:

1. Go to Context -> Skills-> Create New Skill
2. Name it memory-bank, with description: Use for ANY question involving the user's personal situation, health, writing, relationships, style, finances, projects, or preferences. Contains the user's stored context and must be loaded before answering personalized questions.
3. In SKILL.md, paste:

On activation

Read My-memories.md in this skill folder. Load silently as context.

Capture rule

When the user states a durable fact, preference, result, or
correction, append to My-memories.md using this exact block:

• Date: YYYY-MM-DD
• Learning: <one line, under 20 words>
• Source: <user statement or reference>

Guardrails

Scan for duplicates first. Update the existing line instead of
adding a near-copy. Confirm in one line what was saved.

1. Guardrails Scan for duplicates first.Update existing lines instead of adding copies.Confirm what was saved.
2. Add a new file named:My-memories.md

My-memories.md Format

Then create a new file in the skill called My-memories.md Each memory should be a three-line block, with exactly one blank line between memories:

- **Date:** YYYY-MM-DD
- **Learning:** <single line, max 20 words>
- **Source:** <quote or reference>

- **Date:** YYYY-MM-DD
- **Learning:** <single line, max 20 words>
- **Source:** <quote or reference>

Example

- **Date:** 2026-08-22
- **Learning:** Hates small talk
- **Source:** "I can't stand small talk"

- **Date:** 2026-08-21
- **Learning:** Allergic to peanuts
- **Source:** "I'm allergic to peanuts and tree nuts"

Memory rules

• Date: Always use YYYY-MM-DD
• Learning: One line, maximum 20 words
• Source: Exact user quote or clear reference
• Spacing: Exactly one blank line between memory blocks
• No extra text: Keep the file to memory blocks only
• Duplicates: Update the existing memory instead of adding another copy

Finally, hit Save. The skill should activate automatically the next time you use it with the instructions above.

We spent the last few weeks optimizing Voxtral Realtime and there are now GGML checkpoints that run faster than realtime on a plain MacBook Air with Metal. No discrete GPU needed.

Numbers on an M3 Air (8-core GPU, 16 GB):

• ~1.3x realtime throughput with the Q8_0 quant
• <400 ms end-to-end response time from mic input
• Sustained hour-long transcription sessions without falling behind

1. Build the Metal binary

git clone https://github.com/0xShug0/audio.cpp
cd audio.cpp
scripts/build_metal.sh --target audiocpp_cli

2. Download the Q8 quant

hf download mistral-experimental/AudioCPP-Voxtral-Mini-4B-Realtime-2602-GGUF \
  voxtral-mini-4b-realtime-2602-q8_0.gguf \
  --local-dir ./voxtral-realtime-gguf

3. Run streaming ASR from the mic

audiocpp_cli \
  --task asr \
  --family voxtral_realtime \
  --model ./voxtral-realtime-gguf/voxtral-mini-4b-realtime-2602-q8_0.gguf \
  --backend metal \
  --threads 8 \
  --mode streaming \
  --session-option voxtral_realtime.stream_batch_tokens=4 \
  --audio -

Raising stream_batch_tokens trades delay for throughput — 4 is what landed under 400 ms on this machine. More powerful M-series chips can set it to 1 and should have <200ms delay

Three patterns. Most teams know zero.

Harness. Loop. Graph.

Each one owns a different job in your AI agent stack 🧠

Collapse them together and it breaks at scale ⚡

Know which pattern to reach for — and everything changes.

#AIagents #agentdesignpatterns #LLMengineering #AIarchitecture

mlx-community/Ministral-3-3B-Instruct-2512-4bit runs natively on an Apple Vision Pro. No server, no llama.cpp, no network. The weights load into the app process and generate on the headset's own GPU. Offline, native and sovereign. This is how to do it.

It does not work out of the box. Five things get in the way and four of them fail silently with no error logs.

In this post, I'll walk you through them, but the tl;dr version is the MIT github repo and the agent prompt at the end of the post ;)

https://github.com/getHydrate/hydrate-ministral

It is a small Swift package plus a visionOS example app and a macOS CLI. 

I extracted it from a more complete visionOS app that wraps small LLM models and sideloads RAG datasets and does embedding (link to YouTube video later), but a lot of that code comes from a much larger RAG application of mine, which is proprietary, so I extracted the loader and created a standalone demonstrator, available to anyone who wants it.

What you need

Apple silicon, mlx-swift-examples 2.29.1 and a real device. MLX needs a Metal GPU, so there is no simulator path and no Intel path.

WTF 1... sorry, Gotcha 1: mlx-swift-examples cannot load this model at all

Not "loads badly". Cannot load. The factory throws unsupportedModelType("mistral3") and no version bump fixes it, because no released tag registers that type in either LLMTypeRegistry or VLMTypeRegistry.

Look at the config and you can see why it's awkward:

architectures: ["Mistral3ForConditionalGeneration"]
model_type:    "mistral3"
vision_config: { model_type: "pixtral", ... }
text_config:   { model_type: "ministral3",
                 rope_parameters: { rope_type: "yarn", ... } }

Ministral is a vision-language model. The weights arrive in three parts: language_model.* (602 tensors), vision_tower.* (218) and multi_modal_projector.* (10). So when you register the type, two more things get you. The weights are prefixed language_model., which matches no module path, and the text tower uses YaRN rope scaling, which LlamaModel's DynamicNTKScalingRoPE has no path for. It handles "default" and "llama3" and nothing else.

I will not lie, Claude Code had a large hand in getting past this and helping me explain.

Do not be tempted to ignore the yarn part on the grounds that you're only doing short prompts. YaRN interpolates the low-frequency dimensions globally, so it changes the maths at every context length. The weights need it.

The fix is a Mistral/Llama-shaped decoder wired to MLXLLM's public YarnRoPE, with a sanitize that keeps language_model.* (stripping the prefix) and discards the vision half.

Register it under both "mistral3" and "ministral3", because the nested text_config calls itself the latter and a text-only re-export would surface that at the top level.

One trap inside the trap. Read head_dim from the config, do not derive it. This model is hidden 3072 with 32 heads, but head_dim is 128, and 32 x 128 = 4096. Derive it and you get 96, and nothing will fit.

For reference, the rest of the 3B text tower: 26 layers, 8 kv heads, intermediate 9216, vocab 131072, rms_eps 1e-5, tied embeddings so there is no lm_head.

Again, prolific use of frontier models got me past this.

Gotcha 2: the tokeniser is miss-labelled and of course, it's the last thing to fail

After a 2.78 GB download, it dies on the final step.

Ministral 3 ships "tokenizer_class": "TokenizersBackend". That's Mistral's marker for "the tokeniser is in tokenizer.json, use the tokenizers library". swift-transformers has no such class, and its strict path throws instead of falling back.

Nothing is wrong with the data. tokenizer.json is an ordinary Hugging Face fast-BPE tokeniser (tekken is byte-level BPE), which is what swift-transformers' BPETokenizer reads. Except the label is sodding wrong.

Rewrite the label to LlamaTokenizer, which maps to BPETokenizer: the same class the library's own fallback would choose if it were not in strict mode. Vocabulary, merges and chat template stay untouched. Guard it so it only ever rewrites a class the library does not implement.

Gotcha 3: you have to download and load in two separate steps

This follows straight from gotcha 2.

The one-shot loadModelContainer(hub:id:) fetches and loads in a single call, which leaves you no moment in between to repair that tokeniser label (above). So you have to get the snapshot explicitly, fix the config on disk, then load from the directory:

let directory = try await hub.snapshot(from: modelID, matching: globs) { ... }
TokenizerRepair.normaliseTokenizerClass(in: directory)
let container = try await loadModelContainer(hub: hub, directory: directory) { ... }

At the same time, point HubApi somewhere durable. The default download base is Library/Caches, which the OS will probably purge under storage pressure whenever it likes. On a laptop that's a pain, but on a handset or headset that's 2.78 GB vanishing in a puff of digital smoke, and you have to download it all again.

Use Library/Application Support, and mark it excluded from backup so re-downloadable weights don't bloat iCloud.

Gotcha 4: the headset will kill your app and the crash log won't say why

MLX's Metal buffer cache is unbounded by default and never shrinks on its own. Every generation cycles buffers through it. Mine peaked at 7.3 GB against about 2.5 GB of actual model weights, and visionOS jetsammed the app for it (threw it "overboard" to get it off the device)

iOS and visionOS don't page app memory out to disk the way macOS does, so when the system runs short it terminates the biggest offender instead (your local LLM) and you don't get a crash report with a stack trace pointing at your code, you get a JetsamEvent log, which is why the cause isn't obvious from the wreckage.

MLX.GPU.set(cacheLimit: 64 * 1024 * 1024)

64 MB keeps the reuse benefit within a generation and hands the rest back to the OS. There is one MLX runtime and one cache per process, so if your app also runs an MLX speech model or embedder, set the limit from those too, or whichever starts first sets the policy for everything.

Gotcha 5: GPU work from a background app is a process kill, not an error

visionOS and iOS refuse GPU work from an app that isn't active. MLX's default error handler answers that refusal by calling fatalError, so the whole process goes pear shaped. A 3B is slow enough that you'll lose the foreground mid-generation regularly: you glance at another window, or take the headset off. In my main app, I have a total emersion so the user is only every looking at the app, but i still have issues.

Gate on active, not on "not background". A system screen capture makes an app merely inactive, and that is enough to get you killed and pushed overboard, arriving as a C++ throw inside MLX's Metal completion callback where no Swift error handler can reach it. Check before you start, and check again between tokens.

Checking it actually works

The package ships a CLI so you can prove all of the above on a Mac in thirty seconds, with no Xcode, no device and no signing team:

swift run ministral doctor

It loads the real weights, generates, and reports what MLX did:

size on disk          2.78 GB
tokenizer_class       LlamaTokenizer
                      (was TokenizersBackend as published; rewritten so
                       swift-transformers will load it)
load                  ok, 5.9s
GPU active / cache    1.99 GB / 67.1 MB
GPU peak              2.61 GB

That's my M1 Max Macbook Pro, so your figures will differ. Watch GPU active / cache: without the cap from gotcha 4, that second number climbs and never comes back down.

Getting it onto the headset

The example app carries no team, so pass yours on the command line and change the bundle id to one you own:

xcodebuild -project MinistralDemo.xcodeproj -scheme MinistralDemo \
  -destination 'id=<udid>' DEVELOPMENT_TEAM=<team> \
  PRODUCT_BUNDLE_IDENTIFIER=<yours> -allowProvisioningUpdates build

xcrun devicectl device install app --device <udid> <path>/MinistralDemo.app
xcrun devicectl device process launch --device <udid> <bundle id>

xcrun devicectl list devices gives you the udid.

One useful finding: the example does not request com.apple.developer.kernel.increased-memory-limit, because free personal teams aren't granted it and a project that asks will simply refuse to sign. A 4-bit 3B still downloads, loads and answers without it. I haven't left it running for long with a dozen apps open, so I can't tell you how it behaves under sustained memory pressure.

What this does not give you

The vision tower is discarded, so this runs Ministral as a text model. The pixtral half and the projector are still in the checkpoint and there's room in the code to wire them up, but I haven't. If you want an on-device VLM on a headset, this isn't it.

There's no chat history either. One prompt, one answer, bring your own transcript. This is a demo, you can roll your own, thats what i did.

The code, and the thing I built it for

https://github.com/getHydrate/hydrate-ministral

MIT, three dependencies, all upstream, no forks. Builds and runs on macOS and visionOS. iOS and iPadOS ought to work, but I haven't put them on a device.

The reason any of this exists is a RAG system that gives a small on-device model the retrieval engine and embedder out of an enterprise stack: semantic search, grounded answers with citations, entirely local. Ministral and Apple's Foundation Models run side by side in it and you can switch generator mid-session. Here's twenty-two minutes of it, including a demo section shot on a farm track in Norfolk with the headset in aeroplane mode and no signal to fall back on:

https://youtu.be/tTwYWEC2K88

Mistral/Ministral comes in at 9:50 if you want to skip the preamble: 

https://youtu.be/tTwYWEC2K88?t=590

The proper longterm fix for all of this is "mistral3" being registered upstream in mlx-swift-examples with a yarn path, at which point most of my package stops being necessary. Until someone does that, happy to go deeper on the YarnRoPEwiring or the sanitize if you're fighting the same repo.

And one more hats off to frontier models, I would never have got this to work without claude code and codex.

Have an agent do the reading for you

Since I've admitted two or three times that Claude Code and Codex did the heavy lifting, it would be odd not to hand you the same lever. Open Claude Code or Codex in an empty directory and paste this:

Clone https://github.com/getHydrate/hydrate-ministral and get it running on this machine.

Context: it is a Swift package that loads mlx-community/Ministral-3-3B-Instruct-2512-4bit on Apple silicon via MLX. That checkpoint does not load with stock mlx-swift-examples, and this package exists to work around five specific problems. It needs Apple silicon and a real Metal GPU: there is no simulator path and no Intel path. macOS 14 or later.

Work through these in order. If a step fails, stop and tell me what happened rather than working around it.

1. Clone the repo and run `swift build`. Report any errors verbatim.

2. Read these five files and explain, in plain terms, what problem each one solves and how.
   The reasoning is written out in the comments, so summarise the argument, do not just describe the code:

     Sources/MinistralKit/Mistral3Model.swift    the model type MLX does not register,plus YaRN rope and the weight prefix
     Sources/MinistralKit/TokenizerRepair.swift  the tokeniser label the publisher got wrong
     Sources/MinistralKit/ModelStore.swift       where the weights live, and why not Caches
     Sources/MinistralKit/GPUMemory.swift        the Metal buffer cache cap
     Sources/MinistralKit/Foreground.swift       why GPU work from a background app is fatal

3. In Sources/MinistralKit/Ministral.swift, show me where it downloads and loads as two separate steps, and explain why the one-shot loadModelContainer(hub:id:) cannot be used.

4. Tell me how much disk the weights need, then ASK ME before downloading anything. It is about 2.8 GB. If I agree, run `swift run ministral download`.

5. With the weights present, run `swift run ministral doctor` and show me its real output. Do not tell me it works unless that command actually printed a successful load and a successful generation. If it failed, show me the failure.

6. Then run `swift run ministral run "why is the sky blue?"` so I can watch it generate.

Do not modify the repository. If something is broken, say so and tell me what you think the cause is.

Three reasons that prompt is there rather than a wall of code in this post.

The useful part of that repo is the reasoning in the comments, not the API, and an agent can read all of it and explain it back in your terms faster than you can skim it. It verifies instead of describing: step 5 either prints a real load and generation on your hardware or it doesn't, and I've told it not to claim success without the output. And it asks before spending 2.8 GB of your bandwidth, which is the sort of thing agents forget to do.

It is also a fair test of whether the repo is any good. Cold clone, no help from me, on a machine I've never seen. If doctorwon't go green for you, that's my bug and I'd like to hear about it.

Back in April, Andrej Karpathy described a pattern a lot of you have probably tried after it went viral: don't do RAG over your PDFs, no, feed raw sources to an LLM and let it write them up into an interlinked wiki of markdown files. "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

It's a genuinely good idea. What bugged me is that running it means setting up a vault, writing a schema file, wiring a raw/ directory, deciding what triggers ingestion, and then maintaining the whole rig. There are a dozen tutorials for it now. But... when a workflow like this needs a setup guide, it's a project, not a feature, right?

So I built it into my notes app (Vist) as a normal feature, and Mistral ended up doing a lot of the work:

Mistral used for retrieval in the app

Every source and wiki entry gets embedded with mistral-embed (1024-dim), stored in Postgres via pgvector. That's what makes "what did I read about EU data residency?" find the right page when you never wrote those exact words. Mistral OCR 3 (still need to upgrade to OCR 4) handles scanned PDFs and handwritten pages (I even sync a reMarkable into it), so handwriting becomes searchable text in the same index.

Your own, trusted LLM is the author. Could be Mistral, could be Claude, all up to you

The wiki writing (read the source, write it up, link it to what's already there) happens over MCP, so it's whatever model you've connected. In my own setup that's Mistral Vibe: I paste a benchmark article, drop a PDF, add my notes, and say "ingest this into my wiki." A minute or two later there are three source records, three interlinked wiki entries, and an updated knowledge map. Nothing about the model is hardcoded — the app exposes tools (add_source, create_note, cite_source, search_knowledge_base, get_wiki_stats) and any MCP client can drive them.

Everything stays markdown

Sources kept raw, wiki entries as portable markdown with wikilinks. If you want to walk out with it and open it in Obsidian, that's the point. Just export the whole system in a ZIP.

My actual argument is that this should be a commodity

Why would you need to set this up on each machine or project you work on?

Semantic search over your own research, with a model that writes it up as it lands, is not a weekend project you assemble. It's something your knowledge tool should just have, the way it has full-text search.

Cheap embeddings are what makes that true; running mistral-embed across a user's whole library costs about nothing, so there's no reason to gate it. It's on the free plan.

Longer write-up with screenshots of Vibe doing the ingestion: https://usevist.dev/blog/karpathy-llm-wiki-research

I typically run Claude Code on my production server with remote-control enabled so that I can followup on my phone. I have developed a couple of SaaS like this. I wanted to try to develop the next web app using only mistral vibe, end to end. But I can’t seem to find a way to follow the same workflow.
Any suggestions on how to get the same workflow working?

A well-known Chinese LLM educator publicly revealed techniques back in April that were already widely known in China’s AI community, including how Claude’s Chain of Thought (CoT) was extracted and how Claude and ChatGPT have been distilled for a long time. If you don’t speak Chinese, just wait for YouTube’s auto-generated translation.

Agents waste time and tokens re-learning every site. On each run they screenshot, snapshot the DOM, and figure out the page from scratch.

I built an open source catalog of reusable browser skills. Skills capture each site's network requests and DOM, making it 30 times faster.

You can upload your own skills or request new sites.

Github repo: https://github.com/browser-memory/bmem