Your Daily AI Stew from Robin, on Salty Talk.
The Anthropic Claude Code settings files leak thousands of secrets to public repos; Meta AI ships Muse Ember 1.0 priced for agents; Robbyant opens its tactile pretraining model LingBot-Touch.
Security firm Apiiro finds thousands of secrets committed to GitHub inside Claude Code settings files
This one is about security, and the problem lives in a file we touch every day.
AI security firm Apiiro discovered thousands of secrets in public GitHub repositories — database passwords, API tokens, and root login credentials — all hidden inside committed Claude Code settings files.
The root cause is how Claude Code authorizes commands it runs automatically. When a user picks "Yes, and don't ask again" on an authorization prompt, that choice gets written as a rule into the local .claude/settings.local.json file. Sometimes the rule is a wildcard pattern, but more often the command itself is written verbatim into that settings file — and any sensitive information embedded in the command lands on disk along with it.
If the file never leaves the developer's machine, it is not much of a security problem, provided that machine is not compromised. Anthropic's Claude Code documentation also notes that the file is automatically added to the developer's global .gitignore list, so it usually never gets shared publicly.
The part worth hearing is not the novelty but that automatic protection can be bypassed: the docs explicitly say local config is auto-added to the ignore list, yet secrets are still searchable in public repositories — proof that "the tool does the right thing by default" does not cover every case, especially after a human clicks "don't ask again" to save time. What deserves real attention is whether these authorization records will be sanitized before they hit disk, and whether agent tools will start inspecting the command itself. The practical lesson from this incident: once credentials have entered a commit history, treat them as never having been revoked.
Anthropic releases Claude Fable 5.2 and Mythos 5.2; 1,000 agents formalize Fermat's Last Theorem in 30 hours
Next up is a model vendor, and the topic is hardcore — listen for what it did for research workloads.
Anthropic released Claude Fable 5.2 and Mythos 5.2. Fable 5.2 is positioned as a multi-agent system for complex research tasks: it can dispatch large numbers of agents that divide the work, coordinate autonomously, and push formal proofs forward. The release materials say 1,000 Fable 5.2 agents formalized Fermat's Last Theorem in roughly 30 hours with minimal human intervention; starting from the most minimal prompts, the agents built their own collaboration style, consulted no mathematical references, and used only a set of intermediate theorem statements as their scoring basis. As a comparison, the unreleased research version mentioned in the commentary required a dedicated runtime framework and a human researcher at the side, taking 11 days end to end.
Fermat's Last Theorem states that for any integer n greater than 2, there are no positive integers x, y, z satisfying x^n + y^n = z^n. Formalization is not writing a natural-language argument — it is rewriting a proof into a machine-checkable, verifiable object. Anthropic had done this once before with an unreleased research Claude, taking 11 days; this time 1,000 agents organized their own collaboration, which stress-tests model reasoning, multi-agent orchestration, and formal verification all at once.
On availability, Fable 5.2 is already obtainable through Claude Platform and Amazon Bedrock, while Mythos 5.2 is open only to Anthropic-vetted cybersecurity and life-science directions — so the former has a wider usable surface for technical tasks, while the latter remains access-gated.
Community verdict: Fable 5.2 is already strong, but on ordinary tasks it is often hard to distinguish from Opus 5.5 — you only see the difference once the task goals and complexity are pushed up. Others noted that using Opus 5.5 for development on a roughly 125k-line project felt good, and questioned whether Fable and Mythos correspond to workflows with real demand. Some also suspect 5.5 may have been weakened by the new release, and question the benchmarks in the announcement — the anomalous effort-intel curve on Carbon, the lack of a horizontal comparison on a single cybersecurity benchmark, and Robodojo's comparison being swapped to Argon instead of Carbon.
For teams doing research-grade work, the weight of this item is that it pushes multi-agent from orchestration demos onto tasks with explicit acceptance criteria, and formal verification is exactly the kind of work where a mistake gets caught by the machine on the spot. That is also why this demonstration reads more like a stress test than a product promise: whether the same collaboration quality reproduces on other research tasks decides whether it is a dependable capability. And Mythos being gated to verified directions shows Anthropic still keeps an admission threshold on this class of capability.
Meta AI releases Muse Ember 1.0: up to 1M input tokens, built for agentic tasks
Next is a model launch priced aggressively low, positioned for everyday tasks.
On November 10, 2026, Meta AI launched Muse Ember 1.0. Meta calls it its smallest and most efficient model, aimed mainly at the tool calls, coding subtasks, routing, extraction, and long-document parsing that agents run repeatedly; the independent verification in the materials remains limited so far.
On pricing, Ember supports up to 1M input tokens. For prompts up to 200k tokens, input, cached input, and output cost $0.10, $0.004, and $0.50 per million tokens respectively; above 200k, those three rise to $0.30, $0.012, and $1.50.
For comparison, in their respective short-prompt bands Ember's input and output unit prices match GPT-6 Luna and Claude Haiku 5.5 exactly — $0.10 and $0.50 per million tokens — while Claude Fable 5.2 charges $8 and $40. The long-prompt surcharge thresholds are 200k, 272k, and 100k tokens respectively; GPT-6 Luna and Claude Haiku 5.5 charge $0.20/$0.75 and $0.50/$2.50 for long-prompt input and output.
Ember offers six reasoning-effort levels from minimal to max. A chart from Artificial Analysis cited by Simon Willison shows xhigh and max modes costing about $0.12 and $0.14 per task, with Intelligence Index scores around 34 and 36, on the Pareto frontier; but that is one specific benchmark's result, and in one SVG generation attempt the high tier failed to return a complete figure, with no clear mapping between reasoning tier and visual quality.
Put together, these numbers let agent developers cost short-prompt and long-document work separately; but the existing evidence covers only the official positioning, one benchmark chart, and one SVG observation — not enough to claim it is genuinely cheaper in real workloads.
For people building agentic applications this is the most practical item: vendors have started pricing per task, and reasoning effort has become a knob you can turn directly, so developers can trade cost against quality themselves. What to watch is its performance on your own workloads — the public evidence is thin, and whether the savings on the price list actually land in the business depends on third-party measurements and real bills. Also worth watching is whether this pricing structure gets copied; if per-task pricing becomes the norm, the logic of model selection changes with it.
GitHub project describes a specific path for consumer Gemini sending email and Drive content to human review — unconfirmed by Google
Next is a community investigation; the mechanism is still unverified, so listen carefully to the boundaries.
An open-source GitHub project, thisisme6598/gemini_files, claims that consumer Google Gemini, once Connected Apps are enabled and Gmail or Google Drive authorized, may send email and file content to human annotators for review.
One key qualification in the discussion: the claim targets consumer Gemini. The Workspace official guidance cited in the comments says Workspace Gemini and the enterprise-facing Workspace Intelligence are not subject to human review.
If the allegation holds, personal data users hand over for personalization features could enter a human-access flow, giving concrete grounding to concerns about consent scope, privacy disclosure, and data governance. Google has not officially confirmed this specific path: the official help center only states that Connected Apps data may receive human review in limited circumstances and lists that scope; what this project adds is the specific trigger path and frequency, and those reproduction details remain officially unconfirmed, so it should be read as a community investigation.
Human annotation normally means staff reviewing model interactions or tool-call data to evaluate safety and quality; the project claims that email bodies and cloud file contents read through Connected Apps may also enter that review flow. Google's official help documentation does state that Connected Apps data can be human-reviewed and gives the scope of reviewed data; what has no official account is the backend fetch path, the four-state flow, and the trigger frequency described by the project.
Commenters also warn against extrapolating from consumer to enterprise products: Workspace Gemini and Workspace Intelligence still claim their data is not human-reviewed, and several participants are unhappy with how consumer Gemini touches email and files after user authorization. One person mentioned a Gemini reply that fit a specific nudge email suspiciously well; others worry annotated data could be used for training or leak — but those anecdotes and speculations cannot independently verify the core allegation.
What really deserves to be heard here is the boundary: consumer and enterprise products explain data flows inconsistently, and the official docs are explicit on both — consumer may be human-reviewed, enterprise claims it is not; what remains unclear is the specific path this project describes. The material at hand is one community reproduction record; the test procedure and trigger frequency are not public, and Google has made no public response to the specific allegations. So this cannot be treated as confirmed, and it should not be waved away either. Worth following: whether more complete reproduction material appears, and whether the official documentation gets rewritten as a result.
Robbyant open-sources LingBot-Touch tactile pretraining: 49.3% recall at 4K hours of data
Next leans research — teaching robots to learn from touch signals.
Robbyant published a paper and released LingBot-Touch inference code and model checkpoints. The model uses JEPA-style self-supervised learning, predicting latent representations of occluded contact regions rather than reconstructing raw sensor signals, and compares against MAE and VAE baselines of similar scale on the same data.
For touch-to-video Top-5 recall, at 1K hours the three methods score 32.1%, 5.6%, and 4.4% respectively; scaled to 4K hours, JEPA rises to 49.3% while MAE stays below 9% and VAE drops to 3.1%. The paper explains that sparse tactile segments are mostly near-zero signals, so reconstruction loss can keep falling before any useful contact information is learned; and to keep a high mask rate from hiding every contact pixel early in training and exploding the gradients, the mask rate warms up from 40% to 80% over 300 steps.
The encoder normalizes fingertip coordinates to handle magnetic, piezoresistive, and visuotactile sensors uniformly through a shared Transformer, with a 5D RoPE covering time, finger, and 3D position. Across 26 real robot tasks and 104 combinations over 4 policies, frozen features take the top score in 89 cases; when transferring to a magnetic hand unseen during pretraining, LingBot-VLA's score rises from 57.21 to 75.04. The Tiny model saturates around 4K hours while Small keeps improving — bigger models with more data are the natural next step. These conclusions are still limited to the benchmarks reported in this one paper.
What makes this interesting is that it questions a default assumption: sparse, near-zero signals may not suit reconstruction-style learning. Predicting latent representations of the occluded part swaps "reproduce the sensor reading" for "infer what the contact did" — the semantics robots actually need. For teams working with embodied data, this is worth more than one more benchmark score; but the conclusions remain locked to this one study's benchmarks, and whether it reproduces on other sensors awaits more teams' measurements.
Reddit hands-on: Qwen3.8 27B with 8-bit KV cache saves roughly 2 GiB at 64k context
We close with a community measurement about VRAM when running models locally.
This is a self-reported test posted on Reddit. The author took 35 weight-quantized variants of Qwen3.8 27B across llama.cpp, ExLlamaV3, and vLLM, testing KV caches at 16-bit, 8-bit, and — where supported — 4-bit, with prompts mixing agent tool calls and multiple domains up to 64k tokens.
Against a bf16 baseline, the 8-bit cache compresses per-token cache usage from 64 KiB to 32–34 KiB, saving roughly 2 GiB at 64k context. The distribution shift is tiny: llama.cpp's q8_0 and ExLlamaV3's 8-bit both move KL divergence by less than 0.00012, and vLLM's FP8 adds 0.0004 to 0.0006.
The 4-bit cache shows clearly larger drift: llama.cpp's q4_0 typically adds 0.0016 to 0.0027, ExLlamaV3's penalty varies with weight precision, and the 4-bit penalty grows another 15% to 30% from the first 4k tokens into the 16–32k band. vLLM's NVFP4 and FP8 checkpoints improved after switching to Marlin with bf16 activations, but even then they only match the smaller UD-Q5_K_XL quant.
The author's advice: use the 8-bit KV cache when VRAM is tight, avoid 4-bit where possible, and steer clear of it for long contexts especially; but these conclusions come from one author's methods and one model, so treat them as a reference.
A few terms: the KV cache stores the key and value tensors of previous tokens — attention relies on it to reuse computation, and lowering its precision saves VRAM at the cost of error, which gets worse in long contexts; KL divergence measures how far the post-quantization next-token distribution drifts from the bf16 baseline, and the author used paired prompts on identical tokens to separate cache changes from weight quantization. Two unquantized engines already differ by 0.0004 KL on their own, which he treats as the cross-engine noise reference line.
The value of this item is that it gives you a ruler to reconcile against: most people's real question is not whether you can save VRAM but whether the saved gigabytes are worth betting output distribution on. This test lays out the gap between the two tiers, and adds one reminder — it covers one model and one author's methods, so don't treat it as a universal conclusion. For local deployments, the practical reading is: try 8-bit first, then check your own workload, rather than copying parameters blindly.
Taken together, these six items split two-and-four: security and privacy on one side, capability and cost on the other — agents assembling their own teams, small models compressed for mass serving, robots learning from touch, and VRAM squeezed further. Beyond the excitement, whether developers can actually rely on any of it still comes down to these unglamorous engineering details.
🎧 This episode is also available as a podcast: listen to Daily AI Stew · 2026-11-10.
