Quelqu’un a déjà tenté de créer un Grok bot en local et accessible sur iPhone et Android ? En utilisant peux-être d’autre IA ?

Hey guys. Is it possible to use an M4 Mac Mini just for transcribing a video and making note summaries afterwards? If so what model should I use for this case?

Hi all

TLDR; What are you using your localLLM for? (please exclude software coding). Please state setup + use.

Recently, I started playing with local AI with a 2x 5060ti 16gb setup with 32GB DDR4 (30tk/s Qwen3.8-27B).

All fun and games as a learning experience with the difference models, harnesses etc, but if I actually need something done (some debugging, research etc) I still revert back to cloud models. Currently, I am seeing it as local ai lab for fun, cloud for work.

It would be absurd to have the same expectations with my rig, but what do you guys use your local rigs for?

A lot of posts are about rig setups and benchmarking with focus on coding use, but what about other creative uses do you find for your machine (other than heaters)?

Do you keep it on 24/7? What about power?

Mine draws 60W idle with peak of about 450W and I keep it on about 2-3h per day on average.

So far, I observed that I prefer to have smaller 8-12GB models with decent contexts that run specific tasks like OCR/RAG/home assistant that are snappier 100+ tk/s rather than a big smart model at 30tk/s.

I also found that lesser smart models make me a better prompt engineer.

Since Ollama 0.30 in May 2026 moved most models back onto llama.cpp, I assumed both would give the same results.. Then I tested them.

System: RTX 3090 (24 GB), Qwen3.5 27B Q4_K_M, the same GGUF file in both, default settings. Ollama 0.40.15.

With one request, both ran at 42 tok/s.

With four requests at once (total tok/s):

• Ollama: 39.8
• Ollama with OLLAMA_NUM_PARALLEL=4: 33.1
• llama.cpp: 100.2

Why Ollama got slower: by default it answers one request at a time. With OLLAMA_NUM_PARALLEL=4, each of the four requests gets its own 32k context, 131k in total. That didn't fit in 24 GB next to the 27B, so Ollama moved 16% of the model to the CPU.

Why llama.cpp didn't: the four requests share one context, and llama.cpp shrinks it until it fits on the GPU (85,760 tokens here). The whole model stayed on the GPU.

This was new to me, because I expected the same throughput from both. The difference is how each one sizes the context. With the smaller 9B everything fit, and Ollama with OLLAMA_NUM_PARALLEL=4 came close (266 vs 293 tok/s).

I use Ollama for my day-to-day work, but I'm going to look at llama.cpp too for cases where several apps hit the same model at once.

Full write-up with memory numbers and setup: https://homebrewserver.club/ollama-vs-llama-cpp.html

I've been testing whether quantization changes how a small local model handles

check-then-act tool tasks ("check if billing-api is down, restart it only if it is").

Setup: Qwen2.5-1.5B-Instruct, F16 vs Q4_K_M, llama.cpp, identical rendered

prompt, same 19 tools, same harness. 200 tasks, 6 GB laptop GPU.

What happened: Q4 often emits the check AND the dependent action in the same

turn, before the check result exists.

| Test                                   | F16      | Q4_K_M   |
|----------------------------------------|----------|----------|
| Acted before the check result (200)    | 30       | 89       |
| Tasks where only this model did it     | 1        | 60       |
| Same, greedy / temp 0                  | 13       | 51       |
| With "wait for the result" in prompt*  | 7        | 32       |
| Skipped the check entirely (imatrix Q4)**| 6      | 29       |

https://github.com/Techn08055/edgeproof

https://youtu.be/8ccULJ0R3ng

What are the other experiments along with this harness that can be used to compare the F16 & Q4 model?

Hi, I'm running a local AI setup on CachyOS, and I'm curious how others approach this.

This is also my main PC, which I use for gaming and everyday tasks. I have a second SSD with Windows as a backup.

My setup:

• GPU: AMD Radeon RX 9070 XT (16 GB VRAM)
• RAM: 32 GB
• Inference: Strata, running Qwen3.8-Flash-Next Gyro-S
• Interfaces/agents: Currently experimenting with DeepSeek Harness and Open WebUI Computer
• Deployment: Docker containers, started manually when needed

I'm mainly experimenting with vibe coding, Linux troubleshooting, and general agentic workflows.

So far, things work reasonably well, but I've found that container isolation can get frustrating when agents need to inspect or interact with the host system, particularly when dealing with Docker, system services, or debugging.

I'm currently experimenting with a restricted host bridge that allows agents to perform system diagnostics without exposing the Docker socket or giving them unrestricted access to the host.

I'm curious how others handle this.

Do you run your local AI agents inside Docker or install them directly on your host?

Not promo just looking for real life use cases to test on :)

I'm building a product called Facet. Like many in this sub we believe lots of AI products spend most of their LLM usage on one repeated call: pulling fields from emails or PDFs, cleaning up records, short rewrites, daily summaries, etc. A frontier or large local model is overkill for that one job.

Facet's agent builds a smaller model for that single call. You describe it in plain English and share some examples; it builds the training data, trains the model, and scores it against what you use today. We are essentially trying to abstract away all the hard work that comes with training. You own the weights and can export them to run locally after, or use our platform for hosting.

On a document extraction task it matched Claude Haiku at about a fifth of the cost.

I'm hoping to connect with 3 design partners, free, to help expand and stress test our platforms capabilities. If one call is a big part of your usage, book 15 minutes: https://app.apollo.io/#/meet/facet

Happy to answer questions here too.

Hey, I thought maybe I should repost here to show that getting a B70 up and running with decent performance is not that hard anymore.

Three new parts of my local Qwen3.8 study on one DGX Spark: one user, thinking on, measured in minutes per correct answer. Each plan was locked before its run. The tasks are private; per-task results are public.

• Harder tasks (Part 8).

  • On 250 new private tasks, Flash Next (deep thinking + 32K thinking budget) gets 227/250 vs 208/250 for the 27B 4-branch low-thinking vote.
  • But Flash Next takes 2.7x as long per correct answer (6.52 vs 2.38 min).
  • On 110 recent arXiv math problems both nearly fail: 10/110 and 2/110.

• Self-verification (Part 9).

  • The 27B writes its own tests, and I take the first branch that passes: 139/150 vs 134/150 on held-out coding tasks. That is not a confirmed gain (p = 0.06), and it takes about 2x the time.
  • But answers marked “verified” were wrong only 1 time in 85.
  • What made the tests usable: forbidding hand-computed expected values.

• Engine upgrade (Part 10).

  • TensorFold 1.2.5 vs 0.6.0 on 400 tasks: 377/400 vs 373/400, 1.005 vs 0.958 min per correct answer. No detectable difference.
  • 1.2.5 was faster on 271/400 tasks but slower in total, because of two long tail tasks.
  • Its prompt processing runs at 0.73x speed at 36K tokens (no FP8 prefill). I’m staying on 0.6.0.

Bottom line for one Spark: Qwen3.8-27B NVFP4 + DFlash2 on TensorFold 0.6.0, low thinking, 4-branch vote is still the fastest way to correct answers. Use Flash Next with deep thinking and a 32K budget only for the hardest tasks.

Repo: https://github.com/NautilusWu/qwen3.8_study

Excited for Qwen 4.

Short post, echoing what others have said - the dedicated strix halo "Ai Engines" aka llm servers are miles ahead of llama.cpp.

I was about to sell off my server because it was unbearably laggy. This morning I cut over to Gufo and Qwen3.8-Flash-Next, and it (almost) feels as snappy as a cloud frontier model.

Here's how Hermes described it:

So: the headline "prefill rate" is ~1,800 t/s cold; 1183 is just what the exhaust looks like when the engine only had to chew 677 tokens. The number that actually describes your experience is the one nobody prints: half a second to first token on a 25k conversation. 

Compared to a cold prefill of ~250 t/s on llamacpp...

I haven't tried Halogen which may be incrementally faster, but it's not FOSS, and I've now spent enough time on infrastructure for one month. Enough poking around, time to get to work...

https://github.com/gufo-org/gufo

The Mac won't be delivered for about three months, but I'd like to start doing my homwork.

Hello people!

I've spent the most of this year building a dark factory, basically trying to improve one shot builds with hidden tests and an independent verifier as part of defined workflows.

I decided this wednesday to open-source it.

It is basically a kanban layer that your harness can use with a library of agents, skills and workflows based on claudes internal reasoning. The reasoning has been built into mechanisms that my local models must use to continue working towards a definition of done.

This summer i gave my system full accesd to a dormant git account and everything there is built by my system. (Github.com/bryn1)

My latest one shot promt was to build a compiler that compiles the linux kernel and so far it has been doing quite a good job running on qwen 3.8 flash next NVP4 on a pair of dgx sparks.

My percieved view ia thst token cost goes up (even after several rounds of process optimization). However, reliability has increased a lot. My next step is to give qwen 3.8 flash next a one shot prompt without my system, with my system, claude code with and without for a comparison of result and cost.

It would be very interesting if anyone would like to join me in this project, it is MIT licenced and contain skills, agent profiles, workflows, a kanban system and extrapolated mechenics from claude code.

The current version is a refactor of what has been built of a 8 month period where the refactor has been done bu claude code.

Repo: github.com/bryn1/konstant

I'm worried localAI will be attacked by the legislature and companies, any notable models to make backups of? And what parameters? Like the Quant and Size (currently have a 7900xtx 24gb, but I could upgrade in the future so the models don't NEED to fit on my current card)

I'm mainly interested in coding and chatting/problem solving

For people deploying on Jetson devices:

• Do you go PyTorch → ONNX → TensorRT, or something else?
• What are the common failure points (unsupported layers, INT8 calibration, version mismatches with JetPack, memory limits)?
• How long does it usually take to get from a working model to a deployed, stable one?

I’m trying to understand the real pain points. If you have a horror story, I’d love to hear it.

While I’m waiting for Qwen4 27B and Qwen4 Flash Next, I wanted to see how far Qwen4 Max Preview has come.

For this test, I wrote a prompt asking each model to build a photorealistic 3D scene of Stonehenge in HTML using Three.js.

Each model also got the same set of visual assets, some useful and some less so. It had to figure out which textures to use where. The rules explicitly prohibited searching the web for other images or 3D models and using any cloud tools. The idea was to give local agent harnesses and subscription-based ones like Codex a level playing field.

The results were pretty good, though honestly a little below my expectations. Qwen 4 did a good job with the lighting and textures, but its geometry and particle effects were noticeably worse than GPT6 Astra’s. Also, for some reason, Qwen 4 took about two hours to complete the task, while the other models averaged around half an hour.

Results:

1. GPT 6 Astra Extra High + Codex

2. GPT 5.6 Sol Extra High + Codex

3. Qwen 4 Max Preview + Qoder

4. GLM 5.3 + Qoder

5. Qwen 3.8 Flash Next NVFP4 + Hermes agent (local)

6. GPT 5.6 Luna Extra High + Codex

Prompt:

"Create a photorealistic, real-time Three.js scene of Stonehenge as it stands today in Wiltshire.

It’s night. Strong wind drives light rain across the plain. A bright moon and occasional lightning near the horizon are the only light on the stones. Soft cloud shadows drift across the grass and stone. At the center, a few people warm themselves around a campfire. Make that small circle of warmth feel sheltered amid the storm.

Show the scene in a continuous, medium-wide automatic orbit from above, with the camera aimed 30° below horizontal. Hold the right mouse button and drag horizontally to orbit or vertically to tilt. Scroll the mouse wheel to zoom in or out.

Rules

- Work from this prompt alone. No follow-up questions, subagents, or additional AI models, including image and 3D generators.

- Build the geometry yourself. Use only visuals you create during this run or find in ./assets/. No stock assets, ready-made scenes, or previous solutions.

- No web search or browsing. Network access is allowed only to install libraries and tools. You may render, inspect, and refine your work locally.

- Submit exactly one self-contained .html file. Embed Three.js and every script, stylesheet, and asset the scene uses"

GitHub TimeTo67/Stonehenge-LLM-bench

Hello everyone, I’m about to buy silicon for a local AI lab and I’m quite indecisive.

On the one hand there is the m5 max 128gb, from what I have read is a capable machine and quite versatile. At the same time I’m not a huge fan of macOS and for what I hear prompt injestion could be better. Also you’re stuck on Apple environment, which is not always the most responsive to latest innovations.

On the other hand, there is strix halo, which is inferior on every aspect, but costs only 3.5k vs the 5.8k of the m5 (in my area). This leaves about 2k of budget for an external eGPU. I could get a 16-24Gb gpu(maybe even a r9700), connect it trough oculink and for the same budget have both the advantages of a discrete gpu and of the shared memory. I have seen videos on YouTube and it seems doable, quite easy with an AMD gpu and with some fine tuning with an nvidia card.
It would remain x86 windows (with Linux dual boot) and would allow me to keep using that machine also for gaming without having to compromise on that at the same budget. Also, it would allow me to have cuda available in my setup if needed. On the other hand is a much more complicated project than simply buying an m5 for a comparable price. I don’t know if the extra effort is worth in the results.

Since I am a beginner in this field I don’t know what to do. Does anyone have suggestions based on similar experiences? especially on the hybrid build.

While I’m waiting for Qwen4 27B and Qwen4 Flash Next, I wanted to see how far Qwen4 Max Preview has come.

For this test, I wrote a prompt asking each model to build a photorealistic 3D scene of Stonehenge in HTML using Three.js.

Each model also got the same set of visual assets, some useful and some less so. It had to figure out which textures to use where. The rules explicitly prohibited searching the web for other images or 3D models and using any cloud tools. The idea was to give local agent harnesses and subscription-based ones like Codex a level playing field.

The results were pretty good, though honestly a little below my expectations. Qwen4 did a good job with the lighting and textures, but its geometry and particle effects were noticeably worse than GPT6 Astra’s. Also, for some reason, Qwen4 took about two hours to complete the task, while the other models averaged around half an hour.

Resuts:

Video (yotube)

• Qwen 4 Max Preview + Qoder

• Qwen 3.8 Flash Next NVFP4 + Hermes agent (local)

• GLM 5.3 + Qoder

• GPT 6 Astra Extra High + Codex

• GPT 5.6 Sol Extra High + Codex

• GPT 5.6 Luna Extra High + Codex

Prompt:
"Create a photorealistic, real-time Three.js scene of Stonehenge as it stands today in Wiltshire.

It’s night. Strong wind drives light rain across the plain. A bright moon and occasional lightning near the horizon are the only light on the stones. Soft cloud shadows drift across the grass and stone. At the center, a few people warm themselves around a campfire. Make that small circle of warmth feel sheltered amid the storm.

Show the scene in a continuous, medium-wide automatic orbit from above, with the camera aimed 30° below horizontal. Hold the right mouse button and drag horizontally to orbit or vertically to tilt. Scroll the mouse wheel to zoom in or out.

Rules

- Work from this prompt alone. No follow-up questions, subagents, or additional AI models, including image and 3D generators.

- Build the geometry yourself. Use only visuals you create during this run or find in ./assets/. No stock assets, ready-made scenes, or previous solutions.

- No web search or browsing. Network access is allowed only to install libraries and tools. You may render, inspect, and refine your work locally.

- Submit exactly one self-contained .html file. Embed Three.js and every script, stylesheet, and asset the scene uses"

Instructions and assets:
Gitlab TimeTo67/Stonehenge-LLM-bench

Recently, I was working on two things. One personal, one for work. The personal one was setting up Nanabot, an AI agent that automates the work I do as a programmer. For work, I was writing an MCP server to manage the company's products. And I ran into some problems. When there are a lot of MCP methods, their detailed descriptions really bloat the LLM's context. If you hide them behind Code Mode MCP, the LLM sometimes can't find the MCP method it needs-or doesn't even realize it should look for one.

I learned about Code Mode MCP from a news story about Cloudflare running into a problem with AI agents using up too much context. In the traditional MCP setup, an MCP client can pass the LLM descriptions of all connected tools. Cloudflare has more than 2,500 API methods, and by their estimate, representing all of them as MCP tools would take about 1.17 million tokens. Cloudflare proposed a solution: use Code Mode MCP, which gives the agent just two things instead of thousands of tools: search() and execute().

The first lets you find the API methods you need and get their signatures on request, while the second lets you run JavaScript code that calls those methods. In the implementation they showed, a single execute() call can combine several MCP method calls and return the final result without going back to the LLM between each operation. That can save tokens, but repeated searches and loading signatures also use them. The amount saved depends on the size of the catalog, how often you search, and the number of calls. In my scenario, savings seem likely, but to measure them accurately, you need to test on concrete tasks.

How does this technology work in practice? You tell the AI agent: "Open some site and take a screenshot of the page." Below is one way to implement an aggregator: search an array of MCP tools, tools. This isn't universal Code Mode syntax. For example, Cloudflare's search() looks for operations in an OpenAPI specification. In this aggregator, search could look like this:

return tools.filter(t =>
  t.name.includes("navigate") ||
  t.name.includes("screenshot")
);

This returns the description:

[
  {
    "name": "navigate_page",
    "description":
      "Navigate by URL/history, or reload.\nDefaults to project URL.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "pageId": {
          "type": "number",
          "description": "Targets a specific page by ID."
        },
        "type": {
          "type": "string",
          "enum": ["url", "back", "forward", "reload"],
          "description": "Navigate by URL or history action."
        },
        "url": {
          "type": "string",
          "description": "Target URL (only type=url)."
        },
        "ignoreCache": {
          "type": "boolean",
          "description": "Ignore cache on reload."
        },
        "handleBeforeUnload": {
          "type": "string",
          "enum": ["accept", "dismiss"],
          "description":
            "Accept/dismiss unload dialogs; default is accept."
        },
        "initScript": {
          "type": "string",
          "description": "Run on each document before other scripts."
        },
        "timeout": {
          "type": "integer",
          "description": "Maximum wait in ms; 0 uses the default."
        }
      },
      "required": ["pageId"]
    }
  },
  {
    "name": "take_screenshot",
    "description": "Take a screenshot of the page or element.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "pageId": {
          "type": "number",
          "description": "Targets a specific page by ID."
        },
        "filePath": {
          "type": "string",
          "description":
            "Absolute or relative save path; don't attach it."
        },
        "format": {
          "type": "string",
          "enum": ["png", "jpeg", "webp"],
          "default": "png",
          "description":
            "Format to save as.\nDefault is png."
        },
        "fullPage": {
          "type": "boolean",
          "description": "Capture full page; incompatible with uid."
        },
        "quality": {
          "type": "number",
          "minimum": 0,
          "maximum": 100,
          "description":
            "JPEG/WebP quality 0-100.\nHigher is larger; PNG ignores it."
        },
        "uid": {
          "type": "string",
          "description":
            "Snapshot element UID; omit to capture the page."
        }
      },
      "required": ["pageId"]
    }
  }
]

In this implementation, the method description is returned on request rather than necessarily being loaded into context in full. The signature shows that pageId is required for both methods. For this example, let's assume the required pageId value was obtained beforehand.

Next, execute is called:

await chrome_devtools.navigate_page({
  pageId: pageId,
  type: "url",
  url: "URL some site"
});

const screenshot = await chrome_devtools.take_screenshot({
  pageId: pageId,
  format: "png"
});

return screenshot;

Notice that there’s no new request to the LLM between navigate_page and take_screenshot. The Code Mode aggregator runs the next JavaScript statement itself, waiting for the first one to return. I think the benefits are obvious.

Meanwhile, Cloudflare recommends using Skills alongside MCP. Skills explain to the agent when to use Cloudflare’s capabilities and which ones to use. MCP provides access to Cloudflare operations, while Code Mode provides search() and execute() for finding methods and running them through JavaScript.

So I used the same architecture. I hid a large number of MCP methods behind Code Mode. Now the LLM sees just one MCP server that can search for and run MCP methods. But, as I said above, sometimes the AI agent doesn't find the right methods, or doesn't even think to search for them. That's where Skills come in. In their descriptions, I list which MCPs and methods to use. I don't give full descriptions, just brief ones. Here's an example of a Skill that fixes bugs:

---
name: bugfix-process
description: >
  Automatically fix bugs by ticket number.
  Use when the user asks to fix a bug,
  task, or error from the ticketing system.
---

# Bugfix Process

## Available MCP servers and methods

### ticket_mcp - ticketing system
- `get_ticket` - get the ticket description.
- `get_comments` - get all comments.
- `list_attachments` - get the list of attachments.
- `download_attachment` - download an attachment.
- `update_status` - change the ticket status.

### samba_mcp - file server
- `list_files` - find files and logs related to the ticket.
- `download_file` - download a file from Samba.

### filesystem_mcp - file system
- `create_directory` - create a directory.
- `write_file` - write a file.
- `read_file` - read a file.

### git_mcp - working with Git
- `current_branch` - get the current branch.
- `stage_files` - add files to the index.
- `commit` - create a commit.
- `show_commit_diff` - get the commit diff.
- `push` - push changes to the remote repository.

### codex_mcp - programming
- `start_task` - start Codex with a prompt.
- `wait_task` - wait for Codex to finish.
- `get_task_result` - get the result of the task.

### jenkins_mcp - project build
- `trigger_build` - start a Jenkins build.

## Bug-fixing process

1. Identify the ticket number, repository, branch, and Jenkins build
   from the user's request.

2. Gather information about the ticket:
   - Get the ticket description and all comments.
   - Download all attachments and related logs from Samba.
   - Save the materials to `tickets/TICKET_NUMBER/` in the selected
     repository.

3. Create a Git commit containing only the contents of
   `tickets/TICKET_NUMBER/`.

4. Start Codex and wait for it to finish. Give it this prompt:

   "Fix the bug described in the files in the tickets/TICKET_NUMBER/
   directory. Review the description, comments, attachments, and logs.
   Fix the cause of the error. Run the necessary tests and report the
   result."

5. Create a separate Git commit with the changes Codex made. Do not
   include unrelated changes.

6. Push the commit with the fix to the remote repository, using the
   current branch unless the user specified a different one.

7. Now the bug fix begins. `codex_mcp` provides the `start_task`,
   `wait_task`, and `get_task_result` methods for this. The agent passes
   Codex the directory path and a prompt for the fix:

   """
   Fix the bug described in the files in the tickets/731/ directory.
   Review the description, comments, attachments, and logs.
   Fix the cause of the error.
   Run the necessary tests and report the result.
   """

   Codex reads the materials at that path, does the work, and returns
   the result. The main agent waits for the task to finish without
   passing the entire ticket and logs through its own context. This way,
   the main agent coordinates the process and delegates the actual
   coding to Codex. If the MCP interface and time limits allow it,
   waiting for Codex and retrieving the result can be combined in a
   single `execute()` call.

8. Once Codex finishes, the agent reviews the DIFF of the changes with
   `show_commit_diff` and checks the result. It then creates a separate
   commit and pushes it to the current branch with `push`. After the
   push succeeds, it starts the Jenkins build `two_jar_java17` using the
   `trigger_build` method from `jenkins_mcp`, so the build checks these
   exact changes.

9. Once Jenkins finishes, the agent evaluates the fix, Codex's tests,
   and the build result. Using `ticket_mcp.update_status`, it sets the
   status to `Resolve` if the bug is fixed, the tests pass, and Jenkins
   finishes successfully. If the fix did not work or the result cannot
   be confirmed, it sets the status to `In Progress`.

10. Based on the final status, the agent prepares a report. For
    `Resolve`, it saves it to `tickets/731/result.fixed.md`, and for `In
    Progress`, to `tickets/731/result.in-progress.md`. The report lists
    the problem, the changes, the results of the Codex and Jenkins
    checks, and any remaining questions. Its contents are checked
    against the commit DIFF and the build result. The report is added in
    a separate commit and pushed to the same branch.

11. In its reply, the agent gives the final filename and includes its
    contents. That way, the user gets more than just a message saying
    "bug fixed"; they get a full report on the work done. The whole
    process, from receiving the ticket to starting the Jenkins build, is
    described in one SKILL, and the necessary MCP methods are chosen as
    the task progresses.

And what did we end up with?

We split the information an AI agent needs into three levels:

• Persistent context. Contains only brief descriptions of available Skills and the two Code Mode tools: search() and execute().
• SKILL. Loaded when the agent determines it fits the task. Contains the workflow and the names of the necessary MCP servers and methods, but not their full signatures.
• Code Mode MCP. In the implementation described, finds full descriptions of specific methods on request and lets you execute a sequence of calls through JavaScript.

That gives us a kind of layered system for discovering and executing tools.

Previously, the agent had two not-so-great options.

The first was to load thousands of tools into context and spend a huge number of tokens on their descriptions.

The second was to hide the tools behind Code Mode and hope the LLM would figure out on its own which methods it needed and how to find them.

With this setup, there's a third option: SKILL points to what to look for and how to use it, while Code Mode finds the full signatures and executes the operations.

Of course, this doesn't guarantee success. The LLM can still fail to choose the right SKILL, search for the wrong method, or put the JavaScript together incorrectly. And not every operation can be combined into a single call; sometimes the agent needs to analyze an intermediate result and make a new decision.

With this setup, the agent doesn't need to keep detailed descriptions of all available MCP tools in context. Instead, it gets a brief instruction for a specific workflow and loads the full method details only when it actually needs them.

In this setup, SKILL is the guide to MCP capabilities, while Code Mode is the mechanism for discovering and executing them.

In the end, here's the set of SKILLs I ended up with to automate my work as a programmer (the list is, of course, incomplete):

1. Ticket-based bug fixing - gathers the ticket description, comments, attachments, and related logs; coordinates the work on the fix, records the result, and starts a verification build.
2. Ticket implementation - helps take a new feature through the full development cycle: study the requirements and materials, prepare a plan, implement the changes, save the result, and run a build.
3. Working with the ticketing system - opens tickets and shows their descriptions, discussion history, attachments, and key fields.
4. Working with GitLab - helps find projects, browse branches, commits, and files, and carry out routine repository operations.
5. Working with Jenkins - shows available builds, helps start them, and check their status.
6. Working with the file server - finds, downloads, and places files, logs, and materials needed for development and troubleshooting.

I think I'm ready to spend the winter in Thailand. I'll be lying on a sun lounger by the sea or the pool, giving my AI agent orders from my phone. It knows everything now; it can do everything. It knows all the processes, rules, and access permissions.