You can already put op:// references in .env and read them with `op run`.
1P will conceal the value if asked to print to output.
I combine this with a 1P service account that only has access to a vault that contains my development secrets. Prod secrets are inaccessible. Reading dev secrets doesn't require my fingerprint; prod secrets does, so that'd be a red flag if it ever happened.
In the 1P web console I've removed 'read' access from my own account to the vault that contains my prod keys. So they're not even on this laptop. (I can still 'manage' which allows me to re-add 'read' access, as required. From the web console, not the local app.)
I'm sure it isn't technically 'perfect' but I feel it'd have to be a sophisticated, dedicated attack that managed to exfiltrate my prod keys.
AI data centers are a whole lot of pipelines pumping data around utilizing queues. They want those expensive power hungry cards near 100% utilized at all times. So they have a queue of jobs on each system ready to run, feeding into the GPU memory as fast as completed jobs are read out of memory (and passed into the next stage) and they aim to have enough backlog in these queues to keep the pipeline full. You see responses in seconds but at the data center you're request was broken into jobs, passed around into queues, processed in an orderly manner and pieced back together.
With fast mode you're literally skipping the queue. An outcome of all of this is that for the rest of us the responses will become slower the more people use this 'fast' option.
I do suspect they'll also soon have a slow option for those that have Claude doing things overnight with no real care for latency of the responses. The ultimate goal is pipelines of data hitting 100% hardware utilization at all times.
Hmm not sure I agree with you there entirely. You're right there's queues to ensure that you max out the hardware with concurrent batches to _start_ inference, but I doubt you'd want to split up the same job into multiple bits and move them around servers if you could at all avoid it.
It requires a lot of bandwidth to do that and even at 400gbit/sec it would take a good second to move even a smaller KV cache between racks even in the same DC.
If you are looking for proactive filtering, you could leverage the Bluesky moderation labeler, I'm not aware of one focused on EU requirements though. If you are looking for reactive filtering, you may create a small labeler just for you where you can flag just the troublesome posts and then you filter them before the comment page is rendered.
This is amazing! I have no CAD experience and so I tried creating my own bespoke version of LAD a while ago by crawling the SolidWorks docs into a very LLM-optimized format [1] and then asking Claude Code to write C# code using the SolidWorks SDK. Even with docs, it still struggled: functions that fail quietly, extremely verbose code and with no easy way to run tests to ensure that the results are accurate. As an example, here's the 400 lines of code it produced for an eccentric cam [2]. Attempts to close the loop by feeding CC png renders in multiple views had absolutely horrible results. Claude could not differentiate up from down, features etc. I'll try LAD tomorrow, fingers crossed it work better.
CodjiFlo[1,2] - a code review tool inspired by Microsoft's CodeFlow, used by ~40,000 developers. It is especially tailored to power users of pull requests to improve contextual understanding and ease of code review and collaboration.
Thanks for checking it out. It should be possible in the future, I haven't explored what GitHub APIs are available for logged out users. It's not my main focus now because I want to nail the capabilities for repo contributors, who do code reviews most often and will need be authenticated to post comments.
This post resonates a lot with me. I've been experimenting with Claude Code to write code that interacts with the SolidWorks SDK. It is both extremely complex (method calls with 15+ bools, doubles, strings; abbreviated parameters; etc) and obscure. It has been like pulling teeth. Claude would hallucinate methods, parameters etc.
I tried using Context7 MCP with the SolidWorks docs but the results were not satisfactory. I ended up crawling SW's documentation in HTML, painstakingly translating it to markdown and organizing it to optimize greppability [1]. I then created a Claude skill to instruct CC to consult the docs before writing code [2]. It is still stubborn and sometimes does not obey my instructions but it did improve the quality of the code. Claude would need 5 to 10 rounds of debugging before getting code to compile. Now it gets it in 1 to 2 rounds.
I've been using zoo and its KCL language with some success for boundary-representation CAD writing. If I understood correctly, µcad serves the same purpose. Comparing code samples between both of them, I personally enjoy KCL's pipelined approach more.
My main beef with zoo is the fact that they are promoting vendor lock-in by forcing users to use their cloud-hosted geometry kernel with absolutely no local alternative. It's not clear to me how µcad solves this problem.
Hm, at least build123d (which I had never heard of, thanks!) can export STEP, which I believe is becoming a necessity if one wants to assemble real-world models with FreeCAD (and nicely also slicers are picking up support to it). I'm on the edge though if I'd really like a proper DSL instead of building it on top of Python, although I can see that too has its benefits (e.g. library access).
Does anyone have idea about the STEP export support status for KCL/µcad? To me it looks like KCL cannot, and I cannot find information on it about µcad. The one tool I'm familiar within this space is OpenSCAD and it cannot. While FreeCAD is able to (sometimes?) convert from STL to STEP, it seems actually working with such models in FreeCAD is quite compute-inefficient.
Converting from STL to STEP is essentially always a case-by-case thing.
If you import, sew, check geometry, refine, etc., you can eliminate unnecessary triangles in planar faces. But you can't magically make a 120-sided-polygon that should be a circle a circle; you're going to have to do that yourself.
And FreeCAD is not the best tool for correcting broken meshes, which are commonplace. MeshLab and the vaguely-on-life-support AutoCAD MeshMixer are better at it.
STEP/IGES is as you say more or less essential if you want to work with code-CAD output in any other serious context. STL is not enough: it is like converting to JPEG in the middle of a photo editing flow, not at the end. It destroys information — in this case geometry.
Yeah I hate messing with STLs for that reason. It's an output format. Similar to when you make an image in Photoshop with a load of layers and then export to jpeg where it's flattened and all the layer info is lost.
Obj is a bit better but for real design modification you kinda need the original file and the program it was designed in. At least in my experience.
I've never come across STEP though, is that a real design parameter preserving file format?
STEP doesn't preserve all of your design intent (sketches etc.) but it does preserve the geometry (edges, vertexes, faces). So it is a lot easier to work with it because it is lossless and precise. Curves are curves, not quantised/faceted.
So in our image processing analogy, it is still in a sense a "flattened" representation of the layers, but it's a vector format. The best way to think of it is broadly like a 3D SVG, I guess.
3D printer slicers (except maybe Cura without a paid add-on) can usually load STEP now, but they are still internally meshing before slicing. I think Orca/Bambu/PrusaSlicer all give you some control over that meshing (they all use OpenCascade to do it, in fact).
In FreeCAD you can do things like defeaturing, so if you have a hole in a rounded plate, you can delete the hole, you can delete corner-rounding. You can also break STEP files down to faces and use the surface/curves tool to work on them, or use them as a BaseFeature for a Part Design Body, etc.
This is a pretty useful video for showing the differences:
If you're talking about CAD in general I can see your point.
For FreeCAD specifically, there looks to be an OpenSCAD import process directly. I don't have experience with how it works, but that may be better than going through STL
I know the process is there, but I really, really doubt it does anything else than just uses OpenSCAD code to render the mesh, as FreeCAD can also deal with meshes. I think it would be pretty unlikely that the FreeCAD devs would have implemented such a rendering system based on OpenSCAD.
From my quick tests, it seems to rebuild the OpenSCAD objects using FreeCAD part workbench primitives.
But I also quite quickly found examples that don't work. I don't know if that's the import not being very good, me finding weird examples, needing to install more libraries, or PEBKAC.
[1]: https://www.npmjs.com/package/claude-code-types