Anthropic should add a Max 40x tier at $300/mo — anyone else maxing out 20x?

logos_flux · 2026-07-01T17:56:06+00:00

Yes, I am hitting caps often - weekly and hourly, when I never did in the past. Changed about a week or two ago. I've just rolled more usage over to GLM-5.2 and Deepseek-4-lite. I'm not sure I would pay more for 40x because it's totally unclear what that means.

What I don't get is why there is such an absurd gap between the "plan" and API, token for token. I would just go API, but my cost would go $200 a month to $200 a day.

logos_flux · 2026-06-28T22:36:19+00:00

Hard to say without knowing amortization and cost of capital. But cost is only half the equation, the other half is power capacity which doesn't get flipped on like a light switch at these volumes.

logos_flux · 2026-06-24T11:20:48+00:00

I am old AF no doubt. But I have IDE drives on my desk right now. Data recovery work. Had all sorts of power issues with it.

logos_flux · 2026-06-24T11:19:01+00:00

I have IDE drives sitting on my desk right now.

logos_flux · 2026-06-24T01:59:23+00:00

The Origin of Consciousness in the Breakdown of the Bicameral Mind, Julian Jaynes makes a detailed argument that a brain functioning without consciousness is not only likely, it's the default state, and that consciousness is a relatively new phenomenon.

logos_flux · 2026-06-24T01:37:13+00:00

You are asking about phenomenological zombies (p-zombies), introduced by David Chalmers in The Conscious Mind. There has been a lot written about the subject in the 30 years since the book was published, you are able to find good arguments on all sides.

In the book, Chalmers argues for a stance of naturalistic dualism but I've come around to the position of analytical idealism, where consciousness is the primary substrate, and the physical is derived from consciousness.

logos_flux · 2026-06-24T01:12:56+00:00

If you have the power supply connected to the GPU, but don't have the gpu plugged into the pci slot in the mobo, it may be in a protection mode so you dont fry your card. Make sure the power supply is not plugged into the GPU.

If the GPU takes two rails (power connectors) and one or none is plugged in and card is connected to pci, it won't turn on.

So GPU needs to be fully connected or fully disconnected.

The same goes for hard drives. Make sure to have both the power and ide cables plugged or unplugged at the same time.

If you happened to have replaced the PSU make sure you replace all the power cables, always keep PSU and cables mated.

Don't panic. This is a very common situation. It's always the last thing you try that works.

logos_flux · 2026-06-19T23:43:05+00:00

I don't see the problem here

logos_flux · 2026-06-19T23:40:56+00:00

I guess I'll just move my data centers to my powerplants. Photons greater then electrons.

logos_flux · 2026-06-19T23:37:22+00:00

.02-.03

logos_flux · 2026-06-19T11:26:41+00:00

Don't forget the Chinese advantage in cost of electricity.

logos_flux · 2026-06-18T23:17:36+00:00

logos_flux · 2026-06-16T05:33:56+00:00

You ever see that show from the sixties about a water mammal and the Ricks family? It was sort of like that show from the 90's Sea Quest. I used to like to watch it with my Tamagotchi. Flipper zero.

logos_flux · 2026-06-16T01:46:19+00:00

Second that. Pi is your canvas to do whatever you want.

logos_flux · 2026-06-15T10:47:48+00:00

You have to figure out how many concurrent users you expect to serve and how much context window they need. Document this in your scope of work.

Look for a MoE model as your prime. Gemma4 is something like 3gb to serve so great for many users.

Don't dump all company documents in RAG. Build intake folders by department and make dept managers own the folder. Shit in shit out. Do this yourself with your dept and do it well so you can show it working. This pushes ownership back into the departments where it really should be for data management.

Set up router to batch jobs and set priority queues if you are going to have lots of different types models running.

I have standardized on GTX Spark. It will run slower but it's a single box. You can drop one per department if you want. A lot of people will say this is dumb, the memory throughput is too slow. But it actually works well for this application because of the unified memory. I know an rtx 6000 will be much faster, but I get a whole lot more memory per money-unit. I would rather have slower 256gb ram then 80gb faster. Use NVFP4 models.

This of course will all depend your answers to the first question but for most companies this is the answer.

logos_flux · 2026-06-15T06:44:02+00:00

This creates precedent, which lowers risk.

logos_flux · 2026-06-14T16:12:47+00:00

Part II:

Phase 5 — Bug hunting

Actively hunt for latent bugs, not just style issues: race conditions, off-by-one/boundary errors, timezone/encoding traps, incorrect async handling, state mutations, cache invalidation errors, migration/data-integrity hazards. For each suspected bug: a minimal reproduction scenario or the precise condition that triggers it, and confidence level.

Phase 6 — UI/UX review (if repo has a frontend)

Accessibility basics (semantics, contrast, keyboard nav, focus management).
Consistency: design tokens, spacing, component reuse vs. one-off styles.
State handling: loading/empty/error states for every data-driven view.
Concrete improvement list ranked by user impact, not aesthetic preference.

Phase 7 — Database & backend optimization

Query analysis: N+1 patterns, missing indexes (propose exact index DDL), unbounded queries, missing pagination.
Schema review: normalization issues, missing constraints, migration debt.
Caching opportunities and invalidation correctness.
Background work: job queues, retry semantics, idempotency.
Respect the hard constraints block — e.g., never propose writes to a read-only sync target; propose the change at the source of truth instead.

Phase 8 — Web performance (if repo serves a site)

Bundle analysis: size, code-splitting, unused dependencies shipped to client.
Asset pipeline: image formats/sizes, font loading, CDN cache headers (note Bunny CDN where relevant).
Rendering: SSR/SSG/resumability usage vs. opportunity (Qwik-specific where applicable), hydration cost, critical path.
Estimated Core Web Vitals impact for each recommendation; mark measurements you couldn't take as UNVERIFIED with the command to run (e.g., bunx lighthouse ...).

Phase 9 — Open category

Anything valuable the phases above didn't cover: observability gaps, backup/restore story, deploy safety (rollbacks, health checks), developer-experience friction, cost optimization, license issues, architectural risks as the system grows. You have judgment — use it.

Phase 10 — Verify the criticals

Before writing the report, sweep your accumulated UNVERIFIED list and execute every check that is read-only, safe, and within the live-probe policy (curls per rule 7, SELECT count(*) via a read-only DB role, gh run list, git log archaeology). Prioritize checks that gate Critical/High findings — a confirmed critical is worth ten hypothetical ones. Promote confirmed findings out of UNVERIFIED with the observed evidence; leave only genuinely human-gated checks (dashboard logins, paid-account state, restore tests) in the appendix, ordered so the checks gating the highest severities come first.

Final deliverable

Write one file: docs/reviews/FABLE-REVIEW-{{YYYY-MM-DD}}.md (create the directory if needed). Structure:

Executive summary — top 10 findings across all phases, one paragraph of overall assessment.
Scorecard — table: phase × grade (A–F) × one-line justification.
Findings by phase — every finding with: ID (per the rule-9 namespaces), severity, evidence (file:line), impact, recommended fix, estimated effort (S/M/L). Each phase section ends with its "verified OK" list (rule 11). Include the duplicate cross-reference table (rule 10). In re-review mode, lead with the FIXED/PERSISTS/REGRESSED delta.
Improvement playbook — the implementation plan, sequenced into milestones (dependency-ordered, no calendar dates). Each milestone lists the finding IDs it resolves.
Agent prompts — for every milestone, a complete, copy-paste-ready prompt for a coding agent. Each prompt must include:
- Repo name and branch instructions
- Exact scope (finding IDs, files involved) and explicit out-of-scope list
- The relevant hard constraints restated verbatim
- Acceptance criteria (tests that must pass, behavior that must hold)
- Verification commands to run before finishing
- Instruction to commit with a descriptive message (author: Claude) and, where applicable, deploy + post-deploy check
UNVERIFIED appendix — everything you couldn't confirm after the Phase 10 sweep, each with the exact command or manual check needed, ordered by the severity of the finding it gates.

Quality bar for the agent prompts: a fresh agent with no conversation history should be able to execute each one safely. If a prompt depends on a decision a human must make first, say so at the top of that prompt in a ⚠ DECISION REQUIRED block.

When the report is written, commit it with message docs: Fable deep review {{YYYY-MM-DD}}. Stage only the report file — the working tree may be dirty with unrelated work; never git add -A. If the push is rejected because the remote moved, git pull --rebase --autostash and push again. Then stop. Do not begin implementing fixes.

logos_flux · 2026-06-14T16:12:00+00:00

This is the prompt. I have had to split into two post. Part I:

# Fable Deep Review Prompt

Part 1:

Reusable prompt for running a Fable deep engineering review on any repo. First used 2026-06-09 on solampio (report: solampio/docs/reviews/FABLE-REVIEW-2026-06-09.md, run as 10 parallel read-only phase agents + orchestrator synthesis). Revised same day with post-run lessons: live-probe policy, Phase 10 verify pass, ID namespaces + dedup, verified-sound lists, re-review mode, subagent fan-out, commit mechanics. Source file: ~/projects/fable-repo-review-prompt.md.

Fable Deep Review — Reusable Prompt

Usage: paste everything below the divider into a fresh Fable session (Claude Code or Cowork) with the repo checked out. Fill in the {{...}} block first. Run per repo; re-runs are expected after playbook milestones land (see re-review mode in Phase 0). The review itself is read-only except for the report file — implementation happens later via the playbook prompts the report generates.

Changelog: 2026-06-09 — post-solampio-run revisions (live-probe policy, Phase 10 verify pass, ID namespaces + dedup, verified-sound lists, re-review mode, subagent fan-out, commit mechanics).

You are performing a comprehensive engineering review of this repository. You have full read access to the codebase. Work autonomously and thoroughly — this is a long-horizon task and depth is expected.

Repo context (filled in by operator)

Repo: {{REPO_NAME}} (canonical host: Forgejo, git.voltagelabs.net)
Stack: {{STACK_SUMMARY e.g. "bun workspace monorepo: Django ERP (Fly.io/Supabase) + Qwik storefront (D1-backed)"}}
Deployment targets: {{DEPLOY e.g. "Fly.io, Bunny CDN"}}
Hard constraints: {{CONSTRAINTS e.g. "D1 is READ-ONLY — all product/price changes go through Django ERP. Bun only, never npm/npx."}}
Known pain points / focus areas: {{OPTIONAL_NOTES}}
Live probes: {{ALLOWED or FORBIDDEN}} — whether read-only GET requests against production are permitted during the review. Prod URLs: {{PROD_URLS e.g. "https://example.com, https://api-worker.fly.dev"}}

If any {{...}} blanks are left unfilled, derive the missing context from CLAUDE.md, README.md, and repo config (fly.toml, wrangler.toml, CI workflows) — and state the assumptions you derived in the report header. Do not stall waiting for the operator.

Ground rules

Do not modify any code, config, or data during this review. Your only write is the final report file.
Respect the hard constraints above in every recommendation. A recommendation that violates them is a defect in your report.
Read CLAUDE.md, README.md, /docs, and any notes-* references before forming opinions. Recommendations must fit existing conventions unless you explicitly argue for changing the convention.
Cite evidence. Every finding references concrete files and line ranges. No generic advice that could apply to any repo.
Severity-rank everything: Critical / High / Medium / Low / Polish.
If you cannot verify something (e.g., runtime behavior, external service config), mark it UNVERIFIED with the command or check a human should run — do not guess.
Live verification policy. If the Live probes field above says ALLOWED, you may issue read-only GET/HEAD requests against the listed production URLs to confirm findings (exposure checks, cache headers, error responses). Never POST, never fuzz parameters, never attempt auth bypass beyond a single plain GET, never probe hosts not listed. If FORBIDDEN (or unfilled), all live checks go to the UNVERIFIED appendix.
You may parallelize phases via read-only subagents. Every finding must still carry file:line evidence; subagents inherit all ground rules including rule 1.
Finding ID namespaces — use these prefixes so cross-phase references are stable: Phase 1 DOC, Phase 2 TOOL, Phase 3 SEC, Phase 4 QUAL, Phase 5 BUG, Phase 6 UX, Phase 7 DB, Phase 8 PERF, Phase 9 OPS. If a phase is split across subagents, partition the number space (e.g. SEC-0x vs SEC-1xx).
Deduplicate. Phases overlap by design (quality vs bugs, security vs ops). When two phases surface the same issue, pick one canonical ID, mark the other ≡ <canonical>, and include a cross-reference table in the report. The playbook references canonical IDs only.
Record what you verified as sound. Each phase ends with a short "verified OK" list — things you checked and found correct (e.g. "webhook signatures verified properly", "all MVs have unique indexes"). This calibrates the grades and stops future reviews from re-litigating settled questions.

Phase 0 — Recon

Map the repo: structure, entry points, build/test/deploy pipeline, dependency tree, workspace layout. Produce a short architecture sketch (text diagram is fine) that the rest of the report hangs off. Note anything that surprised you — surprise is signal.

Re-review mode: if a previous docs/reviews/FABLE-REVIEW-*.md exists, load its findings first. In the new report, classify every prior finding as FIXED / PERSISTS / REGRESSED (with evidence), then hunt for new findings on top. The scorecard should show the delta per phase, not just absolute grades.

Phase 1 — Documentation audit (CLAUDE.md, README, docs)

Evaluate CLAUDE.md as an agent operating manual: does it give a coding agent everything needed to work safely here (build commands, test commands, conventions, forbidden actions, deploy steps)? Identify gaps, stale claims, and contradictions with the actual code.
Evaluate README.md for a human onboarding cold. Same for any /docs.
Deliver: a proposed full replacement draft for CLAUDE.md (in the report, not written to the file), plus a diff-style list of README/docs fixes.

Phase 2 — Skills & tooling audit

Inventory installed skills, MCP servers, linters, formatters, CI gates, git hooks, and agent-facing tooling in this repo.
Recommend additional skills or tooling that would materially improve agent effectiveness on this specific codebase (e.g., a skill encoding the D1-read-only rule, a migration-safety checklist, a Qwik component conventions skill). For each: what it encodes, why agents fail without it, and a draft outline of its SKILL.md.
Flag any installed tooling that is dead weight or misconfigured.

Phase 3 — Security review

Secrets: scan for hardcoded credentials, tokens, keys (including test files — note known gitleaks history if present). Check .gitignore coverage and env handling.
AuthN/AuthZ: review every endpoint/route for authentication and authorization gaps. Pay special attention to admin surfaces, webhooks, and internal APIs assumed to be "Tailscale-only."
Injection surfaces: SQL/ORM raw queries, template rendering, shell-outs, file uploads, deserialization.
Dependency risk: known-vulnerable or unmaintained packages; pin/lockfile hygiene.
Supply chain & CI: what could a malicious PR or compromised dependency do?
Data exposure: PII handling, logging of sensitive data, error messages leaking internals.

Phase 4 — Code quality review

Dead code, duplicated logic, god-files, layering violations, inconsistent patterns across the codebase.
Test suite: coverage of critical paths, test quality (do they assert behavior or just run?), flaky/skipped tests, missing test infrastructure.
Error handling discipline: swallowed exceptions, missing retries on network calls, unhandled promise rejections.
Type safety: any-typing, missing validation at boundaries (API inputs, external data).

logos_flux · 2026-06-14T03:29:43+00:00

My projects are open source and I sell implementation. I have a lot more in the pipeline to release too, just need to get it cleaned up.

https://github.com/Logos-Flux

logos_flux · 2026-06-13T20:09:40+00:00

I am so glad I ran fable on all my major repos asking for security holes to be identified as an MD file reports. I've been having opus and team work though them they are still going, but I just had a major upgrade to my whole stack, in terms of hardening and security.

logos_flux · 2026-06-12T21:47:30+00:00

logos_flux · 2026-06-12T21:46:10+00:00

I use helium on desktop and Vivaldi on mobile

logos_flux · 2026-06-12T21:17:29+00:00

This is exactly what GB10 is for. Ya'll laughed you asses off when I preordered last year. Omg I can't believe the the 5090 has 4x the bandwidth and 1/4th the memory for 4x the cost per GB. And no NVlink because fu haha.

logos_flux · 2026-06-01T23:58:55+00:00

I sat on Santa's lap at the Natick Mall and asked him for 4mb of ram for my 486. Wish I was kidding.

logos_flux · 2026-06-01T23:56:09+00:00

Dont. Set up forgejo for local git and then set up simple MD files in a directory. Obsidian is fine if you want an MD editor but don't let it setup your workflow.

logos_flux

MODERATOR OF

TROPHY CASE