Alhimik

polymarket degen | the math under the money

[Alhimik @0xAlhimik]

STOP PAYING FABLE PRICES FOR EVERY TURN.

Fable 5.2 is the best model you can run in Claude Code right now. it's also $8/$40 per million tokens. putting every turn on it means paying Fable rates for file reads and grep.

the fix is one launch line:

claude --model sonnet --advisor fable

here's the team:

→ Sonnet 5.5 runs the session and writes the code
→ Haiku 5.5 subagents map the repo, find call sites, pull docs
→ Fable 5.2 stays on call and reads the whole transcript only when consulted

Fable wakes up at three moments:

→ before a plan locks
→ when the same error shows up twice
→ before anything gets called done

Sonnet builds. Haiku scouts. Fable decides.

two things the setup posts skip:

> Claude decides when to call the advisor. no setting forces it. the CLAUDE.md line is your only lever
> if you never see "Advising" in the transcript, it isn't on. check for DISABLE_TELEMETRY first

paste this into Claude Code ↓

"Set up my Claude Code as a 3-model team at user level:
1. Main session on Sonnet 5.5, Fable 5.2 as advisor (advisorModel: fable).
2. Create three Haiku subagents in ~/.claude/agents/ with model: haiku: scout (maps the repo) and grep (finds call sites) with tools Read, Grep, Glob; docs (pulls API references) with Read and WebFetch.
3. Add to my user CLAUDE.md: consult the advisor before locking a plan, after the same error twice, and before calling a task done.
4. Check my env for anything that turns off feature flags.
Show every change as a diff first. No edits until I say go."

the full Fable 5.2 guide is below ↓

[codila @0xCodila]

Claude Fable 5.2 is the most insane AI model in history...

99% of people will never touch it or burn money on it: "Too expensive", "Not for me"

Use it right, and it becomes your second BRAIN, for a fraction of the price

In this article, I show you how: https://t.co/5IFdgKfq4V

[Alhimik @0xAlhimik]

you turned on Fable 5.2 as your Claude Code advisor. it might be getting called 0 times, and nothing will tell you.

I read Anthropic's advisor docs line by line. four ways it goes quiet:

→ an env var that turns off feature-flag fetching, like DISABLE_TELEMETRY. the advisor just stays off
→ the API refuses your model pairing. Claude Code resends without the advisor. no error, no calls
→ Fable on a plan that bills usage credits, and you never accepted the one-time consent. requests go out without it
→ your advisor ranks below your main model. it never gets attached

and even when it works, no setting forces a call. Claude decides when. your instructions are the only lever.

so the setup isn't "/advisor fable" and done. it's three checks:

1. env is clean
2. pairing is valid: Sonnet 5.5 or Opus 5.5 main, Fable advisor
3. one line in CLAUDE.md that says when to consult it

then watch the transcript for "Advising". no line, no advisor.

paste this into Claude Code ↓

"Check whether my advisor setup actually works. Show me every change as a diff before you apply it.
1. Show my Claude Code version, main model and advisorModel from user and project settings.
2. Check my environment and settings for anything that disables feature-flag fetching, or sets CLAUDE_CODE_DISABLE_ADVISOR_TOOL.
3. Check my pairing against the table in https://t.co/8k0h6hDZGC. If the advisor ranks below the main model, say so.
4. Add to my user CLAUDE.md: 'Consult the advisor before committing to a plan, when the same error happens twice, and before saying a task is done.'
5. Give me a 2-minute test task that needs the advisor, so I can watch for the Advising line and check /usage after."

Fable 5.2 at $8/$40 per million is only worth it if it actually gets called.

[codila @0xCodila]

Claude Fable 5.2 is the most insane AI model in history...

99% of people will never touch it or burn money on it: "Too expensive", "Not for me"

Use it right, and it becomes your second BRAIN, for a fraction of the price

In this article, I show you how: https://t.co/5IFdgKfq4V

[Alhimik @0xAlhimik]

your Claude Code project forgets why you made every call. one file fixes it.

three months from now you'll ask "why did we turn off auto-publish?" and a fresh session will give you a confident, reasonable, made-up answer.

the fix is boring: a decisions.md that CLAUDE.md points to, and one rule. no entry, no answer.

every entry is four lines:

→ decision: auto-publish off
→ why: a "fresh" brief could ship yesterday's prices
→ proof: the broken draft + the price snapshot
→ reopen when: the publisher blocks stale snapshots

that last line is the one everyone skips. without it a decision never gets revisited, it just gets re-argued.

paste this into Claude Code in your project ↓

"Set up a decision log for this project:
1. Create decisions.md. Each entry: date, decision, why, proof (file path), reopen when.
2. Create evidence/ and keep the files each decision points to.
3. Add a rule to CLAUDE.md: for any 'why did we...' question, answer only from decisions.md and name the entry. No entry? Say 'not logged' and stop.
4. Read the git history and draft entries for the 5 biggest decisions. Show me before saving."

then ask about something you never logged. if it says "not logged", it works.

[Bober_smart @Bober_smart]

https://t.co/WRvaPXgqIa

[Alhimik @0xAlhimik]

ASK A FRESH CLAUDE CHAT WHY YOU KILLED A FEATURE.

“Why did we turn off auto-publish for the market brief?”

Say you stopped it because yesterday’s prices could still appear under today’s date. You could save “auto-publish is off” and be back in the same debate next month. Or you could save the failure and the condition for turning it back on.

I’d put four lines in decisions.md:

→ Decision: Keep auto-publish off.
→ Reason: A fresh brief can contain stale prices.
→ Evidence: Link the draft that exposed the problem and its source snapshot.
→ Reopen when: The publisher blocks a brief if the price snapshot is too old.

Put the link to decisions.md in your project’s CLAUDE.md. Keep the original draft and source snapshot together under evidence/. Now a new session has somewhere to look when you ask why you made the call.

Paste this into Claude Code in your project folder ↓

“Read CLAUDE.md and find the latest decision about auto-publish. Tell me what we decided, why, and what would make us revisit it. Give me the decision file and the original evidence path. If either is missing, say which one. Flag any later entry that changes the decision.”

Then ask about a decision you never logged. That’s the useful test. Claude can still give you a plausible answer, so open the file it cites and see if the reason is actually there.

[Bober_smart @Bober_smart]

https://t.co/WRvaPXgqIa

[Alhimik @0xAlhimik]

IF THE SOURCE IS MISSING, THE EXPORT SHOULD FUCKING FAIL.

In the clip, a market brief says $840K traded. The chart looks clean. The number looks plausible. Then you open the data file and it only has prices.

The local exporter rejects the draft. Remove the $840K line and it saves the brief with the one claim the file actually supports. That’s a test run on sample data, with the cursors animated over it.

“Always cite your sources” is the kind of instruction you can type three mornings in a row and still find yourself checking by hand on the fourth. This is where mojesko’s Claude Code setup gets interesting. Each kind of instruction has somewhere to live.

→ CLAUDE.md gives a fresh session the project map and the rules that apply everywhere.
→ .claude/rules/ puts your sourcing rule on drafts/**, where it actually matters.
→ A skill holds the steps for assembling and reviewing the brief.
→ Auto memory can carry preferences Claude picks up across sessions. You can inspect what it saved with /memory.

Then take the one thing you absolutely need to hold and put it in the action itself. In this example, the exporter checks that the source exists and matches the structured claim before it writes the file. The editor can forget the rule. The exporter runs the same check anyway.

Try it with a fresh session and a deliberately broken draft. Leave a number in, pull its source out, and see if you can still export. That test tells you exactly which part of your workflow is carrying the rule.

[mojesko @mojeskoqq]

https://t.co/YBUeYgXyjc

[Alhimik @0xAlhimik]

THE TRADE YOU DIDN’T TAKE IS THE ONE YOUR AI SHOULD REMEMBER.

Open a fresh Claude Code session and ask it one thing.

“Why did we skip the 62¢ entry?”

In the sample vault below, the book shows 62¢ with only 20 shares available. The next 80 cost 68¢. Taking all 100 would have cost $66.80 before fees, above the 65¢ average price cap in the decision log.

Imagine opening that market again three days later. The price is back at 62¢. You remember skipping it, but was the price too high? Was there too little size? Did the rules change? Those are three very different reasons to stay out.

I’d give every project one folder and save the part that always gets lost between chats.

→ CLAUDE.md tells a fresh session where to look.
→ decisions.md records what we decided, why, and what would make us revisit it.
→ raw/ holds the dated evidence the decision came from. In this case, the order book.

Then ask Claude for the decision, the source file, and the condition that would reopen it. Open the source and check the numbers yourself. If the book is stale, pull a fresh one and run the math again. The old note explains yesterday’s call. Today’s call needs today’s evidence.

The clip is a local replay on test data. Try the same thing with a real decision from last week. Close the chat, open a fresh session in that folder, and ask why you made the call. If the answer points you to the file you’d use to defend it, the folder is doing its job.

[Ryven @imryven]

https://t.co/KiA3TzMWPs

[Alhimik @0xAlhimik]

IF YOU’RE PASTING THE SAME FUCKING INSTRUCTIONS INTO CLAUDE CODE, SAVE THE WORKFLOW.

I built a sample vault from five Anthropic repos. The question at the end of the clip is one I’d actually ask: how do I make source ingest repeatable? The answer leads back to the Skills notes, and those notes link to the exact sections they came from.

Here’s what I’d take from each repo.

1. Skills. Turn a job you do every week into a folder with a SKILL.md, examples and any scripts it needs. My first one would take a saved article, write a short note and link it to the ideas already in the vault.
https://t.co/iGsHgs7TxH

2. Claude Code Action. Give Claude a GitHub issue or PR with enough context to work on it. Start with a small fix and an acceptance test you can check yourself.
https://t.co/oxBqFvyP8S

3. Security Review. Run a focused pass over a PR diff. Open the lines behind each finding and decide whether it’s real.
https://t.co/v7W2ykkC5I

4. Agent SDK for Python. Use this when the workflow belongs inside your own app. Pick which tools the agent can call and use a hook for a rule you want code to enforce.
https://t.co/pBPyCUOHYh

5. Cookbooks. Grab a retrieval or tool-use notebook and adapt one example to your files. Give it a question that needs two sources and see what it brings back.
https://t.co/C9lcNnLp4R

For the vault itself, I’d start with five sources. Keep the originals in raw/, the linked notes in wiki/, and the answers you plan to reuse in output/. Ask one question and follow the citations all the way back to the source. That’s the part I’d get right before adding more files.

The clip is a local replay of the sample vault. Ryven’s article below walks through the Claude + Obsidian setup. I put a starter ingest prompt in the first reply ↓

[Ryven @imryven]

https://t.co/KiA3TzMWPs

[Alhimik @0xAlhimik]

ONE CHECK FAILED. WHY THE F*CK WOULD YOU RERUN ALL EIGHT?

I gave a Polymarket research graph an 11-minute-old quote. I’d set a 60-second cutoff. The rules, deadline and five other checks passed. The brief still had to wait because the price was stale.

Watch the red branch in the clip. It loops back while the seven green checks stay put. I load a second snapshot with the same price and the same order book, this time just 12 seconds old. One check runs again. All eight pass and the brief waits for my review.

Here’s what I’d put in the instructions for an agent building one of these:

1. Name what each check reads. Quote age needs a timestamp. Spread needs the bid and ask. The rules check needs the market’s rules.
2. Save each result alongside the inputs it actually saw. When I open the brief later, I want to see which version of the data passed.
3. On a failure, show the exact value that tripped the check. Fix the input and rerun every check that used a field you changed.
4. Cap the retries. If you’re still stuck, tell me what’s blocking you. When everything passes, hand me the brief for review.

The third step is the one I’d test first. If the replacement snapshot had come with a different order book, every check that used the book would go back in the queue too. I could keep seven results in this run because only the timestamp changed.

[Hoodie @HoodieFade_]

Your agents can already work for hours without you

But you still check every step they take

Because you have a loop, but no graph

I broke down how to build a system where you only approve the last step ↓ https://t.co/x0Kg0o0Clp

[Alhimik @0xAlhimik]

STOP OPENING EVERY FUCKING BOT CHAT TO FIND THE ONE THAT NEEDS YOU.

An agent can finish its part and wait for your decision while you think the whole team is still working.

That update shouldn't be buried in a conversation you haven't opened.

Give the team one place to report back.

We designed a 3D office with a floor for each team and a desk for each agent. Selected agents show their latest status and last step.

→ Working: leave it alone.
→ Needs you: find the decision holding it up.
→ Error: inspect what failed.
→ Done: see what's ready to review.

The room, roster and activity feed update together. When you wire up the feed, make sure old updates get marked stale.

Now the question is simple: who actually needs my attention?

The video is our original rendered concept with test events; it isn't a connected Grok Bot session or a token-usage measurement.

Start with one team. Send an error event. Check that you can find the affected agent and see what happened.

Setup prompt in the first reply. Full agent-team guide in the article below ↓

[Anatoli Kopadze @AnatoliKopadze]

https://t.co/ptUoYuEW7n

[Alhimik @0xAlhimik]

@ScottyBeamIO @poteto if two bots can say “i thought the other one handled it,” you’ve successfully automated office politics

[Alhimik @0xAlhimik]

@kinderlayer show the move history too. i want to see who solved the cube and who just repainted it

[Alhimik @0xAlhimik]

@A_Pirate_I the missing stat: how much of the whale’s edge survived the delay between their buy and your fill? smart wallet ≠ smart entry

[Alhimik @0xAlhimik]

YOUR AI TEAM SHOULDN'T NEED A FUCKING ROLL CALL.

Which bot is working? Which one is stuck? Which one finished an hour ago and is still waiting for you?

Give the team an office you can actually look into.

We built a 3D status viewer: three floors, a desk for each agent, and a feed that changes what you see in the room.

→ A bot needs input? It lights up amber.
→ A task fails? The agent turns red and its last step stays visible.
→ Click a bot to inspect its status and latest event.

The useful part is the small message behind the animation:

"Scout started checking sources."
"Builder hit an error."
"Reviewer needs your decision."

One event changes the room, the roster and the activity feed together. An old update is marked stale, so a quiet bot doesn't silently pass for a healthy one.

The video is a rendered replay of our viewer's test events. It isn't footage of connected Grok Bots, and it doesn't measure their token usage.

Start with one team's status feed. Make sure you can spot a failure before adding the rest.

Setup prompt in the first reply. The full team-building guide is in the article below ↓

[codila @0xCodila]

https://t.co/xqOqV9xkpp

[Alhimik @0xAlhimik]

AMAZON CAN BLOCK GROK BOT. IT CAN'T MAKE YOU SHOP THERE

A shopper posted Amazon's "unauthorized AI agent" notice. Musk's response: send the Bot to another store.

Now Grok Bot has product cards, Shop Pay support and delivery tracking. That makes the obvious next request a lot more interesting:

"Here's the TV I want. Find the exact model elsewhere. Compare the delivered price. Bring me the order to approve."

One product link becomes a job: find it, compare it, prepare checkout, follow the shipment.

6 commands worth keeping:

→ TV: "Same model and size. Compare three sellers. Include delivery and flag refurbished units."
→ Shoes: "My size, under $90. Three options. Show the trade-off with each."
→ Gifts: "Under $50, here by Friday. Check the arrival estimate before recommending it."
→ Restock: "Every month, compare this exact coffee pack. Bring the best option back for approval."
→ Price watch: "Check this monitor daily. Notify me below $250 delivered."
→ Parcels: "Tell me when an order is late. Handle the tracking checks between updates."

Store access varies. Check the seller, item and final total before approving payment.

Your usual store should have to earn the next order.

The video illustrates the workflow with example offers. The article below explains how to turn jobs like this into a Bot routine you can actually trust ↓

[Mori @0xjmori]

Grok Bot could be the operating layer AI agents have been missing.

It can use tools, run routines and coordinate other agents with minimal supervision.

In this article, I show you how. https://t.co/zsznjlGC3m

[Alhimik @0xAlhimik]

F*CK PAYING THE FIRST PRICE AMAZON SHOWS YOU.

Grok Bot now has shopping cards, checkout and delivery tracking. Give it the product. Make it bring back the alternatives before you touch Buy.

The useful part: one request can carry the whole job. Exact model. Final price. Delivery date. Then your approval.

6 shopping jobs I'd hand it first:

→ Price check: "Match this exact headset across stores. Include shipping. Flag refurbished listings."
→ Shortlist: "Three waterproof jackets under $120, in my size. Show what I'd give up with each."
→ Price watch: "Check these speakers once a day. Tell me when the delivered total falls below $150."
→ Gifts: "Find three gifts under $40 that can reach me by Thursday. Verify the delivery estimate."
→ Restock: "Check my coffee every four weeks. Compare the same pack size and bring me an order to approve."
→ Delivery: "Track my orders. Send one update when a shipment slips, not every time it moves."

One cheap listing means nothing if it's the wrong model or shipping eats the difference.

Put this in the brief: "Show the item, seller and full total. Ask before checkout."

The clip is an animated example with sample prices. No purchase was made.

Start with one product. Get that right before handing it a whole shopping list.

The article below covers turning one useful job into a reliable Bot routine ↓

[Mori @0xjmori]

Grok Bot could be the operating layer AI agents have been missing.

It can use tools, run routines and coordinate other agents with minimal supervision.

In this article, I show you how. https://t.co/zsznjlGC3m

[Alhimik @0xAlhimik]

@quietoraclex $500B wiped and $275B tied to one customer. S-1 receipts every night until $ANT lists is the play.

[Alhimik @0xAlhimik]

@AIDuckLabs Lauren’s point hits. If you’re still the checker, you’re the bottleneck. Self-checking team that ships 50+ updates a day is the move.

[Alhimik @0xAlhimik]

@chonkzu Grok bot flagged the Binance drain before the headlines and turned it into $50k. Speed is the only edge.

[Alhimik @0xAlhimik]

THE PARAGRAPH GREW FUCKING LEGS.

A creature walks across the page, pulls words out of the text and keeps moving while you inspect the joints.

That's the kind of explanation I want more of.

Take one question: how do a bunch of separate legs turn into a coordinated walk?

Give the answer moving parts:

→ a foot plants and holds its position
→ the body travels over it
→ the leg lifts, swings forward and lands again
→ offset the cycles and a gait starts to emerge

Now slow it down. Follow one foot. Scrub back to the moment it leaves the ground. You have something specific to question.

The Anatomy workflow in the article below starts from that idea: ask Claude Code to build an explanation people can operate, with a small model driving the movement and readouts.

Try a brief like this:

"Explain one walking cycle as an interactive object. Let me pause, scrub and slow it down. Make planted feet visibly different from moving feet. Keep the model simple and label what it leaves out."

[Elvar @elvar_official]

https://t.co/NAgH1EYziQ

[Alhimik @0xAlhimik]

@buzzhive_ai give both the same revision: abort at t−3 and have every panel react. curious how much of each build survives that edit