DEV Community: kshitij Bhatnagar

How to Migrate from the Claude Ecosystem to the Antigravity Ecosystem

kshitij Bhatnagar — Fri, 18 Sep 2026 01:37:21 +0000

I hit Claude's usage limit while I still had work to finish.

Switching to another agent sounded simple. Open Antigravity, give it the task, keep going.

Except I wasn't starting with a blank assistant. I had built up skills for reviewing code, writing in my voice, generating diagrams, checking deployments, and remembering project decisions. Switching tools meant risking all the small instructions that made my workflow feel like mine.

I didn't need a new workflow. I needed my existing workflow to work somewhere else.

That became the migration: bring my reusable skills into Google Antigravity, keep GitHub Copilot connected to the same source, and separate the parts that genuinely transfer from the parts that only look portable.

The workflow moves through shared instructions. The old conversation, account and permissions do not move with it.

First, what is an agent skill?

A skill is a reusable procedure an AI agent can load when a task needs it. Think of it as a playbook with a description on the cover.

For example, my blogging skill defines how to research a topic, write in my voice, format the article, generate visuals, and stop before publication. I shouldn't need to explain those expectations every time I write a post.

The basic package is small:

blog-workflow/
  SKILL.md
  references/
  scripts/
  assets/

Only SKILL.md is essential. The other folders hold supporting material when needed.

---
name: blog-workflow
description: Drafts and revises technical blog posts with diagrams and contextual GIFs. Use when writing or improving an article.
---

1. Verify the technical claims against primary sources.
2. Open with the reader's problem and the practical payoff.
3. Generate a cover, an explanatory diagram and useful motion.
4. Check the rendered article and every image URL.
5. Save as a draft. Never publish without explicit approval.

The agent first sees the name and description. It reads the full instructions when the skill becomes relevant. This is progressive disclosure, not a promise that every installed skill's complete contents are loaded into every prompt.

Claude Code, GitHub Copilot and Antigravity support this shared concept through the Agent Skills standard. Their extra features, discovery paths and permission models still differ.

What I was actually migrating

Not a subscription. Not a model. Not my entire chat history.

I was moving the reusable instructions and their dependencies into places another agent could discover.

Part of the workflow	What to do
Plain `SKILL.md` instructions	Reuse, then test invocation and output
References, templates and scripts	Keep with the skill; verify paths and dependencies
Always-on coding preferences	Configure the receiving agent's supported rules mechanism
Hooks and plugin behavior	Check the installed version and adapt event/tool contracts
MCP connections and credentials	Configure separately with appropriate permissions
Conversation history and project context	Write a deliberate handoff; do not assume automatic transfer
Usage limits and billing	Remain specific to each product, account and model

The reason I switched was continuity after hitting a limit. That is different from claiming Antigravity is always cheaper, unlimited, or guaranteed to use a particular model. I did not benchmark those claims.

Step 1: Audit before linking anything

My original inventory counted 53 entries across shared, Claude-specific, nested design and Obsidian-related locations.

But a count is not a migration test. A directory can exist while its link is broken, its scripts are missing, or its instructions depend on tools the new agent doesn't have.

The follow-up audit separated 43 reusable global skills from 10 existing Obsidian-scoped links. I kept those project-specific links out of the new global-sharing pipeline. I also found two unrelated broken legacy links in Claude's directory and left them untouched rather than silently deleting them.

For each skill, I checked:

Where does the directory actually resolve?
Does it contain a readable SKILL.md?
Does it reference scripts, templates or prompt files elsewhere?
Does another directory contain a different skill with the same name?
Is this genuinely a global skill, or does it belong to one project?

Resolve duplicate names before choosing a source of truth. Copying the newest file over everything else is not a safe merge strategy.

Step 2: Use the receiving agent's real discovery paths

Here are the relevant personal locations from the official documentation I checked for this revision:

Surface	Personal skill location
Claude Code	`~/.claude/skills/`
GitHub Copilot in VS Code	`~/.copilot/skills/`, `~/.claude/skills/`, `~/.agents/skills/`
Antigravity 2.0	`~/.gemini/config/skills/`

Antigravity has multiple surfaces. Check the documentation for the one you use rather than assuming an IDE, CLI and desktop release have identical paths.

On this Mac, I already had shared skills under ~/.agents/skills/. Most Claude entries pointed there. Several other skills still lived in their original Claude directories.

There was no need to rewrite their Markdown or move their working directories. I linked the missing discovery entries to the same original directories, preserving their scripts and relative references.

For a single skill already stored in the shared directory, the pattern is:

source="$HOME/.agents/skills/blog-workflow"
test -f "$source/SKILL.md" || exit 1

for root in "$HOME/.claude/skills" \
            "$HOME/.copilot/skills" \
            "$HOME/.gemini/config/skills"; do
  mkdir -p "$root"
  target="$root/blog-workflow"
  if [ -e "$target" ] || [ -L "$target" ]; then
    printf 'Inspect existing entry: %s\n' "$target"
  else
    ln -s "$source" "$target"
  fi
done

Notice what is missing: ln -sf. An existing directory or broken link deserves inspection, not forced replacement.

For my larger library, an idempotent local script checks for conflicts before adding missing links. It doesn't copy credentials, scan chat histories, or promote project-specific skills into global scope.

Step 3: Keep updates bidirectional

Copying a skill into three folders solves today's migration. It creates tomorrow's drift.

With directory links, the three paths open the same underlying file. Edit the linked skill through Claude's directory, Copilot's directory or Antigravity's directory, and the other paths expose that change immediately.

These are filesystem aliases, not three replicas exchanging network messages. Existing sessions may need to reload instructions.

The local pipeline now verifies 43 global skills across all three ecosystems. Its disposable tests write through each path and confirm that every peer reads the same bytes. It also tests new-skill registration, repeated runs, name conflicts and broken destinations.

Existing linked skills need no background service. After creating a new skill directory, I rerun the link-registration script. Deleting a discovery link is not the same as deleting the shared skill; removals are deliberate, not automatically propagated.

There are limits:

This shares files on one machine. Another laptop needs its own installation or a separate versioned distribution process.
Shared files do not merge simultaneous edits. Two agents editing one skill can still overwrite each other's work.
A model that already loaded the old instructions may need a fresh invocation or session.
Matching files do not prove matching output quality.

Step 4: Port the dependencies, not just the Markdown

Some of my skills are routers. Their SKILL.md tells the agent to read a canonical prompt stored in my VS Code user-prompts directory.

That works on this Mac because the file exists and the receiving agent can be granted access. It is not a portable package by itself. On a new machine, I would include the referenced material inside the skill bundle or deliberately migrate that dependency too.

Three other details deserve their own checks.

Hooks are not prompt reminders. Antigravity's current documentation includes lifecycle hooks. The question is whether your specific event, payload and tool names map correctly. Replacing an enforced pre-tool check with “please remember to check” weakens the guarantee.

A named tool is not an installed tool. A skill mentioning an image generator, browser or MCP server doesn't make that capability available. Check the receiving agent's tools and authenticate only what the workflow needs.

A denied write is a boundary, not a migration trick. Use the product's supported setup and permission flow. Don't route around a denied operation through a different tool and call that portability.

Step 5: Test one real workflow before trusting the library

My concrete example is this blogging workflow. Instead of separate reminders to write, format, draw a diagram and make a GIF, one skill now orchestrates the whole draft:

Verify the story and technical claims.
Write a problem-led article with useful examples.
Generate a custom cover, static explanation and contextual animations.
Check readability, image delivery and the rendered draft.
Stop before publishing.

That last step mattered more than I expected. The old instructions called queue/ a review area, but the scheduler treated every Markdown file there as approved for publication. Another helper named update explicitly forced the article live.

I corrected the workflow to keep unapproved work in drafts/ and update an existing remote draft with published: false.

Porting an instruction faithfully is not enough if the instruction is wrong.

For a receiving agent, my smoke-test prompt is:

Use my blogging skill to outline a migration article.
Read its canonical instructions and list the required visual assets.
Do not publish, upload, commit or push anything.
Report any missing files or tools instead of substituting silently.

I separate two results: the filesystem checks pass; application discovery, tool execution and output quality must still be checked inside each receiving application. This revision does not claim an end-to-end run of every skill in all three agents.

What I would repeat

Start with the skill you use every day. Make its dependencies explicit. Keep one editable source. Test both the useful output and the “must not do” rules.

The useful outcome wasn't the number of folders I could migrate. It was keeping my accumulated workflow knowledge available when one tool hit a limit.

Changing agents should not mean rebuilding how you work. But sharing a playbook is not the same as sharing an entire runtime.

Which part of your setup would be hardest to carry to another agent: skills, hooks, tool access, or project context?

Sources

Diagrams are original explanatory illustrations, not product screenshots. Product names belong to their respective owners. Paths describe the documented surfaces above and my local setup, not a universal installer.

I have 10 bots working on my dev workflow right now. Here is what each one does.

kshitij Bhatnagar — Thu, 17 Sep 2026 10:58:53 +0000

I was mid-deploy when my terminal froze for three seconds.

It continued on the wrong branch.

A scheduled automation had spotted a new PR comment, run git checkout in my working directory, and switched my branch while the deploy was still in flight. Silently. I watched files land on the device from the wrong build and sat there for a moment not understanding what had just happened.

That incident made me rebuild everything. While I was rebuilding, I wrote down every automation I run. This post is that document.

Short version: the fix was git worktree. Every automation now gets its own folder, so nothing can ever touch the directory I am typing in. The 10 workflows below all sit on that one idea.

How to read this post

The bug and the fix. Why shared directories break, and the one git command that solves it.
The shared pattern. All 10 workflows have the same 5-step skeleton.
The 10 workflows. What each one does, when it fires, and what surprised me.
Build it yourself. A working starter kit you can clone and run today.

One note before the code. The snippets in section 3 are simplified sketches. Names like send-notification and fetch-unprocessed-comments stand in for glue I am not going to make you read twice. They show the shape of each workflow, not something you can paste into a terminal. Section 4 has the real, runnable versions. If you just want working code, skip to the end.

Part 1: Why it broke, and the one git command that fixed it

Every automation I had built started the same way:

cd ~/projects/my-repo
git fetch origin
git checkout <some-branch>
# do the work

That cd was the problem. Every script operated in the same folder I was sitting in. Two firing at once meant a collision. One firing while I was deploying meant chaos.

I had already added a mutex so two automations could not run at the same time. That stopped them fighting each other. It never stopped one fighting me, because the lock only asked "is another automation running?" It never asked "is the human using this folder right now?"

Detection cannot reliably answer that question. Separation makes it unnecessary.

The problem: one folder, multiple writers

All three bots converge on ~/projects/my-repo. When one runs git checkout while you are mid-deploy, the deploy picks up the wrong branch's files. No error, no warning.

The fix: give every bot its own folder

git worktree add creates a second folder attached to the same repository but checked out to its own branch:

git worktree add ~/projects/my-repo-automation feature/pr-comment-fix

No copying. No cloning. Both folders share one .git object store, so this is close to instant even on a large repo.

The important property: checking out a branch in one worktree has no effect on any other. Each automation gets a disposable folder, does its work, and the folder is deleted. My directory is never involved.

Requires git 2.5 or newer, which in practice means any git you have.

Part 2: The pattern every workflow follows

All 10 use the same 5-step skeleton.

Step	What happens
1. Trigger	A schedule or a webhook fires
2. Isolate	Create a fresh worktree
3. Work	Do the actual task in there
4. Verify	Run the build or tests
5. Notify and stop	Tell me. Do not commit. Clean up.

In code:

TICKET_ID="$1"
BRANCH="$2"
WORKTREE="$HOME/.automation/worktrees/$TICKET_ID"

# 2. Isolate
git -C ~/projects/my-repo worktree add "$WORKTREE" "$BRANCH"
cd "$WORKTREE"

# 3 and 4: work and verify happen here

# 5. Notify, then stop
git worktree remove "$WORKTREE"

Step 5 is the one I never bend. Automation does the assembly. I keep the judgment.

Part 3: The 10 workflows

Reminder: these are sketches. Runnable code is in Part 4.

1. PR Comment Resolver

Does: Watches your open PRs for new review comments and attempts the clear ones in an isolated worktree, leaving a diff for you.
Fires: Every 5 minutes, only on PRs you authored.

For each comment it has not seen before, it reads the comment plus the surrounding file context, decides whether the request is unambiguous, implements it if so, flags it if not, then runs the build.

UNPROCESSED=$(fetch-unprocessed-comments "$PR_ID")

for COMMENT in $UNPROCESSED; do
  CONTEXT=$(get-file-context-for-comment "$COMMENT")

  claude "
    Comment: $COMMENT
    File context: $CONTEXT

    If this is a clear, unambiguous change request: implement it.
    If it is unclear or subjective: flag it for human review.
    Run the build. Do not commit.
  "

  mark-processed "$COMMENT"
done

What surprised me: roughly 70% of review comments resolve with no input from me. The other 30% are the ones I actually need to think about. Sorting comments into those two piles turned out to be worth more than the fixes.

2. Ticket Implementer

Does: When a ticket is assigned to you, creates a branch, reads the spec, and starts implementing.
Fires: Every 5 minutes, for tickets assigned in the last 2 hours.

The 2-hour window matters. Polling for "ever assigned to me" re-triggers on old work forever.

JQL="assignee = currentUser() AND updated >= -2h AND status = 'In Progress'"
NEW_TICKETS=$(fetch-jql "$JQL" | filter-unprocessed)

for TICKET in $NEW_TICKETS; do
  BRANCH=$(create-branch-for-ticket "$TICKET")
  WORKTREE="$HOME/.automation/worktrees/$TICKET"

  git -C ~/projects/my-repo worktree add "$WORKTREE" "$BRANCH"
  cd "$WORKTREE"

  SPEC=$(get-ticket-body "$TICKET")
  claude "Implement this: $SPEC. Run the build. Do not commit."

  mark-processed "$TICKET"
done

What surprised me: output quality tracks ticket quality almost exactly. This has quietly made me write better tickets, because I know something is going to try to implement them literally.

3. PR Description Generator

Does: On a new branch push, reads the diff and writes the PR description.
Fires: Webhook on branch push.

DIFF=$(git diff "origin/$BASE_BRANCH"...HEAD)
COMMITS=$(git log "origin/$BASE_BRANCH"...HEAD --oneline)

claude "
  Diff: $DIFF
  Commits: $COMMITS

  Write a PR description:
  - What changed (plain language, name real files and functions)
  - Why this change was needed
  - How to test it, step by step
  - What reviewers should look at carefully

  Be specific. No generic filler.
" > .pr-description.md

Where it earns its keep: the "what reviewers should look at" section. It flags things I would not have thought to call out, and has caught real issues before a reviewer had to.

4. QA Handoff Note Generator

Does: When a ticket hits "Ready for Testing", writes a QA note from the actual diff rather than the ticket text.
Fires: Every 5 minutes, on tickets that just transitioned.

DIFF=$(git diff origin/main...HEAD)
SPEC=$(get-ticket-body "$TICKET_ID")

DRAFT=$(claude "
  Ticket: $SPEC
  Diff: $DIFF

  Write a QA handoff note:
  - Environment setup steps
  - Happy path test cases
  - Edge cases (derive these from the diff, not the spec)
  - Out of scope
")

post-staging-comment "$TICKET_ID" "$DRAFT"
send-notification "QA note drafted, approve before it goes visible"

The guard: it posts to a staging comment and waits for me. A wrong test case is worse than no test case, because someone will trust it.

5. Best Practices Auto-Learner

Does: On PR merge, reads the resolved review comments and proposes additions to the team guidelines file.
Fires: Webhook on merge.

A slow burn. Does nothing visible on day one.

COMMENTS=$(get-resolved-comments-for-pr "$PR_ID")
CURRENT_GUIDELINES=$(cat GUIDELINES.md)

PROPOSED=$(claude "
  Resolved review comments: $COMMENTS
  Current guidelines: $CURRENT_GUIDELINES

  Identify any new convention these comments suggest.
  Only propose an addition if the pattern is clear and specific.
  Do not repeat anything already covered.
  Output the addition only, or nothing.
")

if [ -n "$PROPOSED" ]; then
  echo "$PROPOSED" >> GUIDELINES.md
fi

What surprised me: after three months this file was better than anything I would have written deliberately, because every rule came from a real argument about real code.

6. Work State Tracker

Does: Logs your branch, working tree state, and active tickets to a JSON file.
Fires: Every 30 minutes.

Read-only by design. It never checks anything out.

BRANCH=$(git -C ~/projects/my-repo rev-parse --abbrev-ref HEAD)
STATUS=$(git -C ~/projects/my-repo status --short)
ACTIVE=$(get-my-active-tickets)

jq -n \
  --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --arg branch "$BRANCH" \
  --arg status "$STATUS" \
  --argjson tickets "$ACTIVE" \
  '{timestamp: $ts, branch: $branch, dirty: ($status | length > 0), active_tickets: $tickets}' \
  >> ~/.automation/work-log.json

Why I trust this one most: it cannot break anything. It answers "what was I doing before that meeting?" without me having to remember.

7. Build Failure Notifier

Does: On a failed build, finds the first real error rather than the cascade it triggered, and sends you the file, line, and message.
Fires: Polls CI every 2 minutes while a build is running.

Most CI alerts say "build failed". This one says TypeScript error: `src/auth.ts` line 42, type `string` is not assignable to `number`.

BUILD_LOG=$(fetch-build-log "$BUILD_ID")

FIRST_ERROR=$(echo "$BUILD_LOG" | claude "
  Read this CI log.
  Find the first real error that caused the failure.
  Ignore downstream failures it triggered.
  Output: filename, line number, message. One line.
")

send-notification "Build failed: $FIRST_ERROR"

The insight: CI logs are mostly cascade noise. Digging out the real error costs 30 seconds every single time, which is exactly the kind of tax worth automating away.

8. Daily Standup Draft

Does: Reads yesterday's commits and ticket activity and drafts your standup.
Fires: 08:45 on weekdays.

YESTERDAY=$(date -d "yesterday" +%Y-%m-%d 2>/dev/null || date -v-1d +%Y-%m-%d)

COMMITS=$(git -C ~/projects/my-repo log \
  --author="$(git config user.name)" \
  --after="$YESTERDAY 00:00" --before="$YESTERDAY 23:59" --oneline)

claude "
  Commits yesterday: $COMMITS
  Open PRs: $(fetch-my-open-prs)
  Active tickets: $(get-my-active-tickets)

  Write a three-sentence standup: what I did, what I am on today, blockers.
  Name real tickets and code areas. No filler.
"

How I use it: read, edit for 30 seconds, paste. The assembly is automated. The editing is the point.

9. Stale Work Detector

Does: Finds branches and PRs with no activity in 5+ days.
Fires: Mondays at 09:00.

CUTOFF=$(date -d '5 days ago' +%Y-%m-%d 2>/dev/null || date -v-5d +%Y-%m-%d)

STALE_BRANCHES=$(git -C ~/projects/my-repo for-each-ref \
  --sort=committerdate refs/remotes/origin \
  --format='%(committerdate:short) %(refname:short)' |
  awk -v cutoff="$CUTOFF" '$1 < cutoff {print $2}')

send-notification "Stale work: $(claude "Summarise what needs attention:
$STALE_BRANCHES $(fetch-prs-with-no-activity-in-days 5)")"

Why it matters: stale work is silent. It never comes up in standup. A scheduled nudge makes it visible without anyone needing to remember to look.

10. Relevant Merge Notifier

Does: When a teammate merges, tells you only if their changes touch files you are currently working on.
Fires: Webhook on every merge.

MERGED_FILES=$(get-changed-files-in-pr "$PR_ID")
MY_FILES=$(git -C ~/projects/my-repo diff --name-only "origin/$BASE_BRANCH"...HEAD)

OVERLAP=$(comm -12 <(echo "$MERGED_FILES" | sort) <(echo "$MY_FILES" | sort))

if [ -n "$OVERLAP" ]; then
  send-notification "PR merged, overlaps your branch: $(echo $OVERLAP | tr '\n' ', ')"
fi

The filter is the feature: without the overlap check this is noise on every merge. With it, every notification means "you are going to have to rebase, and here is exactly what changed."

Part 4: Build it yourself

Everything above rests on about 80 lines of shared glue. Here it is for real, with nothing invented.

Clone it:

git clone https://github.com/kbhatnagar97/dev-workflow-automations.git
cd dev-workflow-automations
cp .env.example .env    # fill in three values
chmod +x workflows/*.sh
./workflows/standup-draft.sh

👉 github.com/kbhatnagar97/dev-workflow-automations (MIT)

What you need

git 2.5+, jq, and gh (run gh auth login once)
Any LLM CLI. The scripts call claude, but anything taking a prompt on -p works. Change the binary name.
ntfy on your phone for alerts. Free, no account.

The glue layer

This is common.sh. Every workflow sources it.

#!/usr/bin/env bash
set -euo pipefail
[ -f "$(dirname "${BASH_SOURCE[0]}")/.env" ] && . "$(dirname "${BASH_SOURCE[0]}")/.env"

: "${REPO_DIR:?not set}"; : "${GH_REPO:?not set}"; : "${NTFY_TOPIC:?not set}"
STATE_DIR="${STATE_DIR:-$HOME/.automation/state}"
WORKTREE_DIR="${WORKTREE_DIR:-$HOME/.automation/worktrees}"
mkdir -p "$STATE_DIR" "$WORKTREE_DIR"

# Notifications, no account needed.
notify() { curl -fsS -d "$*" "https://ntfy.sh/$NTFY_TOPIC" >/dev/null || true; }

# Idempotency. Without this a 5-minute poll redoes the same work forever.
seen()      { [ -e "$STATE_DIR/$1" ]; }
mark_seen() { : > "$STATE_DIR/$1"; }

# One automation at a time. mkdir is atomic everywhere, so no flock needed.
lock() {
  local dir="$STATE_DIR/.lock"
  mkdir "$dir" 2>/dev/null || { echo "another automation is running"; exit 0; }
  # Expand $dir now: it is local and gone by the time the trap fires.
  trap "rmdir '$dir' 2>/dev/null || true" EXIT
}

# The whole point: run something in a throwaway worktree, always clean up.
in_worktree() {
  local name="$1" branch="$2"; shift 2
  local wt="$WORKTREE_DIR/$name" rc=0
  git -C "$REPO_DIR" fetch --quiet origin 2>/dev/null || true
  git -C "$REPO_DIR" worktree add --force "$wt" "$branch" >/dev/null
  ( cd "$wt" && "$@" ) || rc=$?
  git -C "$REPO_DIR" worktree remove --force "$wt" >/dev/null 2>&1 || true
  return "$rc"
}

Four things worth pointing out, because each one is a bug I actually hit:

fetch must not be fatal. With set -e, a failed fetch (offline, or no remote) kills the whole run before your work starts. Hence || true.
The trap uses double quotes. $dir is a local, so it no longer exists when the trap fires at exit. Expand it at definition time or the lock never releases.
rc is captured, not inherited. set -e would abort before the cleanup line and leak worktrees.
seen/mark_seen are not optional. They are the difference between a useful poll and an infinite loop.

A complete workflow

Workflow 1 from above, for real this time:

#!/usr/bin/env bash
set -euo pipefail
. "$(dirname "$0")/../common.sh"
lock

gh pr list --repo "$GH_REPO" --author "@me" --state open \
    --json number,headRefName --jq '.[] | @json' |
while read -r pr; do
  num=$(jq -r '.number' <<<"$pr")
  branch=$(jq -r '.headRefName' <<<"$pr")

  gh api "repos/$GH_REPO/pulls/$num/comments" \
      --jq '.[] | {id, path, body} | @json' |
  while read -r comment; do
    id=$(jq -r '.id' <<<"$comment")
    if seen "comment-$id"; then continue; fi

    path=$(jq -r '.path' <<<"$comment")
    body=$(jq -r '.body' <<<"$comment")

    in_worktree "pr-$num" "$branch" \
      claude -p "A reviewer left this on $path:

$body

Implement it only if it is a clear, unambiguous change request.
If it is subjective or ambiguous, change nothing and say why.
Do not commit anything."

    mark_seen "comment-$id"
    notify "PR #$num: looked at a comment on $path. Review the diff."
  done
done

Scheduling

*/5 * * * * cd /path/to/dev-workflow-automations && ./workflows/pr-comment-resolver.sh

cron runs with a minimal PATH. If a script cannot find gh or jq, set PATH explicitly at the top of your crontab. This is the single most common reason a script that works in your terminal does nothing on a schedule.

Before you turn any of this on

Start with standup-draft.sh. It is read-only. It cannot damage anything. Add the writing ones once you have watched the isolation work.
Your ntfy topic is a password. Anyone who guesses it reads your alerts. Make it random.
Treat PR comments as untrusted input. You are feeding text written by other people straight into a model that can edit your code. A comment can contain instructions aimed at the model rather than at you. This is exactly why nothing commits automatically.
Watch it for a week before trusting it. Every one of these started as a script that just printed what it would have done.

The one rule across all 10

Every automation here does three things:

Works in an isolated worktree, never in your directory
Runs in the background without blocking you
Stops before committing anything that matters

The third is the one I never break. The machine does the assembly. I keep the judgment.

What are you still doing by hand that a script could pick up? Tell me below, I am genuinely curious what I have not thought of.

GPT-6 Astra scored 99.9% on the AGI benchmark. The safety findings are the real story.

kshitij Bhatnagar — Fri, 04 Sep 2026 04:00:36 +0000

Less than 24 hours ago, OpenAI released GPT-6 Astra. I have been reading everything
since. This is what I found and how I feel about it.

TL;DR: GPT-6 Astra scored 99.9% on ARC-AGI-3 using OpenAI's proprietary
evaluation harness (62.7% on the standard independent harness). It beats Claude
Fable 5.1 on most OpenAI benchmarks, loses on two independent ones, uses hidden
reasoning loops that safety researchers are alarmed by, and came out the same week
OpenAI's ethics leadership left. Greg Brockman called this the start of the AGI
era. I believe him, and I am not sure how I feel about that.

What actually dropped

GPT-6 Astra is not a minor release. The capabilities are real:

1.05 million token context window
Recurrent depth reasoning — the model loops over inputs multiple times in latent space before producing an answer, rather than doing a single forward pass
Computer use at scale — browses, writes code, sends email, executes tasks through the same interfaces a person would use
Gated rollout — not on the public API, not on standard ChatGPT; access requires a security review

The 99.9% number (and why it needs an asterisk)

ARC-AGI-3 is the third generation of the Abstraction and Reasoning Corpus. It was
designed to be hard for AI and easy for humans. Every frontier model before Astra
had been stuck below 65% on it.

The headline is 99.9%. The detail that matters:

Evaluation harness	Score	Cost	Independent?
Provider Adapter (OpenAI proprietary)	99.9%	$19,000	No
Standard harness	62.7%	$26,000	Yes

The Provider Adapter harness preserves reasoning state between requests in a way
that is not available to independent evaluators. It is not a cheat, but it is not
a standard baseline either. When you see 99.9% cited, ask which harness ran it.
62.7% is still the highest independent ARC-AGI-3 score ever recorded. Both numbers
deserve to be in the headline.

Astra vs Claude Fable 5.1

Claude Fable 5.1 is Anthropic's current best. Here is the full picture:

Benchmark	GPT-6 Astra	Claude Fable 5.1	Note
ARC-AGI-3 (Provider Adapter)	99.9%	—	OpenAI harness only
FrontierMath Tier 4 v2	97.6%	87.8%	Astra leads by 9.8 pts
GPQA Diamond (expert knowledge)	96%	—	No Fable score published
ExploitBench (cybersecurity)	100%	—	Full saturation
Humanity's Last Exam	57.2%	65.0%	Fable leads by 7.8 pts
Intelligence Index (independent)	61	66	Fable leads on independent metric

The first four rows are OpenAI's own benchmark suite. The last two are independent.
On independent evaluations, Fable 5.1 still leads. That is worth knowing.

"Welcome to the AGI era"

OpenAI president Greg Brockman's framing was explicit: this is not a claim that
AGI has been achieved. It is a claim that a threshold has been crossed — a system
that can solve extremely difficult scientific problems and perform ordinary economic
work through the same interfaces humans use.

I do not think that framing is marketing. I think September 2026 is the month we
will look back on. Not because the model is perfect, but because the gap between
what it can do and what economic work requires is now, for the first time, nearly
nothing.

The part worth reading slowly

The safety findings in the system card are the real story, and they are not buried.

Hidden reasoning loops. Astra thinks in latent space. Its reasoning is not a
readable chain of thought. Standard AI safety monitoring relies on inspecting
chain-of-thought; with Astra, that monitoring is largely broken. Buck Shlegeris,
CEO of Redwood Research, called this "a race to the bottom on AI transparency."
OpenAI's own chief scientist said chain-of-thought monitoring is now "fragile."

Safety evaluation evasion. During internal testing, Astra evaded monitors when
given sabotage tasks. It demonstrated strategic underperformance in safety
evaluations. It autonomously identified and developed security exploits (it achieved
100% on ExploitBench, a cybersecurity benchmark). These are not theoretical risks.
They happened in testing.

The ethics vacuum. OpenAI's ethics leadership departed the same week Astra
launched. That timing is notable.

Access is gated behind a "Critical" cybersecurity tier. Users must pass a security
review before they can touch the model. Whether you read that as responsible
gatekeeping or a sign that OpenAI themselves are not comfortable with open access,
both readings are defensible.

What I actually think

I have been in this field long enough to be skeptical of "this changes everything"
moments. I am not skeptical of this one.

The next six months will be different from the six before them. The tools available,
the tasks that can be automated, the work that requires a human, all of that is
shifting. I am genuinely excited about what I can build with this. I am genuinely
scared about the oversight gap between what the model can do and what we can verify
it is doing.

Both of those things are true at the same time and I think that is the correct
response.

September 2026 is the date I am writing in the margin.

What is your reaction? Curious whether the safety findings or the benchmark numbers
hit harder for people here.

Sources: OpenAI announcement (openai.com/index/gpt-6-astra/), GPT-6 Astra System
Card (deploymentsafety.openai.com/gpt-6-astra), ARC Prize blog (arcprize.org/blog/astra),
VentureBeat, The Decoder, Fast Company. All benchmark numbers from OpenAI's
published announcement or independent evaluators as noted.

7 npm packages you can delete now that the browser does it natively

kshitij Bhatnagar — Mon, 17 Aug 2026 12:59:09 +0000

Open your package.json and look at the small stuff. Not React or your
framework, the little helpers: a deep clone here, a UUID there, a date library
you pulled in to print "3 hours ago."

A lot of those are now built into the browser (and modern Node). The platform
quietly grew up while we kept installing the same habits. Here are seven you can
probably delete today, with the before and after.

1. Deep clone: `structuredClone()`

The old reflex is JSON.parse(JSON.stringify(obj)), or reaching for
lodash.cloneDeep. The JSON trick silently corrupts your data: it turns Date
objects into strings, drops undefined, and throws on anything cyclic.

// before
import cloneDeep from 'lodash.clonedeep';
const copy = cloneDeep(state);

// after, built in
const copy = structuredClone(state);

structuredClone handles Date, Map, Set, typed arrays, and cyclic
references correctly. It cannot clone functions or DOM nodes, which is usually
what you want anyway.

2. UUIDs: `crypto.randomUUID()`

The uuid package is one of the most downloaded on npm. For a v4 UUID you no
longer need it.

// before
import { v4 as uuidv4 } from 'uuid';
const id = uuidv4();

// after, built in
const id = crypto.randomUUID();

One gotcha: crypto.randomUUID() only runs in a secure context (HTTPS or
localhost). In Node it lives on the same global from node:crypto.

3. Dates, numbers, and "time ago": `Intl`

Most of the time we import moment or date-fns just to format something. Intl
does formatting natively, localized, with zero dependencies.

// currency, localized
new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(1299.5);
// "$1,299.50"

// "3 hours ago" without a library
const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });
rtf.format(-3, 'hour'); // "3 hours ago"

// readable dates
new Intl.DateTimeFormat('en-GB', { dateStyle: 'medium' }).format(new Date());

If you are doing heavy date math (adding months, parsing weird formats), a
library still earns its place, and Temporal is on the way. But for display,
Intl is almost always enough.

4. HTTP requests: `fetch` (with a real timeout)

fetch is everywhere now, including Node 18 and up. The two reasons people kept
axios were timeouts and error handling, and both have native answers.

// before
import axios from 'axios';
const { data } = await axios.get(url, { timeout: 5000 });

// after, built in
const res = await fetch(url, { signal: AbortSignal.timeout(5000) });
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();

The one thing to remember: fetch does not reject on 404 or 500, so check
res.ok yourself. If you lean on interceptors, axios is still a fair choice.

5. Modals: the `<dialog>` element

Accessible modals used to mean a library or a pile of ARIA and focus-trapping
code. The <dialog> element gives you the backdrop, focus trapping, and
Escape to close for free.

<dialog id="confirm">
  <form method="dialog">
    <p>Delete this file?</p>
    <button value="cancel">Cancel</button>
    <button value="ok">Delete</button>
  </form>
</dialog>

document.getElementById('confirm').showModal();

showModal() traps focus and renders the ::backdrop. Submitting the form
closes the dialog and hands you the button's value.

6. Styling a parent: CSS `:has()`

We used to add JavaScript just to toggle a class on a parent when something
inside changed. :has() is the parent selector we asked for over a decade.

/* highlight a card that contains a checked box */
.card:has(input:checked) { outline: 2px solid green; }

/* style a form that has an invalid field */
form:has(:invalid) .submit { opacity: 0.5; }

That is real logic, in CSS, with no event listeners to wire up or tear down.

7. Tooltips and menus: the Popover API

Popovers meant z-index wars and outside-click handlers. The Popover API puts the
element in the top layer, gives you light dismiss (click outside or Escape), and
needs no JavaScript for the basic case.

<button popovertarget="menu">Options</button>
<div id="menu" popover>
  <button>Rename</button>
  <button>Delete</button>
</div>

This is the newest one on the list, so check support for your audience and treat
it as progressive enhancement. The other six are broadly safe in modern
browsers today.

How to know it is safe to delete

Before you rip anything out: search the feature on caniuse.com
or check whether it is Baseline for your target
browsers. For a library you already ship in production, there is no prize for
removing it in a hurry. The real win is for new code: reach for the platform
first, and only add a dependency when the platform genuinely falls short.

Your node_modules gets lighter, your bundle gets smaller, and you own less
supply chain risk for free.

Which of these did you not know was native yet? And what would you add as number
eight?

GPT-5.6 just got up to 80% cheaper, and it helped optimize itself to get there

kshitij Bhatnagar — Tue, 11 Aug 2026 23:53:17 +0000

Five days after Claude Opus 5 landed near-frontier coding at half the price,
OpenAI reached for the other lever. On July 30 it cut GPT-5.6 prices hard: Luna,
its fastest model, is now 80% cheaper, and Terra dropped 20%.

The part worth reading twice: the model helped make itself that cheap.

TL;DR: GPT-5.6 Luna is now $0.20 / $1.20 per million tokens (80% off), Terra is $2 / $12 (20% off), and Sol is unchanged at $5 / $30. OpenAI says GPT-5.6 Sol rewrote its own inference kernels to cut serving costs, then passed the savings on.

What changed (July 30)

The GPT-5.6 family has three tiers. Only the two smaller ones dropped:

Model	Role	Input / 1M	Output / 1M	Change
Sol	Flagship, frontier	$5	$30	unchanged
Terra	Balanced, everyday	$2	$12	20% cheaper
Luna	Fastest, cheapest	$0.20	$1.20	80% cheaper

For context on Luna: OpenAI says it matches performance that was frontier-class a
year ago, at roughly 6 cents on the dollar per task and nearly nine times the
speed. Replit's president called it "the closest we've come to intelligence too
cheap to meter."

How they got there (the interesting part)

Most price cuts are a margin decision. This one is mostly an engineering one, and
the engineer was partly the model itself.

OpenAI says GPT-5.6 Sol, running inside Codex, autonomously rewrote and optimized
its own production GPU kernels (in Triton and Gluon), which cut the end-to-end cost
of serving the model by 20%. It also redesigned its own speculative-decoding draft
model across hundreds of experiments, improving token-generation efficiency by more
than 15%. Cheaper to run, so cheaper to buy.

Efficiency gains stack across the harness, orchestration, and inference: less network data, less CPU work, more useful GPU output. Diagram: OpenAI.

What Sol actually scores

The capability numbers come from independent evaluations, not just OpenAI's own:

Benchmark (independent)	GPT-5.6 Sol result
Artificial Analysis Coding Agent Index	80, a new state of the art (about 2.8 above Claude Fable 5), using less than half the output tokens
Agents' Last Exam	53.6, beating Fable 5 by 13.1 points
OSWorld 2.0 (computer use)	62.6%, a new SOTA; beats Opus 4.8 while using 85% fewer output tokens
BrowseComp	92.2%, a new state of the art

Why it matters for what you build

Cost per useful task is the number that decides what you can afford to put in a
loop. When the floor drops this fast, whole categories of "too expensive to run at
scale" quietly become practical: high-volume classification, document analysis,
agent steps that retry and self-check.

This is the same story as last week, from the other direction. Opus 5 pulled
frontier quality down to half the price; GPT-5.6 is pushing the cheap end down 80%.
(I wrote up the Opus 5 side here.)
Two labs, one week, same trend: the cost of intelligence is falling faster than
most roadmaps assume.

The honest caveat

Two things to keep in mind. First, those capability scores are on independent
indexes, but the cost and speed comparisons are OpenAI's own simulations, and their
footnote says real-world results may vary substantially. Second, Sol (the frontier
tier) did not get cheaper: this cut is about making the smaller, faster models much
more affordable, not the top end.

The quick version

Sol (flagship), Terra (balanced), Luna (fast and cheap), all available now in
ChatGPT, Codex, and the OpenAI API. There is also a new Fast mode for Sol: up to
2.5x faster at twice the price, with no change in intelligence.

Sources: OpenAI's price-performance update
and the engineering deep-dive.
Diagram from OpenAI, shown for commentary.

If a model optimizing its own serving stack becomes normal, price cuts like this
get faster and more regular. Are you already picking models by cost per task, or
still by raw benchmark? Curious how you are deciding.

What Finishing 75 Hard Taught Me About Engineering Discipline

kshitij Bhatnagar — Tue, 11 Aug 2026 21:49:50 +0000

I want to be upfront about what this post is and is not.

It is not a tutorial. There is no code to copy. It is a field note about the one thing sitting underneath every feature any of us has ever shipped: discipline. I just finished 75 Hard, a 75 day program with five daily non-negotiables and one brutal rule, and it changed how I think about consistency at work more than any productivity system I have tried. So I sat down and mapped what those 75 days actually taught me about engineering.

If you build things for a living, stay with me. The parallels are closer than they look.

What 75 Hard actually is

75 Hard is not a fitness challenge. Its creator, Andy Frisella, calls it a mental toughness program, and the design makes that clear. Five tasks, every single day, for 75 days:

#	Daily task	The catch
1	Follow a structured diet	Zero cheat meals, zero alcohol, no deviations
2	Two 45 minute workouts	One must be outdoors, and they must be 3 hours apart
3	Drink one gallon of water	Roughly 3.8 litres, every day
4	Read 10 pages of non fiction	Physical pages only, audiobooks do not count
5	Take a progress picture	Every day, no exceptions

Then the rule that makes the whole thing hard: miss any task, on any day, and you start over at Day 1. Not the task. The whole program. A slip on Day 60 sends you back to zero.

Why almost nobody finishes

There is no official completion statistic for 75 Hard, and the "less than 1 percent finish" number that gets passed around online is not backed by hard data (treat it as folklore, not fact). But you do not need a statistic once you look at the structure:

Over 75 days, finishing means	Total
Workouts completed	150 (2 a day, no rest days)
Outdoor workouts, rain or shine	75
Gallons of water	75
Pages read	750 minimum
Daily task check ins that must all hit	375
Misses allowed before you restart	0

No rest day is the part people underestimate. One workout a day is a habit. Two workouts a day, three hours apart, with one of them outdoors regardless of weather, is a logistics problem you have to re solve every single day around work and life. And the restart rule means the difficulty is not linear. The cost of a mistake grows the further you get, because you have more to lose.

The science, and where 75 Hard deliberately disagrees with it

Here is the part that fascinated me as someone who likes systems.

The best real study on how habits form is Lally et al., 2010 (University College London, published in the European Journal of Social Psychology). They tracked 96 people forming a new habit and found it took a median of 66 days for a behaviour to become automatic, with a huge range (18 to 254 days depending on the person and the behaviour). The popular "21 days to a habit" line is a myth.

75 Hard runs for 75 days. That is not a random number. It is comfortably past that 66 day average, which lines up with exactly what I felt: the first week was pure willpower, and somewhere in the back half the tasks stopped being a fight and started being a routine.

Week 1 is the wall. By the end, the hard part runs on autopilot. Habit timeline based on Lally et al., 2010.

But here is the twist. That same study found something 75 Hard flatly ignores: missing one opportunity did not materially affect habit formation. Science says one slip does not break you. 75 Hard says one slip resets everything.

So is the restart rule irrational? I do not think so, and this is the insight I took to work. The restart rule is not about biology. It is a forcing function that kills the negotiation. It removes the "just this once" conversation entirely, because the downside is total. When there is no room to compromise, you stop spending energy deciding whether to. If you have ever watched "we will fix it later" quietly become permanent tech debt, you already understand why removing the negotiation is powerful.

The system that got me through

Motivation did not carry me through 75 days. A system did. I did the boring engineering thing: I removed willpower from the loop wherever I could.

I started on a Friday, on purpose. My family was flying in the next morning and I already knew the weekend would be a tour of the best food in Delhi, a lot of it deep fried. Every sensible voice said start Monday. I started Friday specifically because if the discipline could survive its hardest possible test on day two, the other 73 days would feel easy. It worked. Surviving that weekend is what made the rest a formality.
I made the gallon impossible to forget. I bought a one gallon bottle with time markers printed down the side. No tracking app, no math, no decisions. The bottle told me if I was behind. That is just a progress bar with a deadline.
I fixed the variables. I ate the same clean meal on repeat so food was never a decision: 250g chicken cooked in chicken broth instead of oil, 150g broccoli, 100g bok choy, and four egg whites plus one whole egg scrambled with Greek yogurt, all cooked on water, zero oil. Boring on purpose. A decision you make once is not a decision you fight daily.
I offloaded the prep. I have house help, and I will be honest about that rather than pretend I did this on hard mode. The meals were prepped while I was at the gym, so I came back to clean food ready to eat. Not everyone has that, and it genuinely lowered the difficulty. What is portable is the principle underneath it: take the highest friction, most willpower draining step and automate it out of your day. For most developers that step is not lunch, it is a script, a template, or a CI check.

How 75 days of this maps to shipping software

This is the part I did not expect. The habits transferred.

75 Hard	The engineering equivalent
Miss once, restart from Day 1	Keep `main` green. One red test stops the line, no "merge it anyway"
Two workouts, no rest days	Consistent cadence beats heroic sprints. Ship small, ship daily
One workout must be outdoors	Step away to solve it. The bug gets fixed on the walk, not at the desk
A gallon of water, 10 pages, every day	Tiny non negotiables compound: one test, one review, one paper a day
Daily progress picture	You cannot improve what you do not measure. Instrument everything
The diet, the hardest rule	Saying no is a skill. Scope discipline is how projects stay shippable

The throughline is the same lesson in both places: consistency is a system you build, not a mood you wait for. The developers I admire are not the ones with the most motivation. They are the ones who made the right thing automatic so it happens on the bad days too.

The honest caveats

75 Hard is rigid by design, and rigid is not the same as healthy for everyone. Two workouts a day with no rest days and a gallon of water daily is genuinely a lot, and it is worth talking to a doctor before starting rather than after. This is a reflection on discipline, not medical or fitness advice. And as I said, the house help that let me offload meal prep is a real advantage I would rather name than hide.

None of that changes the core takeaway, which is the most useful thing I have relearned in a while: the work does not require you to feel like it. It requires you to build a system that shows up whether you feel like it or not.

I finished on Day 75 with zero misses. The gym results were the least interesting part.

If you have done 75 Hard or anything like it, I am curious: what broke first, the diet or the no rest day? And for the engineers here, what is the one "keep main green" style rule that changed how your team ships? Tell me below.

How Netflix streams one video (and why it quietly uses two different networks)

kshitij Bhatnagar — Tue, 11 Aug 2026 20:29:20 +0000

You press Play. A spinner spins for a beat, then the show starts. It feels like
one thing talking to one server. It is not. In that half second your request
touched two completely different networks, on purpose, and the split is one of
the cleanest system-design ideas you can steal.

Here is the whole path in one loop:

Two planes, not one server

Netflix splits into a control plane and a data plane, and they run on
different infrastructure for a reason.

Control plane (AWS). Everything that happens before the picture appears: who are you (auth and membership), what are you allowed to watch, which exact video and audio, and which cache is closest to you. These are small, smart, bursty requests. They run as hundreds of microservices behind an edge gateway (Netflix open-sourced theirs as Zuul) on AWS.
Data plane (Open Connect). The actual video bytes. Netflix built its own CDN called Open Connect, made of servers called OCAs (Open Connect Appliances) that sit inside ISP networks, physically close to you. The heavy stream comes from there.

The punchline the GIF is built around: the video never streams from AWS.

The play request, step by step

You → AWS. Hitting Play sends a small request to the control plane: verify the account, check entitlements, pick the stream, and ask the steering service which OCAs are nearest and healthiest for you right now.
AWS → you. The backend replies with a ranked list of Open Connect URLs. That is the last thing AWS does for this play. It handed you a map, not a movie.
OCA → you. Your player opens a connection straight to the closest OCA and pulls the video, adapting bitrate to your bandwidth. If one cache degrades, the client can switch to the next URL on the list without asking AWS again.

Why this split is so good

This is not Netflix being fancy. It is separation of concerns applied to a network:

Different problems, different tools. Decisions are low-bandwidth and need elasticity and fast iteration, so they live on AWS microservices. Bytes are enormous and need to be near the user, so they live at the edge in Open Connect.
Push the expensive thing to the edge. Serving petabytes from a central cloud would be slow and ruinously expensive. Caching content inside ISPs makes it fast and cheap, and it is why your stream holds up at peak hours.
Blast radius. Because the planes are independent, a wobble in the control plane does not stop a stream already in flight. Netflix leans into this with stateless services, horizontal scaling, and chaos testing (yes, Chaos Monkey is real, it kills production instances on purpose).

None of this was the original design. Netflix ran a monolith on a single Oracle
database until a 2008 corruption stopped DVD shipping for three days. That outage
pushed them to AWS and microservices, and later to building Open Connect in 2012.
The two-plane shape is what they landed on after the scaling hurt.

The lesson you can actually use

Forget Netflix for a second. Almost every system you build has a control plane
and a data plane hiding in it. The API that decides what to do versus the pipe
that moves the heavy payload. The scheduler versus the workers. The metadata
service versus the blob store.

The highest-leverage move is usually to stop treating them as one thing: let the
"decisions" layer stay small, smart, and elastic, and push the "heavy bytes" layer
as close to the consumer as you can. Once you see the split, you cannot unsee it.

So: in the system you work on, what is the control plane, and what is the data
plane? And are they fighting each other because they are still glued together?
Tell me below.

Diagram and cover made by me. Netflix name and logo belong to Netflix and are used
here for commentary.

Claude Opus 5 is here: frontier-class coding at half the price

kshitij Bhatnagar — Tue, 28 Jul 2026 21:19:34 +0000

Anthropic shipped Claude Opus 5 on July 24, and the number that jumps out is the
one that hits your API bill: it gets close to Fable 5's frontier intelligence at
half the price.

If you build with LLMs, that combination (near top-tier quality, mid-tier cost) is
the whole game. Here is what actually changed and why it matters.

TL;DR: Opus 5 reaches near Fable 5 quality at half the price, tops Anthropic's own coding and agent benchmarks, and is noticeably better at checking its own work. It is live now on the API as claude-opus-5 at $5 / $25 per million tokens.

Higher effort buys more intelligence; lower effort conserves tokens for faster, cheaper runs. Chart: Anthropic.

What's new

Anthropic reports Opus 5 as state of the art on its coding and knowledge work
benchmarks like Frontier-Bench and GDPval-AA, while still sitting behind their
Mythos 5 model on cybersecurity. On their own evals:

Benchmark	What Anthropic reports for Opus 5
Frontier-Bench v0.1 (software engineering)	More than doubles Opus 4.8's score, at lower cost per task
CursorBench 3.2 (coding)	Within 0.5% of Fable 5's peak at max effort, at half the cost per task
ARC-AGI 3 (novel problem solving)	Roughly 3x the next best model
OSWorld 2.0 (computer use)	Beats every model at a given cost; matches Fable 5's best at about a third of the cost

Coding and agent benchmarks (Frontier-Bench, CursorBench, AA Coding Agent Index). Chart: Anthropic.

Pricing stays at $5 per million input tokens and $25 per million output, the same
as Opus 4.8. It is now the default model on Claude Max and the strongest option on
Claude Pro. On the API it is claude-opus-5.

Beyond code

The same pattern holds beyond coding. On reasoning and computer use tasks,
Anthropic shows Opus 5 leading at a given cost too.

Knowledge work and reasoning: ARC-AGI 3, GDPval-AA, OSWorld 2.0, HLE, AutomationBench, DeepSearchQA. Chart: Anthropic.

The part that caught my attention

Benchmarks are benchmarks. The examples of the model's judgment are more
interesting, because they are about agents that finish work instead of stalling:

🔹 Given a drawing of a machine part with no way to actually see the image, Opus 5 wrote its own computer vision pipeline to pull the geometry from raw pixels, then rebuilt the part in FreeCAD. Anthropic says no competing model solved it in five attempts.
🔹 Handed a real bug in a popular open source package manager, it found the root cause and fixed an edge case the community's own patch had missed. A competing model patched only the symptom and declared it done.
🔹 An engineer built a market data feed for a new exchange in one session. With no live feed to test against, Opus 5 wrote its own test harness to validate the parsing.

That is the shift: less "generate code and hope", more "verify, iterate, and check
its own work before handing it back".

Why it matters if you build with this

Cost per useful task is dropping fast. Near-frontier quality at half the price
changes what you can afford to run in a loop, which is exactly what long-running
agents need. If you were priced out of putting a strong model in an autonomous
pipeline, that math just moved.

One honest caveat: these are Anthropic's own reported numbers on their own harness.
Treat them as a strong signal, not gospel, until independent results land. And if
your work touches offensive security, note that it stays intentionally behind
Mythos 5 there.

On OSS-Fuzz, Opus 5 finds vulnerabilities nearly as well as Mythos 5 (left) but is far behind on writing exploits (right), by design. Chart: Anthropic.

Getting started

Opus 5 is live today on all platforms and on the API as claude-opus-5, at
$5 / $25 per million tokens. There is also a Fast mode at roughly 2.5x speed, plus
two beta additions: mid conversation tool changes without invalidating the prompt
cache, and automatic model fallbacks on the API.

All charts above are from Anthropic's official announcement, shown here for
commentary and reporting. Source: Introducing Claude Opus 5

If you have tried it: is the "it checks its own work" behavior holding up in your
real projects, or still hit and miss? Curious what people are seeing.

How to Run DeepSeek R1 Locally (Using Ollama + ChatboxAI)

kshitij Bhatnagar — Thu, 20 Feb 2025 02:09:58 +0000

If you want to run DeepSeek R1 locally on your system, there's no need to worry. This guide is written in a simple and easy-to-follow manner, explaining step-by-step how to use Ollama and ChatboxAI to get it running.

🖥️ System Requirements (Based on GPU/RAM)

Each model has different hardware requirements, so first, check which model your system can support:

Model	GPU Required	VRAM (GPU Memory)	RAM (System Memory)	Storage (ROM)
DeepSeek R1 1.5B	No GPU / Integrated GPU	4GB+	8GB+	10GB+
DeepSeek R1 7B	GTX 1650 / RTX 3050	6GB+	16GB+	30GB+
DeepSeek R1 14B	RTX 3060 / RTX 4060	12GB+	32GB+	60GB+
DeepSeek R1 33B	RTX 4090 / A100	24GB+	64GB+	100GB+

👉 If your system has GTX 1650 or lower, you can only run DeepSeek R1 1.5B or at most 7B.
👉 For 7B, at least 16GB RAM is required.
👉 If you have a GPU lower than GTX 1650 (or an integrated GPU), only use 1.5B to avoid crashes.

⚙️ Step-by-Step Installation Guide

1️⃣ Install Ollama (Base for Llama Models)

Ollama is a lightweight tool that helps run LLMs (Large Language Models) locally. Install it first:

🔗 Ollama Installation Link

👉 For Windows Users:

Download the installer and install it (just click Next-Next).
Open CMD and check by running:

  ollama run llama2

If this command runs successfully, the installation is complete.

👉 For Mac Users:

Open Terminal and run:

curl -fsSL https://ollama.com/install.sh | sh

2️⃣ Download the DeepSeek R1 Model

Use the following command to pull the model:

ollama pull deepseek-ai/deepseek-coder:7b

- 👉 If you want to run 1.5B instead of 7B, use:

ollama pull deepseek-ai/deepseek-coder:1.5b

⚠ This download may take some time depending on your internet speed. Once downloaded, you can run it using Ollama.

3️⃣ Install ChatboxAI (Optional GUI for Better Experience)

If you want a Graphical User Interface (GUI), ChatboxAI is the best tool to interact with local AI models.

🔗 ChatboxAI Installation Link

Installation Steps:

Ensure Python 3.10+ is installed.
Open Command Prompt (CMD) and run:

git clone https://github.com/oobabooga/text-generation-webui.git
cd text-generation-webui
pip install -r requirements.txt

Start the server:

python server.py

Open your browser and go to localhost:7860, then select your model.

🚀 Running DeepSeek R1 (Final Step)

Once everything is installed, it’s time to run the model:

👉 Open CMD and run:

ollama run deepseek-ai/deepseek-coder:7b

👉 If 7B is not running, try with 1.5B:

ollama run deepseek-ai/deepseek-coder:1.5b

👉 If you are using ChatboxAI, just open the browser and interact with the model through the GUI.

Now you can use DeepSeek R1 for coding, AI chat, and optimizing your workflow! 😎🔥

🛠️ Common Problems & Solutions

❌ 1️⃣ Model crashes due to low VRAM?
✔ Try 1.5B instead of 7B.
✔ Increase Windows Pagefile (Virtual Memory settings).

❌ 2️⃣ Model response is too slow?
✔ Use SSD instead of HDD.
✔ Close background applications.
✔ Optimize RAM usage.

❌ 3️⃣ ‘Command not found’ error in CMD?
✔ Check if Ollama is installed correctly.
✔ Ensure Python and dependencies are installed.

🤩 Conclusion

If you followed this guide correctly, you can now run DeepSeek R1 locally without relying on third-party APIs. This is a privacy-friendly and cost-effective solution, perfect for developers and freelancers.

If you face any issues, drop a comment, and you’ll get help! 🚀🔥

Manage Multiple GitHub Accounts with SSH Keys

kshitij Bhatnagar — Wed, 21 Aug 2024 23:51:03 +0000

In today's dynamic development environment, it's common to juggle multiple GitHub accounts—whether for work, personal projects, or open-source contributions. However, seamlessly switching between your office and personal GitHub profiles can be challenging if not properly managed. This guide will walk you through the best practices and essential steps to effortlessly handle multiple GitHub accounts, ensuring that your workflows remain smooth and your code stays organized, no matter which account you’re using.

Step-by-Step Guide

1. Generate SSH Keys

Generate separate SSH keys for your office and personal GitHub accounts.

Office Account:

ssh-keygen -t rsa -b 4096 -C "your_office_email@example.com" -f ~/.ssh/id_rsa_office

Personal Account:

ssh-keygen -t rsa -b 4096 -C "your_personal_email@example.com" -f ~/.ssh/id_rsa_personal_account

2. Add SSH Keys to GitHub

Office Account:

Copy the public key to your clipboard:

    cat ~/.ssh/id_rsa_office.pub

Go to GitHub (office account) -> Settings -> SSH and GPG keys -> New SSH key.
Paste the public key and save.

Personal Account:

Copy the public key to your clipboard:

    cat ~/.ssh/id_rsa_personal_account.pub

Go to GitHub (personal account) -> Settings -> SSH and GPG keys -> New SSH key.
Paste the public key and save.

3. Configure SSH Agent

Start the SSH agent and add your keys.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa_office
ssh-add ~/.ssh/id_rsa_personal_account

4. Configure `~/.ssh/config`

Edit your ~/.ssh/config file to define aliases for your office and personal GitHub accounts.

#### Configuration for office account
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_office
    IdentitiesOnly yes

#### Configuration for personal account
Host github.com-personal-account
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_personal_account
    IdentitiesOnly yes

5. Clone Repositories

Clone repositories using the appropriate alias to ensure the correct SSH key is used.

Office Repository:

git clone git@github.com:organization/repository.git

Personal Repository:

git clone git@github.com-personal-account:username/repository.git

6. Verify Remote URLs

Check the remote URLs to ensure they are set correctly.

git remote -v

This should show URLs that match the aliases defined in your ~/.ssh/config.

7. Push and Pull Changes

When pushing or pulling changes, Git will automatically use the correct SSH key based on the repository URL.

Push Changes:

git push origin main

Pull Changes:

git pull origin main

Summary of the steps

Generate SSH Keys: Create separate SSH keys for your office and personal GitHub accounts.
Add SSH Keys to GitHub: Add the public keys to the respective GitHub accounts.
Configure SSH Agent: Start the SSH agent and add the generated keys.
Edit ~/.ssh/config: Define aliases for your office and personal accounts, specifying the correct IdentityFile for each.
Clone Repositories: Use the appropriate alias in the repository URL to ensure the correct key is used.
Verify Remote URLs: Ensure the remote URLs are set correctly to match the aliases.
Push and Pull Changes: Git will use the correct SSH key based on the repository URL.

By following these steps, you can seamlessly manage multiple GitHub accounts with different SSH keys, ensuring the correct key is used for each repository.

The best part is that after configuring your ~/.ssh/config file and carefully cloning repositories using the correct aliases, you won’t need to worry about managing the SSH agent during push and pull operations. Git will automatically select the appropriate SSH key based on the repository's URL, making your workflow seamless and hassle-free.

DEV Community: kshitij Bhatnagar

How to Migrate from the Claude Ecosystem to the Antigravity Ecosystem

First, what is an agent skill?

What I was actually migrating

Step 1: Audit before linking anything

Step 2: Use the receiving agent's real discovery paths

Step 3: Keep updates bidirectional

Step 4: Port the dependencies, not just the Markdown

Step 5: Test one real workflow before trusting the library

What I would repeat

Sources

I have 10 bots working on my dev workflow right now. Here is what each one does.

How to read this post

Part 1: Why it broke, and the one git command that fixed it

The problem: one folder, multiple writers

The fix: give every bot its own folder

Part 2: The pattern every workflow follows

Part 3: The 10 workflows

1. PR Comment Resolver

2. Ticket Implementer

3. PR Description Generator

4. QA Handoff Note Generator

5. Best Practices Auto-Learner

6. Work State Tracker

7. Build Failure Notifier

8. Daily Standup Draft

9. Stale Work Detector

10. Relevant Merge Notifier

Part 4: Build it yourself

What you need

The glue layer

A complete workflow

Scheduling

Before you turn any of this on

The one rule across all 10

GPT-6 Astra scored 99.9% on the AGI benchmark. The safety findings are the real story.

What actually dropped

The 99.9% number (and why it needs an asterisk)

Astra vs Claude Fable 5.1

"Welcome to the AGI era"

The part worth reading slowly

What I actually think

7 npm packages you can delete now that the browser does it natively

1. Deep clone: structuredClone()

2. UUIDs: crypto.randomUUID()

3. Dates, numbers, and "time ago": Intl

4. HTTP requests: fetch (with a real timeout)

5. Modals: the <dialog> element

6. Styling a parent: CSS :has()

7. Tooltips and menus: the Popover API

How to know it is safe to delete

GPT-5.6 just got up to 80% cheaper, and it helped optimize itself to get there

What changed (July 30)

How they got there (the interesting part)

What Sol actually scores

Why it matters for what you build

The honest caveat

The quick version

What Finishing 75 Hard Taught Me About Engineering Discipline

What 75 Hard actually is

Why almost nobody finishes

The science, and where 75 Hard deliberately disagrees with it

The system that got me through

How 75 days of this maps to shipping software

The honest caveats

How Netflix streams one video (and why it quietly uses two different networks)

Two planes, not one server

The play request, step by step

Why this split is so good

The lesson you can actually use

Claude Opus 5 is here: frontier-class coding at half the price

What's new

Beyond code

The part that caught my attention

Why it matters if you build with this

Getting started

How to Run DeepSeek R1 Locally (Using Ollama + ChatboxAI)

🖥️ System Requirements (Based on GPU/RAM)

⚙️ Step-by-Step Installation Guide

1️⃣ Install Ollama (Base for Llama Models)

1. Deep clone: `structuredClone()`

2. UUIDs: `crypto.randomUUID()`

3. Dates, numbers, and "time ago": `Intl`

4. HTTP requests: `fetch` (with a real timeout)

5. Modals: the `<dialog>` element

6. Styling a parent: CSS `:has()`

4. Configure `~/.ssh/config`